高可用性の要因について

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

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

高可用性メールボックス サーバーおよびデータベース アーキテクチャを計画する際は、以下の設計に関する決定事項について考慮する必要があります。

• 複数のデータベース コピーを展開するかどうか

• 展開するデータベース コピーの数

• サイト復元を提供するアーキテクチャにするかどうか

• 展開するメールボックス サーバー復元モデルの種類

• 展開するメールボックス サーバーの数

• データベース コピーの配信方法

• 使用するバックアップ モデル

• 使用するストレージ アーキテクチャ

Microsoft Exchange Server 2010 により、スタンドアロンのメールボックス サーバーか、もしくはメールボックス復元用に構成された複数のメールボックス サーバーを使用して、メールボックス サーバー インフラストラクチャを展開することができます。メールボックス復元用に構成されたメールボックス サーバーでは、データベース可用性グループ (DAG) に複数のデータベース コピーが含まれ、DAG を通じて効率的に配布されます。複数のデータベース コピーを展開することによって、以下が可能になります。

• バックアップ使用の最も一般的な原因を減らすソリューションを設計します。データベース コピーは、ハードウェア、ソフトウェア、およびデータ センターの障害に対する保護を提供します。

• 回復機構は別のデータベース コピーであり、バックアップからの復元ではないため、データベース サイズを最大 2 テラバイトまで増やします。

• 3 つ以上のデータベース コピーを展開する場合は、JBOD (Just a Bunch of Disks) のような従来の RAID に代わるストレージ アーキテクチャを検討します。JBOD と、より低価格のディスクの組合せによって、組織のコストを削減することができます。

DAG 内に参加するすべてのサーバーにアクティブ データベースを配布することによって、ハードウェアの効率を最大限に高めることができます。

詳細については、「高可用性とサイト復元の計画」および「バックアップ、復元、および障害復旧について」を参照してください。

目次

展開するデータベース コピーの数の計画

データベース コピーの種類

サイトの復元

メールボックス サーバー復元の計画

展開するメールボックス サーバーの数の計画

データベース コピー レイアウトの計画

バックアップ モデル アーキテクチャの計画

ストレージ モデル アーキテクチャの計画

高可用性に関連する管理タスクについては、「高可用性とサイト復元の管理」を参照してください。

展開するデータベース コピーの数の計画

「メールボックス データベース コピーについて」で説明しているように、製品の Enterprise Edition では、DAG メンバーはサーバーごとに最大 100 まで (アクティブ コピーとパッシブ コピーの両方を合わせた数) のデータベースによって、メールボックス データベースごとに 1 つのコピーをホストできます。つまり、16 のメンバーが属する DAG では、最大で 1,600 (100 データベース コピー/サーバー × 16 サーバー/DAG ÷ 1 コピー/データベース = 1,600 データベース/DAG) のデータベースがサポートされます。

高可用性構成では、単一コピーの展開では冗長性を確保できないため、価値がありません。数式を使用して、特定の DAG がサポートできるデータベースの数を決定します。たとえば、D を展開するデータベースの数、C を各データベースのコピーの数、S をサーバーの数とすると、以下が成り立ちます。

• D × C = DAG 内のデータベース コピーの合計数

• (D × C) ÷ S = サーバーごとのデータベース コピーの数

たとえば、6 台のサーバーと 84 のデータベース コピー、データベースごとに 3 つのコピーがある DAG を想定します(サーバー数 6 は、コピー数 3 の倍数です)。以下が成り立ちます。

• 84 データベース × 3 コピー = 合計 252 データベース

• 252 データベース ÷ 6 サーバー = 42 データベース コピー/サーバー

別の例では、4 台のサーバーと 136 のデータベース コピー、データベースごとに 3 つのコピーがある DAG を想定します。以下が成り立ちます。

• 136 データベース × 3 コピー = 合計 408 データベース

• 408 データベース ÷ 4 サーバー = 102 データベース コピー/サーバー

102 は 100 よりも大きいので、このシナリオは DAG 設計としては有効ではありません。

ページのトップへ

データベース コピーの種類

データベース コピーには、次の 2 種類があります。

• 高可用性データベース コピー

• 時間差データベース コピー

