サーバーのサイズの計算

 

ここでは、特にユーザーのグループのサポートに必要なハードウェアを中心に、サーバーのサイジング要件を判断する方法について説明します。Microsoft® Exchange の構成とユーザー プロファイルは多岐にわたるため、サーバーがサポートするユーザー数を正確に判断することは困難です。クライアントの種類、ユーザーの活動状況、記憶域サブシステムの容量、および Exchange サーバーでのディスク リソースの使用に関する構成について考慮する必要があります。

次の手順を実行すると、これらの問題を評価して必要なハードウェアを判断しやすくなります。

1. 使用プロファイルを測定します。
2. 使用プロファイルに基づいてサーバーを選択します。
3. ディスク サブシステムの容量を検証します。

注 :
ここで説明する方法は、Exchange 2000 Server にも当てはまります。Exchange Server 2003 では、Exchange 2000 Server と比較してユーザー負荷がやや小さく、メモリの使用は大幅に向上します。ユーザー プロファイルが同じである場合、Exchange Server 2003 で使用されるディスク リソースは Exchange 2000 Server より約 10% 少なくなります。サーバーをアップグレードしてそのサーバーを選択する場合は、このことを考慮して見積もりを調整してください。

使用プロファイルの測定

サーバーでサポートできるユーザー数を計算するには、まず現在の使用プロファイルを測定する必要があります。使用プロファイルは、次の 2 つの主要な数値を使用して計算できます。

• Megacycles/mailbox   メールボックスごとの、1 秒あたりのメガサイクルです。メールボックスごとに必要な未加工のプロセッサ使用率で、運用中のサーバーにおけるピーク時の 2 時間に測定します。たとえば、1 人のユーザーがピーク時に 1 メガサイクル/秒を使用し、サーバーに 1,000 人のユーザー (1,000 メガサイクル/秒) がいる場合、2,000 MHz プロセッサは 50% の CPU 使用率で動作します。

  注 :
  この測定で使用する実際の単位は、1 メールボックス、1 秒あたりのメガサイクルです。簡略にするため、"1 秒あたり" はここでは省略されています。

• IOPS/mailbox   1 メールボックス、1 秒あたりの入出力です。ユーザーごとに必要な未加工のデータベース (DB) ディスク使用率 (1 秒あたりの入出力) で、運用サーバー上でピークの 2 時間に測定されます。この数値には、トランザクション ログの入出力 (I/O) 操作は含まれません。たとえば、各メールボックスがピーク時に 0.5 DB IOPS を使用し、サーバー上に 1,000 人のユーザーがいる場合、500 DB IOPS になります。IOPS/mailbox の数値は、ランダムな読み取り/書き込み Exchange データベース入出力 (I/O) 操作に基づきます。

  注 :
  この数値の実際の単位は、1 メールボックス、1 秒あたりの IOPS です。簡略にするため、"1 秒あたり" はここでは省略されています。

使用プロファイルは、Microsoft Outlook® の他にサードパーティ アプリケーションが含まれる運用データに基づきます。ここでの推奨内容は、特定のクライアントまたはクライアントのバージョンに固有の説明ではありません。megacycles/mailbox および IOPS/mailbox を計算するときは、そのサーバーの現在のメールボックス数を使用してください。

メールボックスあたりのメガサイクルを計算する詳細な手順については、「メールボックスあたりのメガサイクルを計算する方法」を参照してください。

メールボックスあたりの IOPS を測定する詳細な手順については、「メールボックスあたりの IOPS を測定する方法」を参照してください。

サーバーに未使用のメールボックスが多数含まれたり、ピークの 2 時間に大きな負荷がかからない他のアプリケーションを実行している場合、測定結果は一般的なユーザーの負荷を表しません。測定のために一般的なユーザー メールボックスが含まれるサーバーを選択するか、未使用のメールボックスを計算に含めないでください。

曜日によって使用負荷が少し異なることに注意してください。たとえば、多くの企業で月曜日の負荷は他の曜日より多くなります。一般的なピークの動作を測定するために適切な時間帯は、現地時間で月曜日の 8:00 から 10:00 の間です。

