メールボックス サーバーの記憶域設計

 

適用先: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

トピックの最終更新日: 2009-04-03

十分な容量を用意することは非常に重要です。データベースのディスク領域が不足すると、データベースはオフラインになります。トランザクション ログのディスク領域が不足すると、そのストレージ グループ内のすべてのデータベースがオフラインになります。多くの場合、追加領域の準備を迅速に行うことは困難で、オフラインでの圧縮を実行して領域を再利用するには長い時間がかかる可能性があります。ほとんどの場合、ディスク領域の不足が発生すると 1 つ以上のデータベースの可用性が一定期間中断し、通常、その長さはほとんどの目標回復時間 (RTO) を上回ります。

このトピックでは、以下の内容について説明します。

• Exchange 2007 メールボックス記憶域計算用シート
• データベース LUN の容量
• ログ LUN の容量
• トランザクション I/O
• Exchange 2007 のベースライン IOPS の予測
• トランザクション以外の I/O
• LUN と物理ディスク
• 記憶域設計に対する連続レプリケーションの影響

Exchange 2007 メールボックス記憶域計算用シート

Exchange Server 2007 Mailbox Server Role Storage Requirements Calculator (メールボックス サーバーの役割の記憶域要件計算用シート) を使用すると、一連の入力要素に基づいて記憶域要件 (I/O パフォーマンスと容量) および最適な論理ユニット番号 (LUN) レイアウトを決めることができます。Exchange 2007 メールボックス サーバー用の最適な記憶域ソリューションを設計するには、多数の入力要素について考慮する必要があります。これらの入力要素について、このトピックで説明します。

この記憶域計算用シートでは、組織固有の値を入力すると、I/O 要件、容量要件、および最適な LUN レイアウトに関する推奨事項が得られるようになっています。

記憶域計算用シートの使い方など、詳細については、Exchange チーム ブログの「Exchange 2007 Mailbox Server Role Storage Requirements Calculator」を参照してください (このサイトは英語の場合があります)。このページでは、計算用シートをダウンロードすることもできます。

注 :
各ブログの内容とその URL は、将来予告なしに変更されることがあります。 各ブログの内容は、保証なしに "現状のまま" 提供され、権利を付与するものではありません。 含まれているスクリプト サンプルまたはコードの使用は、「Microsoft Terms of Use」に規定されている条件に従います (このサイトは英語の場合があります)。

データベース LUN の容量

データベースの論理ユニット番号 (LUN) のサイズを設定する方法を決定するには、さまざまなデータ要素を使用します。さらに、考慮する必要がある要素はこれ以外にもあります。すべての要素を考慮して計算した後、データベース LUN 用の追加オーバーヘッド要素を 20% 含めることをお勧めします。この値によって、メールボックスのサイズや空白領域の計算時に明らかになっているとは限らない、データベース内の他のデータの分の領域が確保されます。たとえば、データベース内のデータ構造 (テーブル、ビュー、内部インデックスなど) によってデータベース全体のサイズが増加します。以降の説明に従って計算した結果、必要な容量がたとえば 120 GB ならば、そのストレージ グループのデータベース LUN は、安全のためのオーバーヘッド 20% を加えた 144 GB を準備することをお勧めします。

メールボックス クォータ

最初に理解する指標はメールボックスのサイズです。各エンド ユーザーがメールボックスに格納できるデータ量がわかっていれば、サーバーに配置できるユーザー数が決まります。最終的なメールボックスのサイズとクォータは変化しますが、必要な容量を決定するにはまず目標を設定する必要があります。たとえば、サーバーのユーザー数が 5,000 人で、メールボックス クォータが 250 MB ならば、最低でも 1.25 TB のディスク領域が必要です。メールボックス クォータにハードウェア制限を設定しないと、必要な容量の見積もりが難しくなります。

データベースの空白領域

物理ディスク上のデータベースのサイズは、単にユーザー数とユーザー クォータを乗算したものではありません。大多数のユーザーが各自のメールボックス クォータにまだ余裕があるというときは、データベースが占有する領域は小さく、空白領域は容量上の問題とはなりません。データベース自体には、常に空きページ、つまり空白領域が全体に散在します。オンライン保守時に、データベースから削除するようにマークされたアイテムが削除され、これらのページが解放されます。空白領域の割合は常に変化し、オンライン保守の直後に最大になり、オンライン保守の直前に最小になります。

データベースの空白領域のサイズは、データベース内にメールボックスを持つユーザーによって送受信されるメールの量によって見積もることができます。たとえば、データベース内に 2 GB のメールボックスが 100 個存在し (合計 200 GB)、ユーザーが 1 日に送受信するメールが平均 10 MB の場合、空白領域は約 1 GB (100 メールボックス × 1 メールボックスあたり 10 MB) です。

オンライン保守ですべての処理を完了できない場合は、空白領域がこの計算よりも大きくなる可能性があります。オンライン保守を毎晩実行するための十分な時間を運用作業に含め、1 週間以内にすべての処理を完了できるようにすることが重要です。

データベースのごみ箱

各データベースには、回復可能な削除によって削除されたアイテムを格納する "ごみ箱" があります。既定では、アイテムは 14 日間 Microsoft Exchange Server 2007 で保存されます。これには、削除済みアイテム フォルダから削除されたアイテムが含まれます。既定では、Exchange Server 2003 と比較すると Exchange 2007 ではデータベースのごみ箱によって消費されるオーバーヘッドが増加します。これは、削除済みアイテムの保存期間が 2 倍になっているからです。ごみ箱の中身の実際の大きさは、各アイテムのサイズと組織で定められた保存期間によって決まります。

保存期間が過ぎると、これらのアイテムはオンライン保守サイクル中にデータベースから削除されます。最終的に、ごみ箱の大きさが受信/送信メール 2 週間分に等しいという定常状態に達しますが、これはデータベース サイズのうち一定の割合を占めます。正確な割合は、削除されるメールの量と個々のメールボックスのサイズによって異なります。

ごみ箱により、メールボックスのサイズとそのメールボックスのメッセージ配信速度に応じた割合のオーバーヘッドがデータベースに追加されます。たとえば、配信されるメッセージの量が 1 週間あたり 52 MB で一定しているとします。250 MB という高負荷プロファイルのメールボックスならば約 104 MB がごみ箱に保管されることになり、41% のオーバーヘッドが追加されます。メールボックスのサイズが 1 GB で、ごみ箱に同じく 104 MB を保管する場合は、10% のオーバーヘッドが追加されます。

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

時間が経過すると、ユーザーのメールボックスはメールボックス クォータに達するため、受信メールと同じ量のメールを削除してメールボックス クォータを超えないようにする必要があります。これは、ごみ箱の中身が増えて、最大サイズである受信/送信メール 2 週間分に達することを意味しています。大多数のユーザーがメールボックス クォータに達していない場合は、受信/送信メールの一部のみが削除されるため、増加分はごみ箱とメールボックス サイズの増加分の間で分けられます。たとえば、250 MB のメールボックスのメッセージ プロファイルが "非常に高負荷" であり、受信するメールの量が 1 週間に 52 MB (メッセージの平均サイズは 50 KB) ならば、ごみ箱で 104 MB (41%)、空白領域で 7.3 MB を消費するので、メールボックスのサイズは合計 360 MB になります。また、サイズが 2 GB で、1 週間に 52 MB のメールを受信する "高負荷" メッセージ プロファイルのメールボックスでは、ごみ箱で 104 MB (5%)、空白領域で 7.3 MB を消費するので、メールボックスのサイズは合計 2.11 GB になります。2 GB メールボックスが 50 個あるストレージ グループの合計は、105.6 GB になります。