高可用性データベース コピーは、再生ラグ タイムをゼロとして構成したコピーです。その名前が示すとおり、高可用性データベース コピーはシステムによって最新の状態に維持され、システムが自動的にアクティブ化することができ、メールボックスのサービスとデータの高可用性を提供するために使用されます。

時間差データベース コピーは、一定期間トランザクション ログの再生を遅らせるように構成されたコピーです。時間差データベース コピーは、特定の時点の保護を行うように設計されており、ストアの論理的破損、管理エラー (たとえば、接続を解除されたメールボックスの削除や破棄)、および自動化エラー (たとえば、接続を解除されたメールボックスの一括破棄) からの回復に使用できます。

通常は、アクティブ マネージャーの最適なコピーの選択アルゴリズムにより、時間差データベース コピーはアクティブ化されていません。時間差データベース コピーは、操作上のリスクを軽減するために展開されるため、アクティブ化すべきではありません。時間差データベース コピーをアクティブ化し、マウント要求が発行された場合、ログ再生が開始し、データベースを最新のクリーン シャットダウン状態にするために必要なすべてのログ ファイルが再生されるため、特定時点の保護の機能が失われます。

メールボックス サーバーのレベルでアクティブ化をブロックする方法、1 つ以上のデータベース コピーのアクティブ化を中断してデータベース コピー (時間差データベース コピーなど) が自動的にアクティブ化されるのを回避する方法については、「Set-MailboxServer」および「Suspend-MailboxDatabaseCopy」を参照してください。

ページのトップへ

サイトの復元

環境が複数のデータ センターから成る場合があります。Exchange 2010 の設計の一環として、Exchange インフラストラクチャを単一のデータ センターに展開するか、2 つ以上のデータ センターに分散するかを決定します。組織のサービス レベル契約 (SLA) で、プライマリ データ センターの障害時に必要とされるサービスのレベルを定義します。

Exchange 展開が、サイトの復元の目標をサポートするために複数のデータ センターにまたがって行われる場合は、どのユーザー分散モデルを使用するかを検討します。ユーザー分散モデルには、データ センターに対するメールボックスの場所に基づいて、次の 2 種類があります。

• アクティブ/パッシブ ユーザー分散モデル

• アクティブ/アクティブ ユーザー分散モデル

ユーザーのメールボックスが主に単一のデータ センターにある場合 (またはユーザーが各自のデータに単一のデータ センターを通じてアクセスする場合)、かつ、ユーザーが通常の操作時にプライマリ データ センターを介して各自のデータに継続してアクセスする SLA 要件がある場合、お使いのアーキテクチャはアクティブ/パッシブ ユーザー分散モデルです。

ユーザーのメールボックスが複数のデータ センターに分散していて、ユーザーが通常の操作時にプライマリ データ センターを介して各自のデータに継続してアクセスする SLA 要件がある場合、お使いのアーキテクチャはアクティブ/アクティブ ユーザー分散モデルです。

アクティブ/パッシブ ユーザー分散モデルでは、次の図に示すようにアーキテクチャを展開できます。ここでは、アクティブ メールボックスはプライマリ データ センターからホストされていますが、データベース コピーはセカンダリ データ センターに展開されています。

2 つのデータ センターを使用したアクティブ/パッシブ ユーザー分散モデル

次の図に示すアーキテクチャは、アクティブ/アクティブ ユーザー分散モデルに使用することが可能です。

2 つのデータ センターを使用したアクティブ/アクティブ ユーザー分散モデル

ただし、上記の図に示すアーキテクチャにはリスクがあります。広域ネットワーク (WAN) は、DAG の単一障害点となります。WAN の障害により、セカンダリ データ センターの DAG メンバーのクォーラムの消失が発生します。この例では、Windows は合計 5 つの票 (4 DAG メンバーと監視サーバー) を持ち、フェイルオーバー クラスターの動作を保つために、常に 3 つの票が必要になります。票のうち 3 つは Redmond データ センターにあり、2 つは Portland データ センターにあります。WAN 接続が失われると、Portland データ センターは 2 つの票しかホストしていないため、クォーラムを維持するには足りません。Redmond データ センターには 3 つの票があるため、クォーラムを維持し、(この 3 つの票が動作している限り) アクティブ メールボックスのサービスを継続することができます。