サーバー リソースを多く消費する他のプロセスがサーバーで実行されている場合、全体の CPU 使用率ではなく、Store.exe プロセスに対する Process\% Processor Time カウンタを使用する方がよいことがあります。CPU 使用率に影響する非線形の多くの要素があるため (メモリ キャッシュの影響や CPU 数によるサーバーの拡張方法など)、この計算は処理ニーズを確認するためのガイドラインとして使用してください。実際の処理ニーズの量は、最終的に使用するハードウェアが測定のために現在使用しているハードウェアとどれだけ異なるかに依存します。

注 :
企業内のユーザーがさまざまな使用要件を持つ場合、異なるユーザーのグループごとに個別に使用プロファイルを測定する必要がある場合があります。たとえば、セールス エンジニアは、各地域のマーケティング グループとは異なる使用プロファイルを持つ場合があります。個別の測定は、ユーザーのグループが大幅に異なる場合のみ役立ちます。

使用プロファイルに基づくサーバーの選択

使用プロファイル (megacycles/mailbox と IOPS/mailbox) を決定すると、CPU およびディスク サブシステム要件を計算できます。

以下のセクションでは、4 種類のサンプルの使用プロファイルについて説明し、サンプルのサーバー ハードウェアを推奨します。各自のユーザーのプロファイルとサンプルのプロファイルを比較して、各企業のニーズを満たす最適なプロファイルを決定し、ガイドラインとして推奨ハードウェアを使用できます。たとえば、負荷の高いユーザーと低いユーザーがいる場合は、負荷の高いユーザー用のガイドラインを使用します。

以下の各ガイドラインは、使用プロファイルおよびサーバー/ストレージ エリア ネットワーク構成に固有のものです。この例では Hewlett Packard StorageWorks Enterprise Virtual Array または CLARiion FC-4500 ストレージ エリア ネットワーク (SAN) を使用していますが、同等のディスク スループットを提供する任意の SAN が機能します。適切なハードウェアを選択した後、ディスク サブシステムがニーズを満たすことを検証します。詳細については、後の「ディスク サブシステムの容量の検証」を参照してください。

ハイエンド サーバー構成に対しては、4 プロセッサ (2.8 GHz) 搭載サーバーを使用することをお勧めします。推奨ハードウェアでは、ネットワーク容量、サーバー メモリ、キャッシュ サイズなど、他のパフォーマンス要素を考慮していません。ただし、サンプルの使用プロファイルを使用することで、サーバーが十分な CPU とディスク容量を持つかどうかを予測できます。

メールボックス サーバーの CPU 要件を計算する方法の詳細については、「メールボックス サーバーの CPU 要件を計算する方法」を参照してください。

メールボックス サーバーのディスク サブシステム要件を計算する方法の詳細については、「メールボックス サーバーのディスク サブシステム要件を計算する方法」を参照してください。

使用プロファイル例

ここでは、使用プロファイルの例、および各プロファイルに対して推奨するハードウェアについて説明します。前のセクションで収集した情報を使用して、現在の要件を最も満たすプロファイル例を決定します。

メールボックスのサイズとユーザーの動作によって、使用する IOPS/mailbox 値は、次のセクションに挙げる例より大幅に高くまたは低くなる場合があります。たとえば、ある企業は 4 IOPS/mailbox という使用プロファイルを持っていました。IOPS/mailbox が大きいのは、ユーザーがメールボックス クォータを持たないことが主な理由でした (一般的なメールボックス サイズは 1 ～ 10 GB でした)。また、ユーザーは大きい添付ファイルを持つメッセージを送信しました (添付ファイルの上限は 25 MB に上げてありました)。

負荷の高いナレッジ ワーカーのプロファイル

HKW (Heavy Knowledge Worker) は、非常に強力なナレッジ ワーカーのプロファイルです。このプロファイルに当てはまるユーザーは、電子メールに大幅に依存する仕事を持ちます。ユーザーは Exchange キャッシュ モードのクライアントを持つことがあります。このプロファイルでは、次の使用負荷を予測できます。

• Megacycles/mailbox: 約 2.5
• IOPS/mailbox: 約 0.75

HKW プロファイル向けの大容量サーバー例

