メールボックス データベースおよびログの容量の要因について

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

トピックの最終更新日: 2015-03-09

ここでは、Microsoft Exchange Server 2010 で、メールボックス データベースおよびログ容量をメールボックス サーバー記憶域の設計の一部として計画する際に考慮すべき要因について説明します。

メールボックス データベースの容量

Exchange Server 2010 メールボックス データベースのサイジングおよび容量計画は、多くの要因に影響されます。ここでは、次のことについて説明します。

• メールボックス格納域の制限

• データベースの空白領域

• メールボックス データベースの回復可能なアイテム

• 実際のメールボックスのサイズ

• コンテンツ インデックス処理

• オフライン データベースの保守

• 回復用データベース

• データベースのサイズ

• データベース拡張のオーバーヘッド

メールボックス格納域の制限

最初に理解する指標は、メールボックス格納域の制限と呼ばれる記憶域のサイズ制限です。このサイズ制限は組織内で有効にされます。各エンド ユーザーがメールボックスに格納できるデータ量がわかっていれば、サーバーに配置できるユーザー メールボックス数を決定できます。メールボックス格納域の制限は、変化する組織の要件に応じて変更することができますが、メールボックス格納域の制限の目標を定めることが、必要なメールボックス容量を決める上での最初のステップとなります。

たとえば、250 MB のユーザー メールボックスが 5000 個存在するサーバーがある場合、回復可能なアイテムの要件を除く、1.25 TB 以上のディスク領域が必要です。メールボックス格納域に制限が設定されていない場合、データベース容量を予測することは難しくなります。Exchange 2010 のメールボックス格納域の制限には、プライマリ メールボックスと個人用アーカイブ メールボックス (使用されている場合) の両方の領域を含める必要があります。詳細については、「メールボックス サーバーの管理」および「個人アーカイブの管理」を参照してください。

データベースの空白領域

物理ディスク上のデータベースのサイズは、単にユーザー数にメールボックス格納域の制限を乗算したものではありません。大多数のユーザーが各自のメールボックス格納域の制限に近づいていない場合、データベースの消費する領域は少なく、空白領域は容量上の問題とはなりません。データベース自体には、常に空きページ、つまり空白領域が全体に散在します。バックグラウンドのデータベース保守時に、データベースから削除するようにマークされたアイテムが削除され、これらのページが解放されます。空白領域の割合は、年中無休 (24x7) のオンライン最適化プロセスの効果によって常に変化しています。

データベース内の空白領域の量は、データベース内にメールボックスがあるユーザーが送受信したメールの容量を確認して見積もることができます。たとえば、データベース内に 2 GB のメールボックスが 100 個存在し (合計 200 GB)、ユーザーが 1 日に送受信するメールが平均 10 MB の場合、空白領域は約 1 GB (100 メールボックス × 1 メールボックスあたり 10 MB) です。バックグラウンドのデータベース保守ですべての処理を完了できない場合は、空白領域の量がこの計算よりも大きくなる可能性があります。

ページのトップへ

メールボックス データベースの回復可能なアイテム

各データベースには、回復可能な削除によって削除されたアイテムを格納する "ごみ箱" があります。既定では、回復可能な削除によって削除されたアイテムは 14 日間、予定表アイテムは 120 日間、Exchange 2010 に保存されます。

また、Exchange 2010 には、削除されたアイテムの保存期間が過ぎる前に、データが削除されるのを防ぐ機能もあります。この機能は、単一アイテムの回復として知られています。単一アイテムの回復は既定で無効になっています。ただし、単一アイテムの回復を有効にすると、14 日間の削除済みアイテムの保存用のメールボックスのサイズが 1.2% 増加します。予定表版のログ データの場合は、メールボックスのサイズがさらに 3% 増加します。予定表版のログ データは、既定で有効になっています。

14 日間の削除済みアイテムの保存期間用の削除済みアイテム収集機能の空き領域要件の式は、単一アイテムの回復および予定表版ログを有効にした状態で、次のようになります。

削除済みアイテム収集機能のサイズ = (1 日の受信/送信メール x 平均的なメッセージのサイズ x 削除済みアイテムの保存期間) + (メールボックス クォータのサイズ x 0.012) + (メールボックス クォータのサイズ x 0.03)

