高可用性とサイトの復元計画

製品: Exchange Server 2013

計画段階では、システム設計者、管理者、その他の主な関係者は、展開のビジネス要件とアーキテクチャ要件 (特に、高可用性とサイトの復元性に関する要件) を把握することが求められます。

これらの機能を展開するために満たす必要がある一般的な要件と、ハードウェア、ソフトウェア、ネットワークの要件も満たす必要があります。

一般的な要件

データベース可用性グループ (DAG) の展開およびメールボックス データベース コピーの作成の前に、以下のシステム全体に関わる推奨事項が満たされていることを確認します。

• ドメイン ネーム システム (DNS) が実行されている必要があります。 通常は、この DNS サーバーで、動的更新を受け付けるように設定しておくことをお勧めします。 DNS サーバーが動的更新を受け付けない場合は、Exchange サーバーごとに DNS ホスト (A) レコードを作成する必要があります。 このレコードを作成しないと、Exchange は正常に動作しません。
• DAG 内の各メールボックス サーバーは、同じドメインのメンバー サーバーである必要があります。
• ディレクトリ サーバーでもある Exchange 2013 メールボックス サーバーを DAG に追加することはサポートされていません。
• DAG に割り当てる名前は、15 文字以内の、有効で、使用可能な一意のコンピューター名である必要があります。

ハードウェア要件

一般に、DAG またはメールボックス データベース コピーに固有の特別なハードウェア要件はありあません。 使用するサーバーは、 Exchange 2013 の前提条件と Exchange 2013のシステム要件に関するトピックに記載されているすべての要件を満たしている必要があります。

格納域の要件

一般に、DAG またはメールボックス データベース コピーに固有の特別な格納域要件はありません。 DAG では、クラスター管理された共有格納域を必要とすることも、使用することもありません。 クラスターで管理される共有ストレージは、EXCHANGE 2013 に組み込まれているサード パーティレプリケーション API を使用するソリューションを使用するように DAG が構成されている場合にのみ、DAG での使用がサポートされます。

ソフトウェア要件

DAG は、Exchange 2013 Standard と Exchange 2013 Enterprise の両方で使用できます。 さらに、DAG には、Exchange 2013 Standard と Exchange 2013 Enterprise を実行しているサーバーを混在させることができます。

DAG の各メンバーも同じオペレーティング システムを実行している必要があります。 Exchange 2013 は、Windows Server 2008 R2、Windows Server 2012、および Windows Server 2012 R2 オペレーティング システムでサポートされています。 特定の DAG のすべてのメンバーは、同じオペレーティング システムを実行する必要があります。 Windows Server 2012 R2 は、Exchange 2013 Service Pack 1 以降を実行している DAG メンバーに対してのみサポートされます。

Exchange 2013 をインストールするための前提条件を満たすだけでなく、オペレーティング システムの要件を満たす必要があります。 DAG は Windows フェールオーバー クラスタリング テクノロジを採用しているため、Windows Server 2008 R2 の Enterprise または Datacenter バージョンか、Windows Server 2012 または Windows Server 2012 R2 オペレーティング システムの Standard または Datacenter バージョンが必要です。

ネットワーク要件

DAG ごとに、および DAG メンバーごとに満たす必要がある特定のネットワーク要件があります。 各 DAG には、DAG メンバーが他のサーバー (たとえば、他の Exchange 2013 サーバーやディレクトリ サーバー) と通信するために使用する 1 つの MAPI ネットワークと、ログ配布とシード処理専用のネットワークである 0 個以上の レプリケーション ネットワークが必要です。

以前のバージョンの Exchange では、DAG 用のネットワークを少なくとも 2 つ (MAPI ネットワーク用とレプリケーション ネットワーク用) 用意することをお勧めしていました。 Exchange 2013 では、複数のネットワークがサポートされていますが、推奨は物理ネットワーク トポロジによって異なります。 DAG メンバー間に物理的に分離された複数の物理ネットワークがある場合は、別の MAPI とレプリケーション ネットワークを使用すると、冗長性が高くなります。 部分的には物理的に分離されているものの、単一の物理ネットワーク (単一の WAN リンクなど) に収束している複数のネットワークが存在する場合は、MAPI とレプリケーションの両方のトラフィック用の単一の物理ネットワーク (10 ギガビット イーサネットを推奨) を使用することをお勧めします。 この方法では、ネットワークとネットワーク パスがわかりやすくなっています。