サーバー ハードウェア	4 プロセッサ搭載、1,996 MHz (ハイパースレッド対応)、4 GB RAM
ストレージ エリア ネットワーク ハードウェア	Hewlett Packard StorageWorks Enterprise Virtual Array 4 ストレージ グループ、1 ストレージ グループあたり 5 データベース、48 ディスク スピンドルで RAID0+1 を使用
メールボックス数/ストレージ グループ	1,150
メールボックス数/サーバー	4,600
ピーク時のプロセッサ使用率	80%
ピーク時のディスク使用率	84%

この構成例では、サーバーは 5,100 HKW ユーザーをサポートできます。サーバー上に 5,100 人の HKW ユーザーがいるとして、ピーク時のプロセッサ使用率は 80% なので、非常に負荷が高い時間帯に十分なオーバーヘッドが残されています。

48 スピンドルで 4,800 IOPS/秒を処理できると予測されています (ディスクが 100 IOPS/スピンドルをサポートすると想定)。したがって、0.75 IOPS/mailbox を必要とする 4,600 人のユーザーがいるとして、ピーク時のデータベース ドライブのディスク使用率は 72% です。RAID1 構成ではすべての書き込みに対して 2 回の入出力 (I/O) 操作が必要であることを考慮すると、予測されるスループットは 3,840 IOPS/秒に減ります (この値の計算方法については、このトピックの後の「ディスク容量の予測」を参照してください)。上の表に示されている実際のピーク時のディスク使用率は、予測ではなく実際のディスク容量の数値に基づくため、少し高くなっています。

中程度のナレッジ ワーカーのプロファイル

MKW (Medium Knowledge Worker) は、強力なナレッジ ワーカーのプロファイルです。クライアントは、BlackBerry または他のローミング デバイスを使用する場合があります。このプロファイルに当てはまるユーザーは、電子メールに大幅に依存する仕事を持ちます。このプロファイルでは、次の使用負荷を予測できます。

• Megacycles/mailbox: 約 1.9
• IOPS/mailbox: 約 0.4

MKW プロファイル向けの大容量サーバー例

サーバー ハードウェア	4 プロセッサ搭載、2,800 MHz、4 GB RAM
ストレージ エリア ネットワーク ハードウェア	Hewlett Packard StorageWorks Enterprise Virtual Array 3 ストレージ グループ、1 ストレージ グループあたり 1 データベース、30 ディスク スピンドルで RAID0+1 を使用
メールボックス数/ストレージ グループ	1,575
メールボックス数/サーバー	4,725
ピーク時のプロセッサ使用率	80%
ピーク時のディスク使用率	67%

この構成例では、サーバーは 4,725 MKW ユーザーをサポートできます。サーバー上に 4,725 人の MKW ユーザーがいるとして、ピーク時のプロセッサ使用率は 80% なので、非常に負荷が高い時間帯に十分なオーバーヘッドが残されています。

30 スピンドルで 3,000 IOPS/秒を処理できると予測されています (ディスクが 100 IOPS/スピンドルをサポートすると想定)。したがって、0.4 IOPS/mailbox を必要とする 4,725 人のユーザーがいるとして、ピーク時のデータベース ドライブのディスク使用率は 63% です。次の表に示されている実際のピーク時のディスク使用率は、予測ではなく実際のディスク容量の数値に基づくため、少し高くなっています。

負荷の低いナレッジ ワーカーのプロファイル

LKW (Light Knowledge Worker) は、負荷の低いナレッジ ワーカーのプロファイルです。このプロファイルに当てはまるユーザーは、通常は少量のメールボックス クォータを持ちます。このプロファイルでは、次の使用負荷を予測できます。

• Megacycles/mailbox: 約 0.75
• IOPS/mailbox: 約 0.18

LKW プロファイル向けの大容量サーバー例

サーバー ハードウェア	4 プロセッサ搭載、2,800 MHz、4 GB RAM
ストレージ エリア ネットワーク ハードウェア	Hewlett Packard StorageWorks Enterprise Virtual Array 3 ストレージ グループ、1 ストレージ グループあたり 1 データベース、30 ディスク スピンドルで RAID0+1 を使用
メールボックス数/ストレージ グループ	3,000
メールボックス数/サーバー	9,000
ピーク時のプロセッサ使用率	76%
ピーク時のディスク使用率	46%

