Exchange Server 2010 サイジングガイド ホワイトペーパー

Exchange Server 2010 サイジングガイド
ホワイトペーパー
著作権
このドキュメントに記載されている情報 （URL 等のインターネット Web サイトに関する情報を含む） は、将来予告なしに変更すること
があります。別途記載されていない場合、このソフトウェアおよび関連するドキュメントで使用している会社、組織、製品、ドメイン名、電
子メール アドレス、ロゴ、人物、場所、出来事などの名称は架空のものです。実在する名称とは一切関係ありません。お客様ご自身の
責任において、適用されるすべての著作権関連法規に従ったご使用を願います。
マイクロソフトは、このドキュメントに記載されている内容に関し、特許、特許申請、商標、著作権、またはその他の無体財産権を有する
場合があります。別途マイクロソフトのライセンス契約上に明示の規定のない限り、このドキュメントはこれらの特許、商標、著作権、また
はその他の無体財産権に関する権利をお客様に許諾するものではありません。
 2010 Microsoft Corporation.All rights reserved.
Microsoft、Active Directory、ActiveSync、Microsoft Press、MSDN、Outlook、Windows、Windows Mobile、Windows NT、および
Windows Server は、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。
記載されている会社名、製品名には、各社の商標のものもあります。
はじめに
本ガイドは、Exchange Server 2010 を導入する際行うサイジング作業について、以
下の章に分けて説明します。
 第一部 サイジングの流れ
サイジング作業全体の流れを説明します。
 第二部 サイジングの考え方
サイジングの考え方を説明します。
 第三部 各 Exchange サーバー ロールのサイジング
Exchange サーバー ロールごとのサイジング方法を説明します。
 第四部 Exchange 2010 サイジング ケーススタディ
特定のシステム構成でのサイジング例を説明します。
 第五部 サイジング検証
サイジングに影響する部分について実施した検証内容を説明します。
また、本ガイドでは以下の表に示す略称を用います。
正式名称
略称
Exchange Server 2010
Exchange 2010
Exchange Server 2007
Exchange 2007
Exchange Server 2003
Exchange 2003
エッジトランスポート サーバー
Edge サーバー
ハブトランスポート サーバー
HUB サーバー
クライアントアクセス サーバー
CAS サーバー
ユニファイド メッセージング サーバー
UM サーバー
メールボックス サーバー
MBX サーバー
データベース可用性グループ
DAG
データベース
DB
Outlook Web App
OWA
Microsoft Outlook
Outlook
本ガイドで使用する基本的な用語を以下に説明します。
 エッジトランスポート サーバー (Edge サーバー)
Edge サーバーは、インターネットに直接接続されたすべてのメール フローを
処理します。これにより、Exchange 組織に SMTP 中継およびスマートホスト
サービスが提供されます。さらに、Edge サーバーで実行される一連のエージェ
ントにより、メッセージ保護とセキュリティが提供されています。これらのエー
ジェントでは、ウイルスやスパムを防御し、メッセージ フローを制御するトラ
ンスポート ルールを適用する機能がサポートされています。
 ハブトランスポート サーバー (HUB サーバー)
HUB サーバーはメールの中継サーバーの役割を果たし、組織内のすべてのメー
ル フローの処理、トランスポート ルールの適用、ジャーナリング ポリシーの
適用、および受信者のユーザー メールボックスへメッセージの配信を行います。
インターネットに送信されるメッセージは、HUB サーバーによって、境界ネッ
トワークに展開される Edge サーバーに中継されます。インターネットから受
信されたメッセージは、Edge サーバーで処理されてから、HUB サーバーに中
継されます。Edge サーバーがない場合は、インターネット メッセージを直接
中継するか、サードパーティ スマートホストを活用するよう HUB サーバーを
構成できます。
 クライアントアクセス サーバー (CAS サーバー)
CAS サーバーは、クライアントから Exchange 2010 サーバーに対する接続を
受け付けます。Outlook などの MAPI クライアント、OWA と Microsoft
Exchange Active Sync クライアント アプリケーション、POP3 プロトコルと
IMAP4 プロトコルからの接続をサポートします。
 ユニファイド メッセージングサーバー (UM サーバー)
UM サーバーにより、音声メッセージング、FAX メッセージング、および電子
メール メッセージングが Exchange ストアに統合されます。UM サーバーを
展開することで、ユーザーは Outlook Voice Access を使用して、電話、携帯電
話、またはコンピューターから自分のメッセージにアクセスできます。
 メールボックス サーバー (MBX サーバー)
MBX サーバーは、Exchange 組織の中でも中心的な機能を果たします。メール
ボックス DB をホストし、Outlook や OWA ユーザーのために、電子メール記
憶域および高度なスケジュール サービスを提供します。さらに、パブリック
フォルダー DB のホスト、アドレス一覧とオフライン アドレス帳の生成などの
MBX サービスを提供します。
 コンバインドロール サーバー
コンバインドロール サーバーとは、HUB サーバー ロール、CAS サーバー
ロールを同じ物理サーバー上に構成したサーバーのことです。これにより、1 つ
の Exchange サーバー ロールでは使用可能な CPU が利用されないままにな
る可能性がある場合に、複数のロールを結合することで、サーバーの CPU リ
ソースをより効果的に使用することができます。
 マルチロール サーバー
マルチロール サーバーとは、HUB サーバー ロール、CAS サーバー ロール、
MBX サーバー ロールを同じ物理サーバー上に構成したサーバーのことです。
MBX サーバー ロール単独では、使用可能な CPU リソースを活用できない場
合に、HUB サーバー ロールと CAS サーバー ロールを追加すると、サーバー
の処理能力をより効率的に活用できます。
目次
サイジングの流れ ............................................................................................................................................ 1
第一部
1.1
サイジングの流れ................................................................................................................................................. 2
1.1.1
プロファイルの決定 ........................................................................................................ 2
1.1.2
システム構成の決定 ........................................................................................................ 3
1.1.3
Exchange サーバー ロールごとのサイジング .............................................................. 4
サイジングの考え方 ........................................................................................................................................ 6
第二部
2.1
ロール構成の考え方........................................................................................................................................... 7
2.1.1
マルチロール構成の考え方 ............................................................................................. 7
2.1.2
コンバインドロール構成の考え方 .................................................................................. 9
2.1.3
単体ロール構成の考え方................................................................................................. 9
2.2
仮想化の考え方............................................................................................................................................... 10
2.3
冗長化の考え方............................................................................................................................................... 11
2.3.1
MBX サーバー ロールの冗長化....................................................................................11
2.3.2
MBX サーバー ロール以外の Exchange サーバー ロールの冗長化 ........................ 12
2.4
CPU サイジングの考え方 ............................................................................................................................... 13
2.4.1
CPU サイジングの概要................................................................................................ 13
2.4.2
MBX サーバー ロールと各 Exchange サーバー ロールのプロセッサ コア数比率 14
2.4.3
最小と最大のプロセッサ コア数の範囲 ....................................................................... 15
2.4.4
CPU サイジングの注意事項......................................................................................... 16
2.5
メモリ サイジングの考え方................................................................................................................................ 17
2.5.1
メモリ サイジングの概要 ............................................................................................. 17
2.5.2
最小と最大のメモリ容量の範囲.................................................................................... 17
2.6
ディスク サイジングの考え方............................................................................................................................ 20
2.6.1
ディスク サイジングの概要 ......................................................................................... 20
2.6.2
サポート対象のストレージ システム........................................................................... 20
2.7
ネットワーク サイジングの考え方 ..................................................................................................................... 24
2.8
Active Directory サーバー サイジングの考え方 ......................................................................................... 25
各 Exchange サーバー ロールのサイジング............................................................................................. 26
第三部
3.1
MBX サーバー ロールのサイジング................................................................................................................. 27
3.1.1
サイジングに必要な要素の確認.................................................................................... 27
3.1.2
CPU のサイジング ....................................................................................................... 28
3.1.3
メモリのサイジング ...................................................................................................... 37
3.1.4
ディスク容量のサイジング ........................................................................................... 43
3.1.5
ディスク性能のサイジング ........................................................................................... 57
3.2
CAS サーバー ロールのサイジング.................................................................................................................. 62
3.2.1
CPU のサイジング ....................................................................................................... 63
3.2.2
メモリのサイジング ...................................................................................................... 63
3.3
HUB サーバー ロールのサイジング ................................................................................................................. 65
3.3.1
CPU のサイジング ....................................................................................................... 66
3.3.2
3.4
メモリのサイジング ...................................................................................................... 66
コンバインドロールのサイジング......................................................................................................................... 68
3.4.1
CPU のサイジング ....................................................................................................... 69
3.4.2
メモリのサイジング ...................................................................................................... 69
3.5
マルチロールのサイジング .................................................................................................................................. 70
3.5.1
CPU のサイジング ....................................................................................................... 70
3.5.2
メモリのサイジング ...................................................................................................... 71
3.5.3
マルチロール サーバーのサイジング例 ....................................................................... 73
3.6
Edge サーバー ロールのサイジング ................................................................................................................ 79
3.6.1
CPU サイジングの考え方 ............................................................................................ 79
3.6.2
メモリのサイジング ...................................................................................................... 80
3.7
UM サーバー ロールのサイジング................................................................................................................... 81
3.7.1
CPU のサイジング ....................................................................................................... 81
3.7.2
メモリのサイジング ...................................................................................................... 81
Exchange 2010 サイジング ケーススタディ.............................................................................................. 82
第四部
4.1
サイジング ケース スタディ ............................................................................................................................... 84
4.1.1
MBX サーバー ロール ................................................................................................. 86
4.1.2
コンバインドロール サーバーのサイジング................................................................ 94
4.1.3
サイジング結果 ............................................................................................................. 95
サイジング検証 ............................................................................................................................................. 96
第五部
5.1
検証概要.......................................................................................................................................................... 97
5.1.1
MBX サーバーの搭載メモリ容量とディスク I/O の相関調査検証 ............................ 97
5.1.2
CAS サーバー 1 台でホスト可能なユーザー数の調査検証........................................ 97
5.1.3
最少構成台数でのマルチロール環境と仮想環境の比較検証 ........................................ 98
5.2
MBX サーバーの搭載メモリ容量とディスク I/O の相関調査検証 ..........................................................100
5.2.1
テスト シナリオ.......................................................................................................... 100
5.2.2
検証環境 ...................................................................................................................... 100
5.2.3
プロセッサとメモリのパフォーマンス....................................................................... 103
5.2.4
ディスク I/O パフォーマンス.................................................................................... 105
5.2.5
サイジング指針と検証結果を比較した考察................................................................ 108
5.2.6
まとめ ...........................................................................................................................110
5.3
CAS サーバーへの RPC 負荷検証 ............................................................................................................112
5.3.1
テスト シナリオ...........................................................................................................112
5.3.2
検証環境 .......................................................................................................................112
5.3.3
プロセッサとメモリのパフォーマンス........................................................................114
5.3.4
RPC パフォーマンス...................................................................................................117
5.3.5
サイジング指針と検証結果を比較した考察.................................................................119
5.3.6
まとめ .......................................................................................................................... 121
5.4
最少構成台数でのマルチロール環境と仮想環境の比較検証 .................................................................122
5.4.1
テスト シナリオ.......................................................................................................... 122
5.4.2
検証環境 ...................................................................................................................... 122
5.4.3
プロセッサとメモリのパフォーマンス....................................................................... 125
5.4.4
RPC パフォーマンス.................................................................................................. 128
5.4.5
ディスク I/O パフォーマンス.................................................................................... 131
5.4.6
サイジング指針と検証結果を比較した考察................................................................ 136
5.4.7
まとめ .......................................................................................................................... 137
付録 A.
ツールの紹介 ..............................................................................................................................................138
第一部
サイジングの流れ
この章では、Exchange 2010 システムをサイジングする場合の流
れを説明します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
1
1.1 サイジングの流れ
システムのサイジングは、大きく分けて以下の 3 ステップで行います。
1.
プロファイルの決定
プロファイルとはシステムの利用状況を定義するもので、サイジングに特に影
響を与える要素です。現在の利用状況を踏まえて決定してください。
2.
システム構成の決定
システム構成は、利用する Exchange サーバー ロールの選択、可用性要件に
従った冗長化構成の有無の選択、仮想化システムの有無の選択により決定しま
す。
3.
Exchange サーバー ロールごとのサイジング
最後に各サーバーをサイジングします。
以降で、それぞれのステップの詳細を説明します。
1.1.1
プロファイルの決定
システム構成の検討や Exchange サーバー ロールごとのサイジングの前に、プロ
ファイルを決定する必要があります。現行のシステム調査を行った上で将来的な増
加分を含めて決定してください。
プロファイルとは、ユーザー メールボックスの利用状況特性であり、1 日あたり
の平均メール送受信数と平均メールサイズで定義されます。プロファイルに基づい
てユーザー メールボックスあたりに必要な性能が算出されるため、プロファイルの
情報はサイジングにおいて特に重要な要素となります。
以下の表は、Exchange 2010 用のプロファイル範囲と、Exchange 2007 用のプロ
ファイル範囲の対応です (平均メールサイズは 75 KB)。
Exchange 2010 でのプロファイル
Exchange 2007 でのプロファイル
(1 日あたりのメール送受信数)
50
平均的負荷
100
高負荷
150
非常に高負荷
200
きわめて高負荷
250
― (Exchange 2007 では該当なし)
300
― (Exchange 2007 では該当なし)
350
― (Exchange 2007 では該当なし)
400
― (Exchange 2007 では該当なし)
450
― (Exchange 2007 では該当なし)
500
― (Exchange 2007 では該当なし)
Exchange Server 2010 サイジングガイド ホワイトペーパー
2
本ガイドでは、1 日あたりの平均メール送受信数が 50 ～ 500 通の範囲における
サイジング方法について説明します。また、特に明記がない部分に関しては平均メー
ルサイズを 75 KB と想定し、説明します。
Exchange 2007 から Exchange 2010 への各種性能向上に加え、今日の電子メー
ル使用量の増加に伴ってプロファイルの範囲も広く想定されています。プロファイ
ルとして、1 日あたりのメール送受信数を上記の表の範囲から決定してください。
1.1.2
システム構成の決定
プロファイルの決定後、システム構成を決定します。システム構成で重要となるの
は、ロール構成 (複数ロール、単体ロール)、仮想化、冗長構成の 3 点です。複数
ロール構成と仮想化はいずれもサーバー リソースを有効活用するソリューション
です。
ロール構成は、複数のロールを 1 台のサーバーで構成するか、それぞれ単体のロー
ルで構成するかを決定します。ロール構成の検討の詳細に関しては以下を参照して
ください。

「2.1 ロール構成の考え方」
仮想化構成は、複数のロールを物理サーバー上の仮想 OS を介して共存することで、
サーバー リソースの有効活用が可能ですが、仮想化を検討する上では、仮想化特有
の考慮事項があります。仮想化構成の検討の詳細に関しては以下を参照してくださ
い。

「2.2 仮想化の考え方」
冗長構成は、障害発生時に継続してサービスを提供する上で非常に重要となります。
冗長化構成の検討の詳細に関しては以下を参照してください。

「2.3 冗長化の考え方」
Exchange Server 2010 サイジングガイド ホワイトペーパー
3
1.1.3
Exchange サーバー ロールごとのサイジング
システム構成の決定後、Exchange サーバー ロールごとに CPU とメモリのサイ
ジングを行います。MBX サーバー ロールではディスク容量のサイジングも行いま
す。
Exchange サーバー ロールの中で、MBX サーバー ロール、CAS サーバー ロー
ル、HUB サーバー ロールは必須であり、Edge サーバー ロールと UM サーバー
ロールは必要な場合に構成します。
各 Exchange サーバー ロールのサイジングは、MBX サーバー ロールのサイジン
グ結果を基準として使用します。そのため、MBX サーバー ロールのサイジングを
最初に行います。Exchange サーバー ロールの構成によって、以下の手順で各
Exchange サーバー ロールのサイジングを行います。
マルチロール
コンバインド
構成
ロール構成
単体ロール構成
マルチロール
MBX
MBX
サーバー
サーバー
サーバー
コンバインド
CAS
ロール サーバー
サーバー
必須
HUB
サーバー
Edge
サーバー
オプション
UM
サーバー
 マルチロール構成を選択した場合
① マルチロールのサイジング
詳細に関しては「3.5 マルチロールのサイジング」を参照してください。
②
Edge サーバー ロール、UM サーバー ロールのサイジング (オプション)
Exchange Server 2010 サイジングガイド ホワイトペーパー
4
詳細に関しては「3.6 Edge サーバー ロールのサイジング」、「3.7 UM サー
バー ロールのサイジング」を参照してください。
 コンバインドロール構成を選択した場合
①
MBX サーバー ロールのサイジング
サイジングの基準となる MBX サーバー ロールのサイジングを行います。
詳細に関しては「3.1 MBX サーバー ロールのサイジング」を参照してくださ
い。
② コンバインドロールのサイジング
①の MBX サーバー ロールのサイジング結果を基に、コンバインドロールの
サイジングを行います。
詳細に関しては「3.4 コンバインドロールのサイジング」を参照してください。
③
Edge サーバー ロール、UM サーバー ロールのサイジング (オプション)
詳細に関しては「3.6 Edge サーバー ロールのサイジング」、「3.7 UM サー
バー ロールのサイジング」を参照してください。
 単体ロール構成を選択した場合
①
MBX サーバー ロールのサイジング
サイジングの基準となる MBX サーバー ロールのサイジングを行います。
詳細に関しては「3.1 MBX サーバー ロールのサイジング」を参照してくださ
い。
②
CAS サーバー ロール、HUB サーバー ロールのサイジング
①の MBX サーバー ロールのサイジング結果を基に、CAS サーバー ロール、
HUB サーバー ロールのサイジングを行います。
詳細に関しては「3.2 CAS サーバー ロールのサイジング」、「3.3 HUB サー
バー ロールのサイジング」を参照してください。
③
Edge サーバー ロール、UM サーバー ロールのサイジング (オプション)
詳細に関しては「3.6 Edge サーバー ロールのサイジング」、「3.7 UM サー
バー ロールのサイジング」を参照してください。
Exchange Server 2010 サイジングガイド ホワイトペーパー
5
第二部
サイジングの考え方
この章では、サイジングを行う前に知っておくべきサイジングの考
え方を説明します。
システム サイジングの考え方として、ロール構成の考え方、仮想化
の考え方、冗長化の考え方を説明します。
サーバー サイジングの考え方として、CPU サイジングの考え方、
メモリ サイジングの考え方、ディスク サイジングの考え方、ネッ
トワーク サイジングの考え方を説明します。
最後に、Exchange で必要となる Active Directory サーバーのサ
イジングの考え方を説明します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
6
2.1 ロール構成の考え方
今日のサーバー ハードウェアでは、CPU パフォーマンスの向上と、サポートする
プロセッサ コア数の増加が図られています。そのため、2 つ以上の CPU を搭載
した標準構成のサーバーに 1 つの Exchange サーバー ロールだけを展開すると、
規模などによってはサーバーの CPU リソースに余裕が生まれ、CPU を効率的に
使用できない可能性があります。
この場合 1 台のサーバーに複数の Exchange サーバー ロールを展開することで、
CPU リソースを十分に活用できるケースがあります。複数の Exchange サーバー
ロールを展開するには、ロール構成を変更するか、サーバーを仮想化します。
ここでは、ロール構成を選択する上での考え方を説明します。Exchange サーバー
ロールの構成には様々なものがありますが、本ガイドでは、以下の 3 つのロール
構成について説明します。
1.
マルチロール構成
CAS サーバー ロールと HUB サーバー ロールと MBX サーバー ロールを
同じサーバーにインストールします。
複数の Exchange サーバー ロールが搭載されるためシステムを構成する上
での制約がありますが、システムを構成する物理サーバーが最も少なくなりま
す。
2.
コンバインドロール構成
CAS サーバー ロールと HUB サーバー ロールを同じサーバーにインストー
ルし、MBX サーバー ロールを単体ロール構成とします。マルチロール構成よ
りも物理サーバーが増えますが、マルチロール構成の制約を解消することがで
きます。
3.
単体ロール構成
1 台のサーバーに 1 つの Exchange サーバー ロールをインストールします。
上記の順番でロール構成を検討してください。それぞれのロール構成の考え方につ
いて、以下で説明します。
2.1.1
マルチロール構成の考え方
マルチロール構成は、以下の場合に推奨されます。また、1 台のマルチロール サー
バーでホストする最大のユーザー メールボックス数 (縮退などのピーク時含む)
は、4,000 個以内を推奨します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
7
 支社などの小規模な組織にサーバー統合し導入する場合
ブランチオフィスに Exchange サーバーを配置する際など管理対象の物理
サーバー、オペレーティング システム インスタンス、および Exchange サー
バーの数を最小限に抑えたい場合、マルチロールでの展開が推奨されます。マ
ルチロールでは、2 台または 3 台の物理サーバーといった最小の要件で必要
なロールの冗長性が得られます。
 単純なスケールアウトを計画する場合
ユーザー メールボックス数の定期的な増加が見込まれ、増加分に対し一定のコ
ストで Exchange のサービスを提供するような組織では、マルチロールでの
展開を検討する必要があります。マルチロール サーバーは、1 台で完結した
構成要素となるため、簡単に構成要素を追加することができ、増大する処理能
力に対応できます。
 サーバー内蔵のストレージにユーザー メールボックスを格納する場合
Exchange 2010 では I/O 要件が削減されているため、サーバー内蔵のディス
クでも、数千個のユーザー メールボックスをホストできる場合があります。
今日、多数のサーバーでは 2 つの CPU (8 ～ 12 プロセッサ コア) と 10 ～
16 個の内蔵ディスクを搭載できるため、プロファイルとディスクの種類に依
存しますが、内蔵ディスクを使用して最大 4,000 個のユーザー メールボック
スをホストできます。この構成では、CPU リソースに余裕が生まれ、CPU を
十分に活用できない可能性がありますが、サーバーに CAS サーバー ロール
と HUB サーバー ロールを追加し、マルチロール構成とすることで、CPU を
効率的に使用できるケースがあります。
 障害発生時に影響を受けるユーザー メールボックス数を制限したい場合
マルチロール サーバーは、障害発生時に影響を受けるユーザー メールボック
ス数を制限したい場合に有用なソリューションになります。たとえば、10,000
個のユーザー メールボックスがある組織で、1 台のサーバーが停止しても環境
内の 25% 超のユーザー メールボックスに影響を与えてはならないというポ
リシーがあるとします。これにより、MBX サーバーあたりのユーザー メール
ボックス数は 2,500 個に制限されるため、サーバーの処理能力を十分に活用で
きない場合があります。この場合、サーバーに CAS サーバー ロールと HUB
サーバー ロールを追加することで、このサーバーの処理能力を活用できます。
マルチロール構成には以下の制約があります。
 Windows ネットワーク負荷分散 (NLB) を使用できない
MBX サーバー ロールを冗長化する場合、冗長化のために使用するクラスタリ
ング コンポーネントと NLB は同じサーバーに構成することは仕様上できま
せん。そのため、ハードウェア負荷分散装置を使用するか、MBX サーバー ロー
ルと CAS サーバー ロールを分離した上で、NLB を利用する必要があります。
Exchange Server 2010 サイジングガイド ホワイトペーパー 8
 仮想化の制約
ホストできるユーザー メールボックス数が大幅に制限されるため、4 つの仮
想プロセッサ コアを搭載した仮想サーバーに、マルチロールを構成することは
推奨されません。各仮想サーバーに 1 つの Exchange サーバー ロールを展
開するか、MBX サーバーの仮想サーバーごとにコンバインドロール サーバー
の仮想サーバーを展開した方が効率的です。
ただし、ユーザー メールボックス数が 500 未満の場合、仮想サーバーにマル
チロールを構成し、管理対象の OS と Exchange サーバーの数を減らすこと
ができます。
仮想化の詳細に関しては「2.2 仮想化の考え方」を参照してください。
2.1.2
コンバインドロール構成の考え方
コンバインドロール構成は、以下の場合に推奨します。
 サーバー統合
2 つの CPU を搭載した標準構成のサーバーに、Exchange サーバー ロール
を 1 つ構成しただけでは、CPU リソースに余裕が生まれ、CPU を効率的に
使用できない可能性があります。システムの制約などでマルチロール構成にで
きないが、上記の様に CPU リソースに余裕がある場合、コンバインドロール
構成にすることで、サーバーの CPU を効率的に使用するとともにサーバー台
数の増加を抑えることができます。また、コンバインドロール構成では、MBX
サーバー ロールを除き最低 2 台の物理サーバーで CAS サーバー ロールと
HUB サーバー ロールに必要な冗長性を実現できます。また、マルチロール構
成とは違い、NLB を使用することができます。
 仮想化
仮想化ホスト サーバーのプロセッサ コア数が 8 で分割できる展開環境の場
合 (8・16・24・32・48 プロセッサ コア)、コンバインドロール サーバーと
MBX サーバーを 1 : 1 のプロセッサ コア比率で仮想化ホスト サーバー上に
仮想サーバーとして展開すると、ホスト サーバーのサイズに関係なく、バラン
スのとれた仮想マシンの配置を実現できます。そのため、仮想化構成をとる場
合はコンバインドロール構成を検討してください。
仮想化の詳細に関しては「2.2 仮想化の考え方」を参照してください。
2.1.3
単体ロール構成の考え方
組織内のメッセージング量が多いほど、MBX サーバー、CAS サーバー、HUB サー
バーに対する負荷が高くなります。組織内のメッセージング量が非常に多く、マル
チロール構成、コンバインドロール構成で負荷を処理しきれない環境では、単体ロー
ル構成とすることを推奨します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
9
2.2 仮想化の考え方
仮想化は、UM サーバー ロールを除いて物理サーバーと同様にマルチロール、コ
ンバインドロール、単体ロールの構成が可能です。また利用する物理サーバーを減
らす事が出来るので、ブランチオフィスやサーバ統合シナリオ向けのソリューショ
ンに最適です。
仮想環境では CPU、メモリ等のリソースの割り当てを柔軟に行うことが可能です
が、仮想環境特有の考慮事項もあります。仮想環境特有の考慮事項は主に下記とな
ります。
 最大の仮想プロセッサ コア数
仮想化プラットフォームでサポートされる仮想プロセッサ コア数の最大数を
確認し、Exchange サーバー ロールに割り当てる CPU を決定してください。
 CPU オーバヘッド
