次の方法で共有

Site Resilience Configurations

  • [アーティクル]

 

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

トピックの最終更新日: 2007-10-29

近年、成功にはメッセージングが不可欠であることを認識する企業がますます増えています。多くの組織にとって、メッセージング システムはビジネスの継続性に関する計画の一部になっている必要があり、メッセージング サービスの展開の設計時にはサイトの復元を考慮に入れる必要があります。基本的に、多くのサイトの復元ソリューションでは、2 番目のデータ センターにバックアップ ハードウェアを展開する必要があります。この場合は通常、以下の基本的な問題が提起されることになります。

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

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

ここでは、RTM (Release to Manufacturing) 版の Microsoft Exchange Server 2007 および Exchange 2007 Service Pack 1 (SP1) のサイトの復元に関する構成について詳しく説明します。サイトの復元ソリューションについて検討を始める前に、以下の用語の意味を十分に理解しておくことをお勧めします。

  • ストレッチ クラスタ   地理的に分散されているクラスタとも呼ばれます。クラスタのノードが複数のデータ センターに存在するクラスタ構成です。
  • データベースの移植性   ホスト データベースを移動するときにメールボックスの移動先を別のサーバーにできるようにする管理上の機能。
  • 分散されている Active Directory サイト   複数のデータセンターのコンピュータが含まれる Active Directory ディレクトリ サービス サイト (物理的に複数の場所にまたがる Active Directory サイトなど)。
  • Active Directory サイト メンバシップ   コンピュータのプライマリ IP アドレスに基づいた、特定の Active Directory サイトのメンバ。IP アドレスを変更したり、その IP アドレスを含む Active Directory サイトを変更したりすると、コンピュータの Active Directory サイト メンバシップが変わります。
  • 運用データセンター   サービスのアクティブ サーバーと、それらに関連付けられているインフラストラクチャをホストしているデータセンター。
  • ホット バックアップ データセンター   サービスの所有権の引き継ぎと継続的な提供を直ちに準備できるバックアップ データセンター。この場所でサービスを実行するために特別な構成は必要ではありません。
  • ウォーム バックアップ データセンター   運用データセンターのサービスの所有権を引き継ぐために使用できるサーバーが用意されているバックアップ データセンター。このデータセンターのサービスをアクティブ化するには手動操作が必要です。
  • コールド バックアップ データセンター   サービスの所有権を引き継ぐ容量を備えたバックアップ データセンター。場合によってはインフラストラクチャも用意されます。このデータセンターでサービスの運用が可能になるまでには、多くの作業が必要になります。
  • 専用   プライマリ データセンターのユーザーをサポートするためだけに割り当てられているサーバー。
  • 非専用   プライマリ データセンターのユーザーと、別の場所のユーザーをサポートしているサーバー。

運用、ウォーム、専用などの用語を組み合わせると、サイトの復元の展開について記述できます。たとえば、専用で大規模な構成のバックアップ データセンターによってバックアップされる運用データ センターであれば、"運用 : ウォーム (専用)" と呼ばれます。

サイトの復元をサポートする機能

Exchange 2007 の機能には、サイトの復元ソリューションの基本要素として使用できるものがいくつかあります。以下にその例を示します。

  • ストレッチ クラスタ。データをレプリケートするため、またはバックアップ データセンターのアクティブ化を簡略化するために使用できます。
  • データベースの移植性。レプリケートされたデータをアクティブ化するために使用できます。
  • 分散されている Active Directory サイト。ストレッチ クラスタをサポートしたり、バックアップ データセンターを有効にするために使用できます。
  • コンピュータの Active Directory サイト メンバシップの変更。バックアップ データセンターをアクティブ化する作業の一部として実行できます。
  • サイト外の格納域の利用を前提にした定期的なテープ バックアップ。バックアップ データセンターでメールボックス データを回復するために使用できます。