非常に負荷の低いナレッジ ワーカーのプロファイル

VLKW (Very Light Knowledge Worker) は、非常に負荷の低い電子メール ユーザーです。このプロファイルに当てはまるユーザーは、おそらく POP3 (Post Office Protocol version 3) を使用し、少量のメールボックス クォータを持ちます。このプロファイルでは、次の使用負荷を予測できます。

• Megacycles/mailbox: 約 .33
• IOPS/mailbox: 約 0.078

VLKW プロファイル向けの大容量サーバー例

サーバー ハードウェア	4 プロセッサ搭載、2,000 MHz、4 GB RAM
ストレージ エリア ネットワーク ハードウェア	CLARiion FC-4500 4 ストレージ グループ、1 ストレージ グループあたり 1 データベース、18 ディスク スピンドルで RAID0+1 を使用
メールボックス数/ストレージ グループ	6,700
メールボックス数/サーバー	20,100
ピーク時のプロセッサ使用率	76%
ピーク時のディスク使用率	46%

ディスク サブシステムの容量の検証

サーバーのサイジングの決定における最後の手順は、ディスク サブシステムの容量を検証することです。ディスク サブシステムを選択した後、ハードウェアのスループットをテストして、要件が満たされることを確認する必要があります。Microsoft の提供する Jetstress ツールを使用すると、ディスク サブシステムのパフォーマンスを測定できます。Jetstress は、Exchange データベースの読み取り/書き込み負荷をシミュレートするストレス負荷を生成します。このツールを実行するときは、最大の回数の IOPS (1 秒あたりの入出力 (I/O) 操作) を、読み取りまたは書き込みの待ち時間が 20 ms を超えないように各 SAN に読み込みます。Jetstress の詳細については、「Exchange Server 2003 パフォーマンス ツール」を参照してください。

多くの種類のディスク サブシステムで Exchange メッセージング展開がサポートされています。次のセクションで説明するサンプルのサブシステムは 1 つの例で、特定の記憶域サブシステムの推奨サブシステムを示すものではありません。選択するディスク サブシステムに関係なく、サブシステムが要件を満たすことをテストによって検証する必要があります。

ファイバ チャネル SAN 上でのサンプル テスト結果

表 C.5 のデータは、ファイバ チャネル SAN 上で最大の持続可能なスループットをテストした際に得られたテスト結果を示しています。このテストはテスト環境で行われたものです。

Jetstress SAN テスト

機能	ログ	データベース
ストレージ グループの構成	6 ディスクの RAID0+1	6 ディスクの RAID0+1
ディスク書き込みの待ち時間 (ms)	3	10
ディスク読み取りの待ち時間 (ms)	0	20
ディスク転送/秒	135	430
ディスク読み取り/秒	0	285
ディスク書き込み/秒	135	145
IOPS/スピンドル	該当なし	71.7

この例では、Jetstress テストは 1 ストレージ グループ データベースあたり 430 IOPS という最大の割合を持続しました。Jetstress テストは、次のパラメータを使用して実行されました。

jetstress -l L:\logfile_location -Z -A -I 50 -D 50 -R 0 -N 0

注 :
Exchange の論理ユニットが他の非メッセージング アプリケーションまたはサーバーとスピンドルを共有している場合、パフォーマンスが低下することがあります。Exchange は、ディスクが Exchange サーバー専用の場合に最適に実行されます。Exchange がスピンドルを共有している場合、実際のパフォーマンスはテスト中に得られたパフォーマンスより低下することがあります。

Jetstress テストによって測定されたスループットに基づいて、使用するディスク サブシステムでサポートできるユーザー数を決定できます。たとえば、このシナリオでは、ストレージ エリア ネットワークは 1,075 HKW メールボックスをサポートできます。

ディスク容量の予測