たとえば、メールボックスのサイズが 2 GB で、14 日間の削除済みアイテムの保存期間用に単一アイテムの回復を有効にすると、さらに 25 MB の空き領域が必要になり、予定表ログ機能には 61 MB の追加の空き領域が必要になります。

詳細については、以下のトピックを参照してください。

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

• 回復可能なアイテムについて

• 回復可能なアイテムの管理

• 予定表修復について

• 予定表修復の管理

実際のメールボックスのサイズ

時間が経過すると、ユーザーのメールボックスはメールボックス格納域の制限に達するため、受信メールと同じ量のメールを削除してメールボックス格納域の制限を超えないようにする必要があります。この要件により、削除済みアイテム収集機能は、1 日に送受信される電子メールの量と削除済みアイテムの保存期間内の日数を乗じた値に等しい最大サイズに増加します。ユーザーの大半が格納域の制限に達していない場合は、受信/送信メールの一部のみが削除されます。したがって、増加分は、削除済みアイテム収集機能およびメールボックス サイズとの間で分割されます。

個人用アーカイブ機能を使用しない 2 GB のメールボックスを使用するデータベースのサイズを計算するには、「Exchange 2010 メールボックス サーバーの役割の設計例」の「メールボックス容量の要件」を参照してください。

実際のメールボックス サイズを見積もったら、その値を使用してデータベースごとのユーザーの最大数を決定することができます。見積もったメールボックスのサイズを推奨されるデータベースのサイズで分割します。この値は、完全にデータが格納されたデータベースであると仮定して、計画されたユーザー数を処理するのに必要なデータベースの数を決定するのにも役立ちます。ただし、トランザクション以外の入出力 (I/O) やハードウェアの制限が理由で、単一のサーバーに配置されるユーザーの数を変更することが必要になる場合もあります。一部の管理者は、さらにデータベース サイズを削減するために、より多くのデータベースを使用する場合があります。この方法では、サーバーごとにより多くのデータベースを管理するため、より複雑になりますが、バックアップと復元の時間が短縮できることがあります。

コンテンツ インデックス処理

コンテンツ インデックス処理によってインデックスつまりカタログを作成することで、ユーザーは手動でメールボックス全体を検索するよりもすばやく簡単にメール アイテムを検索できるようになります。Exchange 2010 では総データベース サイズの約 10% のインデックスが作成され、データベースと同じ LUN に配置されます。そのため、コンテンツ インデックス処理のために、さらに 10% をデータベース LUN サイズに含める必要があります。

ページのトップへ

オフライン データベースの保守

オフラインでの圧縮が必要なデータベースでは、対象のデータベースに 10% を加えたサイズの容量が必要になります。1 つのデータベースまたはバックアップ セットに十分な領域を割り当てたかどうかに関係なく、これらの操作を実行するためには追加領域を利用できる必要があります。

回復用データベース

障害回復計画の一環として回復用データベースの使用を計画する場合は、そのサーバーで同時に復元するすべてのデータベースを処理するための十分な容量が利用できる必要があります。詳細については、「回復用データベース」を参照してください。

データベースのサイズ

データベース サイズにより、各データベース内で展開するメールボックスの数および展開するデータベースの数が最終的に決定されます。展開したデータベースのサイズはいくつかの要因によって決まります。

• バックアップ/復元サービス レベル契約 (SLA)   データベース サイズにより、妥当な時間内でどのくらい速くデータをバックアップおよび復元できるのかが最終的に決定されます。

• 高可用性アーキテクチャ   複数のデータベース コピーの保持を計画している場合は、回復操作の面で第一の対応策となるのはコピーなので、データベースを 2 TB のサイズに設計することができます。

• 記憶域アーキテクチャ   JBOD ストレージ (1 つのディスクでデータベースとその対応するトランザクション ログの両方を格納) の展開を計画している場合は、使用するディスクのサイズによって、最大データベース サイズが決定されます。たとえば、1 TB のディスク (約 917 GB のフォーマット済み容量) の場合、トランザクション ログおよびコンテンツのインデックスも含める必要があり、使用可能な空き領域がすべて消費されないようにします。

データベース拡張のオーバーヘッド

すべての要素を考慮して計算した後、データベース論理ユニット番号 (LUN) 用の追加オーバーヘッド要素を 20% 含めることをお勧めします。この値によって、メールボックスのサイズや空白領域の計算時に明らかになっているとは限らない、データベース内の他のデータの分の領域が確保されます。