仮想マシン内のゲスト OS のオーバーヘッドは約 9% - 12% です。例えば
MBX サーバー ロールで利用を考えた場合、同一のハードウェアであれば物理
サーバーと比較してホストするユーザー数を 10% 削減することを考慮してく
ださい。
Exchange Server 2010 の仮想化とその他の考慮事項の詳細に関しては「サーバ仮
想化における システム構成ガイド ホワイト ペーパー 第 2 版」を参照してくだ
さい。
Exchange Server 2010 サイジングガイド ホワイトペーパー
10
2.3 冗長化の考え方
冗長化は、障害発生時に継続してサービスを提供する上で、非常に重要となります。
冗長構成をとる場合、縮退運用の要件をベースにサイジングを行うことが重要とな
ります。
各 Exchange サーバー ロールの冗長化の考え方について、以下に説明します。
2.3.1
MBX サーバー ロールの冗長化
メールボックス DB およびそれに含まれるデータは、すべての Exchange 組織に
とって最も重要なコンポーネントです。障害発生時にエンドユーザーへの影響を最
小限に抑え、サービスを継続して提供したい場合は MBX サーバーを冗長化します。
Exchange 2010 で MBX サーバーを冗長化するには、データベース可用性グルー
プ (DAG) を構成します。
DAG は、Exchange 2010 で導入された、DB レベルの冗長化機能です。最大 16 台
の MBX サーバーでメールボックス DB のコピーを格納できます。コピーされた
DB はどのサーバーでもマウントできます。そのため、ディスク障害やサーバー障
害だけでなく、メールボックス DB のみの障害発生時でも、影響を最小限にして切
り替えが可能です。
MBX1
MBX2
MBX3
MBX4
アクティブ化
DB1
DB1
DB2
DB2
DB1
アクティブ化
DB2
DB3
DB4
アクティブ DB コピー
DB3
DB3
DB4
DB4
パッシブ DB コピー
運用中のユーザー メールボックスを含む DB コピーをアクティブ DB コピーと
呼び、障害に備えて待機する DB コピーをパッシブ DB コピーと呼びます。障害
発生時は、影響を受けるアクティブ DB コピーに対するパッシブ DB コピーをア
クティブ化し、障害からの復旧を実現します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
11
DAG を構成する場合は、以下のサイジングに影響があります。
 ディスク容量
DB コピーの数に応じた追加の容量が必要です。
 CPU リソース
DB コピーの管理やレプリケーションのために、追加の CPU リソースが必要
です。
 メモリ容量
DB が増えるとメモリ容量の要件が増加する可能性があります。
MBX サーバーの冗長化の詳細に関しては「Exchange Server 2010 可用性ガイド」
を参照してください。
2.3.2
MBX サーバー ロール以外の Exchange サーバー ロールの冗
長化
CAS サーバー、HUB サーバー、Edge サーバー、および UM サーバーの各
Exchange サーバー ロールにおける冗長化は、サーバーの冗長化、負荷分散、お
よびドメイン ネーム システム (DNS) ラウンド ロビンを組み合わせることで実
現されます。
 CAS サーバー
ネットワーク負荷分散 (NLB) またはハードウェア負荷分散装置を使用するこ
とで、高可用性を実現します。
 HUB サーバー
複数台の HUB サーバーを展開することで、自動的に負荷分散が行われます。
 Edge サーバー
複数の Edge サーバーを展開して、DNS MX ラウンド ロビンにより、サー
バー間で処理の負荷分散を行います。
また、NLB を使用して負荷分散と高可用性を実現することもできます。
 UM サーバー
複数の UM サーバーを展開して、VoIP (Voice over IP) ゲートウェイを構成す
ることで、UM サーバーに対する呼び出しをラウンド ロビン方式でルーティ
ングすることができます。
Exchange Server 2010 サイジングガイド ホワイトペーパー
12
2.4 CPU サイジングの考え方
2.4.1
CPU サイジングの概要
Exchange 2010 はマルチコア プロセッサで実行される場合に、大きな利点をもた
らします。マルチコア テクノロジによって Exchange にもたらされるパフォーマ
ンス上の利点は、使用されている CPU によって異なります。特定のハードウェア
アーキテクチャにおけるマルチコア プロセッサの利点については、ご使用のサー
バー ハードウェア ベンダーに問い合わせてください。サーバーの CPU がパ
フォーマンスに影響する要素は、以下のように複数存在します
 CPU の種類
Windows Server 2008 x64 版もしくは Windows Server 2008 R2 が動作する
x64 互換 CPU が Exchange 2010 でサポートされますが、Itanium ベース
のシステムでは動作いたしません。
x64 互換 CPU には Intel がサポートする Intel 64 と AMD がサポートす
る AMD 64 があります。各 CPU の詳細に関しては下記を参照してください。

インテル® 64 アーキテクチャ
http://www.intel.co.jp/jp/technology/intel64/index.htm

AMD Opteron™ プロセッサ・ファミリー
http://www.amd.com/jp-ja/Processors/ProductInformation/0,,30_118_88
25,00.html
 CPU の数
Exchange は複数のプロセッサに完全に対応しており、サーバーで使用する
CPU の数を増やすとパフォーマンスが向上します。ただし、CPU の数、プロ
セッサ コアの数、およびパフォーマンスの関係は複雑です。最適な CPU と
プロセッサ コアの数は、サーバーに展開されている Exchange サーバー
ロールによってある程度決まります。
 CPU のクロック速度
最速の CPU を選択すれば最高のパフォーマンスを得ることができますが、予
算とコストを検討して最適なクロック速度の CPU の選定を行ってください。
Exchange Server 2010 サイジングガイド ホワイトペーパー
13
CPU サイジングは、マルチロールを除き、以下の流れで行います。
1.
MBX サーバーの CPU を決定します。
詳細に関しては「3.1 MBX サーバー ロールのサイジング」を参照してくださ
い。
2.
MBX サーバー以外のサーバーの CPU は、MBX サーバー ロールと他の
Exchange サーバー ロールとのプロセッサ コア数の比率から決定します。
マルチロール サーバーの CPU サイジングの詳細に関しては、
「3.5 マルチロール
のサイジング」を参照してください。
CPU は、マイクロソフトが提示している最小と最大のプロセッサ コア数の範囲で
決定することを推奨します。また、CPU サイジングの注意事項に従って CPU を
決定する必要があります。
2.4.2
MBX サーバー ロールと各 Exchange サーバー ロールのプロ
セッサ コア数比率
MBX サーバー ロールと各 Exchange サーバー ロールのプロセッサ コア数の比
率は、以下の通りです。
Exchange サーバー ロールの構成
推奨されるプロセッサ コア数の比率
MBX サーバー : HUB サーバー
(HUB にウイルス対策スキャンなし)
7:1
(HUB にウイルス対策スキャンあり)
5:1
MBX サーバー : CAS サーバー
4:3
MBX サ ー バ ー : コ ン バ イ ン ド
1:1
ロール サーバー
 比率は原則であり、すべての環境に有効であるとは限りません。また、この比率
はサポート要件ではありません。
 比率は、プロファイルに基づいて大幅に変更できます。例えば、HUB サーバー
ロールよりも MBX サーバー ロールに対して負荷が大きいと予期される場合
は、比率を増やします。また、この逆の場合も同様です。
 MBX サーバー ロールと他の Exchange サーバー ロールの CPU は、同じ種
類で同じクロック数の CPU であることを前提としています。
 上記の推奨比率は、プロセッサ コアあたり約 750 人で、ユーザーあたりの 1 日
の平均メール送受信数が 100 通 (Exchange 2007 では高負荷ユーザー) の環
Exchange Server 2010 サイジングガイド ホワイトペーパー
14
境における、マイクロソフトの社内運用実績に基づく比率です。
 サーバーの障害時に中断しないサービスを提供するためには、プロセッサ コア比
率に関わらず最低でも 2 つの HUB サーバーと 2 つの CAS サーバーが展
開され、冗長化されている必要があります。
 ウイルス対策スキャンを含む HUB サーバー ロールの比率は、5 つのスキャン
エンジンを実行している Microsoft Forefront Protection 2010 for Exchange
Server を使用して取得されています。
 CAS サーバー ロールの比率には、すべてのアクセス プロトコル用の SSL
(Secure Sockets Layer) の使用が含まれています。
2.4.3
最小と最大のプロセッサ コア数の範囲
プロセッサ コア数の最小要件と推奨最大要件は下記のように定義しています。
 最小要件
Exchange サーバー ロールに対して適切な最小のプロセッサ コア数です。マ
イクロソフト カスタマー サポートからサポートを受けるには、提示している
CPU の最小要件を満たす必要があります。

推奨最大要件
Exchange サーバー ロールに対して定義される推奨最大プロセッサ コア数
です。最大とは、リソースを効率良く使用できる上限であり、推奨とは、価格
とパフォーマンスを基にした最適な構成です。設計時には負荷や要件を考慮し
た最小要件を満たすリソースを選択する必要があります。この定義は価格やテ
クノロジーの変遷に伴い、今後変更される可能性があります。
マイクロソフトが提示している、各 Exchange サーバー ロールの 1 台あたりの
最小要件と推奨最大要件のプロセッサ コア数は次の通りです。
Exchange
CPU の最小要件
CPU の推奨最大要件
ロール
(プロセッサ コア数)
(プロセッサ コア数)
Edge サーバー
1 プロセッサ コア
12 プロセッサ コア
HUB サーバー
1 プロセッサ コア
12 プロセッサ コア
CAS サーバー
2 プロセッサ コア
12 プロセッサ コア
UM サーバー
2 プロセッサ コア
12 プロセッサ コア
MBX サーバー
2 プロセッサ コア
12 プロセッサ コア
コンバインドロール
2 プロセッサ コア
12 プロセッサ コア
2 プロセッサ コア
24 プロセッサ コア
サ ー バ ー
サーバー
マルチロール サーバー
Exchange Server 2010 サイジングガイド ホワイトペーパー
15
2.4.4
CPU サイジングの注意事項
CPU サイジングの注意事項は以下の通りです。
 Exchange サーバーの CPU 使用率は、ピーク時 (縮退運用も含む) でも約 60%
までに抑えることを推奨します。CPU 使用率をこのレベルに保つことにより、
極度に負荷がかかった場合でも対応できる余裕が確保されます。CPU 使用率
が 75% を超える状態が続く場合、CPU のパフォーマンスがボトルネックに
なっていると見なされます。
 Exchange サーバーに搭載する CPU では、ハイパースレッディング機能はデ
フォルトで無効にしてください。追加のハードウェアを入手できるまで、CPU
容量を増加させるための一時的な容量として使用する場合のみ有効にしてくだ
さい。
仮想環境に Exchange を導入する場合、以下の点に注意してください。
 最大の仮想プロセッサ コア数
仮想化プラットフォームでサポートされる仮想プロセッサ コア数の最大数を
確認し、Exchange サーバー ロールに割り当てる CPU を決定してください。
 仮想マシンのオーバヘッドについて
仮想マシン内のゲスト OS のオーバーヘッドは約 9% - 12% です。例えば
MBX サーバー ロールで利用を考えた場合、同一のハードウェアであれば物理
サーバーと比較してホストするユーザー数を 10% 削減することを考慮してく
ださい。
Exchange Server 2010 サイジングガイド ホワイトペーパー
16
2.5 メモリ サイジングの考え方
2.5.1
メモリ サイジングの概要
Exchange サーバー ロールに必要なプロセッサ コア数のサイジング後、メモリの
推奨容量をサイジングすることができます。64 ビット版 Windows Server 2008
上の MBX サーバーは、64 GB 以上のメモリも効率的に利用することができます。
Exchange 2010 のハードウェアを選択するときは、サーバーの最大メモリ構成を
考慮することを推奨します。サーバーのアーキテクチャが異なると、メモリの制限
も異なります。以下に示すサーバーの技術仕様を確認し、そのサーバーで最も費用
対効果の高いメモリ構成にすることを推奨します。
 メモリ速度
一部のサーバー アーキテクチャでは、サポートする最大のメモリ容量へ拡張す
るために、低速なメモリ モジュールが必要とされる場合があります。必要なメ
モリ容量と速度が両立することを製造元に確認してください。
 メモリ モジュールのサイズ
一般的には大容量のメモリ モジュールほど高価なため、必要なメモリ容量と価
格のバランスを考慮してください。
 メモリ スロットの合計数
サーバーでサポートされるメモリ モジュール数を考慮してください。メモリ
モジュールは、ペアで取り付けることが必要な場合があることに注意してくだ
さい。
多くのメモリ スロットを使用すると、パフォーマンスが向上するサーバーもあれば、
パフォーマンスが低下するサーバーもある点に注意してください。この点がサー
バー アーキテクチャに与える影響については、ハードウェア ベンダーに確認して
ください。
2.5.2
最小と最大のメモリ容量の範囲
MBX サーバー、マルチロール サーバーを除いた各 Exchange サーバー ロールの
メモリ容量の推奨要件は、プロセッサ コア数から見積ります。MBX サーバー、マ
ルチロール サーバーのメモリ容量はサーバーに搭載する DB キャッシュから見積
ります。メモリ容量は、マイクロソフトが提示しているメモリ容量の最小要件を満
たしてください。メモリ容量の最小要件と推奨要件は下記のように定義しています。
Exchange Server 2010 サイジングガイド ホワイトペーパー
17
 最小要件
Exchange 2010 サーバーに対して適切な最小のメモリ構成です。マイクロソ
フト カスタマーサポートからサポートを受けるには、提示しているメモリ容量
の最小要件を満たす必要があります。
 推奨要件
Exchange サーバー ロールに対して定義される推奨メモリ構成です。推奨と
は、価格とパフォーマンスを基にした最適な構成です。設計時には負荷や要件
を考慮した最小要件を満たすリソースを選択する必要があります。この定義は
価格やテクノロジーの変遷に伴い、今後変更される可能性があります。
各 Exchange サーバー ロールの 1 台あたりの、メモリ容量の最小要件と推奨要
件は次の通りです。
Exchange サ ー
メモリ容量
バー ロール
の最小要件
Edge サーバー
4 GB
1 プロセッサ コアあたり 1 GB
HUB サーバー
4 GB
1 プロセッサ コアあたり 1 GB
CAS サーバー
4 GB
1 プロセッサ コアあたり 2 GB
UM サーバー
4 GB
1 プロセッサ コアあたり 2 GB
MBX サーバー
4 GB
4 GB ＋ ユーザー メールボックス数
メモリ容量の推奨要件
× DB キャッシュ
コンバインド
4 GB
1 プロセッサ コアあたり 2 GB
10 GB
(4 プロセッサ コア サーバー)
ロール サーバー
マルチロール
サーバー
10 GB ＋ ユーザー メールボックス数
× DB キャッシュ
(8 プロセッサ コア サーバー)
14 GB ＋ ユーザー メールボックス数
× DB キャッシュ
(12 プロセッサ コア サーバー)
18 GB ＋ ユーザー メールボックス数
× DB キャッシュ
(16 プロセッサ コア サーバー)
22 GB ＋ ユーザー メールボックス数
× DB キャッシュ
(24 プロセッサ コア サーバー)
30 GB ＋ ユーザー メールボックス数
× DB キャッシュ
Exchange Server 2010 サイジングガイド ホワイトペーパー
18
 Edge サーバーおよび HUB サーバー
Edge サーバーおよび HUB サーバーでは、最適な条件でのパフォーマンスを
得るために、大量のメモリは必要としません。通常は、1 プロセッサ コアあ
たり 1 GB (最小で 4 GB) の RAM があれば、非常に高い負荷を除き、ほとん
どの負荷に対応することができます。
 CAS サーバー
CAS サーバーでは、クライアント接続の数およびトランザクション速度と比
例的な関係にあります。CPU およびメモリ構成の推奨事項 (1 プロセッサ コ
アあたり 2 GB) に基づいて構成した CAS サーバーでは、メモリとプロセッ
サの使用率に関してバランスがとられ、メモリが限度に達するのとほぼ同時に
CPU も限度に達します。これらの推奨事項は、Exchange 2010 の機能、RPC
クライアントアクセスに基づいています。CAS サーバーにかかる負荷が増加
した場合は、より大きなメモリとプロセッサ構成が必要となります。
 MBX サーバー
MBX サーバーのメモリ構成プロセスは、他のロールよりも複雑です。これは、
プロセッサ コアの要件の予測と同じように、最適なメモリ構成がユーザー
メールボックス数、プロファイル、およびアクティブな DB 数に依存している
ためです。
MBX サーバーのメモリ サイジングは、サーバー上のディスク I/O を減らす
上で重要です。MBX サーバーに多くのメモリを追加すると、メモリに展開さ
れた DB キャッシュにより、Exchange によって生成されるディスク I/O が
大幅に軽減されます。しかし、サーバーにメモリを追加しても、そのメモリ価
格の上昇と見合うパフォーマンスの上昇が見られなくなるポイントがあります。
MBX サーバーの推奨要件は、このポイントを考慮すると共に、現在のメモリ
価格およびパフォーマンスの指標に基づいています。
MBX サーバーに適したメモリ サイジングの詳細に関しては「3.1 MBX サー
バー ロールのサイジング」を参照してください。
 マルチロール サーバー
マルチロール サーバーのメモリ要件を決定する際は、HUB サーバー ロール、
CAS サーバー ロール、および MBX サーバー ロールのそれぞれの要件を考
慮する必要があります。
マルチロール サーバーに適したメモリ サイジングの詳細に関しては「3.5 マ
ルチロールのサイジング」を参照してください。
Exchange Server 2010 サイジングガイド ホワイトペーパー
19
2.6 ディスク サイジングの考え方
2.6.1
ディスク サイジングの概要
企業によるサーバー統合が増えている現在、ディスクのサイジングを行う際は、コ
スト、可用性、パフォーマンスのバランスをとる必要があります。また、CPU や
メモリはシステムを停止しなくても拡張できますが、ディスクを再設計するにはシ
ステムの停止が必要になる場合があります。そのため、ディスクのサイジングは十
分な時間をかけて適切に行ってください。
ストレージ アーキテクチャを選択する場合、容量とパフォーマンスは両立しないこ
とが多いため、通常は次の要素を検討し、以下をすべて満たすストレージ アーキテ
クチャを決定することを推奨します。
 すべてのデータを格納するために十分な領域を確保できるか
ディスク容量のサイジング結果から判断します。
 ソリューションによって提供されるディスク性能とユーザー レスポンスが許容
範囲か
ディスク性能のサイジング結果から判断します。
 トランザクション以外の I/O に対して、ディスク レスポンスとスループットを
確保できるか
ディスク性能のサイジング結果から判断します。
2.6.2
サポート対象のストレージ システム
Exchange 2010 でサポートしているストレージ構成、物理ディスクの種類を説明
します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
20
 サポート対象 / 未サポートのストレージ システム構成
以下に、サポート対象と未サポートのストレージ システム構成を説明します。
ストレージ構成
説明
Direct Attached DAS とは、ストレージ ネットワークを挟ま
Storage (DAS)
サポート状況
○
ずにサーバーやワークステーションに直接
接続されるストレージ システムです。
Area SAN とは、リモートのディスク アレイや
Storage
○
Network (SAN) : テープ ライブラリなどをサーバーからロー
iSCSI
カル接続のように認識させる構成です。
iSCSI は、SCSI コマンドを IP パケット内
にカプセル化し、標準ネットワーク (イーサ
ネット) をストレージ転送に使用します。
iSCSI 構成とする場合は、以下を考慮してく
ださい。
・Exchange データと他のアプリケーション
データを同じ物理ディスクで共有しない
でください。
・専用ネットワークを使用してください。
・スタンドアロン構成では、複数のネット
ワーク パスを使用してください。
Area FC 構成の SAN は、SCSI コマンドを FC
Storage
○
Network (SAN) : パケット内にカプセル化し、専用 FC ネット
Fibre
Channel ワークをストレージ転送に使用します。
(FC)
FC 構成とする場合は、以下を考慮してくだ
さい。
・Exchange データと他のアプリケーション
データを同じ物理ディスクで共有しない
でください。
・スタンドアロン構成では、複数の FC パス
を使用してください。
・Queue Depth や Queue Target などの
FC ホスト バス アダプター (HBA) の最
適なチューニングは、ストレージ ベン
ダーにお問合わせください。
Network
NAS は、ネットワーク上の他のデバイスに
×
Attached
ファイルベースのデータ ストレージ サー
(未サポート)
Storage (NAS)
ビスを提供する目的でネットワークに接続
される自己完結型のコンピューターです。
Exchange Server 2010 サイジングガイド ホワイトペーパー
21
 サポート対象の物理ディスクの種類
