Exchange 2010 メールボックス サーバーの役割の設計例

 

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

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

ここでは、メールボックス サーバーの役割とそれに付随するアーキテクチャに合ったメモリ、容量、I/O、および CPU パフォーマンスの要件を決定する方法の例を示します。

Exchange Server 2010 Mailbox Server Role Requirements Calculator (メールボックス サーバーの役割の要件計算用シート) を使用すると、一連の入力要素を指定することで、メールボックス サーバーの役割に適した要件を決定することができます。この例で説明する要件もこの計算シートを使用して決定できます。計算シート (およびそのダウンロード方法) の詳細については、Exchange Server チーム ブログの記事の「Exchange 2010 メールボックス サーバーの役割の要件計算用シート」を参照してください (このサイトは英語の場合があります)。

注意

各ブログのコンテンツおよびその URL は予告なしに変更されることがあります。各ブログのコンテンツは現状のまま何の保証もなく掲載しているものであり、何らかの権利を許諾するものでもありません。スクリプトの例やコードなどを含め、「Microsoft 開発者サービス契約」の規定に従って活用してください。

メールボックス サーバーの役割の記憶域設計の詳細については、「メールボックス サーバーの記憶域設計」を参照してください。

この例では、JBOD (Just a Bunch Of Disks) 記憶域を利用する 3 つのデータベース コピー ソリューションのシナリオを使用します。例として、次のアーキテクチャ要件を考えてみます。

  • 6 つのメールボックス サーバーが 1 つのデータベース可用性グループ (DAG) に参加している

  • Exchange メールボックス サーバーも、ハブ トランスポートおよびクライアント アクセス サーバーの役割をホストしている

  • 3 つの高可用性メールボックス データベース コピー、時間差なしのデータベース コピー

  • 7.2 K (7,200 RPM) 1 テラバイト SATA スピンドルを使用する

  • JBOD 記憶域構成 (1 つの論理ユニット番号 (LUN)/データベース LUN アーキテクチャ)

  • バックアップ アーキテクチャ用に、単一アイテムの回復とメールボックスの復元によるネイティブ データ保護機能を使用する

  • 保守と回復操作用に復元 LUN が展開されている

  • 各 LUN に少なくとも 20% の空き領域がある

  • ソリューションは、サーバーの二重障害に対応する必要がある

  • インストールされているサーバーの役割はメールボックス サーバーの役割のみである

目次

メールボックス容量の要件

データベース コピーの要件

メールボックスのメモリ要件

メールボックス I/O の要件

メールボックスの CPU 要件

メールボックス容量の要件

ここでは、1 日に 100 通のメッセージを受信する 2 GB メールボックス 24,000 個が 6 台のメールボックス サーバーに配置され、6 台のメールボックス サーバーは、各データベースに 3 つのコピーがある DAG に参加している環境でのサイズ計算の例を示します。これらのメールボックスが受け取るメールは平均で 5 稼働日あたり 37 MB、メッセージの平均サイズは 75 KB です。単一アイテムの回復は、14 日の削除済みアイテムの保存期間で有効になります。メールボックスのサイズを決定するには、次の計算式を使用します。

メールボックス サイズ = メールボックスの上限 + スペース + 削除済みアイテム収集機能

スペース = 1 日あたり 100 メッセージ x 75/1024 MB = 7.32 MB

削除済みアイテム収集機能 = (1 日あたり 100 メッセージ x 75/1024 MB * 14 日) + (2048 MB x 0.012) + (2048 MB x 0.03) = 188.6 MB

ディスク上の実際のメールボックス サイズを求めるための値の例

メールボックスのクォータ ごみ箱のサイズ (2 週間) スペース ディスク上の合計サイズ

2 GB

188.7 MB

7.3 MB

2.19 GB (+12%)

この環境は JBOD ストレージを活用しているため、展開できる最大データベース サイズはディスク サイズに依存します。JBOD シナリオの最大データベース サイズを判断するには、1 TB ディスクのフォーマット済み容量が 931 GB、空き領域割合の要件が 20%、コンテンツ インデックスの割合が 10% の場合に次の式を使用します。

最大データベース サイズ = [フォーマット済みディスク容量 x (1 – 空き領域割合の要件)] / (1 + コンテンツ インデックスの割合)

= [931 GB x (1 - .2)] / ( 1+ .10)

= 744.8 GB / 1.1

= 677 GB