さらに、データ レプリケーションを提供するサード パーティ製品があり、バックアップ データセンターにデータを転送するために使用できます。これらの製品は、スタンドアロン サーバー、回復用のクラスタ、または分散されているシングル コピー クラスタ (SCC) と共に使用できます。これらの構成では、プライマリ サーバーまたはプライマリ クラスタのデータが、2 番目のデータセンターにある 2 番目のサーバーまたはクラスタの構成にレプリケートされます。サイトの障害が発生すると、2 番目のデータセンターにあるクラスタまたはサーバーが手動でアクティブ化されます。

Exchange 2007 SP1 では、スタンバイ連続レプリケーション (SCR) と呼ばれる新機能が追加されています。この機能は、特にサイト復元のシナリオのために設計されています。名前が示すとおり、SCR は、待機している (スタンバイ) 回復用サーバーを使用する、またはその使用を可能にするシナリオのために設計されています。SCR は Exchange 2007 RTM に備わっていた既存の連続レプリケーション機能を拡張し、Exchange 2007 SP1 を実行しているメールボックス サーバーで新しいデータ可用性シナリオを使用できるようにします。ローカル連続レプリケーション (LCR) およびクラスタ連続レプリケーション (CCR) で使用されているものと同じログ配布および再生のテクノロジが SCR でも使用され、展開のオプションと構成の幅が広がります。

SCR によって、高可用性 (サービス可用性とデータ可用性で構成される) とサイト復元との分離が可能になります。たとえば、SCR を CCR と組み合わせることで、ストレージ グループをプライマリ データセンターにはローカルにレプリケートし (CCR による高可用性の実現)、セカンダリ データセンターまたはバックアップ データセンターにはリモートでレプリケートします (SCR によるサイト復元の実現)。セカンダリ データセンターでは、SCR ターゲットをホストするパッシブ ノードをフェールオーバー クラスタ内に持ちます。この種のクラスタがスタンバイ クラスタと呼ばれるのは、クラスタ化メールボックス サーバーをメンバとして持たないからですが、回復シナリオにおいて代替クラスタ化メールボックス サーバーを持つクラスタとして迅速に準備することができます。障害発生などが原因でプライマリ データセンターが使用不可能になった場合は、このスタンバイ クラスタでホストされている SCR ターゲットをスタンバイ クラスタ上ですばやくアクティブ化できます。

SCR の詳細については、「スタンバイ連続レプリケーション」を参照してください。

サイトの復元を実現するためのソリューション

組織では、いくつかのサイトの復元ソリューションを検討することができます。この後は、以下に示すサイトの復元ソリューションについて説明します。

  • 運用 : コールド (専用)
  • 運用 : ウォーム (専用)
  • 運用 : ウォーム (非専用) – 2 つの Active Directory サイトを含む
  • 運用 : 運用 (非専用) – 1 つの Active Directory サイトを含む

ここで説明するソリューションは、運用データセンターで障害が発生したときにはメッセージング インフラストラクチャが完全に失われることを前提にしています。バックアップ データセンターには、インターネット接続と、Exchange をホストするために必要なすべてのサービスが用意されている必要があります。さらに、アクティブ化のプロセスがスクリプトに記述され、定期的にテストされている必要があります。

運用 : コールド (専用)

メッセージング サイトの最も基本的な復元ソリューションは、組織がハードウェアと設備についての契約を整えていても、アクティブなバックアップ データセンターは用意していないソリューションです。すべてのメールボックス データは定期的にバックアップされ、サイト外に移動されます。Active Directory データも同様の方法で扱われます。このサイトの復元ソリューションをアクティブ化するには、ハードウェアを調達して展開する必要があります。全体としての停止時間を短縮するため、組織は特に重要なハードウェア要素について、ハードウェア ベンダと迅速な納品の契約を結ぶことができます。

