Exchange 2013 のサイズ変更と構成の推奨事項

製品: Exchange Server 2013

Exchange 2013 は、Exchange の以前のバージョンよりシステム リソースの要件が厳しくなっています。 Exchange 2013 のインフラストラクチャを正しくサイジングし、そのインフラストラクチャ内で Exchange 関連のコンポーネントに推奨される構成を行うと、最適に実行する展開の下地を作ることができます。

Exchange 2013 のサイジング

Exchange 2013 を正しくサイジングすることは、パフォーマンスの問題を回避する最も効果的な方法の 1 つです。 Exchange 2013 サーバーロール要件計算ツールは 、こちらで入手できます。 最新バージョンは 9.1 です。 この計算ツールを正しく使用するには、ブログ投稿「Exchange 2013 Server Role Requirements Calculator」および「Exchange 2013 展開のサイジング」のガイダンスを参考にする必要があります。

ハードウェアを購入して展開する前に、電卓から始める必要があります。 最初に、計算ツールの結果に基づいて全体的なリソース要件を決定する必要があります。 電卓を使用して組織の要求を入力し、その結果を使用してハードウェアをスケーリングする方法に関するガイダンスを得ることができます。 計算ツールでは、使用するサーバーの数は示されませんが、特定のサーバー セットに対する Exchange ワークロードの影響を見積もることができます。 環境に固有のハードウェアとビジネスのニーズを満たすために、さまざまな構成を試してパフォーマンスにどのような影響を与えるかを確認する必要があります。

展開を簡素化してハードウェアを最適に使用するため、Exchange 製品グループは複数の役割のサーバーを推奨しています。 複数の役割のサーバーを使用すると、障害のシナリオのときに要求を処理するために使用できるクライアント アクセス サーバー (CAS) が多くなり、クライアント アクセス サーバー層での可用性が高くなります。 Exchange 2013 の主な設計の考慮事項は、「より小さい」商品タイプのサーバーを活用する (スケール アップではなくスケール アウトする) ことです。 設計とテストは、最大 20 個のプロセッサ コアを含む 2 台のソケット コンピューターと、最大 96 ギガバイト (GB) の RAM で行われました。 ハードウェアがこの推奨事項よりも大きい場合は、他のオプションを検討する必要があります。 たとえば、そのハードウェアを他のニーズに使用し、Exchange 2013 環境用の小規模なサーバーを購入します。 または、仮想化を検討してください。

既存の大規模なサーバーにリソースを追加する (スケールアップ) よりも多くのサーバーを構築 (スケールアウト) することをお勧めします。 スケール アウトを行うと、ご使用の環境は Exchange 2013 の組み込みの高可用性機能を活用できます。 この構成を推奨する理由を理解するには、「 優先アーキテクチャ と サイトの回復性が可用性に与える影響」の投稿を詳しく確認してください。

電卓では、次の項目は考慮されません。

• Exchange サーバー上で実行されているサード パーティ製品。
• 内部開発されたアプリケーションを含め、Exchange と対話する製品。

そのため、サイズ設定でこれらの項目を考慮してください。 たとえば、Lync Server、サード パーティの Exchange Web サービス (EWS) アプリケーション、ActiveSync デバイスはすべて、ユーザーあたりの CPU 要件を大幅に増やすことができます。 Exchange に与える影響の詳細については、サード パーティの製品ドキュメントを使用してください。 サード パーティのソリューションを実装する前に、Exchange のパフォーマンス ベースラインを作成することをお勧めします。

推奨されるパフォーマンス構成

Exchange 2013 環境に推奨されるパフォーマンスの最適化の内容は次のとおりです。

電源

オペレーティング システム (OS) が電源を管理できるように BIOS を設定します。

OS で、高パフォーマンス電源プランをオンにします。

Processing

物理 Exchange サーバーでハイパースレッドをオフにします。 仮想サーバー環境では、物理サーバーでハイパースレッディングを有効にできますが、各仮想サーバーには必要な数の仮想 CPU のみを割り当てる必要があります。 つまり、仮想 CPU を過剰に割り当てず、サイズ設定の計算に物理プロセッサ コア数のみを使用します。

Exchange Server 2013 Service Pack 1 以降では、クライアント アクセス サーバーによって CPU 使用量を軽減する SSL オフロードを有効にすることができますが、SSL オフロードの複雑な構成は利益に見合わないことがあります。

.NET Framework

Exchange のバージョン	.NET Framework 4.6.2	.NET Framework 4.6.1	.NET Framework 4.5.2
Exchange 2013 CU16	X
Exchange 2013 CU15	X	X1、2	X
Exchange 2013 CU13 と CU14		Xsup>1,2	X

¹ .NET Framework 4.6.1 では、Exchange 2013 CU13 を実行しているサーバーにインストールする場合は、リリース後の修正プログラムが必要です。 詳細はこちら。 詳細については、「Exchange 2013 の前提条件」をご覧ください。