ページのトップへ

ログの容量

トランザクション ログ ファイルは、データベース エンジンによって実行されるすべてのトランザクションの記録です。トランザクションはすべて、最初にログに書き込まれ、その後で遅れてデータベースに書き込まれます。Exchange Server 2003 とは異なり、Exchange 2010 ではトランザクション ログ ファイルのサイズが 5 MB から 1 MB に削減されました。この変更は、連続レプリケーション機能をサポートし、プライマリ記憶域の障害が発生した場合にデータの損失量を最小限に抑えるために行われました。

Exchange 2010 メールボックス サーバー上に生成されるトランザクション ログの数を見積もるには、次の表を参考にしてください。メッセージの平均サイズは 75 KB とします。

1 日に生成されたトランザクション ログの数の値は、選択されたメッセージ プロファイルおよびメッセージの平均サイズに基づきます。これは、メールボックスあたり 1 日に生成されるトランザクション ログの数を示します。メッセージ プロファイルごとのログの生成数により次のことが明らかになります。

• メッセージ サイズの影響

• 送信または受信したデータの量

• データベースの正常性の保守操作

• レコードの管理操作

• メールボックスに保存されるメッセージ以外のデータ (タスク、ローカルの予定表の予定、連絡先)

• ログの強制ロールオーバー (現在のトランザクション ログ ファイルを定期的に閉じる機構)

生成されるトランザクション ログの数 (メールボックス プロファイル別)

次のガイドラインを参照すると、トランザクション ログの生成率へのメッセージ サイズの影響がわかります。

• メッセージの平均サイズが 2 倍の 150 KB になると、メールボックスあたりの生成ログ数は 1.9 倍になります。この数字は、データベースのうち、添付ファイルとメッセージ テーブル (メッセージ本文および添付ファイル) を保存する部分の割合を表します。

• メッセージ サイズが 150 KB を超えてからは、サイズが 2 倍になると 1 メールボックスあたりのログ生成率も 2 倍になり、1.9 倍から 3.8 倍へと増加します。

たとえば、1 日あたり 100 メッセージがある場合:

• 平均的なメッセージ サイズが 150 KB では、メールボックスあたりに生成されるログは 20 x 1.9 = 38 になります。

• 平均的なメッセージ サイズが 300 KB では、メールボックスあたりに生成されるログは 20 x 3.8 = 76 になります。

次のセクションでは、ログ サイジングの容量に影響する要因について説明します。

• バックアップと復元の要素

• メールボックスの移動操作

• ログ増加オーバーヘッドの要素

• 高可用性の要素

• LUN 容量計画

バックアップと復元の要素

ログ LUN のサイジングはバックアップと復元の設計に一部左右されます。たとえば、2 週間前の時点までさかのぼって、それ以降に生成されたすべてのログを再生できるように設計している場合は、2 週間分のログ ファイル領域が必要になります。完全バックアップを週 1 回、差分バックアップを毎日行うようにバックアップを設計している場合は、バックアップと復元中の再生の両方を実行できるように、ログ LUN をログ ファイル 1 週間分の領域より大きくする必要があります。夜間に完全バックアップを実行するほとんどの企業は、1 日あたりの必要なログ生成容量を 2 ～ 3 倍にして割り当てています。このようなアプローチを取るのは、バックアップが失敗したためにログ ドライブがいっぱいになってデータベースのマウントが解除されるのを防ぐためです。

バックアップ インフラストラクチャとして、メールボックス復元機能と単一アイテム回復機能を Exchange 2010 内で使用する場合は (つまり、循環ログが有効になります)、ベスト プラクティスとして、1 日あたりに必要なログ生成の容量を 3 倍にして割り当てる必要があります。そうすることで、レプリケーションが中断状態になったり、通常のパラメーターで機能しなくなったりしても、トランザクションの失敗によってデータベースがマウント解除されることがなくなります。

メールボックスの移動操作

メールボックスの移動は、大規模なメールボックス展開の容量にかかわる主要な要素です。多くの大企業では、ある割合のユーザー メールボックスを夜間または 1 週間ごとに別のデータベース、サーバー、またはサイトに移動します。組織でこのような処理を行う場合は、メールボックスの移動に対応できるようにログ LUN の容量を多めに確保することを検討してください。