このソリューションのバリエーションとして、自社で管理する在庫からハードウェアを提供することができる障害回復ベンダと関係を結ぶ方法があります。この種類の関係では、回復時間を短縮するためにバックアップ データをベンダの場所で管理できる場合があります。ベンダの場所にある専用の格納域をメールボックスや Active Directory データのレプリケーション先にすることができます。

わかりやすさのために、展開される構成は、最終的には運用環境と同様の内容になるか、少なくとも運用環境の一部と同じ内容になります。このような回復処理の間は、できるだけ使い慣れたテクノロジと依存関係を使って作業することをお勧めします。

運用 : ウォーム (専用)

"運用 : ウォーム (専用)" の回復モデルでは、運用データセンターに、専用の機器を備えた指定のバックアップ データセンターを用意します。運用データセンターが利用できなくなった場合は、専用の機器を使用します。前に説明したように、このバックアップ データセンターは自動ではアクティブ化されません。管理者が手動でアクティブ化を開始する必要があります。アクティブ化が開始されると、メッセージング サービスを提供するために専用のバックアップ機器とインフラストラクチャが再構成されます。次の図に、"運用 : ウォーム (専用)" 構成を示します。

運用 : ウォーム (専用) 展開

前の図には、エッジ トランスポート サーバーの役割、ハブ トランスポート サーバーの役割、クライアント アクセス サーバーの役割、およびメールボックス サーバーの役割をホストする運用データセンター (A) が示されています。ウォーム バックアップ データセンター (B) には、それぞれの役割と Active Directory のための専用バックアップ サーバーがあります。図では、メールボックス サーバーの役割を除くすべてのサーバーの役割について、単純な冗長性が採用されていることが示されています。メールボックスの冗長性は、適切なレプリケーション ソリューションを備えたクラスタまたはスタンバイ サーバーの構成によって処理されます。

使用できるメールボックスの冗長性ソリューションには以下のものがあります。

  • ストレッチ クラスタ構成のクラスタ連続レプリケーション (CCR)   CCR はログ配布を使用して、メールボックス データの 2 番目のコピーを作成および管理します。したがって、CCR の 2 ノード クラスタには、データセンターごとに 1 つのノードがあります。この構成では、Windows クラスタ サービスには 2 つの場所に分散されたサブネットが必要です。ストレッチ クラスタにより、クラスタ化メールボックス サーバーは、割り当てられている IP アドレスを他のデータセンターのノードで再度登録するだけでフェールオーバーできます。
  • パートナーの同期レプリケーションを使用するシングル コピー クラスタ (SCC)   パートナーのレプリケーションにより、システムはメールボックス サーバー データのコピーを 2 つ持つことができます。CCR と同様に、クラスタが正常にフェールオーバーされるには、分散されたサブネットが必要です。
  • パートナーのレプリケーションによるスタンバイ クラスタ   メールボックス データはバックアップ データセンターの 2 番目のクラスタにレプリケートされ、サーバーの障害回復プロセスを使用してサービスが復元されます。同期または非同期のレプリケーションを使用できます。クラスタ化の必要はなく、分散されたサブネット要件はありません。
  • パートナーのレプリケーションによるスタンバイ サーバー   メールボックス データはバックアップ データセンターの 2 番目のサーバーにレプリケートされ、データベースの移植性またはサーバーの障害回復プロセスを使用してサービスが復元されます。同期または非同期のレプリケーションを使用できます。クラスタ化の必要はなく、分散されたサブネット要件はありません。
  • 2 番目のデータセンターにホストされる 2 番目のコピーを使用したローカル連続レプリケーション (LCR)   これは推奨されるソリューションではありませんが、一部の組織にとってはこれで十分な場合があります。この構成では、インターネット SCSI (iSCSI) ベースの格納域を使用してデータのパッシブ コピーを格納します。接続のネットワーク特性は、パッシブ コピーでアクティブ コピーとの適切な一貫性が維持されるものにする必要があります。この構成では、ネットワークの待機時間と帯域幅がクライアント アクセスをサポートしないレベルになる可能性が高いため、LCR をローカルでの迅速なアクティブ化のために使用することはできません。