² Exchange 2013 CU12 以前から Exchange 2013 CU13、CU14、または CU15 にアップグレードする場合は、4.6.1 と関連するリリース後の修正プログラムを.NET Frameworkする前に、Exchange 2013 CU13 をインストールすることを強くお勧めします。

.NET 4.5.2 をインストールできない場合は、「Windows Server で実行されている Exchange Server 2013 に接続するときのパフォーマンスの問題または遅延」2995145 Microsoft サポート技術情報の記事を参照してください。この記事の修正は、Store Worker Process のメモリ使用率に関する内部の調査結果に基づいて開発されました。 これらの修正プログラムを適用すると、すべてのマネージド プロセス (ストア ワーカー プロセスを含む) の全体的なメモリ消費量が削減され、.NET ガベージ コレクションに費やされる全体的な CPU 時間が短縮されます。

修正プログラム

Exchange パフォーマンス チームは、次のパフォーマンスに関連する修正プログラムをすべてインストールすることを推奨しています。

• Windows Server 2012 でのクラスターの復元性を向上させる更新が利用可能
• 推奨される Windows Server 2012 ベースのフェールオーバー クラスターの修正プログラムおよび更新
• 推奨される Windows Server 2012 の R2 ベースのフェールオーバー クラスターの修正プログラムおよび更新
• マルチコア プロセッサを搭載した Windows 8 または Windows Server 2012 ベースのコンピューターに正しくない RSS プロセッサが割り当てられている
• Windows Server で実行されている Exchange Server 2013 に接続するときのパフォーマンスの問題または遅延
• Outlook の接続の問題: Exchange 2013 で SSLOffloading が "True" の場合
• Exchange Server 2013 でのデータベースのフェールオーバー後の Outlook の長時間サーバー接続
• Lync が Exchange Server 2013 と統合している場合に Outlook Web アプリのパフォーマンスが低下する
• EMS は、Exchange Server 2013 累積更新 5 環境で最初のコマンドを実行する際に時間がかかる
• Exchange Server 2013 で IPv6 が有効な場合の、メッセージのルーティングの待機時間
• Windows Server 2008 R2 SP1 の Microsoft LDAP クライアントに依存するアプリケーションによる CPU 使用率が高い
• Windows 8.1 または Windows Server 2012 R2 で HTTP プロトコル経由で RPC を使用すると CPU 使用率が高くなる

ネットワーク

Exchange 2013 では、MAPI とレプリケーション ネットワークを分割する必要がなくなったため、1 つのネットワーク アダプターをお勧めします。 詳細については、「ネットワーク要件」を参照してください。

利用可能な場合は既定の SNP のオフロード設定を使用し、必ず RSS を有効にしてください (Windows Server 2012 以降の既定の設定)。 RSS は、特に 10 GbE で CPU 使用率をスケーリングするのに役立ちます。

OS が電力を節約するためにネットワーク カードの電源をオフにしないことを確認します。

NIC ドライバーを最新の状態に維持します。 関連するドライバーの更新プログラムについて、月に 1 回ベンダーに確認します。

インターネット インフォメーション サービス (IIS)

インストール時に、Exchange は IIS のいくつかの接続制限を変更します。 これ以上 IIS のチューニングしないことをお勧めします。

カスタマイズを可能な限り避けてください。 web.config やレジストリ キーへのすべての変更は、Exchange の累積更新プログラムまたは Windows Update によって上書きされる可能性があります。

ストレージ

Exchange 2013 記憶域のガイドラインは Exchange 2013 記憶域構成オプション でご利用いただけます。

仮想化

ハードウェア仮想化の要件 を確認してください。 また、Exchange は Non-Uniform Memory Access (NUMA) に対応していないことに注意してください。 このため、ハードウェア製造元の既定の NUMA 設定を使用することをお勧めします。

Active Directory

Active Directory クエリは Exchange の展開に直接影響するため、ディレクトリ サーバーのパフォーマンスを監視します。

Active Directory の正常性に関して、LDAP の検索時間は重要な測定カウンターです。 ドメイン コントローラーで CPU を監視します。 ドメイン コントローラーの CPU の問題は、Exchange サーバーでのパフォーマンスの低下として表れます。

ドメイン コント ローラーのパフォーマンスの問題の原因を特定するため、[データ コレクター セット] の下にある、パフォーマンス モニターのドメイン コントローラーにある組み込みの [Active Directory 診断] を実行します。

AD データベース ファイル全体をキャッシュできるように、ドメイン コントローラーには十分な容量の RAM を計画してください。

アクティブな負荷を処理している 8 つのメールボックス コアごとに 1 つの Active Directory グローバル カタログ コアを展開することをお勧めします (64 ビット グローバル カタログ コアに基づく)。

負荷分散

すべてのクライアント アクセス サーバーは、ほぼ同数の受信接続を受信する必要があります。

すべてのプロトコルで、Exchange 2013 では特定のクライアント アクセス サーバーとロード バランサーの間のセッション アフィニティは必要ありません。