この環境では、各ユーザーのメールボックスは 2.25 GB のディスク容量を消費します。677 GB のデータベースで 24,000 個のメールボックスをサポートするには、102 個のデータベースが必要です。その結果、データベースあたりのメールボックス数は最終的に 235 個となります。

ただし、このソリューションでは JBOD 記憶域アーキテクチャを活用しているため、データベースあたりのメールボックス数が 1 つのディスクで実現できるランダム I/O の量を超えないようにする必要があります。また、このソリューションでは、フォーム ファクターが大きな 7.2 K SATA スピンドルを利用しているため、十分に活用すると、スピンドルは 1 秒あたり最大 55 回のランダム I/O (IOPS) を実現できます。I/O オーバーヘッドが 20% 増加するとして、スピンドルは合計 44 回のランダム IOPS に対応できることになります。

ユーザー ベースのメッセージ プロファイルが 1 日に 100 通として、各メールボックスが 0.1 IOPS を消費すると予想されるため、ディスクでは、この IOPS プロファイルで最大 440 個のメールボックスをサポートできます。容量計算でサポートできるメールボックスの最大数が 235 と決まり、これは IOPS プロファイルに基づいて決まったメールボックス数 440 より少ないため、このソリューションは 1 つのディスクに展開できることになります。

実際のデータベース サイズを決定するには、次の式を使用します。

データベース サイズ = メールボックス数 x ディスク上のメールボックス サイズ x データベース オーバーヘッド増加要素

メールボックス数、実際のメールボックス サイズ、および 20% というデータベース オーバーヘッド増加要素に基づいて、データベース サイズは、次の表に示すように 619 GB となります。

データベース容量の要件

データベースごとのメールボックス数 データベースの合計数 データベース サイズの要件

235

102

619 GB

領域割り当ての問題が原因でメールボックス サーバーのダウンタイムが生じることがないようにするには、トランザクション ログのサイズも、バックアップ セット中に生成されるすべてのログを記録できるように設定する必要があります。このアーキテクチャがバックアップ アーキテクチャとしてメールボックスの復元機能と単一アイテムの回復機能を活用しているとして、コピーの失敗が 3 日間修復されない場合、1 日のログ生成量の 3 倍をログの容量として割り当てる必要があります(コピーが失敗すると、ログの切り捨てが行われません)。

メッセージ プロファイルが 1 日あたり 100 通のメールボックスは、1 日平均 20 個のトランザクション ログを生成するので、メールボックスが 24,000 個ならば、1 日に 576,000 個のトランザクション ログが生成されます。したがって、各データベースが 1 日あたり 5,647 個のログを生成することを意味します。週にメールボックスの 1% が特定の日 (土曜日) に移動されます。このソリューションでは、Exchange に備わったデータ保護機能を活用しているため、バックアップは実行せず、3 日間はログ切り詰めを行わなくても正常に稼働するようにサイズ設定されています。

次の表に示すように、このサーバーではデータベース コピー 1 つにつき 23 GB の領域が必要です。

ログ容量の要件

データベースごとのログ ログ ファイルのサイズ 1 日のログのサイズ 移動するメールボックスのサイズ ÷ データベース 切り詰めフォールト トレランス ログ サイズの要件

5647

1 MB

5.65 GB

6 GB

(240 × 2.19 GB x 1.2 / 102)

16.5 GB

(3 × 5.65 GB)

23 GB

(16.5 GB + 6 GB)

これが 3 つのコピーを持つメールボックスの復元および JBOD 構成の場合、各データベースと対応するトランザクション ログは同じ LUN に配置されます。必要な LUN サイズは、次のとおりです。

LUN 容量 = データベース サイズ ÷ (1 - 空き領域割合の要件)

= (データベースのサイズ + トランザクション ログのサイズ + コンテンツ インデックスのサイズ) ÷ (1 - 0.2)

= (619 GB + 23 GB + 61.9 GB)/0.8

= 879 GB

必要な LUN サイズの決定

データベースのサイズ トランザクション ログのサイズ コンテンツ インデックスのサイズ データベース LUN のサイズ

619 GB

23 GB

61.9 GB

879 GB

ページのトップへ

データベース コピーの要件

24,000 個のメールボックスをサポートする必要があるデータベースが合計 102 個あり、各データベースに 3 つのコピーがあるとすると、DAG では、合計 306 個のデータベースがサポートされます。306 個のデータベースが 6 つのメールボックス サーバーに分散されている場合、各メールボックス サーバーには 51 個のデータベース コピーが格納されていることになります。サーバー レベルの障害が発生した場合に、アクティブなデータベースができる限り多くの残りのサーバーにフェールオーバーするように、データベース コピーは DAG 内のサーバーに分散させる必要があります (データベース コピーは対称的に分散されません)。