前の図は、いずれかのクラスタ化ソリューションが使用されていることを示しています。これは、運用データセンターの Active Directory サイトにメールボックス サーバーが表示されているためです。クラスタ化ソリューションでは、クラスタ内の各ノードのネットワークが同じサブネット上に存在する必要があります。非クラスタ化ソリューションでは、単一のサブネットは必須ではありませんが、この構成にすることをお勧めします。必要に応じて異なるサブネットを使用することができます。

クラスタ化ソリューションを使用する場合、通常の運用の推移は次のようになります。

  1. 受信インターネット メールはすべて、データセンター A のエッジ トランスポート サーバー経由で流れます。
  2. Active Directory サイト Redmond-Prod のメールボックス サーバー宛てになっているメールはすべて、Redmond-Prod のハブ トランスポート サーバーによって処理されます。
  3. Active Directory サイト Redmond-Prod のクラスタ化メールボックス サーバーは、データセンター A またはデータセンター B に構成されているノードでホストされます。NodeA と NodeB は Redmond-Prod の一部であり、Redmond-Prod のハブ トランスポート サーバーとクライアント アクセス サーバーによってサービスが提供されます。
  4. CCR は 2 つのノードをサポートするため、2 番目のノードはデータセンター B 内に置かれている必要があります。これは、データセンター A のアクティブ ノードで障害が発生すると、クラスタ化メールボックス サーバーが強制的にデータセンター B に移動されることを意味します。この場合も、メールボックス サーバーのサービスを提供するのはデータセンター A のハブ トランスポート サーバーとクライアント アクセス サーバーです。
  5. 3 つのサーバーと 2 つのデータのコピーを持つ SCC は、障害発生時に、クラスタ化メールボックス サーバーをデータセンター B にフェールオーバーする代わりにデータセンター A に残すように構成できます。ただし、格納域に関係する障害である場合はやはり、データセンター B のパッシブ ノードをアクティブ化する必要があります。

2 つのデータセンター間をつなぐネットワーク帯域幅の要件には、以下の 3 つの要因が影響を与えます。

  • クラスタ サービスの待ち時間要件   クラスタ サービスでは、クラスタ ノード間のラウンド トリップ時間が 0.5 秒を超えないようにする必要があります。
  • レプリケーションの帯域幅の要件   CCR レプリケーションはデータベースのコピー処理ではなくログ配布に基づくため、CCR で必要な帯域幅はほとんどのサード パーティ レプリケーション ソリューションより少なくなります。CCR ソリューションで必要な帯域幅は、通常はそれぞれの環境に特有のさまざまな要因によって異なりますが、必要な帯域幅には、以下の用途のための帯域幅が含まれます。
    • ログ配布
    • ファイル システムの通知 (新しいログ ファイルの配布準備ができたときに、Microsoft Exchange Replication Service がそれを認識する方法)
    • ディレクトリ サーバーのトラフィック
    • クライアントのトラフィック (クライアントがクラスタ化メールボックス サーバーと物理的に同じ場所に配置されていない場合)
    • クラスタ ハートビートのトラフィック
    • クラスタ データベースの更新
    • ネットワークを使用するその他すべてのアプリケーション
  • ハブ トランスポートおよびクライアント アクセスの各サーバーと、サービス提供先のメールボックス サーバーとの間で必要になる LAN 通信   クライアント アクセス サーバーの場合は、オンライン ユーザーにサービスを提供するため、この要件がより重要です。ドメイン コントローラへのメールボックス アクセスはワイド エリア ネットワーク (WAN) 接続を経由する場合があり、その待ち時間がオンラインの MAPI アクセスに影響します。

待ち時間と帯域幅の要件は、非クラスタ化ソリューションを展開する場合は軽減されることがあります。レプリケーションのためのネットワーク要件は残っており、重要です。ただし、データセンター A で全面的な障害がないときにバックアップ メールボックス サーバーをアクティブ化することを考えている場合を除き、他の要件の大半は存在しません。