DAG のネットワーク インフラストラクチャを設計する場合は、次の要因を考慮してください。

• DAG の各メンバーには、他のすべての DAG メンバーとの通信を可能にする少なくとも 1 つのネットワーク アダプターが必要になります。 単一のネットワーク パスを使用する場合は、少なくとも 1 ギガビット以上のイーサネット、可能であれば、10 ギガビット イーサネットの使用をお勧めします。 さらに、各 DAG メンバーで単一のネットワーク アダプターを使用する場合は、単一のネットワーク アダプターとパスに考慮して、ソリューション全体を設計することをお勧めします。

• DAG メンバーごとに 2 つずつのネットワーク アダプターを使用すると、1 つの MAPI ネットワークと 1 つのレプリケーション ネットワーク、レプリケーション ネットワークの冗長性、および以下の回復動作が実現します。

  • エラーが MAPI ネットワークに影響を与える場合、サーバー のフェールオーバーが発生します (アクティブ化できる正常なメールボックス データベース のコピーがあると仮定します)。

  • エラーがレプリケーション ネットワークに影響する場合、MAPI ネットワークがエラーの影響を受けない場合、MAPI ネットワークの ReplicationEnabled プロパティが False に設定されている場合でも、ログ配布とシード処理の操作は MAPI ネットワークの使用に戻ります。 障害が発生したレプリケーション ネットワークが回復し、ログ配布とシード操作を再開できるようになったら、レプリケーション ネットワークを手動で切り替える必要があります。 MAPI ネットワークから回復したレプリケーション ネットワークにレプリケーションを変更するには、 Suspend-MailboxDatabaseCopy および Resume-MailboxDatabaseCopy コマンドレットを使用して連続レプリケーションを中断して再開するか、Microsoft Exchange Replication サービスを再起動します。 Microsoft Exchange Replication サービスの再起動による短時間の停止を防ぐため、中断と再開による操作をお勧めします。

• 各 DAG メンバーは、同じ数のネットワークを備える必要があります。 たとえば、1 つの DAG メンバー内で単一のネットワーク アダプターを使用するように計画する場合、DAG のすべてのメンバーも単一のネットワーク アダプターを使用する必要があります。

• 各 DAG には、複数の MAPI ネットワークが備えないようにする必要があります。 MAPI ネットワークは、他の Exchange サーバー、および Active Directory や DNS などのその他のサービスへの接続を提供する必要があります。

• 必要に応じて、さらにレプリケーション ネットワークを追加できます。 また、ネットワーク アダプター チームや同様のテクノロジを使用することで、個々のネットワーク アダプターが単一障害点になることを防止することもできます。 ただし、チーミングを使用する場合でも、このテクノロジによってネットワーク自体が単一障害点になるのを防ぐわけではありません。 その上、チームを使用すると DAG の複雑さが不要に増すことになります。

• 各 DAG メンバー サーバーの各ネットワークは、それぞれ独自のネットワーク サブネット上になければなりません。 DAG 内の各サーバーは異なるサブネット上に設定できますが、MAPI とレプリケーション ネットワークは、以下のようにルーティング可能で、接続を提供する必要があります。

  • 各 DAG メンバー サーバーの各ネットワークは、サーバーの他の各ネットワークが使用するサブネットとは別の独自のネットワーク サブネット上にあります。
  • 各 DAG メンバー サーバーの MAPI ネットワークは、他の各 DAG メンバーの MAPI ネットワークと通信できます。
  • 各 DAG メンバー サーバーのレプリケーション ネットワークは、他の各 DAG メンバーのレプリケーション ネットワークと通信できます。
  • 特定の DAG メンバーサーバーのレプリケーション ネットワークから別の DAG メンバー サーバーの MAPI ネットワークへ、その逆、あるいは DAG 内の複数のレプリケーション ネットワーク間のハートビート トラフィックを許可する直接ルーティングは存在しません。

