容量計画での複数のサーバーの役割の構成について

  • [アーティクル]

 

適用先: Exchange Server 2010 SP2, Exchange Server 2010 SP3

トピックの最終更新日: 2016-11-28

サーバー ハードウェアのいくつかの傾向が Microsoft Exchange Server 2010 の期間に適用されます。 1 つの傾向は、プロセッサのパフォーマンスの大幅な向上、および物理プロセッサでサポートされるプロセッサ コア数の増大です。 これは、マルチコア プロセッサを搭載した標準の商品サーバーに 1 つの Exchange サーバーの役割を展開した場合、使用可能な CPU の大部分が十分に活用されないことを意味します。 ユーザーの中には、サーバーの仮想化によってサーバーの CPU リソースをより効率的に活用できると期待するユーザーもいます。 同じ物理サーバー上の Exchange サーバーの役割を結合したいというユーザーもいます。 どちらも有効なソリューションです。

もう 1 つの傾向は、マルチコア プロセッサと 10 ～ 16 個の内部ディスクを搭載したサーバー モデルの可用性です。 10 ～ 16 個のディスクによって提供される、1 秒あたりの入出力トランザクション数 (IOPS) でサポートできるメールボックスの数を考慮した場合、メールボックス サーバーの役割単独では、使用可能な CPU リソースの半分以上も活用できません。 このサーバーにクライアント アクセス サーバーの役割とハブ トランスポート サーバーの役割を追加すると、サーバーの処理能力をより効率的に活用できます。

このトピックの情報は、複数の役割のサーバー構成をどのような場合に展開するのか、および複数の役割のサーバー構成をどのように正しく構成するのかのガイダンスとして使用できます。 例として複数の役割のサーバーの処理能力決定プロセスを示します。

目次

複数の役割の構成が推奨される理由

複数の役割の構成が推奨される場合

複数の役割の構成が推奨されない場合

複数のサーバーの役割でのハードウェアの推奨事項

DAG での複数の役割のサーバーの展開

Exchange 2010 の複数の役割のシナリオの処理能力決定の例

複数の役割の構成が推奨される理由

まず最も重要なことは、今日調達できるハードウェアには、ベースライン プロセッサ構成と比較して、5,000 ～ 6,000 メガサイクルというように非常に高速なプロセッサが搭載されていることです。 その構成は、2 x 4 コアの Intel Xeon x5470 3.33 GHz プロセッサから構成されます。 (ベースライン プロセッサ構成の詳細については、「メールボックス サーバーのプロセッサ容量計画」のセクション「メールボックス サーバーの処理能力計画の例」を参照してください。) 使用する環境のプロセッサ アーキテクチャだけを現在市場で調達できるプロセッサと交換し、その他すべての環境要因は変更しない場合、プロセッサの使用率が大きく低下することがあります。

購入するサーバーの総保有コストを効果的に下げるには、システムを効率的に使用する必要があります。つまり、ピーク時負荷で最悪の障害モード発生中でも、システムが到達する CPU 使用率が約 80% を維持するようにします。現在入手可能なプロセッサを効率的に利用できるようにする 4 つの方法を以下に示します。

  • さらにアクティブなメールボックスをサーバーごとに展開することによって、負荷を増やします。

  • ゲスト マシンを追加するとともに、仮想化層を導入してメールボックスの役割をゲスト マシンとして展開します。

  • Exchange サーバーの役割をシステムに追加展開します。

  • 上記の方法論を組み合わせて使用し、ハードウェアを最大限効率的に使用する最適な構成を探してください。