運用データセンターで障害が発生した場合、管理者は以下のいずれかを実行してメール フローとメッセージング サービスを復元できます。

  • バックアップ データセンターのメールボックス サーバーを Active Directory サイト Redmond-DR に移動する。
  • バックアップ データセンターのハブ トランスポート サーバー、クライアント アクセス サーバー、およびディレクトリ サーバーを Active Directory サイト Redmond-Prod に移動する。

2 番目のオプションでは環境の他の部分への影響が最小限になるため、この方法をお勧めします。たとえば、どの支社の Exchange サーバーでも、キューに置かれているメールについて認識済みのルーティングを変更する必要がありません。正しいサーバーが稼働していて、利用可能であれば、そのまま接続されます。

データセンター B のアクティブ化は、以下の高度な手順に従って行います。

  1. ネットワーク インフラストラクチャをオンラインにします。
  2. Active Directory インフラストラクチャをオンラインにします。
  3. 残っているメールボックス サーバーをオンラインにします。この手順では、残りの 1 台のサーバーと共にクラスタを強制的にオンラインにする必要がある場合があります。
  4. Active Directory サイト Redmond-Prod を、Redmond-DR のハブ トランスポート サーバー、クライアント アクセス サーバー、およびディレクトリ サーバーの IP アドレスで更新します。
  5. 組織のドメインの MX レコードを、データセンター B のエッジ トランスポート サーバーの IP アドレスで更新します。
  6. 新しく移動したクライアント アクセス サーバーをネットワーク負荷分散 (NLB) の構成に追加します。
  7. データセンター A のメッセージング サービスがデータセンター B に復元されます。

データセンター A を使用できるようになったら、以下の高度な手順に従ってデータセンター B を非アクティブ化できます。

  1. データセンター A の個々のサーバーをオンラインにします。これらのサーバーは、Exchange サービスが手動で停止されるか、無効にされていなければ、サービスの提供に参加することになります。元の構成に戻すときには、データセンター A のサーバーがオンラインになることができるようにします。
  2. データセンター B のハブ トランスポート サーバーで、キューを空にすることを許可し、その後サーバーをオフラインにします。
  3. データセンター B のクライアント アクセス サーバーを、NLB の構成から除外します。クライアントはこの後、データセンター A のサーバー経由で接続します。
  4. 組織のドメインの MX レコードが、データセンター A のエッジ トランスポート サーバーの IP アドレスで更新されます。
  5. ネットワーク インフラストラクチャを更新する必要があれば実行します。
  6. クラスタ化メールボックス サーバーをデータセンター A に移動します。
  7. Active Directory サイト Redmond-DR を、アクティブ化の間に移動したサーバーの IP アドレスで更新します。
  8. データセンター A のメッセージング サービスが復元されます。

すべてのサイトの障害ソリューションと同様に、運用データセンターとバックアップ データセンターのアクティブ化をスクリプトとして記述し、定期的にテストする必要があります。メールボックス サーバーのクラスタ化ソリューションを使用すると、バックアップ データセンターのアクティブ化の時間が短縮されます。他のソリューションでは、いくつかのドメイン ネーム システム (DNS) と Active Directory のレプリケーションが必要になる場合があり、これにより、メール フローの再開とクライアントがメールボックスにアクセス可能になるタイミングに影響することがあります。

"運用 : ウォーム (専用)" ソリューションには、専用のコンピュータを使用するため、予測できるレベルのサービスが提供されるという利点があります。

運用 : ウォーム (非専用) – 2 つの Active Directory サイトを含む

"運用 : ウォーム (専用)" 構成では、バックアップ データセンターのエッジ トランスポート サーバー、ハブ トランスポート サーバー、およびクライアント アクセス サーバーは、データセンター A のスタンバイ リソース専用です。この構成は、常に使用されるのではないハードウェアに大きな投資をすることを意味します。その代わりになるモデルを、次の図に示します。