2 GB のメールボックスを使用するデータベースのサイズを計算する式を次に示します。

メールボックス サイズ = メールボックス クォータ + 空白領域 + (1 週間分の受信メール × 2)

メールボックス サイズ = 2,048 MB + (7.3 MB) + (52 MB × 2)

2,159 MB = 2,048 MB + 7.3 MB + 104 MB (クォータ + 5%)

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

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

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

保守

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

回復用ストレージ グループ

障害回復計画の一環として回復用ストレージ グループの使用を計画する場合は、そのサーバーに同時に復元したいすべてのデータベースを処理するための十分な容量を利用できる必要があります。

ディスクへのバックアップ

多くの管理者は目的のディスクへのストリーミング オンライン バックアップを実行します。バックアップと復元の設計にディスクへのバックアップが含まれる場合は、バックアップを格納するサーバーで十分な容量を利用できる必要があります。使用するバックアップの種類によっては、この容量はデータベースおよびログと同じくらい小さなサイズになる場合も、データベースと最後の完全バックアップ以降のすべてのログと同じくらい大きなサイズになる場合もあります。

ログ LUN の容量

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

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

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

メールボックス プロファイル	メッセージ プロファイル	メールボックスあたりの生成ログ数
低負荷	5 通送信/20 通受信	6
平均的負荷	10 通送信/40 通受信	12
高負荷	20 通送信/80 通受信	24
非常に高負荷	30 通送信/120 通受信	36
きわめて高負荷	40 通送信/160 通受信	48

メッセージ サイズがログ生成率に及ぼす影響に関するガイドラインは次のとおりです。

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

以下に例を示します。

• メールボックス プロファイルが "高負荷" で、メッセージの平均サイズが 100 KB ならば、メールボックスあたりの生成ログ数は 24 × 1.9 = 46 となります。
• メールボックス プロファイルが "高負荷" で、メッセージの平均サイズが 200 KB ならば、メールボックスあたりの生成ログ数は 24 × 3.8 = 91 となります。

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

夜間に完全バックアップを実行する企業の多くは、トランザクション ログ LUN 上のストレージ グループにログ ファイル約 3 日分の容量を割り当てています。このように割り当てるのは、バックアップが失敗したためにログ ドライブがいっぱいになってストレージ グループのマウントが解除されるのを防ぐためです。

ログ LUN のサイジングはバックアップと復元の設計に多少左右されます。たとえば、2 週間前の時点までさかのぼって、それ以降に生成されたすべてのログを再生できるように設計している場合は、2 週間分のログ ファイル領域が必要になります。完全バックアップを週 1 回、差分バックアップを毎日行うようにバックアップを設計している場合は、バックアップと復元中の再生の両方を実行できるように、ログ LUN をログ ファイル 1 週間分の領域より大きくする必要があります。

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

メールボックスの移動は、大規模なメールボックス展開の容量にかかわる主要な要素です。多くの大企業では、ある割合のユーザーを夜間または 1 週間ごとに別のデータベース、サーバー、またはサイトに移動します。自分の組織でもこのような処理を行う場合は、ユーザーの移動に対応できるようにログ LUN の容量を多めに確保することを検討してください。移動元サーバーでログに記録されるのはレコードの削除で、ログの量は多くありませんが、移動先サーバーでは転送されたすべてのデータを最初にトランザクション ログに書き込む必要があります。1 日に生成されるログ ファイルが 10 GB で、確保しているバッファが 3 日分 (30 GB) の場合は、2 GB のメールボックス 50 個 (100 GB) を移動すると移動先のログ LUN がいっぱいになり、ダウンタイムが発生します。このようなケースでは、メールボックスの移動に対応できるようにログ LUN に追加の容量を割り当てる必要がある場合があります。

ログ増加要素

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

メールボックス容量計画の例

ここでは、クラスタ連続レプリケーション (CCR) 環境内の単一のクラスタ化メールボックス サーバーに、メッセージ プロファイルが "非常に高負荷" の 1 GB メールボックス 4,000 個が配置されている環境でのサイズ計算の例を示します。これらのメールボックスが受け取るメールは平均で 1 週間に 52 MB、メッセージの平均サイズは 50 KB です。次の表に、実際のメールボックス サイズを求めるための値の例を示します。

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

メールボックスのサイズ	ごみ箱のサイズ (2 週間)	空白領域	ディスク上の合計サイズ
1 GB	104 MB (2 × 52 MB)	7.3 MB	1.11 GB (+ 11%)

この環境では、各ユーザーは 1.11 GB のディスク容量を消費します。CCR 環境における推奨される最大データベース サイズは 200 GB なので、サーバーはデータベースごとにメールボックスを 180 個を超えてホストしないようにします。4,000 個のメールボックスをサポートするには、23 個のデータベースが必要です。また、この環境ではストレージ グループも 23 個必要です。CCR 環境では、ストレージ グループごとに 1 つのデータベースが必要なので、データベースはそれぞれ各自のストレージ グループ内に存在します。最終的に、ストレージ グループあたりのメールボックス数は 174 個となります。メールボックスの数と実際のサイズに基づき、データベース サイズは次の表に示すように 193 GB となります。

データベース容量の要件

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

領域割り当ての問題が原因でメールボックス サーバーのダウンタイムが生じることがないようにするには、トランザクション ログのサイズも、バックアップ セット中に生成されるすべてのログを記録できるように設定する必要があります。多くの組織は、バックアップが失敗した場合に備えて、1 日あたりのログ生成率を 3 倍にして毎日の完全バックアップの計画を立てています。完全バックアップを週 1 回行い、その後は差分バックアップまたは増分バックアップを実行する場合に、復元の処理を行うには、少なくとも 1 週間分のログ容量が必要です。メッセージ プロファイルが "非常に高負荷" であるメールボックスは、1 日平均 42 個のトランザクション ログを生成するので、サーバーのメールボックスが 4,000 個ならば、1 日に 168,000 個のトランザクション ログが生成されます。つまり、ストレージ グループ 1 つにつき 7,304 個のログが生成されます。週にメールボックスの 10% が特定の日 (土曜日) に移動され、バックアップ処理には毎週完全バックアップおよび毎日の増分バックアップが含まれます。また、3 日間はログ切り詰めを行わなくてもサーバーが正常に稼働します。次の表に示すように、このサーバーではストレージ グループ 1 つにつき 38.8 GB の領域が必要です。

ログ容量の要件

ストレージ グループごとのログの数	ログ ファイルのサイズ	毎日のログのサイズ	移動するメールボックスのサイズ	増分復元のサイズ	ログ サイズの要件
7,304	1 MB	7.13 GB	17 GB (17 × 1 GB)	21.4 GB (3 × 7.13 GB)	38.8 GB (17.4 + 21.4)