複数の役割のアーキテクチャで Exchange 2010 を展開することには、いくつかの利点があります。

  • 複数の役割のアーキテクチャは、ビルディング ブロック ベースのアーキテクチャになります。 複数の役割のアーキテクチャを使用すると、Exchange 環境のすべてのサーバー (ユニファイド メッセージングとエッジ トランスポートを除く) は、同じハードウェア、同じ構成というようにまったく同一になります。 このように統一されることによって、ハードウェアの注文が簡素化されるだけではなく、サーバーの保守と管理も容易になります。   

    • コストの点から見た全体的な目標とは、アーキテクチャが CPU とディスクの両方の観点から釣り合っていることを確認することです。 個々のマシンにサーバーの役割を展開すると、実際に使用するより多くの CPU、ディスク、メモリ リソースを購入することにつながり、長期的にはコスト面で不利になることがあります。 たとえば、クライアント アクセス サーバーの役割のみをホストするサーバーがあるとします。 多くのサーバーでは、特定数のディスクであれば非常に経済的な方法で追加できます。特定数のディスクを展開し、それにとどまらず活用すると、コストは本質的にゼロになります。 しかし、使用するディスクが特定数より少ないサーバーの役割を展開すると、あまり使用されないかまったく使用されないディスク コントローラーの代価を払うことになります。

  • 多くの場合は、複数の役割のアーキテクチャを使用すると、環境の物理 Exchange サーバーを減らすことができます。物理サーバーが少ないということは、さまざまな理由でコストが削減されるということです。

    • 運用経費は、設備投資額を上回る場合がほとんどです。 サーバーを使用期間中に管理するコストは、サーバーを購入するコストより高くなります。

    • 購入する Exchange サーバー ライセンスが少なくなります。 複数の役割のサーバーでは、1 つの Exchange サーバーと 1 つのオペレーティング システムのライセンスしか必要になりませんが、役割を分割すると、複数の Exchange サーバー ライセンスが必要となり、さらにオペレーティング システム ライセンスも複数必要になる可能性があります。詳細については、「ライセンスについて:仮想環境に対するライセンス」 を参照してください。

    • 展開するサーバーを少なくすると、その効果は残りのインフラストラクチャにも徐々に広まります。 たとえば、展開する物理サーバーを減らすと、Exchange インフラストラクチャに必要となるラック スペースと床面積の合計が縮小され、それによって電力コストと冷却コストも削減される可能性があります。

  • 複数の役割のアーキテクチャでは、すべてのメールボックス サーバーがハブ トランスポート サーバーとクライアント アクセス サーバーにもなるので、最終的には単一の役割のサーバーよりも多くのサーバーに負荷が分散されます。このアーキテクチャには次の 2 つの利点があります。

    • スケーラビリティの面から見ると、負荷をより多くの物理マシンに分散することになります。 障害の発生中、残りのサーバーの負荷は徐々にしか増加しないため、サーバーが実行しているその他の機能は悪影響を受けません。

    • 復元という観点から見れば、ソリューションはハブ トランスポートとクライアント アクセスの役割 (またはサービス) のエラー数に対してより高い耐性を保ちつつ、サービスを提供できます。

この理由から、Exchange 2010 に推奨する展開戦略は、多くのシナリオで複数の役割のサーバー構成となります。

複数の役割の構成が推奨される場合

複数の役割の構成は、次の理由でほとんどのシナリオに推奨されています。

  • 単純なスケール単位   メールボックス数の定期的な増加が見込まれる組織では、複数の役割のサーバーの展開を検討する必要があります。 複数の役割のサーバーはそれぞれ 1 つの構成要素を表すため、このモデルでは、簡単に構成要素を追加して増大する処理能力の必要性をサポートできます。

  • 最新のプロセッサを活用したいと考える大規模な展開   Exchange 2010 の RTM (release-to-manufacturing) 前に実行されたスケーラビリティ テストに基づいて、複数の役割サーバーは単一のサーバー上でヘックス コア (以上) を効率的に使用できます。 この機能によって、大規模な組織は、少ないプロセッサ コアを搭載したサーバー上に個々にこれらの役割を展開するのではなく、メールボックス、ハブ トランス ポート、クライアント アクセスの各サーバーの役割を組み合わせることで、サーバーの数を削減できます。 このアプローチでは、前述の単純な構成要素モデルを活用して大規模な展開にプラットフォームを提供し、必要なサーバー総数を削減します。 複数の役割構成の規模の大きなコア カウント システムでのスケーラビリティは、運用環境での展開前に、評価機関によって検証する必要があります。

  • 内部ストレージを搭載したサーバーの展開   今日利用可能な多くのサーバーには、2 つの物理マルチコア プロセッサおよび 10 ～ 16 個の内部ディスクが搭載されています。 Exchange 2010 のいくつかの強化機能によって I/O 要件が削減されるため、これらのサーバーは費用対効果の高いソリューションになっています。 ユーザー プロファイルとディスクの種類に応じて、これらのサーバーでは、通常、最大 4,000 個のメールボックスをサポートできます。 これらのサーバーにクライアント アクセス サーバーの役割とハブ トランスポート サーバーの役割を追加し、追加の CPU を活用して、これらのサーバーを自己完結した構成要素にすることをお勧めします。

  • メールボックス サーバー上でホストされているメールボックス数が制限されている場合のリスク軽減シナリオ   複数の役割のサーバーは、リスク管理ポリシーによってメールボックス サーバーに展開できるメールボックス数が制限されている展開のソリューションになります。 たとえば、10,000 個のメールボックスがある組織で、1 つのサーバーが停止しても環境内の 25% 超のメールボックスに影響を与えてはならないというポリシーがあるとします。 この要件により、メールボックス サーバーあたりのメールボックス数は 2,500 に制限されます。このサーバーにクライアント アクセス サーバーの役割とハブ トランスポート サーバーの役割を追加すると、このサーバーに追加された処理能力を活用できます。

  • 小規模な組織と支社の展開   管理する物理サーバー、オペレーティング システム インスタンス、Exchange サーバーの数を最小限にすることが主な目標である場合の展開には、複数の役割の展開が推奨ソリューションになります。ただし、Windows ネットワーク負荷分散を使用するときは次のような例外があります。同じ物理サーバー上でクライアント アクセス サーバーの役割、ハブ トランスポート サーバーの役割、およびメールボックス サーバーの役割を実行すると、2 台または 3 台の物理サーバーといった最小の要件で必要な役割の冗長性が得られます。