運用の例 : ウォーム (非専用) 展開

"運用 : ウォーム (非専用)" では、管理者がバックアップ データセンターのアクティブ化を手動で開始する必要があります。アクティブ化のプロセスが開始されると、データセンター A のユーザー向けのメッセージング サービスを引き継ぐようにバックアップ データセンターの機器とインフラストラクチャの一部が再構成されます。

"運用 : ウォーム (専用)" ソリューションと同様に、"運用 : ウォーム (非専用)" ソリューションには 2 つの Active Directory サイトがあります。しかし、"運用 : ウォーム (専用)" ソリューションと異なり、両方の Active Directory サイトが他のデータセンターにまたがっています。バックアップ データセンターの専用リソースは、バックアップ データセンター内に存在する別の運用構成のために冗長化されたサーバーになっています。この方法では、これらのリソースを通常の使用のために提供します。そのため、効果的に互いのバックアップになっている 2 つの運用データセンターを作成することになります。

たとえば、**「"運用 : ウォーム (非専用)" 展開の例」**の図で示したように、データセンター A で障害が発生すると、ハブ トランスポート サーバー 4、クライアント アクセス サーバー 4、およびグローバル カタログ サーバー 4 が Active Directory サイト Redmond に追加され、Redmond の NodeB と共にデータセンター A のユーザーを担当し、メッセージング サービスを提供します。サイトの障害が発生した後は、2 つの運用環境は通常の状態より少ない容量と冗長性で実行されるようになります。継続している負荷をサポート可能であれば、この構成を許容できます。たとえば、インターネット メールはデータセンター B のエッジ トランスポート サーバー経由で送信されます。データセンターの停止時間が延びる状況に対応するため、企業は要求時に追加のハードウェアが迅速に提供されるベンダ契約を結ぶことができます。追加されたハードウェアを使用して、冗長性の復元や容量の追加を行うこともできます。

Redmond および Dublin Active Directory サイトの展開における通常の運用は、このソリューションでも "運用 : ウォーム (専用)" ソリューションの場合と同じになります。同様に、2 つの場所をつなぐネットワークの帯域幅には、同じ要因が影響を及ぼしますが、Redmond サーバーと Dublin サーバーの両方を同時にサポートする必要がある点が異なります。

バックアップ データセンターのアクティブ化は、次のいずれかの方法で行います。

  • アクティブ ノードとクラスタ化メールボックス サーバーを運用データセンターの Active Directory サイトに移動する。
  • バックアップ データセンターのハブ トランスポート サーバー、クライアント アクセス サーバー、およびディレクトリ サーバーを、障害が発生したデータセンターの Active Directory サイトに移動する。

推奨されるアクティブ化ソリューションは、ハブ トランスポート サーバーとクライアント アクセス サーバーを、障害が発生したデータセンターの Active Directory サイトに移動することです。このソリューションでは、アクティブ化の手順が最も単純で、中断時間が最短になります。

このソリューションでは、データセンター A の回復は以下の高度な手順によって実現されます。

  1. ネットワーク インフラストラクチャをオンラインにします。インターネット メールは既にデータセンター B で受信されているため、ネットワーク インフラストラクチャの変更は必要でないことがあります。
  2. データセンター A の Active Directory インフラストラクチャをオンラインにします (Active Directory サイト Redmond)。
  3. 残っているメールボックス サーバーをオンラインにします。この手順では、残りの 1 台のサーバーと共にクラスタを強制的にオンラインにする必要がある場合があります。
  4. Active Directory サイト Redmond は、ハブ トランスポート サーバー 4、クライアント アクセス サーバー 4、およびグローバル カタログ サーバー 4 の IP アドレスで更新されます。
  5. クライアント アクセス サーバー 3 を Redmond の NLB 構成に追加します。
  6. データセンター A のメッセージング サービスが復元されます。