移動元サーバーでログに記録されるのはレコードの削除で、ログの量は多くありませんが、移動先サーバーでは転送されたすべてのデータを最初にトランザクション ログに書き込む必要があります。1 日に生成されるログ ファイルが 10 GB で、確保しているバッファーが 3 日分 (30 GB) の場合は、2 GB のメールボックス 50 個 (100 GB) を移動すると移動先のログ LUN がいっぱいになり、ダウンタイムが発生します。このようなケースでは、メールボックスの移動に対応できるようにログ LUN に追加の容量を割り当てる必要がある場合があります。

ログ増加オーバーヘッドの要素

ほとんどの展開に対しては、ログ LUN の作成時に 20% のオーバーヘッド要素をログ サイズ (他のすべての要因を考慮して求めた値) に加えることをお勧めします。これは、予期せずにログが生成されたときも必要な容量が確保されているようにするためです。

高可用性の要素

高い可用性はログ容量の用件に 3 つの重要な方法で影響します。

• データベース コピー数   システム全体のログ容量は、高可用性展開で選択したデータベース コピーの数に基づいて増加します。3 台のサーバーにわたって分散されたデータベース コピーが 3 つある場合は、各サーバーのコピーごとにログ容量を準備する必要があります。

• ログの切り詰めメカニズム   Exchange 2010 の高可用性およびメールボックス データごとに 16 個までコピーを保持できる機能により、完全/増分バックアップを実行するのとは異なり、連続レプリケーション循環ログをログの切り詰め/削除メカニズムとして使用して古いログを切り詰め/削除する基盤が提供されます。詳細は、「バックアップ、復元、および障害復旧について」および「高可用性とサイト復元」の「バックアップなしでのログの切り詰め」セクションを参照してください。

• データベース コピーの再生ラグ   Exchange 2010 の高可用性により、パッシブ データベース コピーでログの再生を遅らせるためのオプションが提供されます (コピー単位で構成)。この機能は、時間差データベース コピーにログが再生される際に、遅延を作るために使用されます。この遅延は、望ましくないコンテンツをすべてのデータベース コピーにレプリケートする原因となるイベントから保護するのに役立ちます。コンテンツは、望ましくないコンテンツのログがデータベースに再生される前に再生を中断することにより、時間差データベース コピーに再生されることを中止できます。

  再生ラグをデータベース コピーで有効にすると、ログ容量の要件がそれに従って変更されます。14 日間のラグを構成してある場合は、17 日分のログを準備する必要があります。追加のログ容量が必要なのは、ラグを構成したデータベース コピーのみで、そのデータベースのラグのない他のコピーには、通常の (時間差のない) ログ容量の要件が適用されます。

詳細については、「高可用性の要因について」を参照してください。

LUN 容量計画

LUN の容量の要件は、データ セット (データベース、トランザクション ログ、コンテンツのインデックス、および回復用の空き領域) のサイズおよびある程度の追加の空き領域に基づきます。ほとんどの操作管理プログラムには、LUN が 80% を超えて使用されたたときにアラートを出す容量のしきい値があります。

次の式を使用して、LUN の適切なサイズを決定することができます。

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

たとえば、データ サイズの要件が 3000 MB で、空き領域の要件が 20% の場合、このデータをホストする LUN のサイズは 3750 MB である必要があります。

トランザクション ログのディスク領域の完全消費の予防

トランザクション ログのディスク領域がすべて消費されることがないよう、まず環境の基準値を計算して、1 日あたりの典型的なログ生成率を特定する必要があります。次に、監視メカニズムを設定し、生成される警告に対処する必要があります。次の項目を監視する必要があります。

• トランザクション ログ LUN のディスク領域。いくつかのしきい値と警告メカニズムを設定します。たとえば、典型的なログ生成基準値がわかっていれば、基準値を 20% 上回った時点で報告が行われるようにしきい値を設定することができます。

• バックアップの完了 (ネイティブ データ保護を使用しない場合)。

• アプリケーション ログでのイベントの切り捨て。

• データベース コピーのレプリケーションの状態。

原因不明のトランザクション ログの増加に対するトラブルシューティング

原因不明のトランザクション ログの増加に対するトラブルシューティングを行うには、「シェルの Troubleshoot-DatabaseSpace.ps1 スクリプトを使用してデータベース ログ増加を管理する」を参照してください。

 © 2010 Microsoft Corporation.All rights reserved.