複数の役割の構成が推奨される理由

複数の役割の構成が推奨されない場合

複数の役割の構成は、次のシナリオで推奨されません。

  • Windows ネットワーク負荷分散 (NLB) を使用する小規模な組織または支社の展開   データベース可用性グループ (DAG) のメンバーとして 2 台または 3 台の複数の役割のサーバーを展開する小規模な展開では、複数の役割のサーバーが十分機能しない場合があります。 DAG の詳細については、「データベース可用性グループの管理」を参照してください。 DAG のメンバーであるメールボックス サーバーに追加されたクラスタリング コンポーネントによって、NLB をサーバーにインストールできません。 負荷分散の推奨事項の詳細については、「Exchange 2010 の負荷分散について」を参照してください。 ただし、クライアント アクセス サーバーへの受信トラフィックを負荷分散するという要件は依然残っています。 この場合、主に次のような 2 つのオプションがあります。

    • ハードウェア負荷分散アプライアンスを購入します。 いくつかの基本レベルの NLB アプライアンスはありますが、このオプションは、特に小規模な環境ではコストが高くなる可能性があります。

    • Exchange サーバーの役割を仮想化します。 一部の環境では、サーバーの数を制限すると、ドメイン コントローラー、ファイル サーバーとプリント サーバー、その他のアプリケーションを Exchange 2010 サーバーと同じ物理ハードウェアで展開することになります。 この場合、物理サーバーをホスト サーバーとして実装し、仮想環境内のアプリケーションを分離することをお勧めします。この分離では、仮想マシンで実行中のクライアント アクセス サーバーに対して NLB を実行できます。

  • 仮想化   仮想マシンでホストできるアクティブなメールボックスの最大数は、メッセージ プロファイルおよび複数の役割の構成における実行の組み合わせに基づいて減らせる可能性があります。 メッセージング ユーザーが少ない場合は、仮想マシンにサーバーの役割を共存させることが合理的になることがあります。 ただし、メッセージング ユーザーが多い場合は、仮想マシンでリソースが制限されることがあるので、メールボックス仮想マシンごとにメールボックスの数を減らすか、別の仮想マシンに役割を分割しなければならないことがあります。 この場合、各仮想マシンに 1 つの Exchange サーバーの役割を展開するか、すべてのメールボックス サーバーの仮想マシンに 1 つのクライアント アクセスとハブ トランスポートが組み合わせられた役割仮想マシンを展開した方が効率的なことがあります。

    注意

    ハイパーバイザーのホスト サーバーには、Exchange サーバーの役割をインストールできません。 管理ソフトウェア (ウイルス対策ソフトウェア、バックアップ ソフトウェア、仮想マシン管理ソフトウェアなど) のみホスト サーバー上に展開できます。 その他のサーバーベースのアプリケーション (Exchange、Microsoft SQL Server、Active Directory など) はホスト サーバーにインストールしないでください。 ホスト サーバーはゲスト仮想マシンの実行専用にする必要があります。