データセンター A を使用できるようになったら、以下の高度な手順に従ってデータセンター B を通常の構成に復元できます。

  1. データセンター A の個々のサーバーをオンラインにします。これらのサーバーは、Exchange サービスが手動で停止されるか、無効にされていなければ、サービスの提供に参加することになります。元の構成に戻すときには、データセンター A のサーバーがオンラインになることができるようにします。
  2. ハブ トランスポート サーバー 4 のキューを空にすることを許可し、その後サーバーをオフラインにします。
  3. クライアント アクセス サーバー 4 を NLB 構成から除外します。クライアントはまだ、データセンター A のサーバーに接続できます。
  4. ネットワーク インフラストラクチャを更新する必要があれば実行します。
  5. クラスタ化メールボックス サーバーをデータセンター A に移動します。
  6. Active Directory サイト Dublin を、アクティブ化の間に移動したサーバーの IP アドレスで更新します。
  7. 両方のデータセンターが元の状態に復元されます。

すべてのサイトの障害ソリューションと同様に、運用データセンターとバックアップ データセンターのアクティブ化をスクリプトとして記述し、定期的にテストする必要があります。メールボックス サーバーのクラスタ化ソリューションを使用すると、バックアップ データセンターのアクティブ化の時間が短縮されます。他のメールボックス ソリューションでは、いくつかの DNS と Active Directory のレプリケーションが必要になる場合があり、これにより、メール フローの再開とクライアントがメールボックスにアクセス可能になるタイミングに影響することがあります。

このソリューションでは、サイトの復元に使用されるサーバーを、通常の運用に適用することができます。これによってサイトの復元ソリューションのコストが削減される可能性もありますが、このソリューションは、必要なときに完全にはシステム負荷に耐えることができないリスクを負っています。たとえば、データセンター B のハブ トランスポート サーバーの負荷が増加して容量の 80% を使用している場合、A のためにバックアップ データセンターをアクティブ化すると、ハブ トランスポート サーバーの容量を超えることになります。このソリューションでは、管理者はシステムの使用状況を長期にわたって慎重に追跡し、ソリューションを確実に適用できるようにしておく必要があります。負荷が増加した場合は、新しいハードウェアを購入して展開する必要があります。

運用 : 運用 (非専用) – 1 つの Active Directory サイトを含む

バックアップ サイトの自動アクティブ化をサポートできるソリューションを必要とする組織は、"運用 : 運用 (非専用)" ソリューションを展開する必要があります。このソリューションでは、次の図に示すように、両方のデータセンターにまたがる単一の Active Directory サイトに冗長化されたサーバーを展開します。

運用 : 運用 (非専用) 展開

このソリューションでは、両方のデータセンターのリソースを 1 つの Active Directory サイトに展開します。サイト内の任意のリソースを使用して、ほぼすべての要求に対応することができます。たとえば、データセンター A のエッジ トランスポート サーバーは、データセンター B のハブ トランスポート サーバーを使用して、データセンター A でホストされているクラスタ化メールボックス サーバー上にメールボックスがあるユーザーにメッセージを配信できます。同様に、既定では Active Directory トラフィックに関して参照時に地域は考慮されません。これらの理由で、このソリューションは推奨されません。

バックアップ データセンターのアクティブ化は、複数サーバーの障害が発生した場合の回復と似ています。アクティブ化からの回復で必要なのは、障害が発生したサーバーでサービスを復元することだけです。前に説明した非専用のソリューションと同様に、容量の管理を適切に行わないと、データセンターの障害発生後に負荷がサービスの容量を超える可能性があります。管理者はそのソリューションで、データセンターの障害発生後に予想される負荷を確実にサポートできるようにする必要があります。適切に容量管理を行わないと、1 つのデータセンターに障害が発生した後に全面的なメッセージング サービスの障害が発生するおそれがあります。

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