• 他の DAG メンバーに対する地理的な場所に関係なく、DAG の各メンバーは、互いのメンバー間で 500 ミリ秒以下のラウンドトリップ ネットワーク待機時間を持つ必要があります。 データベースのコピーをホストする 2 つのメールボックス サーバー間のラウンドトリップ待機時間が長くなるにつれて、レプリケーションが最新でない可能性も高くなります。 ソリューションの待機時間に関係なく、お客様は、すべての DAG メンバー間のネットワークが、デプロイのデータ保護と可用性の目標を満たすことができることを検証する必要があります。 待ち時間の長い構成では、必要な目標を実現するために、DAG、レプリケーション、およびネットワーク パラメーターの特別な調整 (データベース数の増加、データベースあたりのメールボックス数の削減など) が必要になる場合があります。

• ラウンドトリップ待機時間の要件は、マルチデータセンター構成の最も厳しいネットワーク帯域幅と待機時間の要件ではない可能性があります。 クライアント アクセス、Active Directory、トランスポート、継続的レプリケーション、その他のアプリケーション トラフィックを含むネットワーク負荷の合計を評価して、環境に必要なネットワーク要件を決定します。

• DAG ネットワークでは、インターネット プロトコル バージョン 4 (IPv4) と IPv6 がサポートされています。 IPv6 は、IPv4 も使用されている場合にのみサポートされます。純粋な IPv6 環境はサポートされていません。 IPv6 アドレスと IP アドレス範囲の使用は、そのコンピューターで IPv6 と IPv4 の両方が有効になっていて、ネットワークが両方の IP アドレス バージョンをサポートしている場合にのみサポートされます。 Exchange 2013 がこの構成に展開されている場合、すべてのサーバー ロールは、IPv6 アドレスを使用するデバイス、サーバー、クライアントとの間でデータを送受信できます。

• 自動プライベート IP アドレス指定 (APIPA) は、Windows の機能の 1 つで、動的ホスト構成プロトコル (DHCP) サーバーがネットワーク上で利用できないときに自動的に IP アドレスを割り当てます。 APIPA アドレス (APIPA アドレス範囲から手動で割り当てられたアドレスを含む) は、DAG または Exchange 2013 で使用することはできません。

DAG 名と IP アドレスの要件

各 DAG には DAG の作成時に一意の名前が付けられ、1 つまたは複数の静的 IP アドレスが割り当てられるか、DHCP を使用するために構成されます。 使用するアドレスが静的または動的に割り当てられたものかに関係なく、DAG に割り当てられたすべての IP アドレスは MAPI ネットワーク上にある必要があります。

Windows Server 2008 R2 または Windows Server 2012 上で実行している各 DAG には、MAPI ネットワーク上に最低 1 つの IP アドレスが必要です。 MAPI ネットワークが複数のサブネットにまたがって拡張されている場合、DAG にはさらに多くの IP アドレスが必要です。 クラスターの管理アクセス ポイントを使用せずに作成された、Windows Server 2012 R2 上で動作している DAG には IP アドレスが必要ありません。

次の図は、DAG 内のすべてのノードが同じサブネット上に MAPI ネットワークを持つ DAG を示しています。

この例では、各 DAG メンバーの MAPI ネットワークは 172.19.18.*x_ サブネットにあります。 このため、DAG にはそのサブネット上に単一の IP アドレスが必要になります。

次の図は、172.19.18.*x_ と 172.19.19.*x_ の 2 つのサブネットにまたがる MAPI ネットワークを持つ DAG を示しています。

この例では、各 DAG メンバーの MAPI ネットワークは、別のサブネット上にあります。 このため、DAG には 2 つの IP アドレス (MAPI ネットワーク上の各サブネットに 1 つずつ) が必要になります。

DAG の MAPI ネットワークが別のサブネットに拡張されるたびに、そのサブネットのもう 1 つの IP アドレスを DAG 用に構成する必要があります。 DAG に対して構成される各 IP アドレスは、DAG の基になるフェールオーバー クラスターに割り当てられ、このクラスターによって使用されます。 DAG の名前は、基になるフェールオーバー クラスターの名前としても使用されます。