トランザクション ログ LUN は、メールボックスの移動操作によって生成される両方のログを処理するのに十分な大きさであると同時に、1 週間分のログを復元するのに十分な領域を持つ必要があります。

トランザクション I/O

トランザクション I/O は、サーバーを使用するユーザーによって引き起こされるディスク I/O です。たとえば、アイテムの受信、送信、および削除によってディスク I/O が発生します。Exchange キャッシュ モードを使用しない Microsoft Outlook ユーザーは、長いディスク待機時間による直接の影響を受けます。これは記憶域の設計で最も重要な問題の 1 つです。記憶域に対するトランザクション I/O 要件は減少しており、連続レプリケーションが利用できるので、高可用性を実現するために高価なファイバ チャネル記憶域を使用する必要はなくなりました (ただし優れたソリューションであることに変わりはありません)。

IOPS について

以前のバージョンの Exchange Server では、記憶域のサイズ計算に必要な主要指標の 1 つとして、各ユーザーによって消費される 1 秒あたりのデータベース I/O (IOPS) の数があります。ユーザー IOPS を測定するには、ストレージ グループに対するデータベース LUN 上の I/O の数 (読み取りおよび書き込み) を、そのストレージ グループ内のユーザー数で除算します。たとえば、1,000 人のユーザーによってデータベース LUN で 1,000 の I/O が発生するということは、ユーザーあたりの IOPS が 1.0 であることを意味します。

ベースライン IOPS の測定

以前のバージョンの Exchange Server を使用していて、ベースライン IOPS を計算したことがある場合は、Exchange 2007 は次の点でベースラインに影響することに注意してください。

• サーバー上のユーザー数は、ユーザーごとのデータベース キャッシュ全体に影響します。
• RAM の容量がデータベース キャッシュの最大サイズに影響します。データベース キャッシュが大きいほどキャッシュの読み取りヒット数が増えるため、データベースの読み取り I/O が減少します。

重要なのは、特定のサーバーでの IOPS がわかっているだけではエンタープライズ全体の計画はできないということです。RAM の容量、ユーザー数、およびストレージ グループ数がサーバーごとに異なる可能性があるためです。実際の IOPS の数値が得られたら、計算時は必ず 20% のオーバーヘッド係数を掛けて、余裕を持たせるようにします。アクティビティの負荷が通常より高いときも、ユーザーの操作性が低下してはならないからです。

データベース キャッシュ

64 ビット Windows Server オペレーティング システムで 64 ビット版の Exchange 2007 を実行する場合は、仮想アドレス スペースが大幅に拡大するので、Exchange のデータベース キャッシュを大きくしてデータベースの読み取り I/O を減らすことができます。また、サーバーあたりのデータベース数は最大 50 個となります。

データベースの読み取り数の減少は、サーバーで利用可能なデータベース キャッシュの容量とユーザーのメッセージ プロファイルによって左右されます。メモリとストレージ グループに関するガイダンスについては、「プロセッサ構成の計画」を参照してください。そのトピックのガイダンスに従うと、トランザクション I/O を Exchange 2003 より最大 70% 削減できます。ユーザーごとのデータベース キャッシュの容量は、実際の I/O 削減の重要な要素です。

次の表は、Exchange 2003 の既定値 900 MB と、Exchange 2007 のユーザーあたりのデータベース キャッシュ 5 MB を比較したときに、ユーザーあたりのデータベース キャッシュが実際にどれだけ増加しているかを示すものです。この追加のデータベース キャッシュにより、キャッシュでの読み取りヒット数を増やして、ディスク レベルでデータベースの読み取りを削減することができます。

メールボックス数に基づくデータベース キャッシュのサイズ

メールボックス数	Exchange 2003 データベース キャッシュ/メールボックス (MB)	Exchange 2007 データベース キャッシュ/メールボックス (MB)	Exchange 2003 からのデータベース キャッシュの増加
4,000	0.225	5	23 倍
2,000	0.45	5	11 倍
1,000	0.9	5	6 倍
500	1.8	5	3 倍

Exchange 2007 のベースライン IOPS の予測

Exchange 2007 データベースの IOPS を予測するのに使用できる主な 2 つの要素は、ユーザーごとのデータベース キャッシュの容量と、各ユーザーが 1 日に送受信するメッセージの数です。次の数式は、Office Outlook 2007 を Exchange キャッシュ モードで使用する標準的なナレッジ ワーカーに基づくもので、テストの結果、誤差が +/- 20% であることがわかっています。クライアントの種類および使用シナリオが異なると、得られる結果が正確でない場合があります。この予測は、サイズが 2 MB ～ 5 MB のデータベース キャッシュに対してのみ有効です。この数式は、1 日に 150 通以上のメッセージを送受信するユーザーでは検証していません。数式の検証に使用した平均的なメッセージ サイズは 50 KB でしたが、メッセージ サイズは IOPS の主な要因ではありません。

次の表に、ベースライン Exchange 2007 IOPS の要件を予測するのに使用できる、ユーザーごとの IOPS の予測値を示します。

ユーザー プロファイルおよびメッセージ アクティビティに基づく、1 ユーザーあたりのデータベース キャッシュおよび予測される IOPS

ユーザーの種類 (使用プロファイル)	1 日あたりの送受信数 (メッセージ サイズ約 50 KB)	ユーザーあたりのデータベース キャッシュ	ユーザーあたりの予測される IOPS
低負荷	5 通送信/20 通受信	2 MB	0.11
平均的負荷	10 通送信/40 通受信	3.5 MB	0.18
高負荷	20 通送信/80 通受信	5 MB	0.32
非常に高負荷	30 通送信/120 通受信	5 MB	0.48
きわめて高負荷	40 通送信/160 通受信	5 MB	0.64

データベース キャッシュのサイズを見積もるには、Exchange サーバーにインストールされているメモリの合計容量から 2,048 MB (ローカル連続レプリケーション (LCR) を使用している場合は 3,072 MB) を引き、その値をユーザー数で割ります。たとえば、ユーザー数 3,000 人で 16 GB の RAM を持つサーバーの場合は、システム用の 2 GB を引いて RAM の残りは 14 GB となり、ユーザー 1 人あたりでは 4.66 MB (14 GB ÷ 3,000 = 4.66 MB) となります。

ユーザーあたりのデータベース キャッシュ サイズが平均 4.66 MB であり、1 日に送受信されるメッセージの数が平均 60 通であることから、データベースの読み取りと書き込みの両方を次のように計算できます。

• データベースの読み取り   1 日あたりのメッセージ数 60 に 0.0048 を掛けると、0.288 となります。次に、メールボックスあたりのデータベース キャッシュの容量 (4.66 MB) を -0.65 乗 (5^-0.65) すると、0.3622 となります。最後に、この 2 つの値を掛けると、1 ユーザーあたりのデータベース読み取り回数は 0.104 となります (0.288 × 0.3622 = 0.104)。
• データベースの書き込み   ユーザーあたりのメッセージ数 (60) に 0.00152 を掛けると、ユーザーあたりのデータベース書き込み回数は 0.0912 となります。

次の数式を使用します。

((0.0048 × M) × (D ^ -0.65)) + (0.00152 × M) = データベース IOPS の合計