クライアント アクセス サーバーへのすべての受信トラフィックを管理するハードウェアまたはソフトウェアのロード バランサーを使用してください。 ターゲット サーバーの選択は、"ラウンドロビン"(受信接続ごとに循環リストの次のターゲット サーバーが選択される) や、"最小接続" (ロード バランサーが新しい各接続を、その時点で確立されている接続数が最小のサーバーに送信する) などの方式で決定できます。 これらの方法の詳細については、「 負荷分散」を参照してください。 また、次の項目も考慮する必要があります。

• ラウンドロビンには、存続期間の長い接続 (RPC/HTTP など) により収束時間が長いという問題があります。 新しいコンピューターがオンラインになるとき、ターゲット コンピューターの間で取られる接続のバランスにより、収束まで非常に時間がかかります。

• 「最小接続」方式では,クライアント アクセス サーバーの停止時またはパッチ処理によるメンテナンス時に、クライアント アクセス サーバーが過負荷になり、応答しない可能性があることに留意してください。 Exchange のパフォーマンスのコンテキストで、認証はコストのかかる操作です。

Exchange 2013 環境の Windows ネットワーク負荷分散 (NLB) にはいくつかの制限があるため、「 負荷分散」で詳しく説明されています。Windows NLB の使用はお勧めしません。

ユーザーおよびデータベースの分散

データベースあたりのユーザーとサーバーあたりのアクティブなデータベースについて、適切なバランスの取れた分散を維持します。 データベースのディスク容量の消費を均等に分散するとともに、データベース全体で高負荷のユーザーのバランスを取ります。

Exchange (デバイス、Outlook、および OWA) との対話方法と、パフォーマンスの観点からこの対話が引き起こす影響を理解するために、ユーザー ベースをプロファイルする必要があります。 ユーザーごとの Exchange の使用法をプロファイルする方法をより深く理解するには、計算ツールのブログ投稿のセクション 2 以降を参照してください。

フェイルオーバー時またはスイッチオーバー時のバランスを維持するために、DB コピーのアクティブ化の優先順位と"MaximumPreferredActiveDatabases" (サーバーごと) の設定を構成します。

RedistributeActiveDatabases.ps1 スクリプトは、DAG ノードの間でアクティブなデータベースのバランスを取り直します。

Microsoft 365 またはOffice 365に一致する厳密な項目数制限を適用することを検討してください。 これを実行するには、Set-Mailbox コマンドレットと「メールボックス フォルダーの制限」に記載された情報を使用します。

ページファイル

32 GB を超える RAM を使用している場合は、ページ ファイルの最大サイズを 32,778 MB に設定します。

ページファイルは、Exchange データベース ファイルまたはデータベースのログ ファイルと同じドライブ上でホストしないでください。

固定サイズのページファイルを使用し、Windows がサイズを管理できないようにすることが不可欠です。 ページ ファイルの増大は非常にパフォーマンス集中型の作業になり、Exchange がストレスを受けたときに問題が発生することがあります。

完全なカーネル ダンプを取得する必要がある場合は、「 カーネルの生成または完全なクラッシュ ダンプ」を参照してください。

Outlook モード

キャッシュ モードをお勧めします。 キャッシュ モードを使用する利点については、「Outlook 2013 の Exchange キャッシュ モードまたはオンライン モードを選択する」をご覧ください。

パフォーマンスは、サーバー アドインと Outlook サード パーティアドインの両方によって影響を受ける可能性があることに注意してください。オンライン モードを使用する場合、クライアントはサード パーティのアドイン、アイテム数の多さ、制限付きビュー、メールボックスにアクセスするユーザーの数などのパフォーマンスの問題を予想できます。 従来のクライアントでは、Outlook 2013 よりもアイテム数とパフォーマンスが高い場合により多くの影響を受ける可能性があります。

組織が Outlook のオンライン モードを構成する主な理由がセキュリティ上の問題である場合は、代わりに BitLocker を使用することを検討してください。

Outlook 2013 は、ダウンロード時間を最短にし、OST ファイルのサイズを最小にする新しい「同期スライダー」機能を提供します。 詳細については、「 Outlook 2013 で Exchange キャッシュ モードを構成する」を参照してください。

ご使用の環境内でサポートされている Outlook クライアントの更新プログラムを月 1 回確認してください。

サード パーティ製ソフトウェア

ベスト プラクティスとして、Exchange のパフォーマンスのトラブルシューティング中にサード パーティ製ソフトウェアをアンインストールまたは無効化します。 次の一覧には、Microsoft サポートが Exchange 2013 のパフォーマンスに最も影響を与えることが最もよく見られるサード パーティ製ソフトウェアの種類が含まれています。

• ウイルス対策ソリューション
• 侵入防止ソフトウェア
• バックアップ ソフトウェア
• ファイルとユーザー両方の監査ソフトウェア
• アーカイブ ソリューション