アクティブ/アクティブ ユーザー分散モデルのこのリスクを軽減するためには、次の図に示すように 2 つの DAG を展開することをお勧めします。

アクティブ/アクティブ ユーザー分散モデル用の 2 つの DAG

DAG1 は、Redmond データ センターのアクティブ メールボックスをホストし、パッシブ データベース コピーを Portland データ センターに展開するアクティブ/パッシブ ユーザー分散モデルとして実装されています。DAG2 は、Portland データ センターのアクティブ メールボックスをホストし、パッシブ データベース コピーを Redmond データ センターに展開するアクティブ/パッシブ ユーザー分散モデルとして実装されています。

このアーキテクチャでは、以下のように WAN の障害を切り抜けることができます。

• Redmond データ センターでは、DAG2 のメールボックス サーバー メンバーがクォーラムの消失によりエラー状態になりますが、DAG1 のアクティブなメールボックス サーバー メンバーは動作を保ち、ユーザーにサービスを提供します。

• Portland データ センターでは、DAG1 のメールボックス サーバー メンバーがクォーラムの消失によりエラー状態になりますが、DAG2 のアクティブなメールボックス サーバー メンバーは動作を保ち、ユーザーにサービスを提供します。

詳細については、「高可用性とサイト復元の計画」を参照してください。

ページのトップへ

メールボックス サーバー復元の計画

Exchange 2010 メールボックス サーバーの容量を計画する上で重要な点は、サーバーをメールボックスの復元用に構成する場合に、サーバー 1 台ごとにアクティブにするデータベース コピーの数を決定することです。さまざまな範囲の設計が可能ですが、以下のセクションで説明する 2 つのモデルをお勧めします。

すべてのデータベース コピーをアクティブにする設計

アクティブになるホストされたデータベース コピーすべてを 100% 処理するようにサーバー アーキテクチャを設計できます。たとえば、サーバーが 35 のデータベース コピーをホストする場合、ユーザー操作のピーク時間中にアクティブになる 35 のデータベースすべてを収容するようにプロセッサおよびメモリを設計します。このソリューションは、通常はペアで展開されます。たとえば、4 台のサーバーを展開する場合、1 番目のペアはサーバー 1 と 2、2 番目のペアはサーバー 3 と 4 となります。また、このシナリオの設計では、各サーバーの通常実行時の動作を想定して、使用可能なリソースが 40% 未満となるようにサーバーのサイズを設定します。

本トピックに記載する 2 つのモデルのうち、このモデルの方がより多くの数のサーバーを必要とします。

対象とする障害シナリオ用の設計

対応を計画する最悪の障害例においてアクティブなメールボックス負荷を処理するようにサーバー アーキテクチャを設計します。このモデルでは、サイトの復元、RAID ストレージと JBOD のどちらを採用するか、DAG のサイズ、データベース コピーの数など多くの要素を考慮します。この容量計画モデルでは、資本コスト、可用性、およびクライアント パフォーマンス特性のバランスを実現します。

データベース コピーが無作為かつ均等に分散されていると仮定します。

• メールボックス データベースごとに 2 つの高可用性データベース コピーを持つ、2 台または 3 台のメンバーを含む DAG 構成における、自動の単一メンバー サーバー障害に対する設計を行います。

• メールボックス データベースごとに 3 つの高可用性データベース コピーを持つ、3 台のメンバーを含む DAG 構成における、二重メンバー サーバー障害 (第 2 の障害後の手動アクティブ化) に対する設計を行います。

• メールボックス データベースごとに 3 つ以上の高可用性データベース コピーを持つ、4 台以上のメンバーを含む DAG 構成における、自動の二重メンバー サーバー障害に対する設計を行います。

この容量計画モデルを選択する場合、単一のサーバーが過負荷状態になりクライアントの操作性が低下することがないように、サーバーごとにアクティブ化できるデータベースの数を制限することを強くお勧めします。