詳細については、「容量計画におけるクライアント アクセスおよびハブ トランスポートの役割を組み合わせた構成について」を参照してください。

複数の役割の構成が推奨される理由

複数のサーバーの役割でのハードウェアの推奨事項

一般的なガイドラインとして、複数の役割のサーバーは、使用可能なプロセッサの半分をメールボックス サーバーの役割に使用し、残りの半分をクライアント アクセス サーバーの役割とハブ トランスポート サーバーの役割に使用するように、処理能力を決定する必要があります。 マイクロソフトは、複数の役割のサーバーに推奨されるプロセッサ コアの最大数を指定していません。代わりに、設定されたプロセッサ ソケットの最大数が提供されます。 これは、マルチコア プロセッサが接続されるマザーボードのプロセッサ ソケットの数を表します。 詳細については、「プロセッサーの構成と Exchange のパフォーマンスについて」を参照してください。

プロセッサ アーキテクチャのサイズ設定に加えて、複数の役割の構成を展開するためにはメモリを正しくサイズ設定する必要もあります。 詳細については、「メモリの構成と Exchange のパフォーマンスについて」を参照してください。

DAG での複数の役割のサーバーの展開

DAG 内に単一の役割のメールボックス サーバーを展開する場合、メールボックス サーバーの負荷に関連して、1 つおよび複数のサーバーの障害に対応する処理能力計画について検討します。 DAG 内に 4 つのメールボックス サーバーがある場合、メールボックス サーバーの処理能力を 50% に設定して、2 つのメールボックス サーバーに同時に障害が発生した場合に、アクティブなユーザー数の 2 倍に対応できるようにします。 ハブ トランスポート サーバーとクライアント アクセス サーバーは別の物理サーバー上にあるため、1 つまたは 2 つのメールボックス サーバーが失われても、これらのサーバーの負荷に多大な影響はありません。

DAG 内に複数の役割のサーバーを展開する場合、クライアント アクセス サーバー、ハブ トランスポート サーバー、およびメールボックス サーバーの各負荷に対する処理能力計画について検討します。 DAG 内に 4 つの複数の役割のサーバーがある場合、ハブ トランスポート サーバーとクライアント アクセス サーバーの各負荷の倍に対応できる十分な処理能力があることを確認します。 複数の役割の構成は、サーバーの役割の推奨されるプロセッサ コア比率と整合しているため、メールボックス サーバーの役割に対するアクティブなデータベースの最大数を正しく決定すると、ハブ トランスポート サーバーとクライアント アクセス サーバーはこのシナリオのパフォーマンス目標を満たすはずです。

複数の役割の構成が推奨される理由

Exchange 2010 の複数の役割のシナリオの処理能力決定の例

次の例では、複数の役割のサーバーの処理能力決定プロセスを示します。 この例では、次の設計が前提となっています。

  • メールボックスの合計数   24,000

  • メールボックス プロファイル   1 日あたり 100 通のメッセージ (たとえば、送信 20 通、受信 80 通)

  • メールボックスあたりのデータベース キャッシュ   6 MB (1 日あたり 100 通のメッセージというプロファイルに基づく)

  • 可用性要件   1 つのサイト内でのメールボックスの復元、3 つのデータベース コピーおよび 2 つのサーバーの同時障害に対する保護

  • データベース要件   DAG 内に 120 個のデータベース、データベースあたり 200 個のメールボックス

  • サーバー プラットフォーム   2 x 6 コア 2.26 GHz プロセッサ ベース (X5650) のサーバー (12 コア)