ここで、M はメッセージの数、D はデータベース キャッシュです (ユーザーあたり)。ユーザーあたりのデータベース IOPS の合計は、読み取りと書き込みをたしたもので、この例では 0.189 IOPS です。

((0.0048 × 60) × (4.66 ^ -0.65)) + (0.00152 × 60) = 0.189

次のグラフは、250 MB のメールボックス 4,000 個、Outlook 2007 の Exchange キャッシュ モードをシミュレート、推奨されるサーバー メモリを装備という条件で Exchange 2007 を実行したときの、データベースの読み取りと書き込みの減少を示しています。

オンライン モード クライアントの影響

Exchange キャッシュ モードのクライアントとは異なり、オンライン モードのクライアントの操作はすべてデータベースに対して行われます。その結果、データベースに対する読み取り I/O 操作が増えます。したがって、大半のクライアントがオンライン モードで動作する場合は、次のガイドラインに従ってください。

• 250 MB オンライン モードのクライアントは、Exchange キャッシュ モードのクライアントと比較して、データベースの読み取り操作数が 1.5 倍になります。250 MB 未満の場合、影響はごくわずかです。
• メールボックスのサイズが倍になると、データベースの読み取り IOPS も倍になります (主要フォルダ間での均等なアイテム分布が変わらないと仮定した場合)。

次のグラフは、メールボックスのサイズに基づく IOPS を示しています。

テストによって明らかになったことは、メールボックスあたりのデータベース キャッシュを 5 MB を超えて増やしても、データベースの読み取り I/O 要件は大幅には減少しないということです。次のグラフは、2 GB メールボックスとオンライン モードのクライアントを使用する場合に、キャッシュを 5 MB を超えて増やしたときのデータベース読み取り I/O 要件の減少への影響を示しています。

この結果として、次の 2 つの事項をお勧めします。

• 可能であれば、キャッシュ モードのクライアントを展開します。後の「フォルダごとのアイテム数」を参照してください。
• データベース記憶域の設計には必ず、I/O 要件を考慮に入れます。

IOPS に関係するこの他の要因 (サード パーティ クライアントなど) については、「Exchange Server 2003 の記憶域の最適化」を参照してください。

データベースの読み取り/書き込みの比率

Exchange 2003 では、データベースの読み取りと書き込みの比率は一般に 2 対 1、つまり 66% が読み取りでした。Exchange 2007 では、データベース キャッシュのサイズが増加したことによってディスク上のデータベースの読み取り数が減少し、I/O 全体に対する読み取りの割合は小さくなっています。推奨されているメモリのガイドラインに従い、Exchange キャッシュ モードを使用した場合は、読み取りと書き込みの比率が 1 対 1 に近くなり、ほぼ 50% が読み取りということになります。

Outlook をオンライン モードで使用するときや、デスクトップ検索エンジンを使用するときは、読み取りと書き込みの比率が読み取り側で少し増加します (メールボックスのサイズによって異なります)。I/O 全体に対する書き込みの割合が増えることは、特に、書き込みに関連するコストが高い種類の RAID (Redundant Array of Independent Disks)、たとえば RAID5 や RAID6 を選択している場合に影響を及ぼします。サーバーに適した RAID ソリューションを選択する方法の詳細については、後の「記憶域テクノロジ」を参照してください。

ログとデータベースの比率

Exchange 2003 では、ストレージ グループのトランザクション ログに必要な I/O の数は、ストレージ グループ内のデータベースの I/O の約 10% に及びます。たとえば、データベース LUN が 1,000 の I/O を使用している場合、ログ LUN は約 100 の I/O を使用します。Exchange 2007 ではデータベースの読み取りが減少しており、ログ ファイルのサイズが小さくなったことと、作成できるストレージ グループ数が増えたこともあって、ログとデータベースの書き込み比率は約 3 対 4 になっています。たとえば、データベース LUN が使用する書き込み I/O の数が 500 のとき、ログ LUN が使用する書き込み I/O は約 375 となります。

測定または予測によってトランザクション ログ I/O の数を求めたら、20% の I/O オーバーヘッド係数を掛けて、通常より I/O の多い期間にも十分に対応するための余地を確保してください。また、連続レプリケーションの使用時は、閉じられたトランザクション ログを読み取り、2 番目の場所に送信する必要があります。このオーバーヘッドはログ読み取りの追加の 10% となります。ストレージ グループのトランザクション ログが 375 の書き込み I/O を使用する場合は、連続レプリケーションの使用時にさらに 37.5 の読み取り I/O を想定することができます。

フォルダごとのアイテム数

「アイテム数の多さと制限付きビューがパフォーマンスに与える影響について」で、重要なフォルダ内のアイテムの数と使用するクライアントの種類およびモードが一部のユーザーのディスク パフォーマンスにどのような影響を及ぼすかを説明しています。

サーバー I/O を減らす 1 つの方法は、Outlook 2007 を Exchange キャッシュ モードで使用することです。初期のメールボックスの同期処理はコストがかかりましたが、時間が経過してメールボックス サイズが大きくなるにつれて、ディスク サブシステムの負荷が Exchange サーバーから Outlook クライアントに移っています。これは、ユーザーが受信トレイに非常に多くのアイテムを残していたり、メールボックスの検索を実行したりしても、サーバーにはほとんど影響しないことを示しています。また、大きなメールボックスを持つ Exchange キャッシュ モードのユーザーは、小さなメールボックスを持つユーザーより高速のコンピュータを必要とする場合があることを示しています (許容可能なパフォーマンスに対する個々のユーザーのしきい値によって異なります)。Exchange キャッシュ モードで Outlook 2007 を実行するクライアント コンピュータを展開するときは、メールボックスの /.OST のサイズに関して以下の点を考慮してください。

• 5 ギガバイト (GB) 以下 : このサイズでは、ユーザーはほとんどのハードウェアを快適に使用できます。
• 5 GB ～ 10 GB : このサイズでの操作性は、通常、ハードウェアに依存します。したがって、高速なハード ディスクと多くの RAM を使用している場合は操作性が向上します。ただし、ポータブル コンピュータや古い世代のソリッド ステート ドライブ (SSD) で通常見られるドライブなどの低速なハード ドライブを使用している場合は、ドライブの応答時にアプリケーションが一時停止することがあります。
• 10 GB を超えるサイズ : このサイズでは、ほとんどのハードウェアで短時間の一時停止が発生し始めます。
• 25 GB 以上の非常に大きなサイズ : このサイズでは、特に新しい電子メールのダウンロード中などに、短時間の一時停止が頻繁に発生します。代替手段として、送受信グループを使用してメールを手動で同期できます。

注 :
このガイダンスは、2009 年 2 月 24 日リリースの Outlook 2007 修正プログラム パッケージ (Outlook.msp) についてのマイクロソフト サポート技術情報の記事 961752 に記載されている、Outlook 2007 Service Pack 1 以上の累積的な更新プログラムのインストールに関する情報に基づいています。

Exchange キャッシュ モードでの Outlook 2007 の展開でパフォーマンスに関する問題が発生している場合は、Outlook 2007 でのパフォーマンスの問題のトラブルシューティング方法についてのマイクロソフト サポート技術情報の記事 940226 を参照してください。