データベースの数を制限するには、最大アクティブ データベース設定を構成します。この設定は Exchange 管理シェルで Set-MailboxServer -MaximumActiveDatabases を実行することによって構成できます。この展開においてサポートされる最大アクティブ データベースに一致するように、DAG 内の各サーバー上でこの制限を構成します。

詳細については、「データベース可用性グループの設計例」を参照してください。

ページのトップへ

展開するメールボックス サーバーの数の計画

展開するメールボックス サーバーの数を決定する際は、展開するデータベース コピーの数の倍数を使用します。たとえば、3 つのデータベース コピーを展開するよう計画している場合は、3、6、9、12、または 15 のいずれかの数のサーバーで設計を開始します。

最初に DAG 内のサーバー数を決定した後、メールボックス数や障害設計モデル、必要となるメールボックス サーバー数の増減の要因となる他の設計上の制約に基づいて、DAG メンバーの規模を決定します。

多くの組織が抱える設計上の制約は、サーバー上に配置できる最大メールボックス数です。たとえば、組織内に 20,000 のメールボックスがあり、障害時に 25% しか影響を受けない場合、単一のサーバーに展開できる最大メールボックス数は 5,000 です。この場合、少なくとも 4 台のメールボックス サーバーの展開が必要となります。

選択したサーバーおよびストレージのモデルによっても、サーバーごとに展開するメールボックス数やデータベース コピー数の調整が必要になり、メールボックス サーバーの合計数に影響することがあります。

複数の役割を持つサーバーとスタンドアロンの役割を持つサーバー

Exchange Server 2007 では、クラスター化メールボックス サーバーとは別のサーバー上に、クライアント アクセス サーバーおよびハブ トランスポート サーバーの役割が必要です。Exchange 2010 ではクラスター化メールボックス サーバーは存在しないため、この制限は適用されません。クライアント アクセス サーバーおよびハブ トランスポート サーバーの役割は、DAG メンバー上でホストすることができ、強化された展開オプションを提供します。

複数の役割を持つサーバー (同一サーバー上のメールボックス サーバー、クライアント アクセス サーバー、およびハブ トランスポート サーバーの役割) を展開すると、ほとんどのアーキテクチャは単純化されます。エッジ トランスポート サーバーおよびユニファイド メッセージング サーバーを除いて、すべての Exchange 2010 サーバーを同一にできます。これらのサーバーは、同一のハードウェア、ソフトウェア インストール プロセス、および構成オプションにより構成することができます。サーバー間で整合性を持たせることにより、Exchange の実装の管理が容易になります。

複数の役割を持つサーバー (大規模の環境において) にでは、多数のコアを持つサーバーをより効率的に使用でき、これにより高メガサイクルの性能を利用できます。それぞれの役割を個別に展開した場合、推奨される最大搭載プロセッサ ソケット数は 2 です。役割を組み合わせた場合には、最大搭載プロセッサ ソケット数は 4 になります。サーバーはより高い負荷に対応できるため、組織内全体のサーバー数を削減できます。展開するサーバー数を少なくすることで、サーバーの管理コストが削減されます。これは、複数の役割を持つサーバーにより、繰り返し発生する運用経費が 1 回限りの資本経費に変わるためです。サーバー数の削減は、消費電力、冷却コスト、データ センターのスペースの削減につながり、繰り返し発生する運用経費をさらに削減することができます。

複数の役割の概念は効率的ですが、スタンドアロン サーバーの役割が適切な場合もあります。たとえば、スタンドアロンの役割の展開は、特定の仮想環境において、または特定のハードウェア アーキテクチャ (たとえば、ハードウェアを適切に分離できないブレード サーバー インフラストラクチャ) を利用する際などに適切な場合があります。

複数の役割を持つサーバーを展開する場合は、プロセッサおよびメモリのアーキテクチャを適切に設計する必要があります。プロセッサの観点からは、障害モードにおいてメールボックス サーバーの役割が使用可能なメガサイクルの 40% 以上を消費しないようにして、40% をハブ トランスポート サーバーおよびクライアント アクセス サーバー用に残しておく必要があります。すべてのサーバーの役割で利用するのに十分なメモリを確保するには、「メールボックス データベース キャッシュについて」で定義されているメモリのガイダンスに従ってください。

詳細については、「容量計画での複数のサーバーの役割の構成について」を参照してください。