次のプロセスが適用されます。

  1. サーバー数を計算する   2 つのサーバーの同時障害から保護するために、4 ノードの DAG が必要です。 ただし顧客は、6 つのサーバーを展開して、サーバーの二重障害発生中にアクティブなメールボックスの最大数を制御することに決めました。したがって、DAG 内で 6 つのメールボックス サーバーを使用して設計を開始します。

  2. アクティブ化モデルに基づいてサーバーごとにアクティブなメールボックスの最大数を計算する   アクティブなデータベースをノード間で均等に分散すると仮定すると、理想的には各サーバーで 4,000 (24,000 ÷ 6) のアクティブなメールボックスをホストすることになります。 この例に基づき、2 つのノードで障害が発生した後のアクティブなメールボックスの数を計算するには、残りの 4 つのノードでメールボックス数を割ることになるので、ノードごとに 6,000 (24,000 ÷ 4) のアクティブなメールボックスになります。

    この例では、Set-MailboxServer コマンドレットの MaximumActiveDatabases パラメーターを 30 に構成して、1 つのサーバーでアクティブになるデータベースが 40% 以下になるようにします。

  3. アクティブなメールボックスの CPU 要件を計算する   「メールボックス データベース キャッシュについて」の表「メッセージ アクティビティおよびメールボックス データベース キャッシュに基づく、メールボックスあたりの予想される IOPS」に基づいて、サーバー上のアクティブなメールボックスの最大数にアクティブなメールボックスあたりのメガサイクルを掛けます (6,000 × 2 メガサイクル = 12,000 メガサイクル)。 この値に追加の各データベース コピーの 10% を掛けます。

    この例では、各データベースに 1 つのアクティブなコピーと 3 つのパッシブなコピーがあるため、12,000 メガサイクルが 30% 増えます (12,000 × 1.3 = 15,600 メガサイクル)。 詳細については、「メールボックス データベース キャッシュについて」の「データベース キャッシュのメトリックス」を参照してください。

  4. パッシブなメールボックスの CPU 要件を計算する   「メールボックス データベース キャッシュについて」の表「メッセージ アクティビティおよびメールボックス データベース キャッシュに基づく、メールボックスあたりの予測される IOPS」に基づいて、パッシブなメールボックスの数 (サーバーがアクティブなメールボックスの最大数をホストしている場合) にパッシブなメールボックスあたりのメガサイクルを掛けます (10,000 × 0.3 メガサイクル = 3,000 メガサイクル)。詳細については、「メールボックス データベース キャッシュについて」の「データベース キャッシュのメトリックス」を参照してください。

  5. アクティブとパッシブの CPU 要件を加算して合計 CPU 要件を取得する   この例では、15,600 (アクティブなメールボックスのメガサイクル) + 3,000 (パッシブなメールボックスのメガサイクル) = 18,600 メガサイクル (合計 CPU 要件)。

  6. メールボックスの CPU 要件をハードウェア プラットフォームに適用する   この例では、2 x 6 コアの 2.26 GHz プロセッサベース (x5650) のサーバーを使用します。「メールボックス サーバーのプロセッサ容量計画」のガイダンスに基づくと、これは 60,083 メガサイクルに相当します。 サーバー プラットフォームに基づいて、必要なメガサイクルを使用可能なメガサイクルで割り、2 つのノードで障害が発生した後のピーク期間の CPU 使用率を見積もります (18,600 ÷ 60,083 = 31% の予想 CPU 使用率)。

    複数の役割の構成のメールボックス サーバーの役割部分は、ピーク時 (2 つのノードに同時に障害が発生した場合など) に 40% を超えないように設計することをお勧めします。 この設計で、サーバーの総 CPU 使用率をピーク時 (2 つのノードに同時に障害が発生した場合など) に 80% を超えないように維持しながら、クライアント アクセス サーバーの役割とハブ トランスポート サーバーの役割の CPU 使用率に対応するのに十分な領域を確保できます。

  7. アクティブなメールボックスのメモリ要件を計算する   アクティブなメールボックスの数にメールボックスあたりの必要なデータベース キャッシュを掛けます。 この例では、2 つのサーバーで障害が発生すると、残りのサーバーが 6,000 のアクティブなメールボックス (6,000 × 6 MB) ÷ 1,024 = 35.1 GB をホストします。 データベース キャッシュの要件は、メールボックス プロファイルに基づきます。 詳細については、「メールボックス データベース キャッシュについて」の「データベース キャッシュのメトリックス」を参照してください。

  8. 合計メモリ要件をハードウェア プラットフォームに適用する   必要なメモリ総数は、データベース キャッシュの要件およびサーバー設計 (専用または複数の役割) に基づきます。 詳細については、「メールボックス データベース キャッシュについて」の「既定のメールボックス データベース キャッシュ サイズ」の表を参照してください。 この例の複数の役割のサーバーの合計メモリ要件は、52.2 GB ((4 GB + 35.1 GB) ÷ 0.75) となっています。52.2 GB は標準的なメモリ構成ではないため、64 GB またはサーバーがサポートしている最も近いメモリ構成まで切り上げます。

    複数の役割の構成が推奨される理由

 © 2010 Microsoft Corporation.All rights reserved.