オンライン モードの Outlook Web Access と Outlook はいずれも、サーバーにあるデータに対してインデックス作成や検索を実行します。中程度のサイズのメールボックスの場合、これによってメールボックスごとの IOPS は同程度のサイズの Exchange キャッシュ モード クライアントの約 2 倍になります。メールボックスのサイズが大きくなると、メールボックスあたりの IOPS はさらに増えます。新しい方法でビューを初めて並べ替えるときに、インデックスが作成され、データベース LUN への多数の読み取り I/O が発生します。それ以降、アクティブなインデックスに対して実行される並べ替えには、それほどコストはかかりません。

問題となるシナリオの 1 つに、Exchange で保存されるインデックス数 (Exchange 2007 の場合は 11 インデックス) を超えた場合があります。ユーザーが新しい方法で並べ替えることを選択すると、12 番目のインデックスが作成され、新たなディスク I/O が発生します。このインデックスは保存されないので、このディスク I/O のコストは並べ替えが行われるたびに発生します。このシナリオでは大量の I/O が発生する可能性があるので、受信トレイ フォルダや送信済みアイテム フォルダなどのコア フォルダに格納するアイテム数は 20,000 以内にすることを強くお勧めします。最上位のフォルダ、つまり受信トレイ フォルダや送信済みアイテム フォルダの下のサブフォルダを増やすと、各フォルダ内のアイテム数が 20,000 を超えない限り、このインデックス作成に関連するコストが大幅に削減されます。アイテム数がメールボックス サーバーのパフォーマンスに与える影響の詳細については、「Recommended Mailbox Size Limits」 (このサイトは英語の場合があります) および「アイテム数の多さと制限付きビューがパフォーマンスに与える影響について」を参照してください。

注 :
各ブログの内容とその URL は、将来予告なしに変更されることがあります。 各ブログの内容は、保証なしに "現状のまま" 提供され、権利を付与するものではありません。 含まれているスクリプト サンプルまたはコードの使用は、「Microsoft Terms of Use」に規定されている条件に従います (このサイトは英語の場合があります)。

使用可能な、強化された機能の詳細については、2009 年 2 月の累積的な更新プログラムにおける Outlook 2007 の機能強化についてのマイクロソフト サポート技術情報の記事 968009 を参照してください。

トランザクション以外の I/O

トランザクション I/O は直接的なユーザー操作に応答して発生します。通常は最も高い優先度が与えられ、記憶域の設計の中心となります。トランザクション I/O が減ると、トランザクション以外の I/O の重要性が増します。大きなメールボックス、特に 2 GB メールボックスを使用する企業がユーザー容量を 2 倍にすることはほとんどありませんが、状況によっては 10 倍になることもあります。このような例の 1 つが、200 MB から 2 GB への移行です。ディスク上のデータ量がこのように大幅に増加する場合は、記憶域の設計の計画を行う際にトランザクション以外の I/O を考慮する必要があります。

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

Exchange 2007 では、メッセージのインデックス処理は受信時に行われるので、ディスク I/O のオーバーヘッドはほとんど発生しません。Exchange 2007 のインデックスに対する検索は、Exchange 2003 の場合より約 30 倍高速になっています。

メッセージング レコード管理

メッセージング レコード管理 (MRM) は、管理者やユーザーがメールボックスを管理する場合に役立つ Exchange 2007 の新機能です。保存期間などの特定のしきい値に一致するメールを移動または削除するようにポリシーを設定できます。MRM は同期読み取り操作中のデータベースに対して実行されるスケジュールされたクロールで、バックアップやオンライン保守と似ています。MRM によるディスク コストは、操作 (削除や移動など) を必要とするアイテム数によって異なります。

バックアップまたはオンライン保守と同時に MRM を実行しないことをお勧めします。連続レプリケーションを使用する場合は、ボリューム シャドウ コピー サービス (VSS) バックアップをパッシブ コピー側で行うことができます。このようにすれば、オンライン保守と MRM にかける時間を増やすことができ、オンライン保守と MRM 相互の、およびユーザーへの影響をなくすことができます。

オンライン保守

データベースでオンライン保守を実行すると、削除済みアイテムの完全な削除やデータベースのオンラインでの最適化の実行など、多くの処理が行われます。保守では読み取りが発生しますが、オンラインでの最適化では読み取りと書き込みの両方が発生します。保守の完了までにかかる時間はデータベースのサイズに比例するため、データベースの拡大を制限する要素になることがあります。オンライン保守の詳細については、「Store Background Processes Part I」を参照してください (このサイトは英語の場合があります)。

注 :
各ブログの内容とその URL は、将来予告なしに変更されることがあります。 各ブログの内容は、保証なしに "現状のまま" 提供され、権利を付与するものではありません。 含まれているスクリプト サンプルまたはコードの使用は、「Microsoft Terms of Use」に規定されている条件に従います (このサイトは英語の場合があります)。

バックアップおよび復元

バックアップと復元に関して、管理者が選択できる方法には、さまざまなものがあります。バックアップと復元の主要な指標はスループット、つまり運用 LUN との間で 1 秒間にコピーできる MB 数です。スループットを確認したら、バックアップと復元に関するサービス レベル契約 (SLA) を満たすために十分かどうかを判断する必要があります。たとえば、4 時間以内にバックアップを完了できることが要件であれば、これを達成するためにハードウェアの追加が必要になる可能性があります。ハードウェアの構成によっては、アロケーション ユニット サイズの変更によって対応できる場合があります。これは、ストリーミング オンライン バックアップ、および VSS バックアップの際に行われる Exchange Server データベース ユーティリティ (Eseutil.exe) による整合性チェックの両方で役に立つ可能性があります。

サーバーのユーザー数が 2,000 人ならば、200 MB のメールボックスを 2 GB のメールボックスに移行するとデータベースのサイズは 10 倍に増えます。多くの管理者は、1 台しかないサーバーで大量のデータ処理を行うことに慣れていません。サーバーに 2 GB のメールボックスが 2,000 個あるとします。既に説明したオーバーヘッドを考慮すると、このデータの大きさは 4 TB を超えます。175 GB/時間 (48 MB/分) の速度でバックアップを実行できるとしても、サーバーのバックアップ完了までに最低でも 23 時間かかることになります。LCR や CCR を使用しないサーバーでは、代わりに、次の表に示すようにデータベースの 7 分の 1 の完全バックアップを毎日実行し、残りについては増分バックアップを実行するという方法をとることができます。

毎週のバックアップ手順の例

バックアップの種類	1 日目	2 日目	3 日目	4 日目	5 日目	6 日目	7 日目
完全	DB 1 ～ 2	DB 3 ～ 4	DB 5 ～ 6	DB 7 ～ 8	DB 9 ～ 10	DB 11 ～ 12	DB 13 ～ 14
増分	DB 3 ～ 14	DB 1 ～ 2 と DB 5 ～ 14	DB 1 ～ 4 と DB 7 ～ 14	DB 1 ～ 6 と DB 9 ～ 14	DB 1 ～ 8 と DB 11 ～ 14	DB 1 ～ 10 と DB 13 ～ 14	DB 1 ～ 12