以下に、サポート対象の物理ディスクの種類を説明します。
物理ディスク
説明
ベストプラクティス
SATA は 、 Advanced Technology
・最適なデータ信頼性と
Attachment (ATA) と Integrated
I/O 性能のためには、バッ
Device Electronics (IDE) ディスク
テリー バックアップ機能
の種類
SATA
のシリアルインターフェースです。 を搭載したアレイ コント
一般的に、SATA ディスクは、大容
ローラーが必要です。
量、適度な性能、適度な電源使用率
・Uninterruptable Power
が設計の要件であった場合に、
Supply (UPS) を使用しな
Exchange 2010 メールボックスと
い場合は、物理ディスクの
して選択されます。
書き込みキャッシュを無
効にする必要があります。
・SATA ディスクを構成す
る場合は、発熱量、振動、
信頼性のよいエンタープ
ラ イ ズ ク ラ ス の SATA
ディスクを推奨します。
SAS
SAS は、SCSI ディスクのシリア
UPS を 使 用 し な い 場 合
ルインターフェースです。
は、物理ディスクの書き込
一般的に、SAS ディスクは、大容
みキャッシュを無効にす
量、高性能、適度な電源使用率が設
る必要があります。
計の要件であった場合に、
Exchange 2010 メールボックスと
して選択されます。
Fibre
ファイバーチャネル (FC) は、SAN
UPS を 使 用 し な い 場 合
Channel (FC)
構成で利用する電気的なインター
は、物理ディスクの書き込
フェースです。
みキャッシュを無効にす
一般的に、FC ディスクは、適度な
る必要があります。
容量、高性能、SAN 接続が設計の
要 件 で あ っ た 場 合 に 、 Exchange
2010 メールボックスとして選択さ
れます。
SSD
Disk)
(Flash
Solid State Drive (SSD) は、半導
・UPS を使用しない場合
体メモリーを使用して、永続的に
は、物理ディスクの書き込
データを格納するストレージ装置
みキャッシュを無効にす
です。
る必要があります。
一般的に、SSD ディスクは、低容
・ 一 般 的 に 、 Exchange
量、超高性能が設計の要件であった
2010 メールボックスは、
Exchange Server 2010 サイジングガイド ホワイトペーパー
22
場 合 に 、 Exchange 2010 メ ー ル
SSD の性能特性を必要と
ボックスとして選択されます。
しません。
Exchange Server 2010 サイジングガイド ホワイトペーパー
23
2.7 ネットワーク サイジングの考え方
Exchange 2010 のネットワーク サイジングを考える上での考慮点は、以下の 3
点です。
 最新のネットワーク ドライバを維持することを推奨します
 1 Gbps 以上のネットワークを備える事を推奨します
 ギガビット イーサネット接続の、複数スイッチを備えた高速イーサネット ネッ
トワークを推奨します
Exchange Server 2010 サイジングガイド ホワイトペーパー
24
2.8 Active Directory サーバー サイジングの考え方
MBX サーバーまたはユーザーを含む各サイトにある Active Directory サーバー
の推奨される数は、MBX サーバー ロールを実行する各コンピューターのプロセッ
サ コア数と Active Directory を実行するハードウェア プラットフォームに依存
します。Active Directory を実行するハードウェア プラットフォームにより、以
下の違いがあります。
 Active Directory が x86 プラットフォーム (32 ビット) で実行されている場
合
Active Directory サーバーのプロセッサ コア数と MBX サーバーのプロセッ
サ コア数の推奨比率は 1 : 4 です。
 Active Directory が x64 プラットフォーム (64 ビット) で実行されている場
合
Active Directory サーバーのプロセッサ コア数と MBX サーバーのプロセッ
サ コア数の推奨比率は 1 : 8 です。この比率を実現するために、Active
Directory サーバーのメモリ容量は、Active Directory DB 全体をキャッシュ
するために十分な量が必要です。Active Directory DB のサイズを確認するに
は、グローバル カタログ サーバーの NTDS.DIT ファイルを調べてください。
既定では、このファイルは%WINDIR%¥NTDS にあります。
上記の比率から、4 プロセッサ コアの MBX サーバーごとに 1 プロセッサ コア
の 32 ビット グローバル カタログ サーバーを、または 8 プロセッサ コアの
MBX サーバーごとに 1 プロセッサ コアの 64 ビット グローバル カタログ
サーバー (Active Directory DB 全体をキャッシュ可能なメモリが実装されている
ことが前提) を展開することを推奨します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
25
第三部
各 Exchange サーバー ロールのサイジング
この章では、Exchange サーバー ロールである、MBX サーバー
ロール、CAS サーバー ロール、HUB サーバー ロール、コンバイ
ンドロール、マルチロール、Edge サーバー ロール、UM サーバー
ロールのサイジング手順を説明しています。
Exchange Server 2010 サイジングガイド ホワイトペーパー
26
3.1 MBX サーバー ロールのサイジング
ここでは、MBX サーバー ロールのサイジング方法を解説します。
MBX サーバー ロールのサイジングは、以下の手順で実施します。
1. サイジングに必要な要素の確認
MBX サーバー ロールのサイジングに必要となる要素を確認します。
2. CPU のサイジング
必要となる CPU クロック速度、プロセッサ コア数、個数を決定します。
3. メモリのサイジング
必要となるメモリ容量を決定します。
4. ディスク容量のサイジング
必要となるディスク容量を決定します。
5. ディスク性能のサイジング
必要となるディスクの IOPS 値を決定します。
Mailbox Server Role Requirements Calculator について
Exchange 2010 Mailbox Server Role Requirements Calculator を使用すると、一連の入力要素を指定す
ることで、MBX サーバー ロールの要件を確認できます。計算用シートで、メモリ、ストレージ (I/O パフォーマンス、
容量、および記憶域構成)、最適な LUN レイアウト、CPU メガサイクルの要件を確認できます。MBX サーバー
の最適なソリューションを設計するには、多数の変数を考慮する必要があり、計算用シートを用いると設計プロセ
スでの作業が容易になります。Exchange 2010 Mailbox Server Role Requirements Calculator の詳細に
関しては「付録 A ツールの紹介」を参照してください。
3.1.1
サイジングに必要な要素の確認
MBX サーバー ロールのサイジングをする場合に必要となる要素を事前に決定し
ておく必要があります。必要な要素とその影響範囲は以下の通りです。
 プロファイル
ユーザーあたりの 1 日の平均メール送受信数、平均メールサイズです。プロ
ファイルからユーザー メールボックスあたりの基準値を導くため、すべてのサ
イジングに影響します。
 ユーザー メールボックス数
システム全体のユーザー メールボックス数です。プロファイルから導くユー
ザー メールボックスあたりの基準値と組み合わせて必要な性能を算出するた
め、すべてのサイジングに影響します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
27
 メールボックス サイズ クォータ
ユーザーに割り当てる最大のメールボックス サイズです。ディスク容量のサイ
ジングに影響します。
 DAG 構成の有無
DAG 構成の有無は、サイジングの手順に影響します。以降で説明するサイジ
ング手順は、DAG 構成をとることを前提としています。DAG を構成しない
場合は、以降で説明するサイジング手順の中で不要な手順もありますが、追加
で必要な特別な手順はありません。
 サーバーでホストするアクティブ メールボックス数
サーバーでピーク時にホストする最大アクティブ メールボックス数です。ピー
ク時のアクティブ メールボックス数は縮退運用ポリシーなどに依存し決定さ
れます。この数値はすべてのサイジングに影響します。
3.1.2
CPU のサイジング
MBX サーバー ロールに必要な CPU は、以下の手順でサイジングします。
1.
CPU のサイジングに必要な要素の確認
2.
CPU 要件の算出
3.
CPU の選定
以下に、それぞれの手順について説明します。
3.1.2.1
CPU のサイジングに必要な要素の確認
CPU のサイジングを行うために、以下の要素が必要です。
 1 つのアクティブ DB コピーに対して他のサーバーへ作成するパッシブ DB
コピー数
DAG を構成しない場合は必要ありません。
 1 サーバーでホストするパッシブ メールボックス数
DAG を構成しない場合は必要ありません。
縮退運用時の数をサイジングに使用します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
28
3.1.2.2
CPU 要件の算出
MBX サーバー ロールの CPU 要件は以下の式で算出します。CPU 要件はメガサ
イクル (CPU クロック数 × プロセッサ コア数) で算出します。
注意事項
メガサイクルの算出は、Intel Xeon x5470 3.33 GHz CPU (4 つのプロセッサ コア) の場合、3.33 GHz CPU の
1 プ ロセ ッ サ コアあ たり 約 3,300 メガサ イクル とな りま す。他の プ ロセ ッ サ構成 につ いては 、 Standard
Performance Evaluation Corporation (SPEC) によってテストされたサーバー プラットフォームを比較して確認
できます。詳細に関しては、「Standard Performance Evaluation Corporation」にある SPEC CPU2006 の
結果を参照してください。
MBX サーバー ロールの CPU 要件
= アクティブ メールボックスのホストに必要な CPU 要件
＋ パッシブ DB コピーへのレプリケーションに必要な CPU 要件
＋ パッシブ メールボックスのホストに必要な CPU 要件
上式の各 CPU 要件は、以下の手順で算出します。
 アクティブ メールボックスのホストに必要な CPU 要件
アクティブ メールボックスのホストに必要な CPU 要件は以下の式で算出し
ます。
アクティブ メールボックスのホストに必要な CPU 要件
= アクティブ メールボックス数
× アクティブ メールボックスあたりに必要な CPU 要件
アクティブ メールボックスあたりに必要な CPU 要件は、プロファイルに応
じて、以下の表から求めることができます。
プロファイル
CPU 要件
(平均メール送受信数)
(メガサイクル、アクティブ
メールボックスあたり)
50
1
100
2
150
3
200
4
250
5
300
6
350
7
400
8
450
9
Exchange Server 2010 サイジングガイド ホワイトペーパー
29
500
10
 パッシブ DB コピーへのレプリケーションに必要な CPU 要件
DAG を構成する場合、1 つのアクティブ DB コピーに対していくつのパッシ
ブ DB コピーを配置するかは、高可用性を考慮する場合に重要な要素ですが、
サイジングにおいても重要な要素となります。
パッシブ DB コピーの数を増やすたびに、アクティブ DB コピーをホストし
ているサーバーで行う作業が増えます。追加作業は、主にログ レプリケーショ
ンとコンテンツのインデックス処理です。この追加作業に必要な CPU 要件は、
アクティブ DB コピーをホストするために必要な CPU 要件の 10% です。
この追加要件はパッシブ DB コピーごとに必要なため、追加の CPU 要件は
以下の式で算出します。
パッシブ DB コピーへのレプリケーションに必要な CPU 要件
= アクティブ メールボックスのホストに必要な CPU 要件 × 10%
× 他のサーバーへ作成するパッシブ DB コピー数
 パッシブ メールボックスのホストに必要な CPU 要件
プロファイルから、パッシブ メールボックスあたりに必要な CPU 要件が求
まります。この値を用いてパッシブ メールボックスのホストに必要な CPU
要件を算出できます。必要な CPU 要件は以下の式で算出します。
パッシブ メールボックスのホストに必要な CPU 要件
= パッシブ メールボックス数
× パッシブ メールボックスあたりに必要な CPU 要件
パッシブ メールボックスあたりに必要な CPU 要件は、プロファイルに応じ
て、以下の表で求めることができます。
プロファイル
CPU 要件
(平均メール送受信数)
(メガサイクル、パッシブ
メールボックスあたり)
50
0.15
100
0.30
150
0.45
200
0.60
250
0.75
300
0.90
350
1.05
400
1.20
Exchange Server 2010 サイジングガイド ホワイトペーパー
30
3.1.2.3
450
1.35
500
1.50
CPU の選定
算出した CPU 要件から、以下の式を満たす CPU を選定します。
プロセッサ コア数 × クロック数 (MHz) × CPU の数 × CPU 使用率
＞ 算出した CPU 要件
DAG を構成しない場合、CPU 使用率は 70% までに抑えることを推奨します。
DAG を構成する場合、CPU 使用率は 80% までに抑えることを推奨します。
また、MBX サーバー ロール には、以下に示す CPU の最小要件と推奨最大要件
があります。MBX サーバー ロールに搭載する CPU は、少なくとも最小要件を
満たす構成で決定してください。
Exchange サ ー バ ー
CPU の最小要件
CPU の推奨最大要件
ロール
(プロセッサ コア数)
(プロセッサ コア数)
MBX サーバー
2 プロセッサ コア
12 プロセッサ コア
Exchange Server 2010 サイジングガイド ホワイトペーパー
31
3.1.2.4
CPU のサイジング例
ここでは以下のようなシステム構成を想定し MBX サーバー ロールの CPU サ
イジング例を示します。
【システム構成図】
MBX1
MBX2
MBX3
DB1
DB1
DB1
DB2
DB2
DB2
DB3
DB3
DB3
DB4
DB4
DB4
DB5
DB5
DB5
DB6
DB6
DB6
DB7
DB7
DB7
DB8
DB8
DB8
DB9
DB9
DB9
MBX4
DB10
DB10
DB10
DB11
DB11
DB11
DB12
DB12
DB12
アクティブ DB コピー
パッシブ DB コピー
【システム要件】
要件
値
ユーザー メールボックス数
12,000 個
プロファイル
平均メール送受信数 150 通
平均メールサイズ 75 KB
1 アクティブ DB あたりのユー
1,000 個
ザー メールボックス数
可用性レベル
2 サーバー同時障害まで対応可能
Exchange Server 2010 サイジングガイド ホワイトペーパー
32
1 MBX サーバーでホストするア 6,000 個
クティブ メールボックス数
(縮退運用時)
サイジングは、縮退運用時の負荷を考慮して行います。本構成の要件では 2 サー
バー同時障害まで対応可能と定義しますので、障害発生時は下記の構成図のように
6,000 個のメールボックスをホストすることになります。
【システム構成図 (縮退運用時)】
MBX1
MBX2
MBX3
DB1
DB1
DB1
DB2
DB2
DB2
DB3
DB3
DB3
DB4
DB4
DB4
DB5
DB5
DB5
DB6
DB6
DB6
DB7
DB7
DB7
DB8
DB8
DB8
DB9
DB9
DB9
MBX4
DB10
DB10
DB10
DB11
DB11
DB11
DB12
DB12
DB12
アクティブ DB コピー
パッシブ DB コピー
Exchange Server 2010 サイジングガイド ホワイトペーパー
33
次のようにサイジングします。
1.
CPU のサイジングに必要な要素の確認
要件
値
根拠
1 つのアクティブ
2 個
2 サーバー同時障害に備え、3 つの
DB コピ ー に対 して
DB コピーが必要なため
作成するパッシブ
DB コピー数
1 MBX サーバーでホ
3,000 個
1 つのアクティブ DB コピーあた
ストするパッシブ
り 2 個のパッシブ DB コピーを配
メールボックス数
置するため、通常運用時の 1 サー
(縮退運用時)
バーあたりのユーザー メールボック
ス数は、3,000 個 (アクティブ DB
コピー) + 6,000 個 (パッシブ DB
コピー) で 9,000 個。
1 サーバーあたり 9,000 個のうち
縮退運用時のアクティブ メールボッ
クス数が 6,000 個のため、縮退運用
時のパッシブ メールボックス数は
3,000 個。
2.
CPU 要件の算出例
① アクティブ メールボックスのホストに必要な CPU 要件の算出
プロファイルから、アクティブ メールボックスあたりに必要な CPU 要件
は 3 メガサイクルです。
プロファイル
CPU 要件
(平均メール送受信数)
(メガサイクル、アクティブ
メールボックスあたり)
150
3
システム要件から、縮退運用時のアクティブ メールボックス数は 6,000
個であるため、必要な CPU 要件は以下のように算出します。
アクティブ メールボックスのホストに必要な CPU 要件
= 6,000 個 × 3 メガサイクル
= 18,000 メガサイクル
Exchange Server 2010 サイジングガイド ホワイトペーパー
34
② パッシブ DB コピーへのレプリケーションに必要な CPU 要件の算出
必要な CPU 要件は以下のように算出します。
パッシブ DB コピーへのレプリケーションに必要な CPU 要件
= 18,000 メガサイクル × 0.1 (10%) × 2 パッシブ DB コピー
= 3,600 メガサイクル
③ パッシブ メールボックスのホストに必要な CPU 要件の算出
プロファイルから、パッシブ メールボックスあたりに必要な CPU 要件は
0.45 メガサイクルです。
プロファイル
CPU 要件
(平均メール送受信数)
(メガサイクル、パッシブ
メールボックスあたり)
150
0.45
必要な CPU 要件は以下のように算出します。
パッシブ メールボックスのホストに必要な CPU 要件
= 3,000 個 × 0.45 メガサイクル
= 1,350 メガサイクル
④ MBX サーバー ロールの CPU 要件の算出
手順①～③の結果を合計し、MBX サーバー ロールの CPU 要件は以下の
ように算出します。
MBX サーバー ロールの CPU 要件
= 18,000 ＋ 3,600 ＋ 1,350
= 22,950 メガサイクル
3.
CPU の選定
縮退運用時に CPU 使用率が 80% を超えないようにするには、サーバーに搭
載する CPU は以下の式を満たす必要があります。
プロセッサ コア数 × クロック数 × CPU の数 × 0.8 [80%]
＞ 22,950 メガサイクル
MBX サーバー ロールに搭載する CPU は、少なくとも以下に示す最小要件を
満たす構成で決定してください。
Exchange サ ー バ ー
CPU の最小要件
CPU の推奨最大要件
ロール
(プロセッサ コア数)
(プロセッサ コア数)
Exchange Server 2010 サイジングガイド ホワイトペーパー
35
MBX サーバー
2 プロセッサ コア
12 プロセッサ コア
一例として、4 プロセッサ コアの CPU を 2 つ利用すると決定した場合 (合
計 8 プロセッサ コア)、搭載する CPU は以下の式を満たすものとなります。
クロック数 ＞ 22,950 メガサイクル ÷ 4 プロセッサ コア ÷ 2 CPU
÷ 0.8 = 3,585 MHz
上記の結果から、MBX サーバーには 3.6 GHz 以上の 4 プロセッサ コア
CPU を 2 つ搭載します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
36
3.1.3
メモリのサイジング
メモリは、以下の手順でサイジングします。
1.
DB キャッシュ総量の算出
2.
DB キャッシュ総量に基づくサーバーの物理メモリ容量の算出
3.
DB 数から導かれるメモリの最小容量の算出
4.
メモリサイズの決定
メモリサイズは、上記 2. と 3. で算出したメモリ容量から決定します。以下に、
それぞれの手順について説明します。
3.1.3.1
DB キャッシュ総量の算出
プロファイルと DB キャッシュは、サーバー上のディスク I/O と相関があります。
メモリ上に展開する DB キャッシュを適切に構成することにより、ユーザーからの
データ アクセスの際にキャッシュ上に存在するデータに関しては、ディスクへの読
み込み I/O が発生しないため、ディスクへの I/O を大幅に減少させることができ
ます。そのため DB キャッシュ容量を適切に構成する必要があります。また、DAG
構成の有無が IOPS 値に影響します。ディスク性能の詳細に関しては「3.1.5 ディ
スク性能のサイジング」を参照してください。
プロファイルと DB キャッシュに基づいたユーザー メールボックスあたりの
IOPS は以下になります。
プロファイル
DB キ ャ ッ
IOPS
IOPS
(平均メール送受信数)
シュ(MB)
(DAG 未構成時)
(DAG 構成時)
50
3
0.06
0.05
100
6
0.12
0.10
150
9
0.18
0.15
200
12
0.24
0.20
250
15
0.30
0.25
300
18
0.36
0.30
350
21
0.42
0.35
400
24
0.48
0.40
450
27
0.54
0.45
500
30
0.60
0.50
上記の表の IOPS 値は、プロファイルと DB キャッシュを決定した場合に予測さ
れる値です。必要な IOPS 値は、プロファイルや DB キャッシュの量によって変
Exchange Server 2010 サイジングガイド ホワイトペーパー
37
わります。本ガイドでは、上記の表のプロファイルと DB キャッシュの対応に従っ
てサイジングを行います。
DB キャッシュ総量は、以下の式で算出します。
DB キャッシュ総量
= アクティブ メールボックス数
× ユーザー メールボックスごとの DB キャッシュ
3.1.3.2
DB キャッシュ総量に基づくサーバーの物理メモリ容量の算出
「3.1.3.1 DB キャッシュ総量の算出」で算出した DB キャッシュ総量から、サー
バーに必要な物理メモリ容量を算出します。必要な物理メモリ容量は、以下の表か
ら求めることができます。
サーバーの物理
DB キャッシュ総量
DB キャッシュ総量
メモリ (RAM)
(MBX サーバー ロールのみ)
(マルチロール)
2 GB
512 MB
非サポート
4 GB
1 GB
非サポート
8 GB
3.6 GB
2 GB
16 GB
10.4 GB
8 GB
24 GB
17.6 GB
14 GB
32 GB
24.4 GB
20 GB
48 GB
39.2 GB
32 GB
64 GB
53.6 GB
44 GB
96 GB
82.4 GB
68 GB
128 GB
111.2 GB
92 GB
例えば、MBX サーバー ロールを単体ロールで構成し、DB キャッシュ総量が 15
GB の場合、サーバーの物理メモリは 24 GB となります。
注意事項
Active Directory の msExchESEParamCacheSizeMax および msExchESEParamCacheSizeMin 属
性を変更することで、既定の DB キャッシュ サイズの値を変更できます。属性の詳細に関しては、「Exchange
2000 Server で ス トア デ ー タベ ース の最 大キ ャ ッシ ュ サ イズを 変更 する 方法 」を 参照 してく だ さい 。
Exchange 2010 ではページサイズが 32 KB に変更になっている点に注意してください。
Exchange Server 2010 サイジングガイド ホワイトペーパー
38
3.1.3.3
DB 数から導かれるメモリの最小容量の算出
1 サーバーでホストする DB コピーの数から、メモリの最小容量が算出できます。
メモリの最小容量は、DB 数に応じて、以下の表で求めることができます。
DB 数
メモリの最小容量
1 ～ 10
2 GB
11 ～ 20
4 GB
21 ～ 30
6 GB
31 ～ 40
8 GB
41 ～ 50
10 GB
51 ～ 60
12 GB
61 ～ 70
14 GB
71 ～ 80
16 GB
81 ～ 90
18 GB
91 ～ 100
20 GB
このメモリ容量は、DB キャッシュを使用することで入出力 (I/O) 操作を減らす
ESE (Extensible Storage Engine) 機能を効率的に動作させるために必要です。
3.1.3.4
メモリサイズの決定
「3.1.3.2 DB キャッシュ総量に基づくサーバーの物理メモリ容量の算出」と
「3.1.3.3 DB 数から導かれるメモリの最小容量の算出」で算出したメモリ容量を比
較し、メモリ容量が大きい方を MBX サーバー ロールのメモリ容量とします。
Exchange Server 2010 サイジングガイド ホワイトペーパー
39
3.1.3.5
メモリのサイジング例
ここでは以下のようなシステム構成を想定し MBX サーバー ロールのメモリサイ
ジング例を示します。
【システム構成図】
MBX1
MBX2
DB1
DB1
DB2
DB2
MBX3
DB3
DB3
DB4
DB4
DB5
DB5
DB6
DB6
DB7
DB7
DB8
DB8
DB9
DB9
DB10
DB10
DB11
DB11
DB12
DB12
アクティブ DB コピー
パッシブ DB コピー
【システム要件】
要件
値
ユーザー メールボックス数
7,500 個
プロファイル
平均メール送受信数 100 通
平均メールサイズ 75 KB
1 アクティブ DB あたりのユー
625 個
ザー メールボックス数
1 サーバーの障害まで対応可能
可用性レベル
(3 メンバー 2 DB コピー構成)
1 MBX サーバーあたりの DB
8 個
数
1 MBX サーバーあたりのアク
3,750 個
Exchange Server 2010 サイジングガイド ホワイトペーパー
40
ティブ メールボックス数 (縮退
運用時)
サイジングは、縮退運用時の負荷を考慮して行います。本構成の要件では 1 サー
バーの障害まで対応可能と定義しますので、障害発生時は下記の構成図のように
3,750 個のアクティブ メールボックスをホストすることになります。
【システム構成図 (縮退運用時)】
MBX1
MBX2
DB1
DB1
DB2
DB2
MBX3
DB3
DB3
DB4
DB4
DB5
DB5
DB6
DB6
DB7
DB7
DB8
DB8
DB9
DB9
DB10
DB10
DB11
DB11
DB12
DB12
アクティブ DB コピー
パッシブ DB コピー
Exchange Server 2010 サイジングガイド ホワイトペーパー
41
以下のようにメモリサイジングを行います。
1.
DB キャッシュ総量の算出
プロファイルから、アクティブ メールボックスあたりの DB キャッシュは 6
MB です。
プロファイル
DB キャッシュ (MB)
(平均メール送受信数)
(アクティブ メールボックス
あたり)
100
6
システム要件から、1 MBX サーバーあたりのアクティブ メールボックス数
(縮退運用時) は 3,750 個のため、必要な DB キャッシュ総量は以下のように
算出します。
DB キャッシュ総量
= 3,750 個 × 6 MB
= 約 22 GB
2.
DB キャッシュ総量に基づくサーバーの物理メモリ容量の算出
DB キャッシュが 22 GB 必要なため、必要な物理メモリ容量は 32 GB です。
3.
サーバーの物理メモリ
DB キャッシュ 総量
(RAM)
(MBX サーバー ロールのみ)
32 GB
22 GB
DB 数から導かれるメモリの最小容量の算出
1 台あたり 8 DB をホストするため、最小限必要な物理メモリ容量は 2 GB で
す。
DB 数
1 ～ 10
4.
メモリの最小容量
2 GB
メモリサイズの決定
DB キャッシュ総量に基づくサーバーの物理メモリ容量 (32 GB) と DB 数
から導かれるメモリの最小容量 (2 GB) を比較した結果、32 GB がサーバーの
メモリ容量となります。
Exchange Server 2010 サイジングガイド ホワイトペーパー
42
3.1.4
ディスク容量のサイジング
ここでは、ディスク容量のサイジングとして、1 DB あたりのデータ容量とトラン
ザクション ログ容量のサイジング方法を説明し、最後に DB とトランザクション
ログの LUN 容量のサイジング方法を説明します。
ディスク容量は、以下の手順でサイジングします。
1.
サイジングに必要な要素の確認
2.
DB 容量の算出
3.
DB あたりのトランザクション ログ容量の算出
4.
必要な LUN 領域の算出
各章で説明するサイジング手順と、ストレージ上の配置を以下の図で示します。
ストレージ
メールボックス
LUN
LUN
3.1.4.2 DB 容量の算出
LUN
DB
インデックス
3.1.4.4 必要な LUN 容量の算出
LUN
LUN
3.1.4.3 DB あたりの
LUN
トランザクション ログ容量の算出
トランザクション
以下で、それぞれの手順について説明します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
43
3.1.4.1
サイジングに必要な要素の確認
ディスク容量のサイジングを行うために、以下の要素が必要です。
 メールボックス サイズ クォータ
ユーザーに割り当てる最大のメールボックス サイズです。システム要件から決
定してください。
 1 つのアクティブ DB コピーに対して他のサーバーへ作成するパッシブ DB
コピー数
MBX サーバーの可用性に関わります。システム要件から決定してください。
 DB サイズ
要件から決める DB サイズの上限値です。オーバヘッドやインデックス領域は
含みません。DB サイズは、システム要件に加え、以下の要素を考慮し決定し
てください。

バックアップからの復旧時間
バックアップからの復旧を計画する場合、復旧時間の要件から DB サイズ
を設計してください。
DB サイズとバックアップ ソリューションのアーキ
テクチャに依存してバックアップに要する時間が変動します。

DAG 構成によるバックアップ計画の有無
DAG により 1 つのアクティブ DB に対して複数のパッシブ DB コ
ピーを構成することで、第一のデータ復旧の対応策としてパッシブ DB コ
ピーを使用できます。複数のパッシブ DB コピーからの復旧が可能なため、
バックアップ ソリューションによる復旧データの取得を計画しない場合、
DB サイズは 2 TB のサイズまで設計することができます。

ディスク上の DB 配置
JBOD ストレージなどの 1 つのディスクに、1 つの DB と対応するトラ
ンザクション ログを配置するよう計画する場合、使用するディスク サイ
ズに応じて DB サイズを設計します。ディスク上には DB 以外に、コン
テンツ インデックスやトランザクション ログを配置する必要があり、す
べての領域が使用されることのないように、空き領域を考慮する必要があ
ります。
たとえば、1 TB のディスク (約 917 GB のフォーマット済み容量) を使
用する場合、トランザクション ログおよびコンテンツのインデックスも含
めて、使用可能な空き領域をすべて消費しないようにします。
Exchange Server 2010 サイジングガイド ホワイトペーパー
44
3.1.4.2
DB 容量の算出
DB 容量の算出は以下の手順で行います。
1.
ユーザー メールボックスあたりのデータ容量の算出
2.
DB あたりのユーザー メールボックス数の算出
3.
実際の DB 容量の算出
4.
コンテンツ インデックス領域の算出
5.
オーバーヘッドの考慮
6.
合計 DB 容量の算出
以下で、それぞれの手順を詳細に説明します。
1.
ユーザー メールボックスあたりのデータ容量の算出
ユーザー メールボックスあたりのデータ容量は、メールボックス サイズ
クォータに加え、空白領域とごみ箱領域を考慮する必要があります。
空白領域
アイテムの削除はすぐに DB へは反映されず、バックグラウンドの DB 保守
時に反映されます。そのため、アイテムの削除が反映されるまでデータを保持
しておく追加の領域が必要になります。この領域を空白領域と呼びます。ユー
ザー メールボックスあたりの空白領域は以下の式で算出します。
空白領域
= ユーザーあたりの 1 日の平均メール送受信数 × 平均メールサイズ
ごみ箱領域
既定では、削除済みアイテムは 14 日間、予定表アイテムは 120 日間保存さ
れるため、これらの容量が追加で必要です。さらに、Exchange 2010 には、
削除済みアイテムの保存機能とは別に、管理者によって有効にする「単一アイ
テムの回復」機能もあります。この機能を有効にすることにより (既定では無
効)、Outlook クライアントの削除済みアイテムの復元機能で表示されるメー
ルデータを削除した場合にもデータが保持されます。この機能を 14 日間保存
すると設定した場合、メールボックス サイズ クォータの 1.2% 分の容量が追
加で必要です。また、予定表 バージョン ログ データ (既定では有効) が有効
な場合、メールボックス サイズ クォータの 5.8% 分の容量が追加で必要です。
Exchange Server 2010 サイジングガイド ホワイトペーパー
45
上記の要素から、ユーザー メールボックスあたりのごみ箱領域は以下の式で算
出します。
ごみ箱領域
= (ユーザーあたりの 1 日の平均メール送受信数 × 平均メールサイズ
× 削除済みアイテム保存期間)
＋ (メールボックス サイズ クォータ × 1.2% [機能有効時] )
＋ (メールボックス サイズ クォータ × 5.8% [既定で有効] )
ユーザー メールボックスあたりのデータ容量は以下の式で算出します。
ユーザー メールボックスあたりのデータ容量
= メールボックス サイズ クォータ ＋ 空白領域 ＋ ごみ箱領域
2.
DB あたりの ユーザー メールボックス数の算出
DB あたりの ユーザー メールボックス数は、DB サイズの上限とユーザー
メールボックスあたりのデータ容量から、以下の式で算出します。小数点以下
は切り捨てます。DB サイズの上限の決定の詳細に関しては「3.1.4.1 サイジ
ングに必要な要素の確認」を参照してください。
DB あたりのユーザー メールボックス数
= 要件から決定した DB サイズの上限
÷ ユーザー メールボックスあたりのデータ容量
トランザクション以外の入出力 (I/O) やハードウェアの制限によりユーザー
メールボックス数の変更が必要になる場合があります。また、DB サイズを削
減するため、DB 数を多くする場合もあります。DB 数を増やし DB サイズを
削減することで、バックアップと復元の時間を短縮できる可能性があります。
Exchange 2010 では 1 MBX サーバーあたり 100 DB までサポートします
(パッシブ DB コピー含む)。
3.
実際の DB 容量の算出
実際の DB 容量は、1. で算出したユーザー メールボックスあたりのデータ容
量と 2. で算出した DB あたりのユーザー メールボックス数から算出できま
す。以下の式で算出します。
実際の DB 容量
= DB あたりのユーザー メールボックス数
× ユーザー メールボックスあたりのデータ容量
4.
コンテンツ インデックス領域の算出
コンテンツ インデックス処理により、ユーザーは手動でユーザー メールボッ
クス全体を検索するよりもすばやく簡単にメール アイテムを検索できます。
Exchange 2010 では DB 容量の約 10% のインデックスが作成され、DB と
同じディスクに配置されます。
コンテンツ インデックス領域は以下の式で算出
します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
46
コンテンツ インデックス領域
= 実際の DB 容量 × 10%
5.
オーバーヘッドの考慮
すべての要素を考慮して計算した後、オーバーヘッドとして追加でバッファ領
域を 20% 含めることを推奨します。この値によって、ユーザー メールボック
ス サイズや空白領域の計算時に明らかになっているとは限らない、
DB 内にあ
る他のデータ領域分が確保されます。
6.
合計 DB 容量の算出
上記で計算した値を合計し、合計 DB 容量を以下の式で算出します。
合計 DB 容量
= (実際の DB 容量 ＋ コンテンツ インデックス領域)
× (1 + オーバーヘッド要素[20%] )
また、以下に示す追加の領域が必要な場合があります。
 オフライン DB 保守用の容量 (オプション)
オフライン保守を行う場合、対象の DB サイズに 10% を加えた容量が必要に
なります。
※DAG を構成する場合、オフライン保守を実行するとすべての DB コピーが
無効にされ、
DB の再同期が必要になるため、マイクロソフト カスタマー サー
ビスおよびサポートから要請があった場合にのみ、実施してください。
 回復用 DB 用の容量 (オプション)
障害回復計画の一環として回復用 DB の使用を計画する場合は、そのサーバー
で同時に復元するすべての DB を処理するための十分な容量が利用できる必
要があります。詳細に関しては、Technet Exchange 2010 のヘルプ「回復用デー
タベース」を参照してください。
3.1.4.3
DB あたりのトランザクション ログ容量の算出
ここでは、DB あたりのトランザクション ログ ファイルに必要な容量を算出しま
す。トランザクション ログ ファイルは、DB エンジンによって実行されるすべて
のトランザクションの記録です。トランザクションはすべて、最初にトランザクショ
ン ログに書き込まれ、その後特定のタイミングで DB に書き込まれます。
Exchange 2003 とは異なり、Exchange 2010 ではトランザクション ログ ファイ
ルのサイズが 5 MB から 1 MB に削減されました。この変更は、連続レプリケー
ション機能をサポートし、
アクティブ DB コピーの障害が発生した場合にデータの
損失量を最小限に抑えるために行われました。
トランザクション ログ容量は、以下の 3 つの高可用性に関する要素に影響されま
す。
 DB コピー数
DAG を構成した場合のシステム全体のログ容量は、DB コピー数に基づいて
Exchange Server 2010 サイジングガイド ホワイトペーパー 47
増加します。例えば、3 台のサーバーにわたって分散された DB コピーが 3
つある場合は、各サーバーのコピーごとにログ容量を準備する必要があります。
 ログの切り詰めメカニズム
DAG を構成して DB コピーから障害復旧を行うなど、バックアップからの復
旧を計画しない場合は、バックアップ ソリューションによってログの切り詰め
は実施されないため、循環ログをログの切り詰め/削除メカニズムとして使用し
て古いログを切り詰め/削除する基盤が提供されます。
 DB コピーの再生ラグ
パッシブ DB コピーでトランザクション ログの再生を遅らせることで、DB
を過去の特定時点まで復元することができます。この機能により、望ましくな
いコンテンツのログが DB に再生される前に、再生を中断することにより、コ
ンテンツが時間差 DB コピーに再生されるのを中止することができます。
再生ラグを DB コピーで有効にすると (既定では無効)、ログ容量の要件がそ
れに従って変更されます。14 日間のラグを構成してある場合は、17 日分のロ
グを準備する必要があります。追加のログ容量が必要なのは、ラグを構成した
DB コピーのみで、ラグのない他のコピーには、通常の (時間差のない) ログ
容量の要件が適用されます。
DB あたりのトランザクション ログ容量の算出は、以下の手順で行います。
1.
DB あたりの 1 日分のトランザクション ログ生成数の算出
2.
バックアップと復元の考慮
3.
ユーザー メールボックスの移動に必要なトランザクション ログ容量の算出
4.
オーバーヘッドの考慮
5.
DB あたりのトランザクション ログ容量の算出
以下で、それぞれの手順を詳細に説明します。
1.
DB あたりの 1 日分のトランザクション ログ生成数の算出
DB あたりの 1 日分のトランザクション ログ生成数は、DB あたりのユー
ザー メールボックス数とユーザー メールボックスあたりの 1 日分のトラン
ザクション ログ生成数から算出できます。DB あたりの 1 日分のトランザク
ション ログ生成数は、以下のように算出します。
DB あたりの 1 日分のトランザクション ログ生成数
= DB あたりのユーザー メールボックス数
× ユーザー メールボックスあたりの 1 日分のトランザクション ロ
グ生成数
Exchange Server 2010 サイジングガイド ホワイトペーパー
48
ユーザー メールボックスあたりの 1 日分のトランザクション ログ生成数は、
プロファイルに依存します。以下の表に、プロファイルとユーザー メールボッ
クスあたりのトランザクション ログ生成数の関係を示します。
プロファイル
1 日あたりのトランザクショ
(平均メール送受信数、
ン ログ生成数 (ユーザー
平均メールサイズ: 75 KB)
メールボックス あたり)
50
10
100
20
150
30
200
40
250
50
300
60
350
70
400
80
450
90
500
100
平均メールサイズが異なる場合は、以下の様に算出します。

平均メールサイズが 150 KB (2 倍) の場合
トランザクション ログ生成数は 1.9 倍になります。

平均メールサイズが 150 KB を超える場合
平均メールサイズが 2 倍になるごとにトランザクション ログ生成数は
2 倍になります。
この倍率は 150 KB を超えた時から適用されることに注意してください。
たとえば、平均メールサイズが 300 KB の場合、トランザクション ログ
生成数は 3.8 倍となります。
2.
バックアップと復元の考慮
トランザクション ログ容量のサイジングはバックアップと復元の設計を考慮
する必要があります。たとえば、2 週間前の時点までさかのぼって、それ以降
に生成されたすべてのログを再生できるように設計している場合は、2 週間分
のログ ファイル領域が必要になります。完全バックアップを週 1 回、差分
バックアップを毎日行うようにバックアップを設計している場合は、バック
アップと復元中の再生の両方を実行できるように、ログ LUN をログ ファイ
ル 1 週間分の領域より大きくする必要があります。夜間に完全バックアップ
を実行するほとんどの組織は、1 日あたりの必要なログ生成容量を 2 ～ 3 倍
にして割り当てています。このようなアプローチを取るのは、バックアップが
失敗したためにトランザクション ログ領域がいっぱいになって DB のマウン
トが解除されるのを防ぐためです。
Exchange Server 2010 サイジングガイド ホワイトペーパー
49
バックアップ運用として、DAG による DB コピーと単一アイテム回復機能を
使用する場合は、循環ログを有効にします。これは、循環ログをログの切り詰
め/削除メカニズムとして使用するためです。この機能を利用する場合、1 日あ
たりに必要なトランザクション ログ容量の 3 倍をトランザクション ログ容
量に割り当てることを推奨します。そうすることで、レプリケーションが中断
状態になったり、通常のパラメーターで機能しなくなったりしても、トランザ
クションの失敗によって DB がマウント解除されることがなくなります。
3.
ユーザー メールボックスの移動に必要なトランザクション ログ容量の算出
ユーザー メールボックスの移動は、大規模なシステムにおいて、トランザク
ション ログ容量にかかわる主要な要素です。多くの大規模な組織では、ある割
合のユーザー メールボックスを夜間または 1 週間ごとに別の DB、サーバー、
またはサイトに移動します。組織でこのような処理を行う場合は、ユーザー
メールボックスの移動に対応できるようにトランザクション ログ容量を多め
に確保することを推奨します。
ユーザー メールボックスの移動元サーバーでは、トランザクション ログに記
録されるのはレコードの削除に関するログであり、
トランザクション ログの量
はそれほど多くありません。これに対し、移動先サーバーでは移動されたすべ
てのデータを最初にトランザクション ログに書き込むため、多量のトランザク
ション ログが生成される可能性があります。例えば、2 GB のユーザー メー
ルボックスを 10 個移動する場合、移動先サーバーには合計 20 GB (2GB ×
10) のトランザクション ログが生成されます。
ユーザー メールボックスの移動に必要なトランザクション ログ容量は、以下
の式で算出します。算出したトランザクション ログ容量は移動先のトランザク
ション ログ領域に必要です。
ユーザー メールボックスの移動に必要なトランザクション ログ容量
= ユーザー メールボックスあたりのデータ容量 (空白領域、ごみ箱領域を
含む)
× 移動するユーザー メールボックスの数
4.
オーバーヘッド要素の考慮
オーバーヘッドとしてトランザクション ログ容量の決定時に 20% のバッ
ファ領域を加えることを推奨します。これは、予期せずにトランザクション ロ
グが生成されたときも、必要な容量を確保するためです。
5.
DB あたりのトランザクション ログ容量の算出
上記で計算した値から、
DB あたりのトランザクション ログ容量を算出します。
トランザクション ログ容量は以下のように算出します。
Exchange 2010 では、
1 つのトランザクション ログファイルの容量は 1 MB です。
DB あたりのトランザクション ログ容量
= (ユーザー メールボックスの移動に必要なトランザクション ログ容量
＋ DB あたりの 1 日分のトランザクション ログ生成数 × 1 MB
× ログの切り詰め/削除間隔[日] × 3 倍)
Exchange Server 2010 サイジングガイド ホワイトペーパー
50
× (1 + オーバーヘッド要素[20%] )
3.1.4.4
必要な LUN 容量の算出
OS で認識される物理ディスク、または論理ユニット番号 (LUN) は、ハードウェ
アから抽象化されたものであり、OS にディスクを認識させるために使用されます。
LUN を設計する方法はいろいろありますが、あまり複雑にならないように、次の
設計方法を推奨します。
 DB ごとに 1 つの LUN
DB およびその対応するトランザクション ログ ファイルを同じ LUN 上に
配置します。この LUN アーキテクチャを利用するには、DAG を構成し、DB
とトランザクション ログ ファイルの複製を展開する必要があります。また、
ハードウェア ベースのボリューム シャドウ コピー サービス (VSS) ソ
リューションは使用しないでください。
この方法には次のような利点があります。

管理する LUN の数が削減され、ストレージ管理が簡素化されます。

バックアップ ジョブの数を削減できる可能性があります。

LUN 間でスピンドルを共有していない場合、DB 間でパフォーマンスを
柔軟に分離できます。
 DB ごとに 2 つの LUN
目標回復時間 (RTO) が小さい場合、または迅速な回復のために VSS クロー
ンを使用する場合は、トランザクション ログと DB を別々の LUN に配置す
ることが最適なこともあります。この方法では、使用可能なドライブ文字数が
不足する場合があり、その場合は、ボリューム マウント ポイントを使用しま
す。
この方法には次のような利点があります。

単一 DB のバックアップと復元を提供する、
DB レベルでのハードウェア
ベースの VSS が利用できます。

LUN 間でスピンドルを共有していない場合、DB 間でパフォーマンスを
柔軟に分離できます。

また、1 つの LUN の容量不足または障害発生時は 1 つの DB にしか影
響が及ばないため、信頼性が向上します。バックアップ運用として、DAG
と単一アイテム回復機能を使用しない場合は、障害時の影響範囲を考慮す
ることが重要です。
この方法には次のような懸念事項があります。

100 個の DB には、記憶域アレイの最大数を超える 200 の LUN が必
要です。DB ごとに別の LUN があるため、サーバーごとの LUN が多
くなり、管理コストや複雑さが増します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
51
 バックアップ セットごとに 2 つの LUN
バックアップ セットは夜間に完全にバックアップされる DB の数です。たと
えば、DB ごとに週 1 回の完全バックアップ (夜間に DB の 7 分の 1 の完
全バックアップを実行) と日常的な増分または差分バックアップを組み合わせ
て使用するようなソリューションでは、
トランザクション ログと DB の LUN
が同時にバックアップされるようにすべての DB を配置することで、複雑さを
軽減できます。これによってサーバー上の LUN の数も減らすことができます。
この方法には次のような利点があります。

管理する LUN の数が削減されて、ストレージ管理が簡素化されます。ま
た、バックアップ ジョブの数を削減できる可能性があります。
この方法には次のような懸念事項があります。

ハードウェア ベースの VSS バックアップと回復手順 (クローン スナッ
プショットなど) を実行する機能が制限されます。VSS の詳細に関しては、
「Exchange Server 2003 でボリューム シャドウ コピー サービスを使
用するためのベスト プラクティス」を参照してください。

1 つの LUN の容量不足または障害発生が、複数の DB に影響を与える
可能性があります。
LUN 容量の算出では、LUN に空き容量を確保する必要があることに注意してく
ださい。多くのストレージ管理ソフトウェアは、LUN が 80% を超えて使用され
たときに警告を出すため、本ガイドでは空き容量の割合を 20% としてサイジング
を行います。
DB とトランザクション ログを別々の LUN に配置する場合、DB 用の LUN と
トランザクション ログ用の LUN に必要な領域は、それぞれ以下の式で算出しま
す。
DB 用の LUN 容量
= 3.1.4.2 で求めた合計 DB 容量
÷ (1 － 必要な空き容量の割合[20%])
トランザクション ログ用の LUN 容量
= 3.1.4.3 で求めた DB あたりのトランザクション ログ容量
÷ (1 － 必要な空き容量の割合[20%])
Exchange Server 2010 サイジングガイド ホワイトペーパー
52
3.1.4.5
ディスク容量のサイジング例
ここでは以下のようなシステム構成を想定し MBX サーバー ロールのディスクサ
イジング例を示します。
【システム構成図】
MBX1
MBX2
DB1
DB1
DB
DB2
DB2
DB3
DB3
DB4
DB4
DB5
DB5
DB6
DB6
DB7
DB7
DB8
DB8
アクティブ DB コピー
パッシブ DB コピー
【システム要件】
要件
値
ユーザー メールボックス数
2,000 個
プロファイル
平均メール送受信数 100 通
平均メールサイズ 75 KB
1 サーバー障害まで対応可能
可用性レベル
(2 メンバー 2 DB コピー構成)
DB あたりのサイズ上限
300 GB
メールボックス サイズ クォータ
1 GB
削除済みアイテムの保存期間
14 日 (既定)
単一アイテムの回復
有効
予定表版トランザクション ログ
有効
ユーザー メールボックスの移動
行わない
フルバックアップ スケジュール
毎晩
データの配置
DB とトランザクション ログは別々の LUN
に配置する
その他の要件
・各 LUN に少なくとも 20% の空き領域を
確保する
・オフライン DB 保守用の領域、回復用 DB
Exchange Server 2010 サイジングガイド ホワイトペーパー
53
の領域、パブリック フォルダー DB 領域は別
途考慮する
以下のようにサイジングを行います。
1.
DB 容量の算出
① ユーザー メールボックスあたりのデータ容量の算出
ユーザー メールボックスあたりのデータ容量は、以下のように算出します。
空白領域
= 100 通 × 75 KB
= 約 7.3 MB
ごみ箱領域
= (100 通 × 75 KB × 14 日) ＋ (1 GB × 1.2%)
＋ (1 GB × 5.8%)
= 約 174 MB
ユーザー メールボックスあたりのデータ容量
= 1 GB ＋ 7.3 MB ＋ 174 MB
= 約 1.18 GB
② DB あたりのユーザー メールボックス数の算出
DB あたりのユーザー メールボックス数は、以下のように算出します。
DB あたりのユーザー メールボックス数
= 300 GB ÷ 1.18 GB
= 約 254 個
この例では、各 DB に均等にユーザー メールボックスを割り当てるため、
DB あたりのユーザー メールボックス数は以下のように算出します。
システム要件のユーザー メールボックス数から、システム全体のアクティブ
DB コピーの数を算出します。
システム全体のアクティブ DB コピー数
= 2,000 ÷ 254
=8 個
8 個の DB に均等にユーザー メールボックスを割り当てると、DB あたり
のユーザー メールボックス数は以下のようになります。
DB あたりのユーザー メールボックス数
= 2,000 ÷ 8 DB
= 約 250 個
Exchange Server 2010 サイジングガイド ホワイトペーパー
54
③ 実際の DB 容量の算出
手順①、②より、実際に必要な DB 容量は以下となります。
実際の DB 容量
= 250 個 × 1.18 GB
= 約 295 GB
④ コンテンツ インデックス領域の算出
DB 容量の約 10% がコンテンツ インデックスとして作成されるため、コン
テンツ インデックス領域は以下のように算出します。
コンテンツ インデックス領域
= 295 GB × 10%
= 約 29.5 GB
⑤ オーバーヘッドの考慮
バッファ領域として、20% を考慮します。
⑥ 合計 DB 容量の算出
手順③～⑤より、DB あたりに必要となるデータ容量は以下のように算出し
ます。
合計 DB 容量
= (295 GB ＋ 29.5 GB) × (1 ＋ 0.2[20%])
= 約 389 GB
2.
DB あたりのトランザクション ログ容量の算出
① DB あたりの 1 日分のトランザクション ログ生成数の算出
プロファイルから、ユーザー メールボックスごとの、1 日あたりのトラン
ザクション ログ生成数は 20 です。
プロファイル
1 日あたりのトランザクショ
(平均メール送受信数、
ン ログ生成数(ユーザー
平均メールサイズ: 75KB)
メールボックスあたり)
100
20
DB あたりの 1 日分のトランザクション ログ生成数は以下のように算出
します。
DB あたりの 1 日分のトランザクション ログ生成数
= 250 個 × 20
= 5,000 個
② バックアップと復元の考慮
毎晩バックアップを取得しますが、バックアップの失敗を考慮して、1 日
Exchange Server 2010 サイジングガイド ホワイトペーパー 55
あたりに必要なログ生成容量の 3 倍の容量を見積ります。
③ ユーザー メールボックスの移動に必要なトランザクション ログ容量の算出
ユーザー メールボックスの移動を行わない為、算出しません。
④ オーバーヘッドの考慮
バッファ領域を 20% とします。
⑤ DB あたりのトランザクション ログ容量の算出
トランザクション ログ容量は以下の通り算出します。
DB あたりのトランザクション ログ容量
= (5,000 個 × 1 MB × 1 日 × 3 倍)
× (1 ＋ 0.2 [20%])
= 約 18 GB
3.
必要な LUN 容量の算出
システム要件より DB とトランザクション ログを別々の LUN に配置しま
す。
DB 用の LUN 容量
= 389 GB ÷ (1 － 0.2 [20%] ) = 約 486 GB
トランザクション ログ用の LUN 容量
= 18 GB ÷ (1 － 0.2 [20%] ) = 約 23 GB
Exchange Server 2010 サイジングガイド ホワイトペーパー
56
3.1.5
ディスク性能のサイジング
ディスクの I/O には、トランザクション I/O と非トランザクション I/O がありま
す。以下で、それぞれの I/O の説明と、DB 領域とトランザクション ログ領域に
必要な IOPS のサイジング方法を説明します。
3.1.5.1
トランザクション I/O
トランザクション I/O は、ユーザー操作によって生成される I/O として定義され
ます。ユーザー操作には、メール送受信、Windows モバイルクライアントとの同
期、OWA からの操作などが含まれます。トランザクション I/O は、Exchange 2010
のストレージ設計をする上で重要な部分です。なぜなら、I/O 待ち時間 (I/O 操作
の実行にかかる時間) が Outlook をオンライン モードで使用する場合や、OWA
のようなオンライン クライアントのユーザー操作のレスポンスに直接影響するた
めです。Outlook のキャッシュモードを使用する場合も、代理人アクセス設定およ
びルールの作成のようなタスクのレスポンスに影響します。
トランザクション I/O は、DB ボリューム I/O とログボリューム I/O に分けるこ
とができます。
トランザクション I/O において、読み込み I/O を軽減する要素として DB キャッ
シュがあり、書き込み I/O を軽減する要素としてログ チェックポイントの深さの
ターゲットがあります。
 DB キャッシュ
64 ビット環境に対応したことにより 32 ビット環境に比べ、より多くのメモリ
を OS から認識することが可能になりました。Exchange 2010 はメモリ上に
DB のキャッシュ情報を展開し、ユーザーからのアクセスがキャッシュにヒッ
トした場合、ディスクへの読み込み I/O を実施しません。そのためディスクへ
の I/O を大幅に減少させることができます。ディスクの読み込み I/O がどの
程度減少するかは、DB キャッシュの量とプロファイルに依存します。
 ログ チェックポイントの深さのターゲット
Exchange では、トランザクション ログ / DB キャッシュに対して行われた
変更は即座に反映されず、一度メモリ内に保持します。このメモリに保持する
量は、ログ チェックポイントの深さのターゲットと呼ばれ、メモリ上のトラン
ザクション ログ / DB キャッシュへの変更がログチェックポイントの深さの
ターゲットに達した場合に、DB ファイルへ変更が反映されます。
ログ チェックポイントの深さのターゲットが大きければ、ユーザー メール
ボックスあたりのディスクの書き込み I/O を減らすことができますが、アク
ティブ DB コピーの障害時にバックアップなどから回復する際、
DB に適用さ
Exchange Server 2010 サイジングガイド ホワイトペーパー
57
れてないトランザクション ログの内容を適用する時間などが増加する可能性
があります。DAG を構成しない場合はこの影響を受けるため、ログチェック
ポイントの深さのターゲットの値を大きくできません。DAG を構成する場合、
DB の障害は DB のフェールオーバーによりコピー先での適用で対応できる
ため、ログチェックポイントの深さのターゲットの値を大きく設定することが
できます。その結果、DAG を構成した場合の方が、ユーザー メールボックス
あたりのディスクの書き込み I/O を減らすことができます。2 つ以上の DB
コピーを持つアクティブ DB コピー (DAG 構成あり) の DB 書き込み I/O
は、スタンドアロン DB (DAG 構成なし) の書き込み I/O と比較して最高で
40% 削減されます。
パッシブ DB コピーのログチェックポイントの深さのターゲットは小さく設
定されています。これは、 DB に適用されていないトランザクションを少なく
し、DB のフェールオーバーを迅速に行うためです。
以下に、
DB 構成ごとのログ チェックポイントの深さのターゲットの値を示し
ます。
DB 構成
ログ チェックポイントの深
さのターゲット (MB)
1 つの DB のコピー (DAG 構成なし)
20
2 つ以上のコピーを持つアクティブ DB
100
コピー (DAG 構成あり)
パッシブ DB コピー
3.1.5.2
5
非トランザクション I/O
トランザクション以外の I/O には、以下の要素があります。
 バックグラウンド DB 保守
バックグラウンド DB 保守の I/O は、アクティブ DB コピーとパッシブ DB
コピーの両方の整合性を確認する (チェックサム) ためのシーケンシャル DB
ファイル I/O です。バックグラウンド DB 保守は、次の特徴があります。

アクティブ DB コピーでは、24 時間 365 日 (既定) または管理者により
設定されたオンラインの保守時間に実行されます。
パッシブ DB コピーで
は、24 時間 365 日実行されます。

アクティブ DB コピーとパッシブ DB コピーの両方で、5 MB/sec 未満
の読み取りでそれぞれスキャンを実行します。I/O は 100% シーケンシャ
ルで、ストレージ サブシステムは非常に効率的に I/O を処理することが
できます。

チェックサムが 24 時間以内に完了すると、DB スキャンを停止します。
スキャンが 3 日以内に完了しなければ、警告イベントが発生します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
58
 高可用性
DAG によるログ レプリケーション I/O： DAG が構成されている場合、ア
クティブ DB コピーからパッシブ DB コピーに トランザクション ログファ
イルをレプリケーションするシーケンシャルな I/O が発生します。
DAG によるログ再生 I/O： DAG が構成されている場合、パッシブ DB コ
ピーにレプリケートされたログの検査と再生を DB に対して行うシーケン
シャル/ランダムな I/O が発生します。
 メッセージング レコード管理
メッセージング レコード管理 (MRM) は、組織の電子メールに関連する法的
リスクの削減に役立つ Exchange 2010 の管理テクノロジーの 1 つです。
MRM は、企業ポリシー、政府規制、法的要件に準拠し、必要なメッセージを
保持しやすくなります。また、法的またはビジネス上の価値がないコンテンツ
を削除するためにも利用されます。これは、保持ポリシーまたは管理フォルダー
を使用して行われます。
管理フォルダー アシスタント (MFA) は、メールボックス DB に対して実行
されるメールボックス アシスタントです。MFA によるディスク I/O は処理
対象となるメールボックス アイテムの数に依存します。MFA はバックアップ
やオンライン保守と同時に実行しないことを推奨します。
 オンライン保守
管理者により DB の保守スケジュールを設定するか、既定の 24 時間 365 日
の DB 保守を使用することが可能です。オンライン デフラグは Exchange の
前バージョンのように実施されず、既定では 24 時間 365 日 DB の I/O が発
生している間、継続的に実行されます。
3.1.5.3
DB 領域に必要な IOPS
MBX サーバー ロールに必要なディスク性能 (IOPS) は、以下の式で算出します。
DB 領域に必要な IOPS の決定時に 20% のバッファを加えることを推奨します。
これは、予期せずに I/O が発生したときも、必要なパフォーマンスを確保するため
です。
必要な IOPS 値
= DB あたりのユーザー メールボックス数
× ユーザー メールボックスごとに必要な IOPS
× (1 + オーバーヘッド要素 [20%] )
Exchange Server 2010 サイジングガイド ホワイトペーパー
59
ユーザー メールボックスごとに必要な IOPS 値は以下の表を参考にしてください。
プロファイル
DB キ ャ ッ
IOPS
IOPS
(平均メール送受信数)
シュ(MB)
(DAG 未構成時)
(DAG 構成時)
50
3
0.06
0.05
100
6
0.12
0.10
150
9
0.18
0.15
200
12
0.24
0.20
250
15
0.30
0.25
300
18
0.36
0.30
350
21
0.42
0.35
400
24
0.48
0.40
450
27
0.54
0.45
500
30
0.60
0.50
注意事項
これらの推定値は、Outlook 2007 または Outlook 2010 で Exchange キャッシュ モード クライアントを使用
し、2 GB のメールボックス サイズ クォータ、および Exchange ActiveSync の利用率が高いユーザーで検証し
た結果です。予測に使用した平均メール サイズは 75 KB でしたが、メッセージ サイズは IOPS の主要な要素
ではありません。クライアントの種類および使用シナリオが異なると、得られる結果が正確でない場合があります。
3.1.5.4
トランザクション ログ領域に必要な IOPS
トランザクション ログ領域の IOPS は、トランザクション ログの read/write と
NTFS のメタデータの read/write に関連する I/O です。
トランザクション ログ領域の IOPS は、シーケンシャルアクセスであり、バッテ
リー バックアップ機能を搭載したアレイ コントローラーを使用した場合に、オー
バーヘッドが最小限となるため、I/O のサイジングよりも容量のサイジングのほう
が重要となることが一般的です。
バッテリー バックアップ機能とは
バッテリー バックアップ機能とは、ディスク装置が電源断となった場合でも電源の供給を行い、キャッシュ (メモリ)
上のデータを保護する機能です。コントローラー上のキャッシュを利用してデータアクセスを実施する際、バッテリー
バックアップ機能があれば、障害発生時でもキャッシュ上のデータが保持されます。
Exchange 2010 のトランザクション ログの I/O は、DB の I/O と比較して、
DAG 未構成時では 40%、DAG 構成時では 50% が必要です。DAG 構成時に
10% 追加で I/O が必要になる理由は、レプリケーション処理によるオーバーヘッ
ドが発生するためです。例として、DAG 構成時に、DB LUN に対して 12 IOPS を
使用する場合は、ログ LUN に対しては約 6 IOPS を使用します。また、トラン
ザクション ログの I/O を予測したあとは、ピーク時を考慮し、20% のオーバー
ヘッドを追加することも重要です。
なお、Exchange 2003 のトランザクション ログ I/O は、Exchange 2003 の DB
Exchange Server 2010 サイジングガイド ホワイトペーパー
60
I/O の 10% が必要です。これに対して Exchange 2010 は Exchange 2003 と比
較して、I/O 比率が 40% または 50% と上昇しています。これは、Exchange 2010
は、DB の読み込み回数の削減や、ログサイズの削減、またより多くの DB を持つ
ことができるようになったことから、DB の I/O 自体が減少しているためです。
Exchange Server 2010 サイジングガイド ホワイトペーパー
61
3.2 CAS サーバー ロールのサイジング
ここでは、CAS サーバー ロールのサイジング方法を解説します。
Exchange 2010 では、クライアントからのアクセスに関する機能のほとんどが
MBX サーバー ロールから CAS サーバー ロールに移りました。例えば POP3
や IMAP4 などの非 MAPI クライアントなどからアクセスされた場合、メッセー
ジは CAS サーバー ロールで変換されます。さらに OWA のブラウザへのレンダ
リング処理は、以前のバージョンでは Exchange Information Store サービスで実
行されていましたが、CAS サーバー ロールで実行されるようになりました。これ
らのアーキテクチャの変更によって CAS サーバー ロールは、MBX サーバー
ロールの処理を軽減させ、8 つのプロセッサ コアも効果的に利用できるようにな
りました。また、これらのアーキテクチャの変更により、MBX サーバー ロールと
CAS サーバー ロールのプロセッサ コア比率は以前の Exchange から変更され
ました。
CAS サーバー ロールのプロセッサ コア数は、MBX サーバー ロールのプロセッ
サ コア数を基準とするため、CAS サーバー ロールのサイジングを実施する前に、
「3.1 MBX サーバー ロールのサイジング」に従って、MBX サーバー ロールのプ
ロセッサ コア数を決定してください。
CAS サーバー ロールのサイジングは、以下の手順で実施します。
1. CPU のサイジング
MBX サーバー ロールのプロセッサ コア数を基準として、プロセッサ コア数
を決定します。
2. メモリのサイジング
1. で算出したプロセッサ コア数から、必要となるメモリ容量を決定します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
62
3.2.1
CPU のサイジング
CAS サーバー ロールのプロセッサ コア数は、MBX サーバー ロールのプロセッ
サ コア数との比率から決定します。MBX サーバー ロールと CAS サーバー ロー
ルの推奨されるプロセッサ コア数の比率は以下の通りです。
Exchange サーバー ロールの構成
推奨されるプロセッサ コア数の比率
MBX サーバー : CAS サーバー
4:3
また、CAS サーバー ロールには、以下に示す CPU の最小要件と推奨最大要件が
あります
Exchange サーバー
CPU の最小要件
CPU の推奨最大要件
ロール
(プロセッサ コア数)
(プロセッサ コア数)
CAS サーバー
2 プロセッサ コア
12 プロセッサ コア
MBX サーバー ロールとのプロセッサ コア数の比率から決定した CAS サーバー
ロールのプロセッサ コア数が、上記の最小要件を満たさない場合は、最小要件であ
る 2 プロセッサ コアにする必要があります。
プロセッサ コア数が推奨最大要件を超える場合は、プロセッサ コア数が推奨範囲
に収まるよう、均等にサーバーを分割する必要があります。
注意事項
一部のサーバー仮想化プラットフォームでは、上記の表で特定されているプロセッサの最大数がサポートされない
可能性があります。Exchange サーバー ロールを仮想化プラットフォームに展開する場合は、そのプラットフォーム
のマニュアルをチェックして、サポートされている仮想プロセッサの最大数を確認してください。
3.2.2
メモリのサイジング
CAS サーバー ロールのメモリは、以下の式で算出します。
CAS サーバー ロールのメモリ容量
= 搭載プロセッサ コア数 × 2 GB
CAS サーバー ロールのメモリには、4 GB という最小要件があります。上式で算
出したメモリ容量が最小要件を下回る場合は、メモリを 4 GB にする必要がありま
す。
一般に、CAS サーバー ロールで使用されるメモリ容量は、クライアント接続の数
およびトランザクション速度と比例的な関係があります。CPU およびメモリ構成
の推奨事項 (1 プロセッサ コアあたり 2 GB) に基づいて構成した CAS サー
バー ロールでは、メモリと CPU の使用率に関してバランスがとられ、メモリが
Exchange Server 2010 サイジングガイド ホワイトペーパー 63
限度に達するのとほぼ同時に CPU も限度に達します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
64
3.3 HUB サーバー ロールのサイジング
ここでは、HUB サーバー ロールのサイジング方法を解説します。
複数の MBX サーバーや数千のユーザー メールボックスが展開された組織では、
HUB サーバー ロールには 8 つのプロセッサ コア数が推奨されます。また、アン
チウイルスとアンチスパムを利用するよう構成された場合は、より多くのプロセッ
サ コアを搭載しても効率よく CPU を利用できます。メッセージの頻度、メッセー
ジ サイズ、有効なトランスポート ルールの数、アンチウイルスの構成、サードパー
ティのアプリケーションによって CPU の使用率は変わるため、それらの要素を加
味して CPU サイジングを行います。
HUB サーバー ロールのプロセッサ コア数は、MBX サーバー ロールのプロセッ
サ コア数を基準とするため、HUB サーバー ロールのサイジングを実施する前に、
「3.1 MBX サーバー ロールのサイジング」に従って、MBX サーバー ロールのプ
ロセッサ コア数を決定してください。
HUB サーバー ロールのサイジングは、以下の手順で実施します。
1. CPU のサイジング
MBX サーバー ロールのプロセッサ コア数を基準として、プロセッサ コア数
を決定します。
2. メモリのサイジング
1. で算出したプロセッサ コア数から、必要となるメモリ容量を決定します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
65
3.3.1
CPU のサイジング
HUB サーバー ロールのプロセッサ コア数は、MBX サーバー ロールのプロセッ
サ コア数との比率から決定します。MBX サーバー ロールと HUB サーバー
ロールの推奨されるプロセッサ コア数の比率は以下の通りです。
Exchange サーバー ロールの構成
推奨されるプロセッサ コア数の比率
MBX サーバー : HUB サーバー
(HUB サーバーにウイルス対策スキャンなし)
7:1
(HUB サーバーにウイルス対策スキャンあり)
5:1
また、HUB サーバーには、以下に示す CPU の最小要件と推奨最大要件がありま
す。
Exchange サーバー CPU の最小要件
CPU の推奨最大要件
ロール
(プロセッサ コア数)
(プロセッサ コア数)
HUB サーバー
1 プロセッサ コア
12 プロセッサ コア
MBX サーバー ロールとのプロセッサ コア数の比率から決定した HUB サー
バー ロールのプロセッサ コア数が、上記の最小 CPU 要件を満たさない場合は 1
プロセッサ コアにする必要があります。プロセッサ コア数が推奨最大要件を超え
る場合は、プロセッサ コア数が推奨範囲に収まるよう、均等にサーバーを分割する
必要があります。
注意事項
一部のサーバー仮想化プラットフォームでは、上記の表で特定されているプロセッサの最大数がサポートされない
可能性があります。Exchange サーバー ロールを仮想化プラットフォームに展開する場合は、そのプラットフォーム
のマニュアルをチェックして、サポートされている仮想プロセッサの最大数を確認してください。
3.3.2
メモリのサイジング
HUB サーバー ロールのメモリは、以下の式で算出します。
HUB サーバー ロールのメモリ容量
= 搭載プロセッサ コア数 × 1 GB
HUB サーバー ロールのメモリには、4 GB という最小要件があります。上式で算
出したメモリ容量が最小要件を下回る場合は、メモリを 4 GB にする必要がありま
す。
HUB サーバー ロールでは、最適な条件でのパフォーマンスを得るために大量のメ
モリは必要としません。通常は、1 プロセッサ コアあたり 1 GB (合計で最小 4
Exchange Server 2010 サイジングガイド ホワイトペーパー
66
GB) の RAM があれば、非常に高い負荷を除き、ほとんどの負荷に対応すること
ができます。
Exchange Server 2010 サイジングガイド ホワイトペーパー
67
3.4 コンバインドロールのサイジング
ここでは、コンバインドロールのサイジング方法を解説します。
コンバインドロール構成を選択するシナリオは「2.1 ロール構成の考え方」を参照
してください。
コンバインドロールのプロセッサ コア数のサイジングは、MBX サーバー ロール
のプロセッサ コア数を基準とするため、
コンバインドロールのサイジングを実施す
る前に、
「3.1 MBX サーバー ロールのサイジング」に従って、MBX サーバー ロー
ルのプロセッサ コア数を決定してください。
コンバインドロールを利用した構成では、MBX サーバーのプロセッサ コアの構成
を効率よく利用して構成を組む事が出来ます。例えば 4 つのプロセッサ コアを搭
載したコンバインドロール サーバーがある場合、CAS サーバー ロールで約 3 つ
のプロセッサ コアが使用され、HUB サーバー ロールで約 1 つのプロセッサ コ
アが使用されます。これを 4 つのプロセッサ コアを搭載した MBX サーバー
ロールと組み合わせて展開すれば、MBX サーバー ロールと HUB サーバー ロー
ルのプロセッサ コア比率は 4 : 1 になり、MBX サーバー ロールと CAS サー
バー ロールのプロセッサ コア比率は 4 : 3 になります。このことから、用意した
サーバーのプロセッサ コア数を単体ロールでは効率的に使い切れない場合などに、
コンバインドロール構成を選択することでリソースを効果的に使用することが可能
です。
コンバインドロールのサイジングは、以下の手順で実施します。
1. CPU のサイジング
MBX サーバー ロールのプロセッサ コア数を基準として、必要となる CPU
の個数、プロセッサ コア数を決定します。
2. メモリのサイジング
1. で算出した プロセッサ コア数から、必要となるメモリ容量を決定します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
68
3.4.1
CPU のサイジング
コンバインドロールのプロセッサ コア数は、MBX サーバー ロールのプロセッサ
コア数との比率から決定します。MBX サーバー ロールとコンバインドロールの推
奨されるプロセッサ コア数の比率は以下の通りです。
Exchange サーバー ロールの構成
推奨されるプロセッサ コア数の比率
MBX サ ー バ ー : コ ン バ イ ン ド
1:1
ロール サーバー
また、コンバインドロール サーバーには、以下に示す CPU の最小要件と推奨最
大要件があります。
Exchange サ ー バ ー
CPU の最小要件
CPU の推奨最大要件
ロール
(プロセッサ コア数)
(プロセッサ コア数)
コンバインドロール
2 プロセッサ コア
12 プロセッサ コア
サーバー
MBX サーバーとのプロセッサ コア数の比率から決定したコンバインドロールの
プロセッサ コア数が、上記の最小要件を満たさない場合は 2 プロセッサ コアに
する必要があります。プロセッサ コア数が推奨最大要件を超える場合は、プロセッ
サ コア数が推奨範囲に収まるよう、均等にサーバーを分割する必要があります。
注意事項
一部のサーバー仮想化プラットフォームでは、上記の表で特定されているプロセッサの最大数がサポートされない
可能性があります。Exchange サーバー ロールを仮想化プラットフォームに展開する場合は、そのプラットフォーム
のマニュアルをチェックして、サポートされている仮想プロセッサの最大数を確認してください。
3.4.2
メモリのサイジング
コンバインドロールのメモリは、以下の式で算出します。
コンバインドロールのメモリ容量
= 搭載 プロセッサ コア数 × 2 GB
コンバインドロールのメモリには、4 GB という最小要件があります。上式で算出
したメモリ容量が最小要件を下回る場合は、メモリを 4 GB にする必要があります。
Exchange Server 2010 サイジングガイド ホワイトペーパー
69
3.5 マルチロールのサイジング
ここでは、マルチロールのサイジング方法を解説します。
マルチロール構成を選択するシナリオは「2.1 ロール構成の考え方」を参照してく
ださい。
マルチロールのサイジングは、以下の手順で実施します。
1. CPU のサイジング
必要となる CPU の個数、プロセッサ コア数を決定します。
2. メモリのサイジング
1. で算出した プロセッサ コア数から、必要となるメモリ容量を決定します。
3. ディスクのサイジング
必要なディスク容量とディスク性能は MBX サーバー ロールと同じため、
「3.1 MBX サーバー ロールのサイジング」を参照してください。
3.5.1
CPU のサイジング
マルチロールのプロセッサ コア数は、各 Exchange サーバー ロールのプロセッ
サ コア数のサイジング結果の合計となります。以下の順番に算出します。
1.
MBX サーバー ロールのプロセッサ コア数を算出します。
詳細に関しては「3.1 MBX サーバー ロールのサイジング」を参照してくださ
い。
2.
CAS サーバー ロールのプロセッサ コア数を算出します。
詳細に関しては、
「3.2 CAS サーバー ロールのサイジング」を参照してくださ
い。
3.
HUB サーバー ロールのプロセッサ コア数を算出します。
詳細に関しては、「3.3 HUB サーバー ロールのサイジング」を参照してくだ
さい。
4.
1. ～ 3. を合計し、マルチロールのプロセッサ コア数を決定します。
上記の算出結果より、マルチロール構成では搭載可能な CPU の半分を MBX
サーバー ロールに使用し、残りの半分を CAS サーバー ロールと HUB サーバー
ロールに使用することになります。そのため、MBX サーバー ロールで算出した
CPU 要件を 2 倍にすることで、マルチロールに必要な CPU 要件を見積ることが
できます。
Exchange Server 2010 サイジングガイド ホワイトペーパー
70
また、マルチロールには以下に示す CPU の最小要件と推奨最大要件があります。
Exchange サ ー バ ー
CPU の最小要件
CPU の推奨最大要件
ロール
(プロセッサ コア数)
(プロセッサ コア数)
マルチロール
2 プロセッサ コア
24 プロセッサ コア
上記の最小要件を満たさない場合は、最小要件である 2 プロセッサ コアにする必
要があります。
プロセッサ コア数が推奨最大要件を超える場合は、プロセッサ コア数が推奨範囲
に収まるよう、均等にサーバーを分割する必要があります。
注意事項
1 台のマルチロール サーバーでホストする最大のユーザー メールボックス数 (縮退などのピーク時含む) は、
4,000 個以内を推奨します。
3.5.2
メモリのサイジング
プロセッサ コア数の決定後、メモリの推奨要件を算出できます。次の表に、マルチ
ロール構成の最小メモリ要件および推奨要件を示します。
Exchange サ ー
メモリ容量
バー ロール
の最小要件
マルチロール
10 GB
サーバー
メモリ容量の推奨要件
(4 プロセッサ コア サーバー)
10 GB ＋ ユーザー メールボックス数
× DB キャッシュ
(8 プロセッサ コア サーバー)
14 GB ＋ ユーザー メールボックス数
× DB キャッシュ
(12 プロセッサ コア サーバー)
18 GB ＋ ユーザー メールボックス数
× DB キャッシュ
(16 プロセッサ コア サーバー)
22 GB ＋ ユーザー メールボックス数
× DB キャッシュ
(24 プロセッサ コア サーバー)
30 GB ＋ ユーザー メールボックス数
× DB キャッシュ
Exchange Server 2010 サイジングガイド ホワイトペーパー
71
DB キャッシュは以下の表を参考にしてください。
プロファイル
DB キャッシュ(MB)
(平均メール送受信数)
(ユーザー メールボックス
あたり)
50
3
100
6
150
9
200
12
250
15
300
18
350
21
400
24
450
27
500
30
マルチロール サーバーのメモリには、10 GB という最小要件があります。算出し
たメモリ容量が最小要件を下回る場合は、メモリを 10 GB にする必要があります。
Exchange Server 2010 サイジングガイド ホワイトペーパー
72
3.5.3
マルチロール サーバーのサイジング例
ここでは、以下のシステム構成を想定した、マルチロール サーバーの CPU、メモ
リのサイジング例を示します。
【システム構成図】
HUB
HUB
HUB
HUB
CAS
CAS
CAS
CAS
MBX
MBX
MBX
MBX
DB1
DB1
DB1
DB2
DB2
DB2
DB3
DB3
DB3
DB4
DB4
DB4
DB5
DB5
DB5
DB6
DB6
DB6
DB7
DB7
DB7
DB8
DB8
DB8
DB9
DB9
DB9
DB10
DB10
DB10
DB11
DB11
DB11
DB12
DB12
DB12
DB13
DB13
DB13
DB14
DB14
DB14
DB15
DB15
DB15
DB16
DB16
DB16
アクティブ DB コピー
パッシブ DB コピー
【システム要件】
要件
値
ユーザー メールボックス数
8,000 個
プロファイル
1 日あたりのメール送受信数 100 通
平均メールサイズ 75 KB
Exchange Server 2010 サイジングガイド ホワイトペーパー
73
1 アクティブ DB あたりのユー
500 個
ザー メールボックス数
2 サーバー同時障害まで対応可能
可用性レベル
(4 メンバー 3 DB コピー構成）
メールボックス サイズ クォータ
500 MB
1 MBX サーバーあたりの DB 数
12 個
1 サーバーでホストするアクティ
4,000 個
ブ メールボックス数
(縮退運用時)
サイジングは、縮退運用時の負荷を考慮して行います。本構成の要件では 2 サー
バー同時障害まで対応可能と定義しますので、障害発生時は下記の構成図のように
4,000 個のメールボックスをホストすることになります。
【システム構成図】
HUB
HUB
HUB
HUB
CAS
CAS
CAS
CAS
MBX
MBX
MBX
MBX
DB1
DB1
DB1
DB2
DB2
DB2
DB3
DB3
DB3
DB4
DB4
DB4
DB5
DB5
DB5
DB6
DB6
DB6
DB7
DB7
DB7
DB8
DB8
DB8
DB9
DB9
DB9
DB10
DB10
DB10
DB11
DB11
DB11
DB12
DB12
DB12
DB13
DB13
DB13
DB14
DB14
DB14
DB15
DB15
DB15
DB16
DB16
DB16
アクティブ DB コピー
パッシブ DB コピー
Exchange Server 2010 サイジングガイド ホワイトペーパー
74
Exchange Server 2010 サイジングガイド ホワイトペーパー
75
次のようにサイジングします。
 CPU のサイジング
1.
CPU のサイジングに必要な要素の確認
要件
値
根拠
1 つのアクティブ DB
2 個
2 サーバー同時障害時、パッシブ
コ ピー に対 して作 成
DB コピー数は 2 個となるため
す る パ ッ シ ブ DB コ
(4 ノード 3 DB コピー構成)
ピー数
1 サーバーでホストす
2,000 個
1 つのアクティブ DB コピーあ
るパッシブ メール
たり 2 個のパッシブ DB コピー
ボックス数
を配置するため、通常運用時の 1
（縮退運用時）
サーバーあたりのユーザー メー
ルボックス数は、2,000 個 (アク
ティブ DB コピー) + 4,000 個
(パッシブ DB コピー) で 6,000
個。
1 サーバーあたり 6,000 個のう
ち縮退運用時のアクティブ メー
ルボックスが 4,000 個のため縮
退運用時のパッシブメールボック
ス数は 2,000 個。
2.
MBX サーバー ロールに必要な CPU 要件の算出
①
アクティブ メールボックスのホストに必要な CPU 要件
プロファイルから、1 つのアクティブ メールボックスあたりに必要な
CPU 要件は 2 メガサイクルです。
プロファイル
CPU 要件
(平均メール送受信数)
(メガサイクル、アクティブ
メールボックスあたり)
100
2
システム要件から、縮退運用時のアクティブ メールボックス数は 4,000
個であるため、必要な CPU 要件は以下のように算出します。
アクティブ メールボックスのホストに必要な CPU 要件
= 4,000 個 × 2 メガサイクル
= 8,000 メガサイクル
Exchange Server 2010 サイジングガイド ホワイトペーパー
76
② パッシブ DB コピーへのレプリケーションに必要な CPU 要件の算出
必要な CPU 要件は以下のように算出します。
パッシブ DB コピーへのレプリケーションに必要な CPU 要件
= 8,000 メガサイクル × 0.1 (10%) × 2 パッシブ DB コピー
= 1,600 メガサイクル
③ パッシブ メールボックスのホストに必要な CPU 要件の算出
プロファイルから、パッシブ メールボックスあたりに必要な CPU 要件は
0.3 メガサイクルです。
プロファイル
CPU 要件
(平均メール送受信数)
(メ ガサイク ル、パ ッシ ブ
メールボックスあたり)
100
0.3
必要な CPU 要件は以下のように算出します。
パッシブ メールボックスのホストに必要な CPU 要件
= 2,000 個 × 0.3 メガサイクル
= 600 メガサイクル
④
MBX サーバー ロールの CPU 要件の算出
手順①～③の結果を合計し、MBX サーバー ロールの CPU 要件は以下の
ように算出します。
MBX サーバー ロールの CPU 要件
= 8,000 ＋ 1,600 ＋ 600
= 10,200 メガサイクル
3.
マルチロールサーバーに必要な CPU の選定
縮退運用時 にサーバーの CPU 使用率が 80% を超えないように CPU を選
定します。
MBX サーバー ロールでサーバー全体の CPU リソースの半分を使用するた
め、縮退運用時 に MBX サーバー ロールでの CPU 使用率が 40% を超え
ないように設計します。その結果、サーバーに搭載する CPU 要件は以下とな
ります。
10,200 ÷ 0.4 (40%) = 25,500 メガサイクル
Exchange Server 2010 サイジングガイド ホワイトペーパー
77
4 プロセッサ コアの CPU を 2 つ利用する場合、搭載する CPU は以下の
式を満たすものです。
クロック数 ＞ 25,500 メガサイクル ÷ 4 プロセッサ コア ÷ 2 CPU
= 3,188 MHz
そのため、マルチロール サーバーには、3.2 GHz 以上の 4 プロセッサ コア
CPU を 2 つ搭載します。
 メモリのサイジング
①
DB キャッシュ総量の算出
プロファイルから、アクティブ メールボックスあたりの DB キャッシュは 6
MB です。
プロファイル
DB キャッシュ(MB)
(平均メール送受信数)
(アクティブ メールボックス
あたり)
100
6
システム要件からアクティブ メールボックス数 (縮退運用時) は 4,000 個の
ため、必要な DB キャッシュ総量は以下のように算出します。
DB キャッシュ総量
= 4,000 個 × 6 MB
= 約 23.4 GB
②
合計メモリ要件の算出
4 プロセッサ コアの CPU を 2 つ利用した場合 (合計 8 プロセッサ コア)、
合計メモリ要件は以下のように算出します。
14 GB ＋ 23.4 GB = 37.4 GB
37 GB は、標準的なメモリ構成ではないため、48 GB またはサーバーがサポー
トしているもっとも近いメモリ構成まで切り上げます。
Exchange Server 2010 サイジングガイド ホワイトペーパー
78
3.6 Edge サーバー ロールのサイジング
ここでは、Edge サーバー ロールのサイジング方法を解説します。
複数の MBX サーバーや数千のユーザー メールボックスが展開された組織では、
Edge サーバー ロールには 8 つのプロセッサ コア数が推奨されます。また、アン
チウイルスとアンチスパムを利用するよう構成された場合は、より多くのプロセッ
サ コアを搭載しても効率よく CPU を利用できます。メッセージ頻度、メッセー
ジ サイズ、有効なトランスポート ルールの数、アンチウイルスの構成、サードパー
ティのアプリケーションによって CPU 使用率は変わるため、それらの要素を加味
して CPU サイジングを行います。
Edge サーバー ロールのサイジングは、以下の手順で実施します。
1. CPU のサイジング
必要となる CPU の個数、プロセッサ コア数を決定します。
2. メモリのサイジング
1. の考え方を基に算出したプロセッサ コア数から、必要となるメモリ容量を
決定します。
3.6.1
CPU サイジングの考え方
必要な Edge サーバーの数を特定するには、ピーク時に次の指標を測定または見積
る必要があります。
 1 秒あたりの接続
 1 秒あたりのメッセージ
 平均メールサイズ
サイジングは、処理される接続とメッセージの数に基づいて行い、二次的要素とし
て平均メールサイズを考慮します。すべての SMTP 接続が SMTP メッセージに
変換されるわけでも、すべての受け付けるメッセージがウイルス対策スキャンおよ
びスパム対策スキャンを通過するわけでもないため、メッセージの比率に基づいた
単純なサイジング方法を提供することは困難です。Edge サーバーの使用率は、そ
れぞれの組織に固有のいくつかの要素によって異なります。
次の表で、マイクロソフトでの内部展開の主要な指標のパフォーマンス データ値を
示します。指標とその値は、Edge サーバー ロールのパフォーマンスの特性を理解
するために使用できます。
Exchange Server 2010 サイジングガイド ホワイトペーパー
79
パフォーマンスの指標
値
SMTP 接続数/秒
55
受け入れられた接続の割合 (%)
80%
IMF がスキャンした SMTP メッセージ数/秒
3.7
IMF のスキャンを通過した SMTP メッセージの割合 (%)
80%
A/V がスキャンした SMTP メッセージ数/秒
3
平均メールサイズ
70 KB
CPU 使用率
20%
※2 ソケットのデュアル コア AMD Opteron 275 (2.2 GHz) を使用
サーバー側の処理は接続の分析および受け入れられたメッセージのスキャンのオー
バーヘッドに関連します。したがって、ウイルス対策操作とスパム対策操作は Edge
サーバー ロールの CPU 使用率が高い機能であるため、1 秒あたりに送受信され
たメッセージ数だけに基づいたサイズ変更の指標を示すことはできません。
3.6.2
メモリのサイジング
Edge サーバー ロールのメモリは、以下の式で算出します。
Edge サーバー ロールのメモリ容量
= 搭載プロセッサ コア数 × 1 GB
Edge サーバー ロールのメモリには、4 GB という最小要件があります。上式で算
出したメモリ容量が最小要件を下回る場合は、メモリを 4 GB にする必要がありま
す。
Edge サーバー ロールでは、最適な条件でのパフォーマンスを得るために大量のメ
モリは必要としません。通常は、1 プロセッサ コアあたり 1 GB (合計で最小 4
GB) の RAM があれば、非常に高い負荷を除き、ほとんどの負荷に対応すること
ができます。
Exchange Server 2010 サイジングガイド ホワイトペーパー
80
3.7 UM サーバー ロールのサイジング
ここでは、UM サーバー ロールのサイジング方法を解説します。
UM サーバー ロールのサイジングは、以下の手順で実施します。
1. CPU のサイジング
必要となるプロセッサ コア数を決定します。
2. メモリのサイジング
1. で算出したプロセッサ コア数から、必要となるメモリ容量を決定します。
3.7.1
CPU のサイジング
UM サーバー ロールのプロセッサ コア数の推奨要件は、8 プロセッサ コアです。
UM サーバー ロールでは、ボイスメールを Microsoft Windows Media Audio
(WMA) 形式に変換する処理等で、複数のプロセッサ コアが使用されます。
UM サーバー ロールの CPU サイジングは、その使用率が MBX サーバー ロー
ルとは直接関係していないためサイジングをするためには別の要素から考える必要
があります。UM サーバー ロールの容量計画の詳細に関しては、「ユニファイド
メッセージングの可用性について」を参照してください。
3.7.2
メモリのサイジング
UM サーバーのメモリは、以下の式で算出します。
UM サーバーのメモリ容量
= 搭載プロセッサ コア数 × 2GB
UM サーバーのメモリには、4 GB という最小要件があります。上式で算出したメ
モリ容量が最小要件を下回る場合は、メモリを 4 GB にする必要があります。
Exchange Server 2010 サイジングガイド ホワイトペーパー
81
第四部
Exchange 2010 サイジング ケーススタディ
この章では、一般的なシステム構成でのサイジング例を説明します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
82
Exchange Server 2010 サイジングガイド ホワイトペーパー
83
4.1 サイジング ケース スタディ
ここでは実際の企業システムを想定した CPU、メモリ、ディスク容量、I/O の要
件をサイジングする例を示します。
Exchange Server 2010 Mailbox Server Role Requirements Calculator (MBX
サーバー ロールの要件計算用シート) を使用すると、一連の入力要素を指定するこ
とで、MBX サーバー ロールに適した要件を決定することができます。この例で説
明する要件もこの計算シートを使用して決定できます。計算シート (およびそのダ
ウンロード方法) の詳細に関しては、Exchange Server チーム ブログの記事の
「Exchange 2010 メールボックス サーバーの役割の要件計算用シート」を参照し
てください。
下図のシステム構成イメージにおけるサイジング例を示します。
なお、下図は構成イメージであり、サーバー台数、ディスク構成については、以降
のサイジング結果より決定していきます。
【システム構成イメージ】
HUB
HUB
…
CAS
CAS
CAS アレイ
冗長化
HUB
MBX
…
…
…
DAG
MBX
…
…
アクティブ DB コピー
パッシブ DB コピー
Exchange Server 2010 サイジングガイド ホワイトペーパー
84
【システム要件】
要件
値
平均メール送受信数
100 通
平均メールサイズ
75 KB
メールボックス
サイズ
2 GB
クォータ
システム全体のユーザー
24,000 個
メールボックス数
1 MBX サーバーあたりにホ
6,000 個
ストするユーザー メール
ボックス数
(縮退運用時)
削除済みアイテムの保存期間
14 日
予定している DB サイズ
530 GB
予定表アイテム保存期間
120 日間
単一アイテムの回復
有効(既定は無効)
予定表バージョン ログ デー
有効(既定は有効)
タ
ユーザー メールボックスの
週に 1% 程度
移動の有無
MBX サーバー ロール可用
・2 サーバー同時障害まで対応可能
性レベル
・アクティブ DB コピー 1 つに対して 2 つの
パッシブ DB コピーを配置
その他の要件
・CPU は 1 サーバーあたり 4 プロセッサ コア、
2 CPU 構成とする。
・各 LUN に少なくとも 20% の空き領域を確保
する
・メールボックス DB とトランザクション ログは
同じ LUN に配置する。
・オフライン DB 保守と回復用 DB は別途考慮
する
・サイジングに伴うオーバーヘッドは 20% とす
る。
・ウイルス対策スキャンは Forefront Protection
2010 for Exchange Server にて実施する。
・バックアップ運用として、DAG による DB コ
ピーと単一アイテム回復機能を使用し、循環ロ
グを有効とする。
・HUB サーバー ロールと CAS サーバー ロー
ルはコンバインドロール 構成とする。
Exchange Server 2010 サイジングガイド ホワイトペーパー
85
4.1.1
MBX サーバー ロール
前提として、システム要件から MBX サーバーの台数を算出します。
縮退運用時、1 MBX サーバー あたり 6,000 個のユーザー メールボックスをホス
トするため、縮退運用時は以下のサーバー台数が必要です。
縮退運用時の MBX サーバー台数
= 24,000 個 ÷ 6000 個
=4 台
2 サーバーの同時障害に備え、MBX サーバーは 6 台 (4 + 2) となります。
4.1.1.1
1.
MBX サーバー ロールの CPU サイジング
CPU のサイジングに必要な要素の確認
要件
値
根拠
1 つ の ア ク テ ィ ブ DB
2 個
2 サーバー同時障害まで対応可能であ
コピー に対して作成す
るため、1 つのアクティブ DB コピー
るパッシブ DB コピー
に対するパッシブ DB コピー数は 2
数
個
1 サーバーでホストする
6,000 個
1 つのアクティブ DB コピーあたり 2
パッシブ メールボック
個のパッシブ DB コピーを配置するた
ス数 (縮退運用時)
め、通常運用時の 1 サーバーあたりの
ユーザー メールボックス数は、4,000
個 (アクティブ DB コピー) + 8,000 個
(パッシブ DB コピー) で 12,000 個。
1 サーバーあたり 12,000 個のうち縮
退運用時にホストするアクティブ メー
ルボックス数が 6,000 個のため縮退運
用時のパッシブメールボックス数は
6,000 個。
Exchange Server 2010 サイジングガイド ホワイトペーパー
86
2.
CPU 要件の算出
①
アクティブ メールボックスのホストに必要な CPU 要件
プロファイルから、アクティブ メールボックスあたりに必要な CPU 要
件は 2 メガサイクルです。
プロファイル
CPU 要件
(平均メール送受信数)
(メガサイクル、アクティブ
メールボックスあたり)
100
2
システム要件から、縮退運用時のアクティブ メールボックス数は 6,000
個であるため、必要な CPU 要件は以下のように算出します。
アクティブ メールボックスのホストに必要な CPU 要件
= 6,000 個 × 2 メガサイクル
= 12,000 メガサイクル
②
パッシブ DB コピーへのレプリケーションに必要な CPU 要件の算出
必要な CPU 要件は以下のように算出します。
パッシブ DB コピーへのレプリケーションに必要な CPU 要件
=12,000 メガサイクル × 0.1 (10%) × 2 パッシブ DB コピー
= 2,400 メガサイクル
③
パッシブ メールボックスのホストに必要な CPU 要件の算出
プロファイルから、パッシブ メールボックスあたりに必要な CPU 要件
は 0.3 メガサイクルです。
プロファイル
CPU 要件
(平均メール送受信数)
(メ ガサイク ル、パ ッシ ブ
メールボックスあたり)
100
0.3
必要な CPU 要件は以下のように算出します。
パッシブ メールボックスのホストに必要な CPU 要件
= 6,000 個 × 0.3 メガサイクル
= 1,800 メガサイクル
Exchange Server 2010 サイジングガイド ホワイトペーパー
87
④
MBX サーバー ロールの CPU 要件の算出
手順①～③の結果を合計し、MBX サーバー ロールの CPU 要件は以下
のように算出します。
MBX サーバーの CPU 要件
= 12,000 ＋ 2,400 ＋ 1,800
= 16,200 メガサイクル
3.
CPU の選定
縮退運用時に CPU 使用率が 80% を超えないようにするには、サーバーに搭
載する CPU は以下の式を満たす必要があります。
プロセッサ コア数 × クロック数 × CPU の数 × 0.8 [80%]
＞ 16,200 メガサイクル
4 プロセッサ コアの CPU を 2 つ利用すると決定した場合、搭載する CPU
は以下の式を満たすものです。
クロック数 ＞ 16,200 メガサイクル ÷ 4 プロセッサ コア ÷ 2 CPU
÷ 0.8 = 約 2,531 MHz
そのため、MBX サーバーには、2.6 GHz 以上の 4 プロセッサ コア CPU を
2 つ搭載します。
4.1.1.2
1.
MBX サーバー ロールのメモリ サイジング
DB キャッシュ総量の算出
プロファイルを考慮し、アクティブ メールボックスあたりの DB キャッシュ
は 6 MB と決定します。
プロファイル
DB キャッシュ (MB)
(メール送受信数)
(アクティブ メールボックス
あたり)
100
6
システム要件からアクティブ メールボックス数 (縮退運用時) は 6,000 個の
ため、必要な DB キャッシュ総量は以下のように算出します。
DB キャッシュ総量
= 6,000 個× 6 MB
= 約 35.1 GB
Exchange Server 2010 サイジングガイド ホワイトペーパー
88
2.
DB キャッシュ総量に基づくサーバーの物理メモリ容量の算出
DB キャッシュが 35.1 GB 必要なため、必要な物理メモリ容量は 48 GB で
す。
3.
サーバーの物理メモリ
DB キャッシュ総量
(RAM)
(MBX サーバー ロールのみ)
48 GB
39.2 GB
DB 数から導かれるメモリの最小容量の算出
1 サーバーあたりのアクティブ DB コピー数を求めます。
ディスクサイジングの詳細に関しては、
「3.1 MBX サーバー ロールのサイジ
ング」を参照してください。
① ユーザー メールボックスあたりのデータ容量を算出します。
ユーザー メールボックスあたりのデータ容量は、以下のように算出します。
空白領域
= 100 通 × 75 KB
= 約 7.3 MB
ごみ箱領域
= (100 通 × 75 KB × 14 日) ＋ (2 GB × 1.2%)
＋ (2 GB × 5.8%)
= 約 246 MB
ユーザー メールボックスあたりのデータ容量
= 2 GB ＋ 7.3 MB ＋ 246 MB = 約 2.25 GB
② DB あたりのユーザー メールボックス数の算出
DB あたりのユーザー メールボックス数は、以下のように算出します。
DB あたりのユーザー メールボックス数
= 530 GB ÷ 2.25 GB
= 約 235 個
③ 1 サーバーあたりの DB 数の算出
24,000 個のユーザー メールボックスを 6 台のサーバーでホストするため、
1 サーバーあたりのアクティブ メールボックス数は以下のように算出しま
す。
1 サーバーあたりのアクティブ メールボックス数
= 24,000 ÷ 6 台 = 4,000 個
Exchange Server 2010 サイジングガイド ホワイトペーパー
89
よって、1 サーバーあたりのアクティブ DB コピー数は、②で算出した DB
あたりのユーザー メールボックス数と、上記で算出した 1 サーバーあたり
のアクティブ メールボックス数から、以下のように算出します。
1 サーバーあたりのアクティブ DB コピー数
= 4000 個 ÷ 235 個
= 約 17 個
1 アクティブ DB コピーあたり 2 パッシブ DB コピーであるため、1
サーバーあたりの DB 数は、以下のように算出します。
1 サーバーあたりの DB 数
= 17 個 (アクティブ DB コピー) ＋ 17 × 2 個 (パッシブ DB コ
ピー)
= 51 個
1 台のサーバーあたり 51 DB をホストするので最小限必要な物理メモリ容
量は 12 GB です。
4.
DB 数
メモリの最小容量
51 ～ 60
12 GB
メモリサイズの決定
DB キャッシュ総量に基づくサーバーの物理メモリ容量 (48 GB) と DB 数
から導かれるメモリの最小容量 (12 GB) を比較した結果、48 GB がサーバー
のメモリ容量となります。
4.1.1.3
1.
MBX サーバー ロールのディスク容量のサイジング
DB 容量の算出
① ユーザー メールボックスあたりのデータ容量の算出
ユーザー メールボックスあたりのデータ容量は、以下のように算出します。
空白領域
= 100 通 × 75 KB
= 約 7.3 MB
ごみ箱領域
= (100 通 × 75 KB × 14 日) ＋ (2 GB × 1.2%)
＋ (2 GB × 5.8%)
= 約 246 MB
ユーザー メールボックスあたりのデータ容量
= 2 GB ＋ 7.3 MB ＋ 246 MB = 約 2.25 GB
Exchange Server 2010 サイジングガイド ホワイトペーパー
90
② DB あたりのユーザー メールボックス数の算出
DB あたりのユーザー メールボックス数は、以下のように算出します。
DB あたりのユーザー メールボックス数
= 530 GB ÷ 2.25 GB
= 約 235 個
③
実際の DB 容量の算出
手順①、②より、実際に必要な DB 容量は以下となります。
実際の DB 容量
= 235 個 × 2.25 GB
= 約 530 GB
④ コンテンツ インデックス領域の算出
DB 容量の約 10% がコンテンツ インデックスとして作成されるため、コン
テンツ インデックス領域は以下のように算出します。
コンテンツ インデックス領域
= 530 GB × 10%
= 53 GB
⑤
オーバーヘッドの考慮
バッファ領域として、20% を考慮します。
⑥
合計 DB 容量の算出
手順③～⑤より、DB あたりに必要となるデータ容量は以下のように算出し
ます。
合計 DB 容量
= (530 GB ＋ 53 GB) × (1 ＋ 0.2[20%])
= 約 700 GB
2.
DB あたりのトランザクション ログ容量の算出
① DB あたりの 1 日分のトランザクション ログ生成数の算出
プロファイルから、1 日にあたりのトランザクション ログ生成数は 20 で
す。
プロファイル
1 日あたりのトランザクショ
(平均メール送受信数、
ン ログ生成数(ユーザー
平均メールサイズ: 75KB)
メールボックスあたり)
100
20
Exchange Server 2010 サイジングガイド ホワイトペーパー
91
DB あたりの 1 日分のトランザクション ログ生成数は以下のように算出
します。
DB あたりの 1 日分のトランザクション ログ生成数
= 235 個 × 20
= 4,700 個
② バックアップと復元の考慮
システム要件より、バックアップは行わず循環ログを有効にするため、トラ
ンザクション ログ容量として、1 日に必要なトランザクション ログ容量の
3 倍を割り当てます。
③ ユーザー メールボックスの移動に必要なトランザクション ログ容量の算出
システム要件より、1 週間に全体の 1% のユーザー メールボックスを移動
します。すべての DB へ均等にユーザー メールボックスを移動するとして、
1 DB あたりのユーザー メールボックスの移動に必要なトランザクション
ログ容量は、以下のように算出します。
ユーザー メールボックスの移動に必要なトランザクション ログ容量
= 移動するユーザー メールボックスの数
× ユーザー メールボックスあたりのデータ容量 (空白領域、ごみ箱
領域を含む)
÷ 全アクティブ DB コピー数
= (24,000 個 × 0.01 [1%]) × 2.25 GB ÷ (17 個 × 6 台)
= 約 5.3 GB
④ オーバーヘッドの考慮
バッファ領域を 20% とします。
⑤ DB あたりのトランザクション ログ容量の算出
トランザクション ログ容量は以下の通り算出します。
DB あたりのトランザクション ログ容量
= (5.3 GB ＋ 4,700 個 × 1 MB × 1 日 × 3) × (1 ＋ 20%)
= 約 23 GB
3.
必要な LUN 領域の算出
システム要件より DB とトランザクション ログを同じ LUN に配置します。
DB あたりの LUN 容量
= (700 GB ＋ 23 GB) ÷ (1 － 0.2 (空き領域 20%) )
= 約 904 GB
Exchange Server 2010 サイジングガイド ホワイトペーパー
92
4.1.1.4
1.
MBX サーバーのディスク性能サイジング
DB 領域に必要な IOPS
プロファイルと DB キャッシュサイズから、DAG 構成におけるユーザー
メールボックスあたりの IOPS は 0.1 です。
プロファイル
DB キ ャ ッ シ ュ
IOPS
(平均メール送受信数)
(MB)
(DAG 構成時)
100
6
0.1
DB あたりのユーザー メールボックス数は 235 個であるため、必要な IOPS
は以下となります。
DB 領域に必要な IOPS 値
= 235 個 × 0.1 × ( 1 ＋ 0.2 (オーバーヘッド 20%) )
= 28.2 IOPS
2.
トランザクション ログ領域に必要な IOPS
DAG 構成におけるトランザクション ログの IOPS は、DB と比較して 50%
分が必要となるため、以下となります。
トランザクション ログ領域に必要な IOPS 値
= 28.2 IOPS × 0.5 × ( 1 ＋ 0.2 (オーバーヘッド 20%) )
= 16.9 IOPS
Exchange Server 2010 サイジングガイド ホワイトペーパー
93
4.1.2
コンバインドロール サーバーのサイジング
コンバインドロール サーバーのプロセッサ コア数は、MBX サーバー ロールのプ
ロセッサ コア数との比率から決定します。MBX サーバー ロールとコンバインド
ロール サーバーの推奨されるプロセッサ コア数の比率は以下の通りです。
Exchange サーバー ロールの構成
推奨されるプロセッサ コア数の比率
MBX サ ー バ ー : コ ン バ イ ン ド
1:1
ロール サーバー
※最低 2 プロセッサ コア必要
※推奨最大 12 プロセッサ コア
MBX サーバー ロールのプロセッサ コア数は、以下のように算出します。
MBX サーバー ロールのプロセッサ コア数
= 8 プロセッサ コア × 6 台
= 48 プロセッサ コア
よって、コンバインドロール サーバーに必要なプロセッサ コア数は、48 プロ
セッサ コアとなります。
CPU は 4 プロセッサ コア 、2 CPU で構成するため、必要なコンバインドロー
ル サーバー台数は以下となります。
CAS サーバー台数
= 48 プロセッサ コア ÷ 4 プロセッサ コア ÷ 2 CPU
=6 台
4.1.2.1
コンバインドロール サーバーのメモリ サイジング
コンバインドロール サーバーのメモリ容量は、以下のように算出します。
コンバインドロール サーバーのメモリ容量
= 搭載プロセッサ コア数 × 2 GB
= 8 プロセッサ コア × 2 GB
= 16 GB
Exchange Server 2010 サイジングガイド ホワイトペーパー
94
4.1.3
サイジング結果
サイジングの結果、以下の図に示すシステム構成となります。
【システム構成図】
HUB
HUB
HUB
HUB
HUB
HUB
CAS
CAS
CAS
CAS
CAS
CAS
CAS アレイ
冗長化
…
…
…
DAG
MBX
MBX
MBX
…
MBX
…
MBX
…
MBX
1 サーバー
あたり 17 個
…
…
…
…
…
…
1 サーバー
あたり 34 個
アクティブ DB コピー
パッシブ DB コピー
本ケース スタディでは、仮想環境を使用せず、物理サーバー上に Exchange サー
バー ロールをインストールしました。また、ロール構成は HUB サーバー ロール
と CAS サーバー ロールを同じサーバーにインストールするコンバインドロール
構成としました。
本ケース スタディでは、上記のような構成を選択しましたが、システム要件によっ
て推奨される構成は変わります。例えば、上記のシステム構成よりパフォーマンス
を良くしたい場合、ロール構成を単体ロール構成としたり、ストレージに RAID を
使用します。上記のシステム構成よりコストを下げたい場合、ロール構成をマルチ
ロール構成としたり、ストレージに JBOD を使用します。また、仮想環境などの
選択肢もあります。
システム構成には様々な構成が考えられるため、本ガイドを参考に、要件にあった
適切なシステム構成を選択し、サーバー サイジングを行ってください。
Exchange Server 2010 サイジングガイド ホワイトペーパー
95
第五部
サイジング検証
この章ではサイジングに関する検証について記載します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
96
5.1 検証概要
ここでは、主に Exchange 2007 から Exchange 2010 で変更されたアーキテク
チャを中心に、サイジングに影響する負荷検証を行い、そのパフォーマンスを計測
した 3 つの検証に関して説明します。
No.
検証概要
検証内容
1
MBX サーバーの搭載メモリ
MBX サーバーの搭載メモリ容量を
容量とディスク I/O の相関調
変更することによる IOPS などの
査検証
ディスク負荷を調査する
CAS サーバーへの RPC 負荷
CAS サーバー 1 台あたりでホスト
検証
可能なユーザー数を調査する
最少構成台数でのマルチロー
マルチロールでの物理サーバー 2
ル環境と仮想環境の比較検証
台 の構 成と 仮想 環境 での 物理 サ ー
2
3
バー 2 台の構成において、パフォー
マンス比較を実施する
5.1.1
MBX サーバーの搭載メモリ容量とディスク I/O の相関調査検
証
Exchange 2010 では、ユーザーからのアクセスが DB キャッシュにヒットした場
合、ディスクへの読み取り I/O が発生しないため、ディスクの負荷を低減できます。
また、DB キャッシュの容量は、MBX サーバーの搭載メモリ容量と相関関係にあ
ります。これにより、MBX サーバーの搭載メモリ容量を増加することで、ディス
クへの負荷を低減させることが可能です。
そこで、 MBX サーバーの搭載メモリ容量を変化させた場合に、I/O やディスク負
荷がどの程度軽減するかを検証します。本検証結果は、MBX サーバーの搭載メモ
リ容量とディスクを選択する際に参考にしてください。
なお、DB キャッシュの詳細に関しては「3.1.3.1 DB キャッシュ総量の算出」を参
照してください。
5.1.2
CAS サーバー 1 台でホスト可能なユーザー数の調査検証
Exchange 2007 の CAS サーバーと比較し、Exchange 2010 の CAS サーバーは、
クライアントからのアクセスに関する機能のほとんどを処理するようにアーキテク
チャが変更されました。たとえば、Outlook などの MAPI クライアントからのア
クセスや、OWA のブラウザへのレンダリング処理などが MBX サーバーから
CAS サーバーへ移りました。
Exchange Server 2010 サイジングガイド ホワイトペーパー
97
そこで本検証では、Exchange 2010 の CAS サーバーにおいて 1 台あたりでホス
ト可能なユーザー数を調査するための検証を実施します。本検証結果は、CAS サー
バーのサイジングを行う際に参考にしてください。
なお、CAS サーバーの変更点に関しては「3.2 CAS サーバー ロールのサイジング」
を参照してください。
5.1.3
最少構成台数でのマルチロール環境と仮想環境の比較検証
Exchange 2007 から Exchange 2010 へのアーキテクチャ変更により、冗長化す
る場合の最少構成台数が 4 台から 2 台へと変更されました。2 台構成を実現する
には、次の 2 つの方法があります。
 マルチロール環境
2 台の物理サーバーにそれぞれマルチロールを展開し、DAG を構成すること
で MBX サーバーの冗長化を実施し、ハードウェア負荷分散装置により CAS
サーバーあるいは HUB サーバーを負荷分散する構成。少なくとも CAS サー
バーの負荷分散には、ハードウェア負荷分散装置が必須であることに注意が必
要です。
 仮想環境
2 台の物理サーバーに 2 つの仮想マシンを展開し、1 つの仮想マシン上に
MBX サーバーを DAG で構成することで MBX サーバーの冗長化を実施し、
もう 1 つの仮想マシンに HUB/CAS サーバーを 構成し NLB や ハード
ウェア負荷分散装置により 仮想マシン上の CAS サーバーあるいは HUB
サーバーを負荷分散する構成。仮想環境の場合、CPU の割り当てやオーバー
ヘッドを考慮する必要があります。
次の図は、マルチロールと仮想環境のそれぞれの 2 台構成の一例です。なお、図
の点線の青枠は、Exchange 組織を示しています。
Exchange Server 2010 サイジングガイド ホワイトペーパー
98
マルチロール構成
ハードウェア
負荷分散装置
仮想環境構成
HUB / CAS
MBX
HUB
HUB
CAS
CAS
MBX
MBX
HUB / CAS
MBX
マルチロール
マルチロール
ホスト
ホスト
サーバー 1
サーバー 2
サーバー 1
サーバー 2
上記のように、同一スペックの物理サーバー 2 台構成で、同一負荷をかけた場合
にパフォーマンスを比較した検証を実施します。
本検証結果は、最少構成台数での導入や、マルチロールもしくは仮想環境の導入を
検討している際に参考にしてください。
なお、マルチロール構成の詳細に関しては「2.1.1 マルチロール構成の考え方」を、
仮想環境の詳細に関しては「2.2 仮想化の考え方」を参照してください。
Exchange Server 2010 サイジングガイド ホワイトペーパー
99
5.2 MBX サーバーの搭載メモリ容量とディスク I/O の相関調査検証
ここでは、MBX サーバーの搭載メモリ容量の変動が、ディスク I/O のパフォーマ
ンスへどのような影響を与えるかについて検証した内容を説明します。
5.2.1
テスト シナリオ
MBX サーバーの搭載メモリ容量の変動によるディスク I/O への影響を検証するた
めに、次の 3 つのテスト ケースを用意し、MBX サーバーのパフォーマンスを測定
します。
No.
比較項目
テスト ケース 1
MBX サーバーの搭載メモリ容量 8 GB
テスト ケース 2
MBX サーバーの搭載メモリ容量 16 GB
テスト ケース 3
MBX サーバーの搭載メモリ容量 32 GB
各テスト ケースは、比較項目以外のサーバー台数やサーバー スペックはすべて同一
のものであり、ドメイン コントローラー (DC)、HUB サーバー、CAS サーバー、
MBX サーバーをそれぞれ別々の物理コンピュータに展開して、MBX サーバーのパ
フォーマンスを測定します。
5.2.2
検証環境
 検証環境の全体構成
次の図に、パフォーマンス検証テストのために用意したシステムの全体構成を
示します。すべてのテスト ケースにおいて、MBX サーバー以外の Exchange
サーバー ロールを実行するサーバーは、同じプロセッサ コア数・クロック数・
搭載メモリ容量とし、比較項目である MBX サーバーの搭載メモリ容量のみ 8
GB / 16 GB / 32 GB と変動させて、同一負荷に対するパフォーマンスを検証し
ます。なお、本検証結果は、MBX サーバー以外はボトルネックが発生してい
ないことを確認した上での結果となります。
Exchange Server 2010 サイジングガイド ホワイトペーパー
100
【サーバー環境図】
HUB
CAS
テスト ケース 1 :
8 GB RAM
MBX
8 コア
テスト ケース 2 :
16 GB RAM
テスト ケース 3 :
32 GB RAM
DB 1
DC
DB 2
負荷クライアント
DB 3
ストレージ機器
役割
使用機種
サーバー一台あたりのスペック
DC
富士通 PC サーバ
8 プロセッサ コア (Intel® Xeon®
PRIMERGY
プロセッサ X5460 (3.16 GHz / 12
RX300 S4
MB) × 2 CPU)
4 GB メモリ
HUB
富士通 PC サーバ
8 プロセッサ コア (Intel® Xeon®
サーバー
PRIMERGY
プロセッサ X5460 (3.16 GHz / 12
RX300 S4
MB) × 2 CPU)
4 GB メモリ
CAS
富士通 PC サーバ
8 プロセッサ コア (Intel® Xeon®
サーバー
PRIMERGY
プロセッサ X5570 (2.93 GHz / 8
TX300 S5
MB) × 2 CPU)
32 GB メモリ
NLB による冗長構成
MBX
富士通 PC サーバ
8 プロセッサ コア (Intel® Xeon®
サーバー
PRIMERGY
プロセッサ X5570 (2.93 GHz / 8
TX300 S5
MB) × 2 CPU)
8 GB / 16 GB / 32 GB メモリ
 MBX サーバーのストレージ構成
ストレージは、富士通 ストレージシステム ETERNUS DX 60 を使用します。
ディスク構成は、RAID 編成 (RAID 1 または RAID 10) とし、3 つのメール
ボックス DB と、それに対応する 3 つのトランザクション ログを、別々の
LUN に配置します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
101
【ストレージ環境図】
DB 1
DB 2
DB 3
Log 1
Log 2
Log 3
LUN 1
LUN 2
LUN 3
LUN 4
LUN 5
LUN 6
RAID 10
RAID 10
RAID 10
RAID 1
RAID 1
RAID 1
物理ディスク (300 GB, SAS, 15,000 rpm)
なお、本検証では、ディスクがボトルネックとならないように余裕を持ったス
トレージ装置、ディスク本数、RAID 編成でストレージを構成しています。こ
のストレージ構成は一例であり、実運用のためには最適なサイジングが必要に
なります。ストレージのサイジングの詳細に関しては「2.6 ディスク サイジン
グの考え方」 や 「3.1.4 ディスク容量のサイジング」、
「3.1.5 ディスク性能の
サイジング」 を参照してください。
 Exchange 2010 の設定
Exchange 2010 の主な設定はデフォルト設定としますが、本検証では、MBX
サーバーの搭載メモリ容量と IOPS の相関関係を調査することが目的である
ため、非トランザクション I/O が発生する処理は、すべて動作しない設定に変
更して実施します。検証の際に変更した設定を次の表に示します。
設定項目
検証時の設定
デフォルト値
バックグラウンド データ
OFF
ON
循環ログ
ON
OFF
Microsoft Exchange Search
停止
開始
ベース保守 (24 x 7 ESE ス
キャン)
Indexer
Exchange Server 2010 サイジングガイド ホワイトペーパー
102
 テスト ツール
各テスト ケースに対して同一の負荷を生成するために、Exchange Load
Generator 2010 (LoadGen) を使用します。このツールは、Exchange Server
に対するベンチマーク テストやストレス テストのために、MAPI、OWA
(Outlook Web App)、ActiveSync、IMAP、POP、SMTP クライアントといっ
た、さまざまなタイプのワークロードをシミュレーションします。
Exchange Load Generator 2010 (Loadgen.msi)
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyI
D=cf464be7-7e52-48cd-b852-ccfc915b29ef
LoadGen に、以下のプロファイルを設定し、1 台の管理端末からの指示で、3
台の実行端末から負荷を発生させます。パフォーマンス データは、サーバー側
のパフォーマンス モニターを使用して測定します。
設定項目
設定値
ユーザー数
6,000 ユーザー (6,000 ユーザー/サーバー、3 データ
ベース/サーバー、2,000 ユーザー/データベース)
Outlook_100 (100 通送受信、送受信メッセージ サイズ
プロファイル
約 75 KB/通)
Outlook 2007 オンライン モード
クライアント
(Outlook 2007 の既定値はキャッシュ モード)
メールボックス サイ
約 250 MB/ユーザー
ズ
1,000 グループ (メンバーシップ数： 最少 2、平均 20、
配布グループ
最大 50)
シミュレーションに
8 時間
おける 1 日の長さ
シミュレーションを
4 時間
実施する長さ
パフォーマンス測定
シミュレーション 4 時間のうち、後半の 2 時間で測定
のタイミング
5.2.3
プロセッサとメモリのパフォーマンス
次の図は、各テスト ケースにおける MBX サーバーの CPU 使用率 (Processor
Time) とメモリ空き容量 (Memory¥Available MBytes) の平均値です。
Exchange Server 2010 サイジングガイド ホワイトペーパー
103
Processor Time パフォーマンス カウンターは、プロセッサがアプリケーションま
たはシステム プロセスを実行している時間の割合を示します。このカウンターの平
均値は DAG を構成していない場合は 70% 未満、DAG を構成する場合は、80%
未満であることが推奨されます。
本検証では、すべてのテスト ケースにおいて良好な値を示しており、テスト ケー
ス間で大きな差は見られません。
Memory¥Available MBytes パフォーマンス カウンターは、プロセスやシステム
のために直ちに利用可能な物理メモリの容量を MB 単位で示します。このカウン
ターは、常に 100 MB を上回っていることが推奨されます。
本検証では、テスト ケース間で値が異なりますが、すべてのテスト ケースにおい
て良好な値を示しています。テスト ケース間で値が異なる原因は、搭載メモリ容量
が異なるためです。
これらについての考察は次の通りです。
 CPU 使用率 (Processor Time)
本検証では、各テスト ケースに対して同一の負荷を生成したことで、MBX
サーバーにかかる負荷が同等であったため、各テスト ケースにおいても
Exchange Server 2010 サイジングガイド ホワイトペーパー
104
Processor Time がほぼ同等になったと考えられます。
 使用メモリ容量
次の表は MBX サーバの搭載メモリ容量から空き容量を引き、使用メモリ容量
を示したものです。
本検証では、各テスト ケースにおいて負荷が同一であるにも関わらず、MBX
サーバーの搭載メモリ容量が多いほど、メモリ使用量が多いことがわかります。
これは、搭載メモリ容量が多いほど、DB キャッシュをより多く展開するため
であると考えられます。
また、サイジング指針の搭載メモリ容量と DB キャッシュ総量の関係と、本検
証の使用メモリ容量をまとめた表を次に示します。
サーバーの物理
DB キャッシュ総量
本検証での使用メモリ
メモリ (RAM)
(MBX サーバー ロールのみ)
容量
8 GB
3.6 GB
5.1 GB
16 GB
10.4 GB
11.3 GB
32 GB
24.4 GB
24.8 GB
使用メモリ容量には、OS などにより使用されるメモリが含まれているため、
サイジング指針よりも多めに使用されていますが、ほぼサイジング指針の通り
の DB キャッシュが展開されていると考えられます。
5.2.4
ディスク I/O パフォーマンス
次の図は、各テスト ケースにおける、MBX サーバー ロールのディスク I/O パ
フォーマンス (Disk Reads/sec、Disk Writes/sec、および IOPS) の平均値を示し
ています。なお、次のデータは、1 つの DB (2,000 ユーザー) において得られた I/O
Exchange Server 2010 サイジングガイド ホワイトペーパー
105
パフォーマンスを示しています。本検証では、6,000 ユーザーを 3 つの DB に
2,000 ユーザーずつ分割して格納したため、システム全体の I/O パフォーマンスは
次のデータのおおよそ 3 倍となることに注意してください。
IOPS (Input / Output Per Second) は、一定期間の Physical Disk (Logical Disk)
¥Disk Transfers/sec の平均値であり、1 秒あたりに発生したディスク I/O を示し
ます。IOPS の値は、読み取り I/O (Disk Reads/sec パフォーマンス カウンター)
と 書き込み I/O (Disk Writes/sec パフォーマンス カウンター) の合計と一致しま
す。
Disk Reads/sec の値は、テスト ケース 1 よりテスト ケース 2 の値が小さく、
またテスト ケース 2 よりテスト ケース 3 の値が小さいため、搭載メモリ容量が
多い方がディスクに対する読み取り I/O 負荷が低いことを示していることがわか
ります。また、Disk Writes/sec の値は、テスト ケース間で大きな差は見られませ
ん。なお、IOPS は、Disk Reads/sec と Disk Writes/sec の合計数であるため、
Disk Reads/sec と同様に搭載メモリ容量が多い方がディスクに対する I/O 負荷が
低いことを示していることがわかります。
次の図は、メールボックス DB を配置したディスク (LUN) の Avg. Disk Queue
Length パフォーマンス カウンターの平均値を示しています。なお、次に示すデー
タは 3 つの DB の平均値となります。
Exchange Server 2010 サイジングガイド ホワイトペーパー
106
Avg. Disk Queue Length は、ディスクのキューに入った読み取りおよび書き込み
I/O の平均値で、待ち行列の長さを示しています。ディスクにボトルネックが発生
している場合、この値が増加します。このカウンターの平均値は、ディスク スピン
ドル数に 2 を加えた値未満であることが推奨されます。
Avg. Disk Queue Length の値は、すべてのテスト ケースにおいて良好な値を示し
ていますが、搭載メモリ容量が多い方がより良好な値を示していることがわかりま
す。
これらについての考察は次の通りです。
 ディスクへの読み取り I/O (Disk Reads/sec)
MBX サーバーの搭載メモリ容量を増加させることで、DB キャッシュが多く
利用できるようになったため、ディスクへの読み取り I/O が減少したと考えら
れます。
 ディスクへの書き込み I/O (Disk Writes/sec)
ディスクへの書き込み I/O は、ログ チェックポイントの深さのターゲットの
値により異なり、ログ チェックポイントの深さのターゲットは、DAG 構成の
有無により変動します。本検証では、各テスト ケースにおいて DAG を構成
しておらず、ログ チェックポイントの深さのターゲットの値は同一です。その
ため、各テスト ケース間でディスクへの書き込み I/O が、ほぼ同一の値になっ
たと考えられます。
 Avg. Disk Queue Length
ディスクへの読み取り I/O が減少したことにより、Avg. Disk Queue Length
が減少したと考えられます。
Exchange Server 2010 サイジングガイド ホワイトペーパー
107
5.2.5
サイジング指針と検証結果を比較した考察
ここでは、サイジング指針から導き出される必要スペックと、検証から得られた実
測データを比較した考察を示します。
今回の検証は、Outlook 2007 オンライン モードを利用するユーザー 6,000 人が、
それぞれ 1 日に 100 通のメールを送受信することを想定した環境です。この環境
では、ユーザーごとにメールボックスを持ち、ユーザー メールボックスを 2,000 個
格納した DB が 3 つ存在します。
この環境で必要な IOPS は、サイジングから以下のように算出します。計算式の詳
細に関しては、「3.1.5 ディスク性能のサイジング」を参照してください。
2,000 個 × 0.12 × 3 DB ＝ 720 IOPS
同様にこの環境で必要な DB キャッシュをサイジングから以下のように算出しま
す。
2,000 個 × 6 MB × 3 DB ＝ 35.2 GB
35.2 GB の DB キャッシュに必要なサーバーの搭載メモリ容量は 48 GB です。
計算式の詳細に関しては「3.1.3 メモリのサイジング」を参照してください。
これらから、今回の検証環境で必要なスペックをサイジングから算出した結果は次
のようになります。 (注：オーバーヘッド 20% は除いた数値)
搭載メモリ指針
IOPS 指針
48 GB
720
これに対して、本検証の各テスト ケースにおいて 6,000 人 (DB 3 つから得られ
た数値の合計) の IOPS をまとめた表を次に示します。
搭載メモリ容量
実測 IOPS
8 GB
1222
16 GB
618
32 GB
355
Exchange Server 2010 サイジングガイド ホワイトペーパー
108
この実測 IOPS と 1 人あたりの IOPS を表したものが次のグラフです。
次に、サイジング指針通りの DB キャッシュが展開されてたと仮定した場合、本検
証でのユーザー 1 人あたりの DB キャッシュ割り当ては次のようになります。
サーバーの物理
本検証でのユーザー 1 人あたり
メモリ (RAM)
の DB キャッシュ割り当て
8 GB
0.61 MB
16 GB
1.77 MB
32 GB
4.16 MB
ここまでで得られた情報から、ユーザー 1 人あたりのサイジング指針と実測値を
照らし合わせた表が次のようになります。
搭載メモリ
DB キ ャ ッ
DB キ ャ ッ
容量
シュ指針
シュ実績
8 GB
16 GB
32 GB
IOPS 指針
0.61 MB
6 MB
1.77 MB
IOPS 実績
0.20
0.12
4.16 MB
0.10
0.06
すべてのテスト ケースにおいて DB キャッシュ容量はサイジング指針よりも少な
くなっていることがわかります。ただし、IOPS は、8 GB の場合のみサイジング
指針よりも多い IOPS となっており、16 GB 以上の搭載メモリ容量の場合は、サ
イジングよりも少ない IOPS となっていることがわかります。
これらから、サイジング結果と実測データは異なり、実測データの方が負荷が低い
ことがわかりました。
ただし、本検証においてパフォーマンス測定のタイミングは、
シミュレーション 4 時間のうち、後半の 2 時間の処理が安定したタイミングを測
Exchange Server 2010 サイジングガイド ホワイトペーパー 109
定したデータであることや、サイジング指針とプロファイルが異なる (※) こと、
検証のため非トランザクション I/O が発生する処理を停止していたことなどから、
実運用では若干のオーバーヘッドが発生する可能性があります。
※ サイジングの基となるプロファイル (100 通送受信 / 6 MB キャッシュ / 0.12
IOPS) は、Outlook 2007 または Outlook 2010 キャッシュ モード クライアント
を 使 用 し 2 GB の メ ー ル ボ ッ ク ス サ イ ズ ク ォ ー タ 、 お よ び Exchange
ActiveSync の利用率が高いユーザを想定したものです。
5.2.6
まとめ
以上により、MBX サーバーの搭載メモリ容量が増加することで IOPS が減少し、
それによりディスクの負荷が軽減することがわかりました。また、サイジング指針
から算出される必要メモリよりも少ない搭載メモリ容量であった場合は、ディスク
の負荷が上昇しますが、上昇した負荷をまかなえるディスク スペックを確保するこ
とで、問題なく動作することがわかりました。これらにより、MBX サーバーの搭
載メモリ容量を増加させることでディスクへの負荷が軽減されるため、サイジング
によってはより安価なストレージ システムを採用することが可能となります。
Exchange Server 2010 サイジングガイド ホワイトペーパー
110
Exchange Server 2010 サイジングガイド ホワイトペーパー
111
5.3 CAS サーバーへの RPC 負荷検証
ここでは、CAS サーバー 1 台でホスト可能なユーザー数を調査する検証について
説明します。
5.3.1
テスト シナリオ
ユーザーの増減による CAS サーバー 1 台あたりの負荷を調査するために、次の 3
つのテスト ケースを用意し、CAS サーバーのパフォーマンスを測定します。
No.
比較項目
テスト ケース 1
ユーザー数 6,000
テスト ケース 2
ユーザー数 12,000
テスト ケース 3
ユーザー数 18,000
これらのテスト ケースにおいて、サーバー台数やサーバー スペックはすべて同じで
あり、DC、HUB サーバー、CAS サーバー、MBX サーバーをそれぞれ別々の物理
コンピュータに展開して、パフォーマンスを測定します。
5.3.2
検証環境
 検証環境の全体構成
次の図に、パフォーマンス検証テストのために用意したシステムの全体構成を
示します。すべてのテスト ケースにおいて、同じ Exchange サーバー ロー
ルを実行するサーバーは、同じプロセッサ コア数・クロック数・搭載メモリ容
量とし、テスト ケースごとに負荷を変動させてパフォーマンスを検証します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
112
【環境図】
HUB
CAS
MBX 1
MBX 2
テスト ケース 1 :
6,000 ユーザー
テスト ケース 2 :
12,000 ユーザー
テスト ケース 3 :
18,000 ユーザー
DB 1
DB 4
DB 2
DB 5
DB 3
DB 6
DC
負荷クライアント
ストレージ機器
※DB とトランザクション ログ 領域は物理ディスクを分けて格納
※DB とトランザクション ログ は SAS ディスク、15,000 rpm HDD を使用
役割
使用機種
サーバー一台あたりのスペック
DC
富士通 PC サーバ
8 プロセッサ コア (Intel® Xeon®
PRIMERGY
プロセッサ X5460 (3.16 GHz / 12
RX300 S4
MB) × 2 CPU)
4 GB メモリ
HUB
富士通 PC サーバ
8 プロセッサ コア (Intel® Xeon®
サーバー
PRIMERGY
プロセッサ X5460 (3.16 GHz / 12
RX300 S4
MB) × 2 CPU)
4 GB メモリ
CAS
富士通 PC サーバ
4 プロセッサ コア (Intel® Xeon®
サーバー
PRIMERGY
プロセッサ X5570 (2.93 GHz / 8
TX300 S5
MB) × 1 CPU)
16 GB メモリ
MBX
富士通 PC サーバ
8 プロセッサ コア (Intel® Xeon®
サーバー
PRIMERGY
プロセッサ X5570 (2.93 GHz / 8
TX300 S5
MB) × 2 CPU)
32 GB メモリ
 テスト ツール
各テスト ケースに対して異なる負荷を生成するために、Exchange Load
Generator 2010 (LoadGen) を使用します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
113
LoadGen に、以下のプロファイルを設定し、1 台の管理端末からの指示で、3
台の実行端末から負荷を発生させます。パフォーマンス データは、サーバー側
のパフォーマンス モニターを使用して測定します。
設定項目
設定値
ユーザー数
テスト ケースごとに変動のため後述
プロファイル
Outlook_100 (100 通送受信、送受信メッセージ サイズ
約 75 KB/通)
Outlook 2007 オンライン モード
クライアント
(Outlook 2007 の既定値はキャッシュ モード)
メールボックス サイ
約 100 MB/ユーザー
ズ
配布グループ
テスト ケースごとに変動のため後述
シミュレーションに
8 時間
おける 1 日の長さ
シミュレーションを
4 時間
実施する長さ
パフォーマンス測定
シミュレーション 4 時間のうち、後半の 2 時間で測定
のタイミング
設定項目
ユーザー数
配布リスト
テスト ケース 1
6,000 ユ ー ザ ー (3,000 ユ ー
1,000 グ ル ー プ ( メ ン
ザー/サーバー、3 データベー
バーシップ数： 最少 2、
ス/サーバー、1,000 ユーザー/ 平均 20、 最大 50)
データベース)
テスト ケース 2
12,000 ユーザー (6,000 ユー
2,000 グ ル ー プ ( メ ン
ザー/サーバー、3 データベー
バーシップ数： 最少 2、
ス/サーバー、2,000 ユーザー/ 平均 20、 最大 50)
データベース)
テスト ケース 3
18,000 ユーザー (9,000 ユー
3,000 グ ル ー プ ( メ ン
ザー/サーバー、3 データベー
バーシップ数： 最少 2、
ス/サーバー、3,000 ユーザー/ 平均 20、 最大 50)
データベース)
5.3.3
プロセッサとメモリのパフォーマンス
次の図は、各テスト ケースにおける CAS サーバーの CPU 使用率 (Processor
Time) とメモリ空き容量 (Memory¥Available MBytes) の平均値です。
Exchange Server 2010 サイジングガイド ホワイトペーパー
114
Processor Time パフォーマンス カウンターは、プロセッサがアプリケーションま
たはシステム プロセスを実行している時間の割合を示します。このカウンターの平
均値は CAS サーバーの場合は 60% 未満であることが推奨されます。
本検証では、すべてのテスト ケースにおいて良好な値を示していますが、ユーザー
数が少ない方がより良好な値を示しています。
Memory¥Available MBytes パフォーマンス カウンターは、プロセスやシステム
のために直ちに利用可能な物理メモリの容量を MB 単位で示します。このカウン
ターは、常に 100 MB を上回っていることが推奨されます。
本検証では、すべてのテスト ケースにおいて良好な値を示していますが、ユーザー
数が少ない方がより良好な値を示しています。
これらについての考察は次の通りです。
 CPU 使用率 (Processor Time)
本検証では、各テスト ケースに対してユーザー数を変化させることで負荷を変
化し、ユーザー数に比例して CAS サーバーへのアクセスが増加した結果、
Processor Time が上昇したと考えられます。また、すべてのテスト ケースに
おいて CPU がボトルネックにならないことから、18,000 ユーザーにおいて
Exchange Server 2010 サイジングガイド ホワイトペーパー
115
も CPU の負荷はしきい値範囲内です。
ただし、本検証においてパフォーマンス測定のタイミングは、シミュレーショ
ン 4 時間のうち、後半の 2 時間の処理が安定したタイミングを測定したもの
を記載しており、CAS サーバーの負荷という観点では、朝のピーク時などを
想定して同時接続ユーザー数を考慮する必要があります。LoadGen のシミュ
レーションでは、シミュレーション開始時に設定したすべてのユーザーが
CAS サーバーへログオン処理を行います。そのため、シミュレーション開始
直後は、CAS サーバーの負荷が上昇します。次のグラフは、 シミュレーショ
ン 4 時間のうち、前半 2 時間の CAS サーバーの Processor Time の推移を
示した物です。
このようにシミュレーション開始直後は、6,000 ユーザーのテスト ケースは、
しきい値範囲内の 60 % に収まっていますが、12,000 ユーザーと 18,000
ユーザーのテスト ケースは 60% を超えており、CPU がボトルネックとなっ
ていることがわかります。これにより、同時接続ユーザー数は、CAS サーバー
1 台において 6,000 ユーザー以内であれば問題がないと言えます。
なお、LoadGen で設定するユーザー数は、企業のユーザー数と同等のユーザー
数を想定したものですが、同時接続ユーザー数を考慮した場合は意味合いが異
なり、LoadGen の設定数が必ずしも企業のユーザー数と同一とならないこと
に注意してください。たとえば、18,000 人規模の企業において、始業時から
メールを使用するユーザーが約 6,000 人であるといった環境を想定した場合、
同時接続ユーザー数は、6,000 ユーザーとなります。そのため、この環境のピー
ク時の想定負荷は、上記グラフの 18,000 ユーザーのテスト ケースではなく、
6,000 ユーザーのテスト ケースが該当することに注意してください。
 使用メモリ容量
Processor Time と同様に CAS サーバーへのアクセス増加により使用メモリ
容量が増えたと考えられます。
Exchange Server 2010 サイジングガイド ホワイトペーパー
116
5.3.4
RPC パフォーマンス
次の図は、各テスト ケースにおける CAS サーバのリモート プロシージャ コー
ル (RPC) 操作数 (RPC Operations/sec) と RPC 要求数 (RPC Requests) の平均
値です。
MSExchangeIS (または MSExchange RPCClientAccess) ¥RPC Operations/sec
パフォーマンス カウンターは、過去 1 秒間に発生している RPC 操作の数を示し
ます。Exchange 2010 において CAS サーバーが MAPI クライアントからのアク
セスを処理するように変更されたため、この値も合わせて参照することで CAS
サーバーへのクライアントアクセス負荷を調査することが可能です。
本検証においては、ユーザー数に比例して RPC Operations/sec が上昇しているこ
とがわかります。
MSExchangeIS ( ま た は MSExchange RPCClientAccess) ¥RPC Requests パ
フォーマンス カウンターは、Microsoft Exchange Information Store サービスに
よって現在処理されている MAPI RPC またはクライアントの数を示します。この
カウンターの平均値は、常に 70 未満であることが推奨されます。Exchange Server
2010 における RPC 要求の最大値は 500 であり、それ以上の新しい RPC 操作
Exchange Server 2010 サイジングガイド ホワイトペーパー 117
は拒否されます。
本検証においては、すべてのテスト ケースにおいて良好な値を示していますが、
ユーザー数が少ない方がより良好な値を示していることがわかります。
次の図は、各テスト ケースにおける CAS サーバーの RPC 待機時間 (RPC
Averaged Latency) の平均値と、負荷クライアントで測定されたレスポンス タイ
ム (Read And Process Messages Action Latency) の平均値です。
MSExchangeIS ( ま た は
MSExchange RPCClientAccess) ¥RPC Averaged
Latency パフォーマンス カウンターは、過去 1,024 パケットの RPC の平均待ち
時間をミリ秒単位で示しています。オンライン モードの Outlook クライアントを
使用する場合、このカウンターの最大値は 50 ミリ秒以下であることが推奨されま
す。
本検証においては、すべてのテスト ケースにおいて良好な値を示していますが、
ユーザー数が少ない方がより良好な値を示していることがわかります。
Exchange Load Generator User Groups¥Read And Process Messages Action
Latency パフォーマンス カウンターは、負荷クライアントの LoadGen が提供す
るものです。このカウンターは、クライアント側におけるメッセージ読み取りタス
クが完了するまでの平均時間 (ミリ秒) を示します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
118
本検証においては、ユーザー数が少ない方が、処理時間が減少しています。この結
果は、サーバー側の RPC 待機時間が減少したことによる影響を示しています。
これらについての考察は次の通りです。
 RPC 操作数 (RPC Operations/sec)
送受信数などのプロファイルが同一である場合にユーザー数を増加させた場合、
RPC Opeations/sec はユーザー数に比例して増加することが正常です。本検証
では、各テスト ケースごとに RPC Operations/sec の値がユーザー数に比例
して増加していることがわかります。そのため、想定通りの負荷がかけられた
と考えられ、検証に問題がなかったと言えます。
 RPC 要求数 (RPC Requests)
各テスト ケースにおいて、ユーザー数が多いほど RPC 要求数が増加する傾
向にあります。ただし、推奨値のしきい値範囲内であることから、サーバーの
ボトルネックとはなっていません。
 RPC 待機時間 (RPC Average Latency)
各テスト ケースにおいて、ユーザー数が多いほど RPC 待機時間が増加する
傾向にあります。これは CAS サーバーが処理する人数が多いほど RPC 要求
数が多くなり、CAS サーバーの CPU 負荷が上昇するため、待ち時間が増加
すると考えられます。
 クライアント側のレスポンス タイム (Read And Process Messages Action
Latency)
各テスト ケースにおいて、ユーザー数が多いほどクライアント側のレスポンス
タイムが増加する傾向にあります。これは RPC 待機時間が増加することによ
りレスポンス タイムが増加すると考えられます。
5.3.5
サイジング指針と検証結果を比較した考察
ここでは、本検証の想定環境において、CAS サーバーに必要なスペックをサイジ
ング指針から算出し、実際の検証データと照らし合わせた結果から考察を記載しま
す。
本検証では、100 通送受信を想定した環境であったため、アクティブ メールボッ
クスあたりに必要な CPU 要件は 2 メガサイクルです。各テスト ケースにおいて
必要な CPU 要件は次のようになります。
Exchange Server 2010 サイジングガイド ホワイトペーパー
119
ユーザー数
必要な CPU 要件 (MHz)
6,000 ユーザー
12,000
12,000 ユーザー
24,000
18,000 ユーザー
36,000
本検証で MBX サーバーと CAS サーバーに使用した CPU のスペックは次の通
りです。
項目
CPU スペック
機種
Intel® Xeon® プロセッサ X5570
クロック数
2,930 MHz (2.93 GHz)
必要な CPU 要件と CPU のクロック数から MBX サーバーに必要なプロセッサ
コア数が算出できます。また、CAS サーバーのプロセッサ コア数は、MBX サー
バーのプロセッサ コア数との比率により算出できます。これらを算出した結果の表
が次の通りです。
MBX サ ー バ ー の プ ロ
CAS サ ー バ ーの プ ロ
セッサ コア数
セッサ コア数
6,000 ユーザー
5.2 プロセッサ コア
3.9 プロセッサ コア
12,000 ユーザー
10.4 プロセッサ コア
7.8 プロセッサ コア
18,000 ユーザー
15.6 プロセッサ コア
11.7 プロセッサ コア
ユーザー数
本検証において CAS サーバーは 4 プロセッサ コアを使用したため、サイジング
指針と照らし合わせると 6,000 ユーザーのみサイジング指針を満たし、12,000
ユーザー以上の環境では、プロセッサ コア数が不足する結果となりました。
次に、本検証において、各テスト ケースの結果をまとめた表が次の通りです。
ユーザー数
安定稼働時のユーザー数
同時接続ユーザー数を
を想定した場合
想定した場合
6,000 ユーザー
ボトルネックはない
ボトルネックはない
12,000 ユーザー
ボトルネックはない
CPU がボトルネック
18,000 ユーザー
ボトルネックはない
CPU がボトルネック
この表から、安定稼働時はサイジング指針よりも CPU スペックが低い場合でもあ
る一定のユーザー数まではボトルネックが発生しない可能性が伺えます。ただし、
ピーク時などの同時接続ユーザー数が多い場合は、その数を考慮したサイジングを
する必要があります。
Exchange Server 2010 サイジングガイド ホワイトペーパー
120
以上のことから CAS サーバーのサイジング指針の通りにサイジングを行うこと
で安定時の負荷をまかなうことができますが、ピーク時における同時接続ユーザー
数については設計時に考慮する必要があると考えられます。
5.3.6
まとめ
本検証環境においては、通常業務時に CAS サーバー 1 台で 18,000 ユーザーを
ホストできることがわかりました。ただし、朝のピーク時などに同時にログオンす
るユーザー数が 6,000 人を超える場合、4 プロセッサ コアの CAS サーバーにお
いて CPU がボトルネックとなる可能性があります。そのため、サイジングにおい
て、ピーク時の同時接続ユーザー数を考慮することが重要です。また、CAS サー
バー 1 台でホストするユーザー数が多い場合、CAS サーバーの障害時に影響を受
けるユーザー数が多くなります。
以上のように、CAS サーバー 1 台で 1 万ユーザーを超えるユーザーをホストす
ることが可能な場合もありますが、ピーク時における負荷分散や、障害時の影響の
軽減、または冗長化といった観点を考慮した場合、2 台以上の CAS サーバーで運
用することを推奨します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
121
5.4 最少構成台数でのマルチロール環境と仮想環境の比較検証
ここでは、Exchange 2010 の最少構成台数である 2 台構成において、マルチロー
ル サーバー 2 台による構成と、仮想環境 2 台による構成のパフォーマンスを比
較した検証内容について説明します。
5.4.1
テスト シナリオ
マルチロール サーバーと仮想環境によるパフォーマンス比較のため、次の 2 つのテ
スト ケースを用意し、それぞれのサーバーのパフォーマンスを測定します。
No.
比較項目
テスト ケース 1
マルチロール サーバー 2 台構成
テスト ケース 2
仮想環境 2 台構成
これらのテスト ケースは、物理サーバーの台数とサーバー スペックはすべて同じで
あり、DC は物理コンピュータに展開します。テスト ケース 1 では、マルチロール
サーバーを物理サーバー 2 台に展開し、ハードウェア負荷分散装置と DAG により
冗長化を実現します。テスト ケース 2 では、コンバインドロールを展開した仮想マ
シンと MBX サーバーを展開した仮想マシンを 1 台の Hyper-V ホストに配置し
ます。この構成を 2 セット用意し、仮想マシン上で NLB と DAG により冗長化を
実現します。それぞれのテスト ケースにおいて同一の負荷をかけてパフォーマンス
を比較します。
5.4.2
検証環境
 検証環境の全体構成
次の図に、パフォーマンス検証テストのために用意したシステムの全体構成を
示します。なお、図内の VP は Virtual Processor の略であり仮想マシンへの
プロセッサ コア割り当てを示した物です。同様に、LP は Logical Processor
の略であり物理サーバーに搭載した CPU コア数を示したものとなります。
Exchange Server 2010 サイジングガイド ホワイトペーパー
122
マルチロール構成
仮想環境構成
負荷クライアント
DC
負荷クライアント
DC
NLB
ハードウェア
負荷分散装置
4 VP 8 GB RAM
4 VP 8 GB RAM
HUB
HUB
CAS
CAS
4 VP 20 GB RAM
HUB
HUB
CAS
CAS
MBX
MBX
8 LP 32 GB RAM
4 VP 20 GB RAM
MBX
8 LP 32 GB RAM
MBX
8 LP 32 GB RAM
DAG
8 LP 32 GB RAM
DAG
DB 1
DB 1
DB 1
DB 1
DB 2
DB 2
DB 2
DB 2
DB 領域
DB 領域
- RAID 5 (内蔵 HDD × 3)
- RAID 5 (内蔵 HDD × 3)
- SAS, 15,000 rpm HDD
- SAS, 15,000 rpm HDD
・DB 1
・DB 1
・DB 2
・DB 2
トランザクション ログ領域は
トランザクション ログ領域は
別 HDD に格納
別 HDD に格納
Exchange Server 2010 サイジングガイド ホワイトペーパー
123
役割
使用機種
サーバー一台あたりのスペック
DC
富士通 PC サーバ
8 プロセッサ コア (Intel® Xeon®
PRIMERGY
プロセッサ X5460 (3.16 GHz / 12
RX300 S4
MB) × 2 CPU)
4 GB メモリ
マ ル チ
富士通 PC サーバ
8 プロセッサ コア (Intel® Xeon®
ロ ー ル
PRIMERGY
プロセッサ X5570 (2.93 GHz / 8
サーバー
TX300 S5
MB) × 2 CPU)
/
32 GB メモリ
仮 想
サーバー
 Exchange 2010 の設定
Exchange 2010 の主な設定はデフォルト設定としますが、本検証では、マル
チロール サーバーと仮想サーバーでのディスク I/O パフォーマンスを調査す
ることが目的の一つであるため、非トランザクション I/O が発生する処理は、
すべて動作しない設定に変更します。検証の際に変更した設定を次の表に示し
ます。
設定項目
検証時の設定
デフォルト値
バックグラウンド データ
OFF
ON
循環ログ
ON
OFF
Microsoft Exchange Search
停止
開始
ベース保守 (24 x 7 ESE ス
キャン)
Indexer
 テスト ツール
各テスト ケースに対して同一の負荷を生成するために、Exchange Load
Generator 2010 (LoadGen) を使用します。
LoadGen に、以下のプロファイルを設定し、1 台の管理端末からの指示で、3
台の実行端末から負荷を発生させます。パフォーマンス データは、サーバー側
のパフォーマンス モニターを使用して測定します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
124
設定項目
設定値
ユーザー数
3,000 ユーザー (3,000 ユーザー/サーバー、2 データ
ベース/サーバー、1500 ユーザー/データベース)
Outlook_100 (100 通送受信、送受信メッセージ サイズ
プロファイル
約 75 KB/通)
Outlook 2007 オンライン モード
クライアント
(Outlook 2007 の規定値はキャッシュ モード)
メールボックス サイ
約 100 MB/ユーザー
ズ
500 グループ (メンバーシップ数： 最少 2、平均 20、
配布グループ
最大 50)
シミュレーションに
8 時間
おける 1 日の長さ
シミュレーションを
4 時間
実施する長さ
パフォーマンス測定
シミュレーション 4 時間のうち、後半の 2 時間で測定
のタイミング
5.4.3
プロセッサとメモリのパフォーマンス
次の図は、マルチロール環境の物理サーバーと仮想環境の各仮想マシン (MBX
サーバーと コンバインドロール サーバー)の CPU 使用率 (Processor Time) と
メモリ空き容量 (Memory¥Available MBytes) の平均値です。
Exchange Server 2010 サイジングガイド ホワイトペーパー
125
Processor Time パフォーマンス カウンターは、プロセッサがアプリケーションま
たはシステム プロセスを実行している時間の割合を示します。このカウンターの平
均値は DAG を構成していない MBX サーバーの場合は 70% 未満、DAG を構成
する MBX サーバーの場合は、80% 未満、それ以外のサーバーでは 60 % 未満で
あることが推奨されます。
本検証では、それぞれのサーバーにおいて良好な値を示していますが、マルチロー
ル環境の方がより良好な値を示しています。
Memory¥Available MBytes パフォーマンス カウンターは、プロセスやシステム
のために直ちに利用可能な物理メモリの容量を MB 単位で示します。このカウン
ターは、常に 100 MB を上回っていることが推奨されます。
本検証では、それぞれのサーバーで値が異なりますが、すべてのサーバーにおいて
良好な値を示しています。サーバーごとに値が異なる原因は、利用可能なメモリ容
量が異なることと、実行する Exchange サーバー ロールが異なるためです。
これらについての考察は次の通りです。
 CPU 使用率 (Processor Time)
本検証では、各テスト ケースに対して同一の負荷を生成しており、MBX サー
バーにかかる負荷は同等ですが、マルチロール環境では 8 LP、仮想環境では 4
VP とプロセッサ コア比率が異なっていることや、仮想環境では仮想マシンが
複数台動作していることや仮想化によるオーバーヘッドにより、仮想環境の
CPU 負荷が上昇したと考えられます。
 使用メモリ容量
次の表は、マルチロール環境の物理サーバーと仮想環境の各仮想マシン (MBX
サーバーと コンバインドロール サーバー)の搭載メモリ容量と空き容量から
使用メモリ容量を算出した物です。
Exchange Server 2010 サイジングガイド ホワイトペーパー
126
本検証では、各テスト ケースにおいて負荷が同一であるにも関わらず、マルチ
ロール環境の方がメモリ使用量が多いことがわかります。これは仮想環境に比
べて、利用可能なメモリ容量が多いため、DB キャッシュをより多く展開する
ためであったと考えられます。また、MBX サーバー ロール以外にも HUB
サーバー ロールと CAS サーバー ロールを実行していることも理由として
考えられます。これらについては、次のように考察した結果です。
まず、本検証において、マルチロールの搭載メモリ容量は 32 GB、仮想環境は
20 GB であるため、サイジング指針から、搭載メモリ容量と DB キャッシュ
総量の関係を次の表に示します。
サーバーの物理
DB キャッシュ総量
DB キャッシュ総量
メモリ (RAM)
(MBX サーバー ロールのみ)
(マルチロール)
16 GB
10.4 GB
8 GB
24 GB
17.6 GB
14 GB
32 GB
24.4 GB
20 GB
本検証の仮想環境のように搭載するメモリ容量が 20 GB における DB キャッ
シュ総量は、サイジング指針の例に記載されていません。そのため、本考察で
は、上記表の搭載メモリ容量 16 GB と 24 GB の DB キャッシュ総量の中間
値を取ることにし、 DB キャッシュ総量を 14 GB と仮定します。これにより、
DB キャッシュは、マルチロール環境では 20 GB、仮想環境では 14 GB の
キャッシュが展開されたと考えられます。この DB キャッシュ総量と、本検証
の使用メモリ容量をまとめた表を次に示します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
127
本検証環境
DB キ ャ ッ
本検証での使用
使用メモリ容量から
シュ総量
メモリ容量
DB キャッシュ総量を
除いたメモリ容量
マルチロー
ル環境
仮想環境
(MBX)
20 GB
27.7 GB
7.7 GB
20 GB
14.9 GB
0.9 GB
使用メモリ容量には、OS などにより使用されるメモリが含まれているため、
サイジング指針よりも多めに使用されていますが、仮想環境においては、ほぼ
サイジング指針の通りの DB キャッシュが展開されていると考えられます。マ
ルチロール環境では、複数の Exchange Server ロールを実行しているため、
仮想環境に比べて 多くのメモリが使用されていることがわかります。
5.4.4
RPC パフォーマンス
次の図は、各テスト ケースにおける CAS サーバのリモート プロシージャ コー
ル (RPC) 操作数 (RPC Operations/sec) と RPC 要求数 (RPC Requests) の平均
値です。
Exchange Server 2010 サイジングガイド ホワイトペーパー
128
MSExchangeIS (または MSExchange RPCClientAccess) ¥RPC Operations/sec
パフォーマンス カウンターは、過去 1 秒間に発生している RPC 操作の数を示し
ます。Exchange 2010 において CAS サーバーが MAPI クライアントからのアク
セスを処理するように変更されたため、この値を参照することで CAS サーバーへ
のクライアント アクセス負荷を調査することが可能です。
本検証においては、それぞれのテスト ケースで同一の負荷をかけているため、同等
の値になっています。
MSExchangeIS ( ま た は MSExchange RPCClientAccess) ¥RPC Requests パ
フォーマンス カウンターは、Microsoft Exchange Information Store サービスに
よって現在処理されている MAPI RPC またはクライアントの数を示します。この
カウンターの平均値は、常に 70 未満であることが推奨されます。Exchange Server
2010 における RPC 要求の最大値は 500 であり、それ以上の新しい RPC 操作
は拒否されます。
本検証においては、それぞれのテスト ケースにおいて良好な値を示していますが、
マルチロール環境の方がより良好な値を示していることがわかります。
次の図は、各テスト ケースにおける CAS サーバーの RPC 待機時間 (RPC
Averaged Latency) の平均値と、負荷クライアントで測定されたレスポンス タイ
ム (Read And Process Messages Action Latency) の平均値です。
Exchange Server 2010 サイジングガイド ホワイトペーパー
129
MSExchangeIS ( ま た は
MSExchange RPCClientAccess) ¥RPC Averaged
Latency パフォーマンス カウンターは、過去 1,024 パケットの RPC の平均待ち
時間をミリ秒単位で示しています。オンライン モードの Outlook クライアントを
使用する場合、このカウンターの最大値は 50 ミリ秒以下であることが推奨されま
す。
本検証においては、それぞれのテスト ケースにおいて良好な値を示していますが、
マルチロール環境の方がより良好な値を示していることがわかります。
Exchange Load Generator User Groups¥Read And Process Messages Action
Latency パフォーマンス カウンターは、負荷クライアントの LoadGen が提供す
るものです。このカウンターは、クライアント側におけるメッセージ読み取りタス
クが完了するまでの平均時間 (ミリ秒) を示します。
本検証においては、マルチロール環境の方が、処理時間が減少しています。この結
果は、サーバー側の RPC 待機時間が減少したことによる影響を示しています。
これらについての考察は次の通りです。
 RPC 操作数 (RPC Operations/sec)
送 受 信 数 や ユ ー ザ ー 数 な ど の プ ロ フ ァ イ ル が 同 一 で あ る 場 合 、 RPC
Opeations/sec は同一の値を記録することが正常です。本検証では、各テスト
ケースにおいて同一の負荷をかけたため、Operations/sec の値が同等になりま
した。そのため、想定通りの負荷がかけられたと考えられ、検証に問題がなかっ
たと言えます。
 RPC 要求数 / RPC 待機時間 / クライアント側のレスポンス タイム
これらの結果において、各パフォーマンス カウンターの値は、推奨のしきい値
範囲内であることから、サーバーのボトルネックとはなっていないことがわか
ります。また、マルチロール環境の方が仮想環境よりも良好な結果となりまし
た。これは、マルチロール環境は、仮想環境と比べて、プロセッサ コア数の数
が多いことや、利用可能なメモリ容量が多いこと、および仮想環境によるオー
バーヘッドなどによる影響であると考えられます。
Exchange Server 2010 サイジングガイド ホワイトペーパー
130
これらにより仮想環境は、同一の物理サーバーに展開したマルチロール環境に
比べて、クライアントへのサービス レベルが低下する可能性があるため、
RPC 待機時間やクライアント側のレスポンス タイムを確認しておくことが
重要です。
5.4.5
ディスク I/O パフォーマンス
ディスク I/O パフォーマンスについては、まず、マルチロール環境と仮想環境を比
較し、サーバー構成の違いによるディスク I/O パフォーマンスとディスク負荷を調
査します。また、本検証では DAG を構築していることから、マルチロール環境を
例にして アクティブ DB コピーとパッシブ DB コピーのディスク I/O パフォー
マンスを比較します。
まず、マルチロール環境と仮想環境の比較のために、それぞれの環境におけるアク
テ ィ ブ DB コピ ー のデ ィ スク I/O パ フ ォー マン ス (Disk Reads/sec 、 Disk
Writes/sec、および IOPS) の平均値を調査したグラフを次に示します。
IOPS (Input / Output Per Second) は、一定期間の Physical Disk (Logical Disk)
¥Disk Transfers/sec の平均値であり、1 秒あたりに発生したディスク I/O を示し
Exchange Server 2010 サイジングガイド ホワイトペーパー
131
ます。IOPS の値は、読み取り I/O (Disk Reads/sec パフォーマンス カウンター)
と 書き込み I/O (Disk Writes/sec パフォーマンス カウンター) の合計と一致しま
す。
Disk Reads/sec の値は、マルチロール環境の方が仮想環境よりもディスクに対する
読み取り I/O 負荷が低いことを示しています。また、Disk Writes/sec の値は、そ
れ ぞ れ のテ ス ト ケ ース に おい て 大き な 差は 見ら れ ま せん 。 IOPS は 、 Disk
Reads/sec と Disk Writes/sec の合計数であるため、マルチロール環境の方が仮想
環境よりもディスクに対する I/O 負荷が低いことを示しています。
次の図は、マルチロール環境と仮想環境における、アクティブ DB コピーを配置し
たディスク (LUN) の Avg. Disk Queue Length パフォーマンス カウンターの平
均値を示しています。
Avg. Disk Queue Length は、ディスクのキューに入った読み取りおよび書き込み
I/O の平均値で、待ち行列の長さを示しています。ディスクにボトルネックが発生
している場合、この値が増加します。このカウンターの平均値は、ディスク スピン
ドル数に 2 を加えた値未満であることが推奨されます。
Avg. Disk Queue Length の値は、各テスト ケース間で大きな差は見られず、良好
な値を示しています。
次に、アクティブ DB コピーと パッシブ DB コピーの比較のために、マルチロー
ル環境のアクティブ DB コピーと パッシブ DB コピーのディスク I/O パフォー
マンス (Disk Reads/sec、Disk Writes/sec、および IOPS) の平均値を調査したグ
ラフを次に示します。
Exchange Server 2010 サイジングガイド ホワイトペーパー
132
Disk Reads/sec と Disk Writes/sec の値は、アクティブ DB コピーの方がパッシ
ブ DB コピーよりもディスクに対する読み取り I/O 負荷と書き込み I/O 負荷が
低いことを示しています。IOPS は、Disk Reads/sec と Disk Writes/sec の合計
数であるため、アクティブ DB コピーの方がディスクに対する I/O 負荷が低いこ
とを示しています。
次の図は、アクティブ DB コピーとパッシブ DB コピーを配置したそれぞれの
ディスク (LUN) の Avg. Disk Queue Length パフォーマンス カウンターの平均
値を示しています。
Exchange Server 2010 サイジングガイド ホワイトペーパー
133
Avg. Disk Queue Length の値は、アクティブ DB コピーがパッシブ DB コピー
に比べて良好な値を示しています。なお、ディスク スピンドル数が 3 であるため、
しきい値が 5 となるため、パッシブ DB コピーにおいてもボトルネックは発生し
ていません。
これらについての考察は次の通りです。
Exchange Server 2010 サイジングガイド ホワイトペーパー
134
 マルチロール環境と仮想環境のディスク I/O パフォーマンス
本検証では、ディスクへの読み取り I/O は、マルチロール環境と仮想環境では、
マルチロール環境の方がディスクに対する読み取り I/O 負荷が低い結果とな
りました。これは、次に示すように各テスト ケースにおいて展開された DB
キャッシュ総量が、マルチロール環境の方が多かったため、ディスクに対する
読み取り I/O が減少したと考えられます。
本検証環境
DB キャッシュ総量 (サイジング指針から)
マルチロール環境
20 GB
仮想環境
14 GB
なお、ディスクへの読み取り I/O が、DB キャッシュ総量により変化すること
の詳細に関しては「3.1.5.1 トランザクション I/O」を参照してください。
次にディスクへの書き込み I/O ですが、マルチロール環境と仮想環境では、ほ
ぼ同一の値となりました。これは、各テスト ケースにおいて DAG を構成し
たため、ログ チェックポイントの深さのターゲットの大きさが同一であるため
であると考えられます。
なお、ディスクへの書き込み I/O と、ログ チェックポイントの深さのターゲッ
トの詳細に関しては「3.1.5.1 トランザクション I/O」を参照してください。
最後に IOPS とディスク負荷についてですが、IOPS は Disk Reads/sec と
Disk Writes/sec の合計であるため、マルチロール環境の方がディスクに対す
る I/O 負荷が低いことを示していますが、IOPS としては誤差であったため、
ディスク負荷には大きな違いが見られないという結果になりました。
 アクティブ DB コピーとパッシブ DB コピーのディスク I/O パフォーマンス
本検証において、アクティブ DB コピーはパッシブ DB コピーより、ディス
クへの書き込み I/O が減少しました。これは、次に示すようにアクティブ DB
コピーとパッシブ DB コピーのログ チェックポイントの深さのターゲットの
大きさが異なるためであると考えられます。
DB 構成
ログ チェックポイントの深
さのターゲット (MB)
1 つの DB のコピー (DAG 構成なし)
20
2 つ以上のコピーを持つアクティブ DB
100
Exchange Server 2010 サイジングガイド ホワイトペーパー
135
コピー (DAG 構成あり)
パッシブ DB コピー
5
なお、ディスクへの書き込み I/O が、ログ チェックポイントの深さのターゲッ
トの値により変化することの詳細に関しては「3.1.5.1 トランザクション I/O」
を参照してください。
最後に IOPS とディスク負荷についてですが、IOPS は Disk Reads/sec と
Disk Writes/sec の合計であるため、アクティブ DB コピーの方がディスクに
対する I/O 負荷が低いことを示しています。これによりアクティブ DB は、
パッシブ DB コピーに比べてディスク負荷が減少したという結果になりまし
た。
5.4.6
サイジング指針と検証結果を比較した考察
ここでは、サイジング指針から導き出される必要スペックと、検証から得られた実
測データを比較した考察を示します。
本検証において、展開された DB キャッシュ総量を次に示します。本検証における
DB キャッシュ総量の詳細は「5.4.3 プロセッサとメモリのパフォーマンス」を参
照してください。
本検証環境
DB キャッシュ総量
マルチロール環境
20 GB
仮想環境
14 GB
上記のように、サイジング指針の通りの DB キャッシュが展開されていると仮定し
た場合、本検証でのユーザー 1 人あたりの DB キャッシュ割り当ては次のように
なります。
本検証環境
本検証でのユーザー 1 人あたりの
DB キャッシュ割り当て
マルチロール環境
6.82 MB
仮想環境
4.77 MB
本検証のプロファイルは 100 通送受信のため、サイジング指針ではユーザー 1 人
あたり 6 MB のキャッシュ割り当てを想定していますが、マルチロール環境ではサ
イジング指針以上の DB キャッシュが割り当てられ、仮想環境ではサイジング指針
以下の DB キャッシュが割り当てられたことがわかります。
Exchange Server 2010 サイジングガイド ホワイトペーパー
136
以上のように、本検証のマルチロール環境と仮想環境を比較すると、マルチロール
環境の方が展開された DB キャッシュ総量が多いため、ディスクへの読み取り I/O
が減少する結果となりました。ただし、仮想環境では自由にメモリの割り当てが可
能なため、仮想環境の設計時において MBX サーバーの仮想マシンに割り当てるメ
モリ容量を増減させることによって I/O をある程度コントロールすることができ
ると言えます。
5.4.7
まとめ
本検証環境において、マルチロール環境と仮想環境を比較した結果、マルチロー
ル環境の方が CPU や RPC などのパフォーマンスが良好であったと言えます。
これは仮想環境では複数の OS を稼働させること、仮想環境のオーバーヘッドの
存在などによる結果と言えます。また、ディスク負荷に関しては、本検証におい
てはマルチロール環境の方がディスクに対する負荷が低い結果となりましたが、
仮想環境は MBX サーバーへのメモリ割り当てを調整することが可能なため、仮
想環境の設計時にはメモリの割り当てが重要であると言えます。
以上のようにマルチロール環境と仮想環境においてパフォーマンスや考慮する点
などの違いがありますが、それぞれの環境においてボトルネックは発生していな
いため、マルチロール環境と仮想環境どちらにおいても、最低構成台数である 2
台で Exchange 2010 を稼働させることは可能です。どちらを選択するかは、パ
フォーマンスの観点だけではなく、追加コスト (マルチロールの冗長化における
ハードウェア負荷分散装置が必須になることなど) も考慮して総合的に判断する
ことが重要です。
Exchange Server 2010 サイジングガイド ホワイトペーパー
137
付録A.
ツールの紹介
Exchange Server Load Generator
Load Generator (LoadGen) は、MAPI クライアントのパフォーマンス負荷をシ
ミュレートします。サーバーの処理能力を決定し、展開計画を評価するのに有益な
ツールです。
LoadGen は、Exchange に対し、シミュレートされたクライアント作業負荷を生
成することを目的としています。この作業負荷を用いることで、Exchange の性能
を評価したり、システムに負荷がかかった状態でのさまざまな構成の変更が
Exchange の動作とパフォーマンスにどのように影響を与えるかを分析できます。
また、LoadGen は、運用環境ではなくテスト環境で使用することを目的としてい
ます。
LoadGen のマニュアルには、Exchange サーバーに対する負荷テストを構成して
実行する方法が記載されています。LoadGen は、Outlook 2003 (オンラインおよび
キャッシュ)、Outlook 2007 (オンラインおよびキャッシュ)、POP3、IMAP4、SMTP、
ActiveSync、および OWA クライアントの活動をシミュレートできます。単一プロ
トコルの作業負荷を生成するのにも使用できます。また、これらのクライアント プ
ロトコルを組み合わせることで、複数プロトコル作業負荷を生成できます。
これらのテストの出力は、以下の目的で使用します。
 展開の検証
 クライアントに負荷がかかった状態で、
サーバーの構成に対するクライアント コ
ンピューターの応答時間を計算
 サーバーあたりのユーザー数の予測
 サーバー ボトルネックの特定
Exchange Load Generator 2010 (Loadgen.msi)
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=cf
464be7-7e52-48cd-b852-ccfc915b29ef
Microsoft Exchange JetStress
JetStress は、ディスク サブシステムのパフォーマンスと安定性をテストするツー
ルです。
Exchange がベースとする Extensible Storage Engine (ESE) の DB テクノロジ
Exchange Server 2010 サイジングガイド ホワイトペーパー
138
と直接対話することで、DB レベルでの Exchange I/O をシミュレートすることを
目的としています。JetStress は Exchange の必要なパフォーマンス制限の範囲内
で、ディスク サブシステムで利用できる最大 I/O スループットをテストするよう
に構成できます。また、ユーザー カウントとユーザーあたりの IOPS に関する適
切なプロファイルを与えることで、ディスク サブシステムが許容レベルのパフォー
マンスを維持できることを検証できます。
JetStress は、サーバーに運用データを配置する前に使用する必要があります。
JetStress は運用データを含むシステムに使用するべきではありません。
JetStress テストを使用して、Exchange サーバーの展開前にストレージの信頼性
とパフォーマンスを検証できます。ストレージ サブシステムのパフォーマンスに懸
念がある場合や、システムの I/O 容量を判断する必要がある場合に JetStress を
実行する必要があります。
Microsoft Exchange Server Jetstress 2010 (Jetstress.msi)
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=1
3267027-8120-48ed-931b-29eb0aa52aa6
Mailbox Server Role Requirements Calculator
Mailbox Server Role Requirements Calculator (Mailbox Calculator) を使用する
と、一連の入力要素を指定することで、MBX サーバー ロールの要件を確認できま
す。計算用シートで、メモリ、ストレージ (I/O パフォーマンス、容量、記憶域構
成)、最適な LUN レイアウト、CPU メガサイクルの要件を確認できます。
Exchange 2010 MBX サーバーの最適なソリューションを設計するには、多数の変
数を考慮する必要があり、計算用シートを用いると設計プロセスでの作業が容易に
なります。
ダウンロードは、Exchange Server チーム ブログの記事「E2010 Mailbox Server
Role Requirements Calculator」を参照してください。
Exchange Server 2010 サイジングガイド ホワイトペーパー
139
免責
この資料に記載されている情報は、この資料の発行日におけるマイクロソフトの見解を示すものです。マイクロソフトは市場の変化に対応
する必要があるため、この資料の内容に関する責任をマイクロソフトは問われないものとします。また、発行日以降に発表される情報の
正確性を保証できません。資料に記載された内容は情報の提供のみを目的としており、明示、黙示、または法律の規定にかかわらず、
これらの情報についてマイクロソフトはいかなる責任も負わないものとします。
マイクロソフトは、この資料に記載されている内容に関し、特許、特許申請、商標、著作権、またはその他の無体財産権を有する場合
があります。別途マイクロソフトのライセンス契約上に明示の規定のない限り、このドキュメントはこれらの特許、商標、著作権、またはその
他の無体財産権に関する権利をお客様に許諾するものではありません。
Exchange Server 2010 サイジングガイド ホワイトペーパー
140