ページのトップへ

データベース コピー レイアウトの計画

高可用性設計の一環として、バランスの取れたデータベース コピー レイアウトを設計する必要があります。データベース コピー レイアウトを設計する際は、以下の設計原則を使用してください。

• 特定のメールボックス データベースの複数のデータベース コピーの障害を、各コピーを分離することにより最小化します。たとえば、同じサーバー ラックまたは同じストレージ アレイ内に特定のメールボックス データベースの複数のデータベース コピーを置かないようにします。そうしないと、ラックまたはアレイの障害により、同じデータベースの複数のコピーの障害につながることがあります。

• データベース コピーを整合性の取れた分散した形でレイアウトし、アクティブ メールボックス データベースが障害後に均等に分散されるようにします。特定のサーバー上の各データベース コピーのアクティブ化優先順位の合計は、等しいか、ほぼ等しくする必要があります。これにより、レプリケーションが正常で最新であると仮定して、障害後のほぼ均等な分散が行われるためです。

詳細については、「データベース コピー レイアウトの設計」を参照してください。

ページのトップへ

バックアップ モデル アーキテクチャの計画

Exchange 2010 には、いくつかの機能およびアーキテクチャの変更が含まれています。正しく展開および構成された状態でネイティブ データ保護機能を使用すると、従来のデータのバックアップが不要になります。以下の表を使用して、従来のバックアップ モデルを継続して利用する必要があるか、Exchange 2010 のネイティブ データ保護機能を実装できるかを判断します。

論理的破損は、特定時点のバックアップが必要となる典型的なシナリオです。しかし、Exchange 2010 では、特定時点のバックアップの必要性を低減できるいくつかのオプションが使用可能です。

• 単一アイテムの回復では、ユーザーがメールボックス フォルダー内のアイテムの特定のプロパティを変更すると、変更内容がデータベースに書き込まれる前に、アイテムが回復可能なアイテム フォルダーに保存されます。メッセージの変更によりコピーが破損した場合は、元のアイテムを復元できます。

• 予定表修復アシスタントは、メールボックス サーバーをホームにしているメールボックスの 1 回または定期的な予定表アイテムの不整合を自動的に検出して修正し、受信者が会議の案内を見過ごしたり、あるいは信頼性の低い会議の情報を得たりしないようにします。

• メールボックスの移動中に、Microsoft Exchange メールボックス レプリケーション サービスにより破損したアイテムが検出され、それらのアイテムを移動先のメールボックス データベースに移動しないようにします。

• Exchange 2010 Service Pack 1 (SP1) では、New-MailboxRepairRequest コマンドレットが導入され、検索フォルダー、アイテム数、フォルダー ビュー、および親/子フォルダーの問題による破損を修正できます。

特定時点のバックアップは、従来のバックアップまたは時間差データベース コピーのいずれかが可能で、両方とも同じ機能を提供します。2 つの間でどちらを選ぶかは、回復 SLA によって異なります。回復 SLA は、目標回復ポイント (障害発生時に、データを特定の時間内に復元する必要があります)、およびバックアップを保持する期間を指定します。回復 SLA が 14 日以下の場合は、時間差データベース コピーを使用できます。回復 SLA が 14 日を超える場合は、従来のバックアップを使用する必要があります。不正な管理者、および企業または規制準拠のシナリオでは、特定時点のバックアップは通常、メッセージング インフラストラクチャおよびメッセージング IT スタッフから分離して保持されるため、従来のバックアップ ソリューションを使用します。

特定時点のバックアップを保持することを選択した場合は、設計のいくつかの側面が変化する可能性があります。

• 時間差データベース コピーの展開は、ストレージに影響を与えます。ReplayLagTime 設定によって、時間差データベース コピー上のトランザクション ログに追加の領域を割り当てる必要があります。また、時間差データベース コピーの配置は、ストレージ アーキテクチャにも影響する可能性があります(詳細については、このトピックに記載されている「ストレージ モデル アーキテクチャの計画」を参照してください)。