この表からわかるように、夜間にバックアップされるデータ量の合計は約 650 GB になり、速度が 175 GB/時間ならば 3.7 時間で完了することになります。この程度のスループットならば達成は可能ですが、メールボックスのサイズが大きい場合は、別の方法が必要になる可能性があります。

LCR および CCR では、パッシブ コピーが第一の対応策です。アクティブ コピーとパッシブ コピーの両方が失敗した場合や使用できない場合は、バックアップからのみ復元できます。数日分の増分ログからの回復では、回復するまでにかかる時間が長くなることがあります。このため、CCR や VSS クローンなどの高速回復ソリューションでは増分バックアップが使用されることはまれです。VSS クローンを使用する場合は高速でデータを回復できるので、ログ再生の時間が多少長くなっても、バックアップに関する SLA の範囲でバックアップを行うためにはおそらく許容されます。

ストリーミング オンライン バックアップ

ストリーミング バックアップを行うときは、バックアップの対象となる複数のストレージ グループが同時に同じディスク リソースを要求することがないように、ストリーミング I/O (バックアップ元とバックアップ先) を分離することをお勧めします。バックアップ先がディスクまたはテープかに関係なく、物理ディスクとコントローラには各ハードウェア ソリューションに特有のスループットの制限があります。バックアップ時間を最小限に抑えるために同時バックアップ処理数とスループットを最大にするには、ストレージ グループを互いに分離することが必要になる場合があります。次の表に、14 個のデータベースを 2 つに分けて同時バックアップする例を示します。

同時バックアップ手順の例

バックアップ番号	LUN 1	LUN 2	LUN 3	LUN 4	LUN 5	LUN 6	LUN 7
最初のバックアップ	ストレージ グループ (SG) 1	SG 2	SG 3	SG 4	SG 5	SG 6	SG 7
2 番目のバックアップ	SG 8	SG 9	SG 10	SG 11	SG 12	SG 13	SG 14

この表に示すように、ストレージ グループ LUN を互いに分離している場合は、各 LUN から 1 つずつ、ストリーミング バックアップを同時に実行することができます。各 LUN の最初のストレージ グループに対するバックアップ ジョブが終了してから 2 番目のストレージ グループのバックアップを開始するようにします。このようにして、バックアップ ストリームを分離します。同じ物理ディスクで 2 つのストリーミング バックアップ ジョブを実行しても、速度が 2 倍になるわけではありませんが、MB/秒単位では 1 つのストリーミング バックアップ ジョブを実行するよりも高速です。

VSS バックアップ

Exchange 2007 では、Windows Server 2003 の機能である VSS を使用して、データベースとトランザクション ログ ファイルのボリューム シャドウ コピーが作成されます。VSS の詳細については、「Exchange Server 2003 でボリューム シャドウ コピー サービスを使用するためのベスト プラクティス」を参照してください。このページには、複製 (クローン) とスナップショットの手法についても説明があります。Exchange 2007 の新機能として、LCR または CCR 環境で実行しているストレージ グループのパッシブ コピーの VSS バックアップを作成することができます。これらの環境では、パッシブ コピーから VSS スナップショットを作成すると、バックアップのチェックサム整合性中や、その後のテープやディスクへのコピー中における、アクティブ LUN のディスクの負荷が軽減されます。また、オンライン保守、MRM、およびその他のタスクを実行するために、アクティブ LUN により多くの時間を割くこともできます。

LUN と物理ディスク

多くの場合、オペレーティング システムで認識される物理ディスク、つまり LUN は、ハードウェアから抽象化されたものであり、オペレーティング システムに対してディスクを提示するために使用されます。パフォーマンスと回復のためには、LUN および物理ディスク レベルでトランザクション ログ ファイルをデータベース ファイルと区別することが常に重要になります。同じ物理ディスクに対してランダム ディスク I/O とシーケンシャル ディスク I/O の両方を行うと、パフォーマンスは大幅に低下します。また、回復の観点からは、ストレージ グループのログ ファイルとデータベース ファイルを分けておくと、物理ディスクの 1 セットに致命的な障害が発生しても、データベース ファイルとログ ファイルが両方失われることはありません。

Exchange 2007 では、ストレージ グループのすべてのデータベースを同じ物理 LUN に置くことがベスト プラクティスです。また、各ストレージ グループに 1 つのデータベースしか置かないこともベスト プラクティスです。Exchange データベースの I/O はランダムであり、各物理ディスクの負荷が均一な場合に、ほとんどの記憶域サブシステムに利点がもたらされます。多くの記憶域アレイは、多くの物理ディスクが最初にディスクのグループにプールされると、LUN がそのディスク グループで使用可能な容量から作成され、すべての物理ディスク間で等しく配分されるように設計されます。ストレージ グループのデータベース LUN をバックアップする物理ディスクでは、他のストレージ グループとサーバーのデータベースを格納している LUN もバックアップできます。同様に、シーケンシャル I/O がなくなると、多少パフォーマンスに影響がありますが、各ストレージ グループのトランザクション ログ LUN を別の物理スピンドルに分離するのに問題はありません。

1 台のサーバーに最大 50 のストレージ グループが構成されている場合、各ストレージ グループに独自のトランザクション ログ LUN とデータベース LUN を指定する必要があります。この場合、使用可能なドライブ文字数を超えるため、NTFS ファイル システム ボリューム マウント ポイントを使用する必要があります。50 個のストレージ グループの連続レプリケーションを行うように構成するには、200 個の LUN が必要ですが、この数は記憶域アレイの最大数を超えることがあります。特に LCR の場合は、200 個の LUN すべてが 1 つのサーバーに対して提示される必要があります。LUN の数が増えるにつれて、監視はさらに重要になります。ディスク容量が不足すると、そのストレージ グループはマウント解除されるためです。

LUN の設計

多くの場合、オペレーティング システムで認識される LUN は、実際にその "ディスク" の背後にある物理ハードウェアから抽象化されたものです。パフォーマンスと回復性のためには、LUN および物理ディスク レベルでトランザクション ログをデータベースと分離することが常に重要になります。一部の記憶域アレイでは、同じ物理ディスクでランダム I/O とシーケンシャル I/O を組み合わせると、パフォーマンスが低下する可能性があります。回復の観点からは、ストレージ グループのトランザクション ログとデータベースを分けておくと、物理ディスクの特定のセットに致命的な障害が発生しても、データベースとトランザクション ログが両方失われることはありません。

Exchange データベースの I/O はランダムであり、ほとんどの記憶域サブシステムでは、各物理ディスクの負荷が均一になるのが好ましい状態です。多くの記憶域アレイでは仮想記憶域が使用されており、多数の物理ディスクが最初にプールされてディスクのグループが作成されます。LUN は、このディスク グループの中の使用可能な領域から作成され、すべての物理ディスク間で均等に配分されます。連続レプリケーションを使用しない場合は、あるストレージ グループのデータベース LUN をバックアップする物理ディスクが、他のストレージ グループとサーバーのデータベースを格納する他の LUN を同時にバックアップしても、問題はありません。同様に、各ストレージ グループのトランザクション ログ LUN をそれぞれ別の物理スピンドルに分離することは必須ではありません。ただし、シーケンシャル I/O がなくなることで、パフォーマンスへの多少の影響はあります。同じストレージ グループのログ LUN とデータベース LUN を個別の物理ディスク上に分離することは重要です。30 IOPS と容量の 5% を必要とする場合、2 台または 4 台の 500 GB の物理ディスクを単一のストレージ グループのトランザクション ログ LUN 専用に使用することは現実的ではありません。