どのような時でも、DAG のクラスターは割り当てられた IP アドレスの 1 つのみを使用します。 Windows フェールオーバー クラスタリングは、クラスター IP アドレスとネットワーク名リソースがオンラインで接続されるときにこの IP アドレスを DNS に登録します。 IP アドレスとネットワーク名の使用以外に、Active Directory 内でクラスター名オブジェクト (CNO) が作成されます。 クラスターの名前、IP アドレス、CNO は、DAG のセキュリティ保護と内部通信のためにシステムによって内部的に使用されます。 管理者とエンドユーザーは、DAG 名または IP アドレスとインターフェイスしたり、接続したりする必要はありません。

DAG のネットワーク アダプターの構成

各ネットワーク アダプターは、その使用目的に基づいて正しく構成する必要があります。 MAPI ネットワークで使用するネットワーク アダプターは、レプリケーション ネットワークで使用するネットワーク アダプターとは別に構成します。 各ネットワーク アダプターを正しく構成するばかりでなく、MAPI ネットワークが接続順序の最上位になるように Windows でネットワーク接続の順序も構成する必要があります。 ネットワーク接続順序の変更方法の詳細手順については、「プロトコルのバインドとネットワーク プロバイダーの順序を変更する」を参照してください。

MAPI ネットワーク アダプターの構成

MAPI ネットワークで使用することを目的とするネットワーク アダプターは、次の表に示すように構成する必要があります。

次のように MAPI ネットワーク アダプターの TCP/IP v4 プロパティを構成します。

• DAG メンバーの MAPI ネットワークの IP アドレスは、DHCP を使用するために手動での割り当て、または構成が可能です。 DHCP を使用する場合は、サーバーの IP アドレスには永続的な予約を使用することをお勧めします。
• MAPI ネットワークは通常、既定のゲートウェアを使用しますが、これは必須ではありません。
• 少なくとも 1 つの DNS サーバー アドレスを構成する必要があります。 冗長性のために複数の DNS サーバーを使用することをお勧めします。
• [この接続のアドレスを DNS に登録する] チェック ボックスをオンにします。

レプリケーション ネットワーク アダプターの構成

レプリケーション ネットワークで使用することを目的としたネットワーク アダプターは、次の表に示すように構成する必要があります。

次のようにレプリケーション ネットワーク アダプターの TCP/IP v4 プロパティを構成します。

• DAG メンバーのレプリケーション ネットワークの IP アドレスは、DHCP を使用するために手動での割り当て、または構成が可能です。 DHCP を使用する場合は、サーバーの IP アドレスには永続的な予約を使用することをお勧めします。
• レプリケーション ネットワークには通常、既定のゲートウェイがないため、MAPI ネットワークに既定のゲートウェイがある場合は、他のネットワークに既定のゲートウェイを含める必要はありません。 レプリケーション ネットワーク上のネットワーク トラフィックのルーティングは、レプリケーション ネットワーク間でルーティングできるゲートウェイ アドレスを使用して、他の DAG メンバー上の対応するネットワークへの永続的な静的ルートを使用して構成できます。 このルートと一致しないその他のすべてのトラフィックは、MAPI ネットワークのアダプターで構成されている既定のゲートウェイによって処理されます。
• DNS サーバー アドレスを構成しないようにします。
• [この接続のアドレスを DNS に登録する] チェック ボックスをオンにしないようにします。

監視サーバーの要件

ミラーリング監視サーバーは、DAG の外部にあるサーバーで、DAG が偶数のメンバーを持つときにクォーラムを達成および保持するのに使用されます。 DAG のメンバーの数が奇数の場合は、ミラーリング監視サーバーを使用しません。 偶数のメンバーを持つすべての DAG がミラーリング監視サーバーを使用する必要があります。 ミラーリング監視サーバーには、Windows Server を実行しているコンピューターであればどのコンピューターでも指定できます。 ミラーリング監視サーバーの Windows Server オペレーティング システムのバージョンが、DAG メンバーによって使用されるオペレーティング システムと一致しなければならないという要件はありません。