• 従来のバックアップ ソリューションの展開は、ボリューム シャドウ コピー サービス (VSS) の種類によって、論理ユニット番号 (LUN) のレイアウトに影響します。これは、ハードウェア ベースの VSS 複製ソリューションで、データベース アーキテクチャごとに 2 つの LUN が必要になるためです。

ストレージ アーキテクチャによっては、従来のバックアップ ソリューションの使用する際に、バックアップおよび復元の保存期間 SLA を満たすために、目的のユーザー メールボックス サイズの大幅な削減が必要になる場合があります。

Exchange ネイティブ データ保護を展開する場合は、メールボックス データベースで循環ログを有効にします。循環ログを有効にする際は、ログの切り捨てが行われない障害が発生した場合にこのソリューションが耐えられるように、システムに十分な容量が組み込まれていることを確認してください。最低でも、3 日以上のトランザクション ログの容量 (時間差コピーの要件を除く) を確保する必要があります。連続レプリケーションでの循環ログの機能の詳細については、「バックアップ、復元、および障害復旧について」を参照してください。

バックアップの計画に関する追加情報については、以下を参照してください。

• Exchange 2010 LUN のアーキテクチャについて

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

• 予定表修復について

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

ページのトップへ

ストレージ モデル アーキテクチャの計画

Exchange 2010 では、ストレージの設計が柔軟に行えます。Exchange 2010 には、組織がさまざまなストレージ デバイスで Exchange を実行できるようにするための、パフォーマンス、信頼性、および高可用性の強化が含まれています。Exchange 2007 で導入されたディスク入出力 (I/O) の機能強化を基にして、最新バージョンの Exchange では、より低いストレージ性能でも、より高いストレージ障害耐性を実現できます。

容量要件と I/O 要件のバランスが取れるストレージ プラットフォームを選択し、ソリューションにより許容可能なディスクの待ち時間と迅速なユーザーの操作性を提供できるようにします。

RAID または JBOD

RAID テクノロジまたは JBOD アプローチ (ストレージ プラットフォームで JBOD 構成を使用できることが前提) を使用してストレージ プラットフォームを実装するかどうかを決定します。Exchange の観点からは、JBOD の使用は、データベースおよびその関連付けられたログの両方が単一のディスクに格納されることを意味します。JBOD に展開するには、少なくとも 3 つの高可用性データベース コピーを展開する必要があります。単一ディスクの使用は、ディスクに障害が発生するとそのディスク上のデータベース コピーが失われるため、単一障害点となります。最低 3 つのデータベース コピーを持つことにより、1 つのコピー (またはディスク) で障害が発生した場合に他の 2 つのコピーによってフォールト トレランスが可能になります。ただし、3 つの高可用性データベース コピーの配置は、時間差データベース コピーの使用と同様、ストレージの設計に影響します。以下の表は、RAID または JBOD に関する考慮事項のガイドラインを示します。

RAID または JBOD に関する考慮事項

プライマリ データ センター サーバーで JBOD 上に展開するには、DAG 内に 3 つ以上の高可用性データベース コピーが必要です。高可用性データベース コピーをホストしているサーバーと同じサーバー上で時間差コピーを混在させる場合 (たとえば、専用の時間差データベース コピー サーバーを使用しない場合) には、少なくとも 2 つの時間差データベース コピーが必要になります。

セカンダリ データ センター サーバーで JBOD を使用するには、セカンダリ データ センターに少なくとも 2 つの高可用性データベース コピーが必要です。セカンダリ データ センターのコピーを失っても、WAN を通じて再シードする必要が生じたり、セカンダリ データ センターをアクティブ化する場合に単一障害点になったりすることはありません。高可用性データベース コピーをホストしているサーバーと同じサーバー上で時間差データベース コピーを混在させる場合 (たとえば、専用の時間差データベース コピー サーバーを使用しない場合) には、少なくとも 2 つの時間差データベース コピーが必要になります。

専用の時間差データベース コピー サーバーでは、JBOD を使用するにはデータ センター内に少なくとも 2 つの時間差データベース コピーが必要です。データベース コピーが足りない場合、ディスクの障害により時間差データベース コピーおよび保護メカニズムが失われます。

詳細については、「格納域の構成について」を参照してください。

ページのトップへ

 © 2010 Microsoft Corporation.All rights reserved.