ディスク容量を予測する場合、適切なガイドラインはスピンドルごとに約 100 IOPS (10,000 rpm を想定) を予測することです。ディスク構成によっては、調整が必要になる場合があります。Exchange データベース ディスクの場合、ディスク読み取りとディスク書き込みの妥当な比率は 3:1 です。ただし、ユーザーのために自分でこの比率を測定することもできます。比率を 3:1 と想定して、次の表に RAID0、RAID1、RAID0+1、および RAID5 構成に対するスループット予測を示します。

予測されるスピンドルあたりの RAID スループット

RAID 構成	予測されるスピンドルあたりの IOPS/秒
Raid0	100
Raid1	80
Raid0+1	80
Raid5	57

これらの計算では、ストライプ化された 48 ディスク全体で 3,840 IOPS/秒が可能であると予測されます。同様に、RAID5 構成の 5 ディスクで 285 IOPS/秒が可能です。

RAID0 構成では、読み取りと書き込みごとに 1 回の入出力 (I/O) 操作が発生します。RAID1 と RAID0+1 構成では、読み取りごとに 1 回の入出力 (I/O) 操作が発生しますが、書き込みごとに 2 回の入出力 (I/O) 操作が必要です (ミラー化されたディスクごとに 1 書き込み)。RAID5 では、書き込みごとに 4 回の入出力 (I/O) 操作が必要です。これはパリティを計算するための 2 回の読み取り、および 2 回の書き込み (データで 1 回、パリティの書き込みで 1 回) です。したがって、読み取りと書き込みの最初の回数は、RAID1、RAID0+1、および RAID5 の場合は増大します。入出力 (I/O) 操作の増加の例については、このトピックの後の「計算の例」を参照してください。読み取りおよび書き込みの最初の回数に関して、見かけのスループットは減少します。

計算の例

次の表に、300 回の読み取り入出力 (I/O) 操作と 100 回の書き込み入出力 (I/O) 操作に対し、各 RAID 構成で必要な入出力 (I/O) 操作の回数を示します。

RAID 入出力 (I/O) 操作のパフォーマンスの例

RAID 構成	読み取りと書き込みの回数	合計の入出力 (I/O) 操作
RAID0	1 読み取り + 1 書き込み	400
RAID1	1 読み取り + (2 書き込み)	500
RAID0+1	1 読み取り + (2 書き込み)	500
RAID5	1 読み取り + (4 書き込み)	700

この例では、400 トランザクション (300 回の読み取りと 100 回の書き込み) によって、RAID1 構成で 500 回の入出力 (I/O) 操作が生成されることがわかります。見かけのスループットは、400/500、つまり 0.8 の比率で減少します。したがって、RAID0 の場合、スピンドルあたり 100 IOPS を予測する代わりに、適切な予測数値はスピンドルあたり 80 IOPS です。

System Center Capacity Planner 2006 を使用したトポロジの計画

System Center Capacity Planner 2006 は、Exchange Server 2003 などのサーバー アプリケーションを展開するためのシステム アーキテクチャ モデルを作成するように設計された Microsoft 製品です。標準的なモデルは以下の要素から構成されます。

• トポロジ : サイトの場所、ネットワークの種類、ネットワーク コンポーネント、およびネットワークの特性 (帯域幅、待ち時間)。
• ハードウェア : サーバーの分散および特性、サーバーおよびネットワークのマッピング。
• ソフトウェア : サーバーの役割およびサービスのマッピング、ファイルおよびストレージ デバイスのマッピング。
• 使用プロファイル : サイト使用状況およびクライアント使用状況。

モデルを作成したら、シミュレーションを実行して、アプリケーションおよびそのサポート コンポーネントのパフォーマンスに関する要約と詳細情報を得ることができます。このツールの詳細については、System Center Capacity Planner 2006についての Web ページを参照してください (このサイトは英語の場合があります)。

要約

サーバーのサイジングの際に使用する 3 つの手順は次のとおりです。

• 使用プロファイルを決定します。
• ハードウェアを選択し、ハードウェアの CPU とディスクが使用プロファイルに対して適切かどうかを計算します。
• ディスク サブシステムのパフォーマンスを検証します。

使用プロファイルは時間が経過すると変化します。したがって、サーバーを定期的に監視して、全体の適切なパフォーマンスと適切な負荷を維持する必要があります。