Exchange 2007 で LUN を設計する方法はいろいろありますが、あまり複雑にならないように、次の 2 つの設計方法をお勧めします。

• ストレージ グループごとに 2 つの LUN
• バックアップ セットごとに 2 つの LUN

ストレージ グループごとに 2 つの LUN

ストレージ グループごとに 2 つの LUN (ログ用とデータベース用) を作成することは、Exchange 2003 の標準的なベスト プラクティスでした。Exchange 2007 では、最大 50 のストレージ グループがある場合、準備する LUN の数はバックアップ戦略によって異なります。RTO が小さい場合、または迅速な回復のために VSS クローンを使用する場合は、各ストレージ グループを専用のトランザクション ログ LUN とデータベース LUN に配置することがおそらく最適です。この方法では、使用可能なドライブ文字数を超えるため、ボリューム マウント ポイントを使用する必要があります。

この戦略には次のような利点があります。

• 単一ストレージ グループのバックアップと復元を提供する、ストレージ グループ レベルでのハードウェア ベースの VSS が可能になります。
• ストレージ グループ間でパフォーマンスを柔軟に分離できます。
• 信頼性が高くなります。1 つの LUN 上の容量、破損、またはウイルスの問題は 1 つのストレージ グループにしか影響しません。

この戦略には次のような問題点があります。

• 50 個のストレージ グループに対して連続レプリケーションを行うには、200 個の LUN が必要ですが、この数は記憶域アレイの最大数を超えることがあります。特に LCR の場合は、200 個の LUN すべてを 1 つのサーバーに対して提示する必要があります。
• ストレージ グループごとに別の LUN があるため、サーバーごとの LUN が多くなり、管理コストが増大します。

バックアップ セットごとに 2 つの LUN

バックアップ セットは夜間に完全にバックアップされるデータベースの数です。夜間にデータベースの 7 分の 1 の完全バックアップを実行するソリューションでは、ストレージ グループがすべて同じログとデータベース LUN にバックアップされるようにすることで複雑さを軽減できます。これによってサーバー上の LUN の数も減らすことができます。

この戦略には次のような利点があります。

• 管理対象の LUN が少なくなるため、記憶域の管理が簡略化されます。
• バックアップ ジョブの数を削減できる可能性があります。

この戦略には次のような問題点があります。

• ハードウェア ベースの VSS バックアップと復元を行う機能が制限されます。
• マスタ ブート レコード (MBR) パーティションには 2 TB という上限があるので、容量拡張に限界があります。

ボリューム マウント ポイント

複数のノードのシングル コピー クラスタ (SCC) のように、使用可能なドライブ文字数を超える LUN が必要になる状況は多数あります。このような場合は、ボリューム マウント ポイントを使用する必要があります。ドライブ文字とは、パーティションやディスクを認識するための、MS-DOS オペレーティング システムから受け継いだ機能であるので、ドライブ文字を多用しないことをお勧めします。ボリューム マウント ポイントにすべてのトランザクション ログとデータベース LUN を配置する方がはるかに簡単で、管理も容易になります。20 個のストレージ グループがあり、それぞれにデータベースがある場合、どのドライブ文字にデータベース 17 が格納されているかを判断することは困難です。次の表に、ボリューム マウント ポイントの使用例を示します。

ボリューム マウント ポイントを使用したフォルダ レイアウトの例

トランザクション ログ (L:)	データベース (P:)
L:\SG1LOG	P:\SG1DB
L:\SG2LOG	P:\SG2DB
L:\SG3LOG	P:\SG3DB
L:\SG4LOG	P:\SG4DB

この例では、L: および P: は、すべてのログの LUN とデータベース LUN をそれぞれ格納するアンカー LUN です。これらのドライブの各フォルダは、別の LUN へのボリューム マウント ポイントです。

ハードウェア ベースの VSS

ハードウェア ベースの VSS を使用する場合は、LUN への Exchange データの配置に関していくつかの推奨事項があります。ハードウェア ベースの VSS ソリューションでは、各トランザクション ログ LUN とデータベース LUN には、選択したバックアップ セットからのファイルのみを格納してください。他のストレージ グループに影響を与えずにストレージ グループを復元するには、ストレージ グループごとに個別のトランザクション ログ LUN とデータベース LUN が必要になります。1 つのデータベースを復元するために他のデータベースやストレージ グループをオフラインにしてもかまわない場合は、複数のストレージ グループを単一のトランザクション ログ LUN とデータベース LUN に配置できます。

ソフトウェア ベースの VSS

ソフトウェア ベースの VSS を使用する際に、大容量のメールボックスがあり、連続レプリケーションを利用する場合は特に、バックアップを 2 つの手順で実行します。最初に VSS スナップショットを作成してから、フラット ファイルをディスクまたはテープにストリーム出力します。

LUN の信頼性

ストレージ グループのトランザクション ログとデータベースをそれぞれ別の物理ディスクに配置することは常に重要です。このようにすれば、信頼性が向上するからです。連続レプリケーションでは、アクティブ LUN とパッシブ LUN を完全に別の記憶域に分離することも重要です。CCR と LCR では、プライマリ記憶域の致命的な障害が発生した場合に記憶域の回復性が必要になります。

LUN の例

次のシナリオについて考えます。このシナリオは、前の容量の例に基づいて構築されたもので、その情報を LUN の作成に適用します。この例では、バックアップ処理は毎日の完全バックアップです。コンテンツ インデックス処理を有効にして、データベース LUN に配置するとします。193 GB の 5% は約 10 GB です。これを最終的な LUN のサイズに追加します。193 GB に対する増加要素は、最終的なデータベース サイズの 20% です。193 GB の 20% は 39 GB となります。結果を次の表に示します。

データベース LUN サイズを決定するための値の例

データベースのサイズ	増加要素	コンテンツ インデックス処理	データベース LUN のサイズ
193 GB	39 GB	10 GB	241 GB

各ストレージ グループでは 1 日に 7.13 GB のログが作成されます。また、少なくとも 3 日分のログを保存するという要件があります。

ログ LUN サイズを決定するための値の例

ログ (1 日)	ログ (3 日)
7.13 GB	21.4 GB

メールボックスの移動

この例の組織では、1 週間にメールボックスの 10% を移動しますが、移動はすべて土曜日に実行します。そのため、ログ LUN は、負荷全体を 1 日で処理する必要があります。Microsoft で使用されるメールボックスの移動戦略は、接続するユーザーを、各ストレージ グループ全体で均等に分散することです。つまり、この例のサーバーのユーザー数が 4,000 人ならば、約 400 人のユーザーを毎週土曜日に移動することになります。ストレージ グループが 23 個ならば、次の表に示すように、各ストレージ グループは 1 GB のメールボックスを 17 個受け取る必要があります。

移動するメールボックスのログ LUN サイズを決定するための値の例

ログ (3 日)	メールボックスの移動	ログ LUN のサイズ
21.4 GB	17.64 GB (1 GB ユーザー 17 人)	46.6 GB (38.8 GB + 20%)