DAG に参加しているメールボックス サーバーの効率を最大限高めるには、アクティブなデータベースをすべてのメールボックス サーバーに均等に分散させます。この結果、6 つのメールボックス サーバーすべてが機能している場合、各サーバーは 17 個のアクティブなデータベース コピーをホストしている必要があります。

1 つのメールボックス サーバーに障害が発生した場合、17 個のデータベースが残りのメールボックス サーバーに再分散されるため、サーバーあたりのアクティブなデータベース コピーは 21 個に増えます。

2 つのメールボックス サーバーに障害が発生した場合、34 個のデータベースが残りのメールボックス サーバーに再分散されるため、サーバーあたりのアクティブなデータベース コピーは 26 個に増えます。メールボックス サーバーのメモリと CPU 要件のサイズ設定に使用されるのは、このアクティブなコピー数です。

メールボックス サーバー全体にデータベースのコピーを分散させる方法の詳細については、「データベース コピー レイアウトの設計」を参照してください。

ページのトップへ

メールボックスのメモリ要件

メッセージ プロファイルが 1 日に 100 通の場合、データベース キャッシュをサポートするために必要なメールボックスあたりの最小メモリは 6 MB です。最悪の場合のサーバーごとのアクティブなメールボックス データベースのコピー数が 26 であれば、各サーバーでは、合計 6,110 個のライブ メールボックスをホストできます。さらに、サーバーごとに合計 51 個のデータベース サーバーがあります。メールボックス サーバーには、少なくとも 12 GB のデータベース キャッシュが必要になります。したがって、データベース キャッシュをサポートするために必要なメモリの容量は次のようになります。

最低限必要なデータベース キャッシュ = MAX((ライブ メールボックスの数 x 必要なメモリ / メールボックス), データベースの最小メモリ)

= MAX(6110 x 6/1024 GB, 12 GB)

= MAX (36 GB, 12 GB)

= 36 GB

複数の役割を持つアーキテクチャを展開する場合、この構成をサポートするために必要な物理メモリの合計は、「メールボックス データベース キャッシュについて」の表に基づき、64 GB となります。

ページのトップへ

メールボックス I/O の要件

各メールボックスでは、1 日あたり 100 通のメッセージを送受信します。このため、各メールボックスの IOPS プロファイルは 0.1 です。各データベースには、235 個のメールボックスが格納されています。このため、データベース ボリューム I/O の合計量は次のようになります。

データベース ボリューム I/O = メールボックス数 x IOPS プロファイル x (1 + I/O オーバーヘッド増加要素)

= 235 x 0.1 x 1.2

= 28.2 IOPS

このアーキテクチャのデータベース読み取り I/O 割合は 60% です。このため、各データベース ボリュームで、16.92 IOPS の読み取り I/O と 11.28 IOPS の書き込み I/O が生成されます。

このアーキテクチャでは、各ログ ストリームによって 50% のデータベース書き込み I/O が生成されます。このため、ボリュームあたりのログ書き込み I/O は 5.64 IOPS となります。

また、26 個のアクティブなデータベース コピーによってログ書き込み I/O の 10% を占めるログ読み取り I/O が生成されます。このため、これらのデータベースのログ読み取り I/O は 0.56 IOPS となります。

フォーム ファクターが大きな 7.2 K SATA ディスクそれぞれで 55 回のランダム IOPS が生成されることを考慮すれば、ディスクでデータベースの I/O 要件を処理できないという懸念はありません。

ページのトップへ

メールボックスの CPU 要件

サーバーの二重障害が発生した場合、残りの各サーバーは、サーバーごとに合計 6,110 個のアクティブなメールボックスに対して 26 個のデータベースをホストすることになります。「メールボックス サーバーのプロセッサ容量計画」に記載されている計算式に基づけば、各サーバーには、次の CPU メガサイクル要件があります。

CPU メガサイクル要件の決定

アクティブなメールボックスの CPU メガサイクル要件 パッシブなメールボックスの CPU メガサイクル要件 合計 CPU メガサイクル要件

14,682

1,765

16,447

選択したサーバー プラットフォームで合計 26,400 メガサイクルをサポートできるとすれば、サーバー CPU プラットフォームでは、サーバーの二重障害発生時にユーザー環境をサポートできます。

ページのトップへ

 © 2010 Microsoft Corporation.All rights reserved.