クォーラムは、DAG の下のクラスター レベルで維持されます。 ほとんどのメンバーがオンラインであり、DAG の他のオンライン メンバーと通信できる場合、DAG にはクォーラムがあります。 クォーラムのこの概念は、Windows フェールオーバー クラスタリングにおけるクォーラムの概念の 1 つの側面です。 フェールオーバー クラスターのクォーラムに関連して必要な側面は、 クォーラム リソースです。 クォーラム リソースは、フェールオーバー クラスター内のリソースであり、クラスターの状態とメンバーシップの決定につながる仲裁手段を提供します。 クォーラム リソースには、構成情報を格納するための永続的なストレージも用意されています。 クォーラム リソースのコンパニオンはクォーラム ログであり、クラスターの構成データベースです。 クォーラム ログには、クラスターのメンバーであるサーバー、クラスターにインストールされているリソース、それらのリソースの状態 (オンラインやオフラインなど) などの情報が含まれます。

各 DAG メンバーは、DAG の基になるクラスターの構成方法を一貫したビューで確認することが重要です。 クォーラムは、クラスターに関連するすべての構成情報の最終リポジトリとして動作します。 また、クォーラムは、スプリットブレイン現象を回避するためのタイ ブレーカーとして使用されます。 スプリットブレイン現象は、DAG メンバーが相互に通信できないが、稼動しているときに発生する状態です。 分割脳症候群は、ほとんどの DAG メンバー (および DAG のメンバー数が偶数の場合は DAG 監視サーバー) を常に使用可能にし、DAG を操作できるようにする必要があるために防止されます。

サイトの復元計画

日々多くのビジネスで、高い信頼性と可用性を備えたメッセージング システムへのアクセスがビジネス成功の基になるという認識が高まっています。 多くの組織では、メッセージング システムはビジネス継続性計画の一部であり、組織のメッセージング サービスの展開はサイトの復元を考慮して設計されます。 基本的に、多くのサイトの復元ソリューションでは、第 2 データセンターにハードウェアを展開する必要があります。

最終的に、DAG メンバー数やメールボックス データベース コピー数などの DAG の設計全体は、多様な障害シナリオを網羅する各組織の回復に関するサービス レベル契約によって左右されます。 計画段階においてソリューションの設計者と管理者は、特にサイトの復元に必要な要件などの展開の要件を確認します。 ソリューションの設計者と管理者は、使用する場所と必要な回復に関する SLA の目標を確認します。 SLA によって、高可用性とサイトの復元を提供するソリューション設計の基となる 2 つの要素、目標復旧時間と目標復旧時点が決定されます。 これら 2 の値は共に分単位で計測されます。 目標復旧時間は、サービスの復元にかかる時間を指します。 目標復旧時点は、回復操作が完了した後のデータがどの程度最新のものであるかを表します。 また、SLA にはプライマリ データセンターの問題が解決した後にプライマリ データセンターが完全なサービスを提供する状態まで戻すことが既定されることもあります。

さらに、ソリューションの設計者と管理者は、サイト復元保護を必要とするユーザー セットを特定し、複数サイト ソリューションをアクティブ/パッシブ構成にするか、またはアクティブ/アクティブ構成にするかも決定します。 アクティブ/パッシブ構成では、通常スタンバイ データセンター内でユーザーはホストされません。 アクティブ/アクティブ構成では、ユーザーは両方の場所でホストされ、ソリューション内のデータベース総数のうちの一定の割合に、第 2 データセンターで優先度の高いアクティブな場所が割り当てられます。 1 つのデータセンターのユーザー向けのサービスに障害が発生すると、これらのユーザーは他のデータセンターでアクティブ化されます。

多くの場合、適切な SLA を作成するには次の基本的な質問に答える必要があります。