このレイアウトでは、1 つのストレージ グループに移動するユーザーの数は 1 日に 17 人までとなります。したがって、1 日で 10% 以上を移動する必要に備えて、ログ LUN のサイズを大きくしておくと合理的です。

記憶域設計に対する連続レプリケーションの影響

連続レプリケーションは、ストレージ グループのデータベースとログ ファイルが 2 番目の場所にコピーされる Exchange 2007 の新機能です。新しいトランザクション ログが閉じられるかいっぱいになると、2 番目の場所にコピーされ、検証されてから、再生されてデータベースのパッシブ コピーに反映されます。記憶域を復元できるようにするため、パッシブ コピーは稼働中の運用 LUN から完全に分離された記憶域アレイに置くことをお勧めします。障害の発生時には、パッシブ コピーに依存して運用環境の負荷を処理するため、その記憶域は、ストレージ グループのアクティブなコピーで使用されるストレージ ソリューションのパフォーマンスと容量に一致する必要があります。

連続レプリケーションを使用する場合は、1 つのストレージ グループに 1 つのデータベースしか入れることができません。したがって、データベースのコピー 1 つにつき 4 つの LUN が必要です。データベースの各コピーは独自のストレージ グループに入り、アクティブ コピー用の異なるログとデータベース LUN、およびパッシブ コピー用の異なるログとデータベース LUN を必要とします。

以下にベスト プラクティスを示します。

• 記憶域は、オペレーティング システム内で LUN の複数の論理パーティションを作成するのではなく、ハードウェア レベルで個々の LUN に分割します。
• フォールト トレランスを向上させるため、トランザクション ログとデータベースを異なる物理ディスクに置きます。
• アクティブな LUN とパッシブ LUN をまったく異なる記憶域アレイに分離し、記憶域が単一障害点にならないようにします。
• 複数のクラスタ化メールボックス サーバーからのストレージ グループまたはデータベースを同じ記憶域アレイ上でホストする場合は、LUN をそれぞれ異なる物理ディスクを使用して構築します。

また、記憶域設計では、フォールト トレランスを最大化するため、記憶域コントローラを異なる Peripheral Component Interconnect (PCI) バスに分離します。さらに、容量とパフォーマンスの点でアクティブ コピーで使用される記憶域に一致するように、パッシブ コピー用の記憶域を設計します。アクティブ コピーの記憶域に致命的な障害が発生した場合、パッシブ コピーの記憶域が最も重要な防御部分となり、フェールオーバーの際にはパッシブ コピーがアクティブ コピーになります。パッシブ コピーの LUN をまったく異なる記憶域ハードウェアに置くと、アクティブ コピーはパッシブ コピーに対して行われたアクションの影響を受けることはありません。

連続レプリケーションを使用すると、トランザクション I/O は増加します。この要因は、サーバーのサイジングの際に考慮に入れる必要があります。シーケンシャルな書き込みであるアクティブなトランザクション ログでは、ログを閉じた後にもログを読み取り、レプリカ トランザクション ログ LUN 検疫フォルダにコピーする必要があります。その後、ログはレプリカの場所で検査され、レプリカ LUN の最終的な格納先に移動されます。最後にログは読み取られ、データベースに再生されます。アクティブおよびレプリカのトランザクション ログ LUN では、スタンドアロンのメールボックス サーバーで行われるほぼ 100% のシーケンシャルな書き込み処理に対して読み取りと書き込みを行う必要があります。このように動作が変更することから、記憶域コントローラのキャッシュ設定の評価が必要になる可能性があります。推奨設定は、バッテリー バックアップ付きの記憶域コントローラで読み取り 25%、書き込み 75% です。

連続レプリケーションとデータベース サイズ

連続レプリケーションを使用すると、最大データベース サイズがさらに拡大する可能性があります。Exchange 2007 では、次の最大データベース サイズを使用することをお勧めします。

• 連続レプリケーションを使用しないメールボックス サーバーでホストされるデータベース :100 GB

• 連続レプリケーションとギガビット イーサネットを使用するメールボックス サーバーでホストされるデータベース :200 GB

  注 :
  大規模なデータベースでは、修復時のシナリオに対応できるように、より帯域幅の広い、新しいストレージ テクノロジが必要になる場合もあります。

  重要 :
  データベースの真の最大サイズは、組織で導入されている SLA によって決まります。組織の SLA で指定された期間内にバックアップおよび復元できる最大のサイズを計算することで、データベースの最大サイズが決まります。

LCR 記憶域オプション

LCR を使用すると、1 台のサーバーでログ配布を行うことができます。データベースまたはログ ファイルのアクティブ コピーを格納している記憶域に致命的障害が発生した場合、管理者はデータベースのパッシブ コピーを手動でアクティブ化できます。パッシブ コピー用の記憶域は、アクティブ コピー用の記憶域とは完全に分離します。さらに、以下のことに注意してください。

• コントローラ カードは異なる PCI バスに装着します。
• 各ストレージ ソリューションには、独自の無停電電源装置 (UPS) を用意します。
• 各ストレージ ソリューションは、異なる電源回路上に配置します。

CCR 記憶域オプション

CCR を使用すると、アクティブまたはパッシブのフェールオーバー クラスタのパッシブ ノードにログ配布を行うことができます。まったく異なるサーバーにログを配布し、そのサーバーにパッシブ コピーを保持すると、アクティブ ノードの運用上の影響は減少し、サーバーへのフォールト トレランスが実現されます。

CCR の展開が地理的に分散されている場合、パッシブ コピーはアクティブ ノートとは物理的に異なる場所にあるノードに置き、サイトの復元を可能にすることができます。Exchange Server の複数サイトへのデータ レプリケーションに関する展開ガイドラインの記事 (このサイトは英語の場合があります) の情報はまだ適用されますが、連続レプリケーションの背後にあるプル ベースのテクノロジでは、待機時間の長さがユーザーの操作性に影響しません。これは、同期レプリケーションの待機時間の長さがアクティブなサーバーに悪影響を与える、物理的に分散されているクラスタ ソリューションとは対照的です。CCR では、レプリケーション処理は背後で実行されることがあるため、アクティブ コピーとパッシブ コピーが同期していない時間が増えます。ただし、アクティブ コピーに障害が発生した場合、ハブ トランスポート サーバーのトランスポート収集機能のため、パッシブ ノードにレプリケートされていないメッセージは回復可能です。

シングル コピー クラスタ記憶域のオプション

SCC に使用されるハードウェアは、Windows サーバー カタログのクラスタ分類に記載されている必要があります。地理的に分散されている SCC に使用されるハードウェアは、Windows サーバー カタログの Geographically Dispersed Cluster カテゴリに記載されている必要があります。

共有記憶域を使用するクラスタ化メールボックス サーバーでは、スタンドアロン サーバーと同じように、基本的な記憶域に関して考慮する必要があります。同期レプリケーションを使用すると、ディスクの待機時間はレプリケーション処理により不自然に増加することがあります。記憶域アレイ内でレプリケーションを最大にするには、注意が必要です。SCC のレプリケーションの詳細については、Exchange Server の複数サイトへのデータ レプリケーションに関する展開ガイドラインの記事を参照してください (このサイトは英語の場合があります)。

参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。