• プライマリ データセンターの障害発生後に、どのようなレベルのサービスが必要か。
• ユーザーにはデータが必要であるか、またはメッセージング サービスだけが必要か。
• データはどれだけ迅速に必要とされるか。
• 何人のユーザーをサポートする必要があるか。
• ユーザーは自分のデータにどのようにアクセスするか。
• どのような SLA でスタンバイ データセンターをアクティブ化するか。
• どのようにしてプライマリ データセンターにサービスを戻すか。
• リソースはサイトの復元ソリューション専用であるか。

これらの問題に回答することで、メッセージング ソリューションのためのサイトの復元設計の具体化を開始します。 サイト障害からの回復の中心的な要件は、バックアップ メッセージング サービスをホストするバックアップ データセンターに、必要なデータを届けるソリューションを作成することです。

証明書の計画

単一のデータセンター内で DAG を展開する場合、証明書の設計に関する考慮事項は特にありません。 ただし、サイトの復元構成の複数のデータセンター間に DAG がまたがる場合は、証明書に関する特定の考慮事項がいくつかあります。 一般に、証明書の設計は、使用中のクライアントと、証明書を使用する他のアプリケーションによる証明書要件によって異なります。 ただし、証明書の種類や数について準拠すべき特定の推奨事項とベスト プラクティスがいくつかあります。

ベスト プラクティスとして、Exchange サーバーとリバース プロキシ サーバーに使用する証明書の数は最小限に抑えてください。 各データセンター内のこれらのサービス エンドポイントすべてに対して単一の証明書を使用することをお勧めします。 このアプローチにより、必要な証明書の数が最小限に抑えられ、ソリューションのコストと複雑性の両方が削減されます。

Outlook Anywhere クライアントの場合、データセンターごとに単一のサブジェクトの別名 (SAN) 証明書を使用し、証明書内に複数のホスト名を含めることをお勧めします。 データベース、サーバー、またはデータセンターの切り替え後に Outlook Anywhere の接続が確実に行われるようにするには、各証明書で同じ証明書のプリンシパル名を使用し、Microsoft の標準フォーム (msstd) の同じプリンシパル名で Active Directory の Outlook プロバイダー構成オブジェクトを構成する必要があります。 たとえば、mail.contoso.com の証明書のプリンシパル名を使用する場合、次のように属性を構成します。

Set-OutlookProvider EXPR -CertPrincipalName "msstd:mail.contoso.com"

Exchange と統合される一部のアプリケーションには、より多くの証明書を使用する必要がある特定の証明書要件があります。 Exchange 2013 は、Office Communications Server (OCS) と共存できます。 OCS には、証明書のプリンシパル名に OCS サーバー名を使用する 1024 ビット以上の証明書を含めた証明書が必要です。 証明書プリンシパル名に OCS サーバー名を使用すると、Outlook Anywhere が正常に動作しなくなるため、OCS 環境には別途の証明書を使用する必要があります。

ネットワークの計画

DAG ごとに満たす必要がある特定のネットワーク要件と、DAG のメンバーである各サーバーに加えて、サイトの回復性構成に固有の要件と推奨事項がいくつかあります。 すべての DAG と同様に、DAG メンバーが単一サイトまたは複数のサイトのどちらに展開されるとしても、DAG メンバー間のラウンドトリップ リターン ネットワーク待ち時間は 500 ミリ秒未満にする必要があります。 さらに、複数のサイトにまたがる DAG について推奨する次のような特定の構成設定があります。

• MAPI ネットワークは、レプリケーション ネットワークから分離する必要があります。MAPI ネットワークとレプリケーション ネットワーク間のトラフィックをブロックするには、Windows ネットワーク ポリシー、Windows ファイアウォール ポリシー、またはルーター アクセス制御リスト (ACL) を使用する必要があります。 この構成は、ネットワーク ハートビートの漏話を防止するために必要になります。

• クライアントに接続する DNS レコードの Time to Live (TTL) の値は 5 分である必要があります。クライアントが発生するダウンタイムの量は、切り替えの実行速度だけでなく、DNS レプリケーションの発生速度や更新された DNS 情報に対するクライアントのクエリにも依存します。 内部 DNS サーバーと外部 DNS サーバーの両方で、Outlook Web App、Exchange ActiveSync、Exchange Web サービス、Outlook Anywhere、SMTP、POP3、IMAP4 など、すべての Exchange クライアント サービスの DNS レコードを 5 分の TTL で設定する必要があります。

• 静的ルートを使用してレプリケーション ネットワーク間の接続を構成する: 各レプリケーション ネットワーク アダプター間にネットワーク接続を提供するには、永続的な静的ルートを使用します。 このプロセスは、静的 IP アドレスを使用するときに各 DAG メンバーに対して実行される、迅速かつ 1 回限りの構成です。 レプリケーション ネットワークの IP アドレスを取得するために DHCP を使用する場合、DHCP を使用してレプリケーションの静的なルートを割り当てることが可能で、これにより構成プロセスを簡略化することができます。

一般的なサイト復元計画

高可用性に関する上記の要件に加えて、サイトの回復性のある構成に Exchange 2013 を展開するためのその他の推奨事項があります (たとえば、複数のデータセンターに DAG を拡張するなど)。 計画段階で実行する内容がサイトの復元ソリューションの成功に直接影響することになります。 たとえば、名前空間の設計が適切でないと、証明書上に問題が発生する可能性があったり、また証明書の構成が正しくないと、ユーザーがサービスにアクセスできなかったりする場合があります。

第 2 データセンターをアクティブ化するためにかかる時間を最小限に抑え、障害が発生したデータセンターのサービス エンドポイントを第 2 データセンターがホストできるようにするには、適切な計画を立案する必要があります。 次に、例を示します。

• サイトの復元ソリューションの SLA の目的を十分に理解し、ドキュメント化する必要があります。

• 第 2 データセンター内のサーバーには、2 つのデータセンター内の合計ユーザー人口をホストするのに十分な容量を確保する必要があります。

• 第 2 データセンターでは、プライマリ データセンターで提供されるすべてのサービスを有効にする必要があります (ただし、サイトの復元 SLA の中にそのサービスが含まれていない場合は除きます)。 これらのサービスには、Active Directory、ネットワーク インフラストラクチャ (DNS や TCP/IP など)、テレフォニー サービス (ユニファイド メッセージングが使用されている場合)、サイト インフラストラクチャ (電源や冷却など) が含まれます。

• 一部のサービスでは障害が発生したデータセンターのユーザーにサービスを提供できるようにするために、ユーザーが適切なサーバー証明書を構成する必要があります。 サービスによってはインスタンス化が許可されず (POP3 や IMAP4 など)、単一の証明書の使用のみが許可されるものがあります。 このような場合、証明書を、複数の名前を含めた SAN 証明書にするか、複数の名前に、ワイルドカード証明書を使用できるような類似名を付ける必要があります (ただし、組織のセキュリティ ポリシーによってワイルドカード証明書の使用が許可されていなければなりません)。

• 第 2 データセンター内に必要なサービスを定義する必要があります。 たとえば、最初のデータセンターに異なるトランスポート サーバー上に 3 つの異なる SMTP 宛先がある場合は、2 つ目のデータセンターで適切な構成を定義して、少なくとも 1 つの (3 つすべてではない場合) トランスポート サーバーがワークロードをホストできるようにする必要があります。

• データセンターの切り替えをサポートするために必要なネットワーク構成を正しく設定する必要があります。 この要件は、負荷分散構成が設定されていること、グローバル DNS が構成されていること、および適切なルーティングが構成された状態でインターネット接続が有効になっていることを意味する場合があります。

• データセンターの切り替えに必要な DNS 変更を有効にする戦略を理解する必要があります。 TTL 設定などの特定の DNS 変更は、SLA で効力を持たせるために既定し、ドキュメント化する必要があります。

• ソリューションをテストする戦略を立案して、SLA に盛り込むことも必要です。 時間の経過に伴って展開の質と実行可能性が低下することがないようにするには、定期的に展開を検証することが唯一の方法です。 展開の検証後には、ソリューションの成功に直接影響する構成部分を明示的にドキュメント化する必要があります。 さらに、展開のこれらのセグメント前後の変更管理プロセスを強化することをお勧めします。