次の方法で共有

データセンター切り替え

  • [アーティクル]

サイトの回復性のある構成では、サイト レベルの障害に応答する自動回復が DAG 内で発生する可能性があり、メッセージング システムは機能状態のままです。 この構成では、2 つの場所に DAG メンバーを展開し、DAG の監視サーバーを 3 番目の場所に展開する必要があるため、少なくとも 3 つの場所が必要です。

3 つの場所が存在しない場合、または存在するものの、データセンター レベルの回復処理を制御したい場合は、サイト レベルの障害が発生した場合に備えて手動回復用に DAG を設定できます。 その場合、データセンター切り替え と呼ばれるプロセスを実行します。 多くの障害回復シナリオと同様に、データセンターの切り替えを事前に計画および準備すると、回復プロセスを簡略化して停止期間を短縮できます。

第 2 データセンターをアクティブ化するための初期決定を行った後、4 つの基本手順に従ってデータセンター切り替えの実行を完了します。

  1. 部分的に実行されているデータセンターを終了する: この手順では、サービスがまだ実行されている場合は、プライマリ データセンター内の Exchange サービスを終了します。 メールボックス サーバーの役割はアクティブ/パッシブの高可用性モデルを使用するため、メールボックス サーバーの役割には特に重要です。 部分的に障害が発生したデータセンターでサービスを停止しないと、プライマリ データセンターに戻る時点で、部分的に障害が発生したデータセンターからの問題が、サービスに悪影響を及ぼす可能性があります。

    重要

    プライマリ データセンターの障害の結果としてネットワークまたは Active Directory インフラストラクチャの信頼性が危険にさらされた場合は、これらの依存関係が正常なサービスに復元されるまで、すべてのメッセージング サービスをオフにすることをお勧めします。

  2. 2 つ目のデータセンターの前提条件を検証して確認します。この手順は、2 番目のデータセンターのインフラストラクチャの正常性の検証が最初のデータセンターとは大きく関係ないため、手順 1 と並行して実行できます。 各組織には通常、この手順を実行するための独自の方法が必要です。 たとえば、インフラストラクチャ監視アプリケーションによって収集およびフィルタリングされた正常性情報を確認するか、組織のインフラストラクチャに固有のツールを使用して、この手順の完了を決定する場合があります。 これは、第 2 データセンターのインフラストラクチャが正常でなく不安定な状態のときに第 2 データセンターをアクティブ化したくないため、重要な手順です。

  3. メールボックス サーバーのアクティブ化: この手順では、2 つ目のデータセンターをアクティブ化するプロセスを開始します。 Microsoft Exchange サービスでデータベースの停止と回復を処理できるため、この手順を手順 4 と並行して実行できます。 メールボックス サーバーのアクティブ化のプロセスでは、プライマリ データセンターからの障害のあるサーバーを利用できないようにマークした後、第 2 データセンターのサーバーをアクティブ化します。 メールボックス サーバーのアクティブ化プロセスは、DAG がデータベース アクティブ化調整 (DAC) モードであるかどうかによって異なります。 詳細については、「 データセンター ライセンス認証調整モード」を参照してください。

    DAG が DAC モードの場合、Exchange のサイト復元コマンドレットを使用して、部分的に障害が発生したデータセンターを停止 (必要な場合) し、メールボックス サーバーをアクティブ化できます。 たとえば DAC モードでは、この手順を Stop-DatabaseAvailabilityGroup コマンドレットを使用して実行できます。 場合によっては、サーバーを利用不可として 2 回マークする必要があります (データセンターごとに 1 回ずつ)。 次に、 Restore-DatabaseAvailabilityGroup コマンドレットを実行して第 2 データセンターのデータベース可用性グループ (DAG) の残りのメンバーを復元するため、DAG メンバーをまだ動作しているメンバーまで減らし、それによってクォーラムを再確立します。 DAG が DAC モードにない場合は、Windows のフェールオーバー クラスター ツールを使用してメールボックス サーバーをアクティブ化する必要があります。 いずれかのプロセスが完了すると、第 2 データセンターでパッシブであったデータベース コピーがアクティブになりマウントできます。 この時点で、メールボックス サーバーの復旧は完了です。

  4. クライアント アクセス サービスのアクティブ化: これには、URL マッピング情報とドメイン ネーム システム (DNS) 変更手法を使用して、必要なすべての DNS 更新を実行する必要があります。 マッピング情報は、実行する DNS 変更について記述します。 更新を完了するために必要な時間は、使用される方法および DNS レコードでの TTL (Time to Live) 設定 (および展開のインフラストラクチャが TTL を許可するかどうか) に依存します。

手順 3 および 4 を完了してしばらくしたら、ユーザーがメッセージング サービスにアクセスできるようになります。 手順 3 および 4 については、後で詳しく説明します。

部分的に障害が発生したデータセンターの終了

障害が発生したデータセンターの DAG メンバーがまだ動作している場合は、サービスを終了する必要があります。

Exchange DAG が DAC モードの場合は、1 つのコマンドを使用して、障害が発生したデータセンター内のサーバーを無効にすることができます。 これにより、DAG にクォーラム (DAG のメンバーの半分以上が使用可能) がない場合でも、別のデータセンターにデータベースをマウントできます。

DAG が DAC モードの場合、プライマリ データセンターの残存 DAG メンバーを終了するための特定の操作は以下のとおりです。

  1. プライマリ データセンターの DAG メンバーは、プライマリ データセンターで停止済みとしてマークする必要があります。 停止は 、データベースのマウントを妨げる Active Manager の状態であり、障害が発生したデータセンター内の各サーバー上の Active Manager は 、Stop-DatabaseAvailabilityGroup コマンドレットを使用してこの状態になります。 このコマンドレットの ActiveDirectorySite パラメーターを使用すると、プライマリ データセンター内のすべてのサーバーを 1 つのコマンドで停止済みとしてマークできます。 この手順は、エラーによっては不可能な場合があります。 データセンターの状態で許可されている場合は、この手順を実行する必要があります。 Stop-DatabaseAvailabilityGroup コマンドレットは、プライマリ データセンター内のすべてのサーバーに対して実行する必要があります。 メールボックス サーバーが使用できないが、Active Directory がプライマリ データセンターで動作している場合は、ConfigurationOnly パラメーターを使用して Stop-DatabaseAvailabilityGroup コマンドをプライマリ データセンター内のこの状態のすべてのサーバーに対して実行するか、メールボックス サーバーをオフにする必要があります。 障害が発生したデータセンターのメールボックス サーバーをオフにするか、サーバーに対して Stop-DatabaseAvailabilityGroup コマンドを正常に実行しないと、2 つのデータセンターでスプリットブレイン症候群が発生する可能性があります。 この要件を満たすために、電源管理デバイスを介してコンピューターを個別にオフにする必要がある場合があります。

  2. どのプライマリ データセンターのサーバーが停止されているかを表すために第 2 データセンターを更新する必要があります。 これは、同じ ActiveDirectorySite パラメーターを使用して ConfigurationOnly パラメーターで同じ Stop-DatabaseAvailabilityGroup コマンドを実行し、失敗したプライマリ データセンター内の Active Directory サイトの名前を指定することで行われます。 この手順の目的は、第 2 データセンター内のサーバーに、サービスの復元時にどのメールボックス サーバーが使用できるかについて通知することです。

DAG が DAC モードではない場合、プライマリ データセンターの残存 DAG メンバーを終了するための特定の操作は以下のとおりです。

  1. プライマリ データセンターの DAG メンバーは、メンバーごとに次のコマンドを実行して、DAG の基になるクラスターから強制的に削除される必要があります。

    net stop clussvc

    cluster <DAGName> node <DAGMemberName> /forcecleanup

  2. この際、第 2 データセンター内の DAG メンバーを再起動して、第 2 データセンターからの削除プロセスを完了するために使用する必要があります。 第 2 データセンター内の各 DAG メンバーで、メンバーごとに次のコマンドを実行してクラスター サービスを停止します。

    net stop clussvc

  3. 第 2 データセンター内の各 DAG メンバーで、次のコマンドを実行してクラスター サービスのクォーラム開始を強制します。

    net start clussvc /forcequorum

  4. フェールオーバー クラスター管理ツールを開き、DAG の基になるクラスターに接続します。 クラスターを展開し、 [ノード] を展開します。 プライマリ データセンターの各ノードを右クリックし、 [他の操作] に続いて [削除] を選択します。 プライマリ データセンターの DAG メンバーの削除を完了後、フェールオーバー クラスター管理ツールを閉じます。

障害が発生したデータセンターでユニファイド メッセージング サービスが使用されている場合は、障害が発生したデータセンターへの通話ルーティングを防ぐために、それらのサービスを無効にする必要があります。 Disable-UMService コマンドレット (など) を使用して、Disable-UMService EX1ユニファイド メッセージング サービスを無効にすることができます。 または、VoIP (VoIP) ゲートウェイを使用している場合は、VoIP ゲートウェイからサーバー エントリを削除するか、VoIP ゲートウェイが DNS を使用して呼び出しをルーティングするように構成されている場合は、障害が発生したサーバーの DNS レコードを 2 番目のデータセンターのサーバーの IP アドレスを指すように変更することもできます。

注:

Exchange 2019 ではユニファイド メッセージングを使用できません

メールボックス サーバーのアクティブ化

データセンター切り替えの間にメールボックス サーバーをアクティブ化するために必要な手順もまた、DAG が DAC モードであるかどうかによって異なります。 第 2 データセンター内の DAG メンバーをアクティブ化する前に、第 2 データセンターのインフラストラクチャ サービスでメッセージング サービスのアクティブ化の準備ができていることを検証することをお勧めします。

DAG が DAC モードである場合、第 2 データセンター内のメールボックス サーバーのアクティブ化を完了する手順は、次のとおりです。

  1. 第 2 データセンターの各 DAG メンバーでクラスター サービスを停止する必要があります。 Stop-Service コマンドレットを使用してサービスを停止するか (例: )、Stop-Service ClusSvc管理者特権のコマンド プロンプトからを使用net stop clussvcできます。

  2. 次に、Restore-DatabaseAvailabilityGroup コマンドレットを使用してスタンバイ データセンター内のメールボックス サーバーをアクティブにします。 サービスの復元に使用するサーバーを識別し、DAG での代替監視サーバーの使用を構成するため、スタンバイ データセンターの Active Directory サイトが Restore-DatabaseAvailabilityGroup コマンドレットに渡されます。 代替監視サーバーが以前に構成されていない場合は、Restore-DatabaseAvailabilityGroup コマンドレットの AlternateWitnessServer パラメーターと AlternateWitnessDirectory パラメーターを使用して構成できます。 このコマンドが成功した場合、クォーラム条件がスタンバイ データセンターのサーバーに縮小されます。 データセンター内のサーバー数が偶数の場合、DAG は、DAG オブジェクトの設定によって識別されるように代替監視サーバーの使用に切り替えます。

  3. これで、データベースをアクティブ化できるようになります。 組織が使用する特定の構成によっては、自動でない可能性があります。 スタンバイ データセンター内のサーバーがアクティブ化ブロックの設定を持つ場合、システムは、データベースのプライマリ データセンターからスタンバイ データセンターへの自動フェールオーバーを実行しません。 スタンバイ データセンター内のデータベース コピーに対してフェールオーバーの制限が存在しない場合、システムは、第 2 データセンターのコピーを正常であると仮定してアクティブ化します。 データベースが、明示的な手動操作が必要なアクティブ化ブロック設定で構成されている場合、操作には 2 つの選択肢があります。

  4. アクティブ化をブロックする設定をオフにします。 これにより、システムが既定の動作に戻り、使用可能なコピーがアクティブ化されます。

  5. 設定を変更せずそのままにし、Move-ActiveMailboxDatabase コマンドレットを使用して、第 2 データセンターでデータベースのアクティブ化を完了します。 アクティブ化ブロックが設定されているときに Move-ActiveMailboxDatabase コマンドレットを使用してこの手順を完了するには、移動の対象を明示的に識別する必要があります。

  6. 最後の手順は、タスクからのすべてのエラーおよび警告メッセージを確認することです。 表示された警告をフォローアップおよび修正する必要があります。 これらのコマンドのタスク設計モデルでは、設計の基本的な目標を達成できない場合にのみ失敗するようになっています。 たとえば、 Restore-DatabaseAvailabilityGroup コマンドレットは、第 2 データセンター内のサーバーがクォーラムを停止させずにサービスを再開できるよう DAG のクォーラムを縮小できなかった場合に失敗します。 ただし、各タスクの出力は、管理者のフォローアップを必要とする問題の識別にも使用されます。 すべてのタスク出力を保存し、フォローアップ操作のために確認することを強くお勧めします。

DAG が DAC モードでない場合、第 2 データセンター内のメールボックス サーバーのアクティブ化を完了する手順は、次のとおりです。

  1. クォーラムは、第 2 データセンター内の DAG メンバー数に基づいて変更される必要があります。

  2. DAG メンバー数が奇数である場合、次のコマンドを実行して、DAG クォーラム モデルをノードおよびファイル共有マジョリティ クォーラムからノード マジョリティ クォーラムに変更します。

    cluster <DAGName> /quorum /nodemajority

  3. DAG メンバー数が偶数である場合、Exchange 管理シェルで次のコマンドを実行して、監視サーバーおよびディレクトリを再構成します。

    Set-DatabaseAvailabilityGroup <DAGName> -WitnessServer <ServerName>

  4. 次のコマンドを実行して、第 2 データセンター内の残りの DAG メンバーでクラスター サービスを開始します。

    net start clussvc

  5. サーバー切り替えを実行し、DAG メンバーごとに次のコマンドを実行して、DAG 内のメールボックス データベースをアクティブ化します。

    Move-ActiveMailboxDatabase -Server <DAGMemberinPrimarySite> -ActivateOnServer <DAGMemberinSecondSite>

  6. 次のコマンドを実行して、2 番目のサイトの DAG メンバーごとにメールボックス データベースをマウントします。

    Get-MailboxDatabase <DAGMemberinSecondSite> | Mount-Database

クライアント アクセス サービスのアクティブ化

クライアントは、サービス エンドポイント (Web 上の Outlook、自動検出、Exchange ActiveSync、Outlook Anywhere、POP3、IMAP4、RPC クライアント アクセス サービス アレイなど) に接続し、Exchange のサービスとデータにアクセスします。 したがって、クライアント アクセス サービスをアクティブ化すると、これらのサービス エンドポイントの DNS レコードのマッピングが、プライマリ データセンターの IP アドレスから新しいサービス エンドポイントとして構成される第 2 データセンターの IP アドレスに変更されます。 変更が必要な DNS レコードが同じ DNS ゾーンに存在するかどうかは、DNS 構成によって変わります。

クライアント アクセス サービスのアクティブ化

クライアントは、次の 2 つの方法のどちらかで新しいサービス エンドポイントに自動的に接続します。

  • クライアントは引き続き接続を試み、元の DNS エントリの TTL の有効期限が切れた後、およびクライアントの DNS キャッシュからエントリの有効期限が切れた後に自動的に接続する必要があります。 ユーザーはコマンド プロンプトからコマンドを ipconfig /flushdns 実行して、DNS キャッシュを手動でクリアすることもできます。

  • 開始または再起動するクライアントは起動時に DNS 参照を実行し、2 つ目のデータセンターでクライアント アクセス サービスを実行している Exchange サーバーまたはクライアント アクセス サービス配列となるサービス エンドポイントの新しい IP アドレスを取得します。

すべての適切な構成の変更が完了し、第 2 データセンターのサービスが、プライマリ データセンターのときと同様に機能するように定義および構成されていると仮定し、確立された DNS 構成が正しいと仮定すれば、クライアント アクセス サービスをアクティブ化するためにこれ以上の変更は必要ありません。

トランスポート サービスのアクティブ化

メッセージを送信するクライアントおよび他のサーバーは、通常、DNS を使用してこれらのサーバーを識別します。 第 2 データセンター内のトランスポート サービスのアクティブ化では、第 2 データセンターのメールボックス サーバーの IP アドレスをポイントするように DNS レコードを変更します。 クライアントおよび送信サーバーは、次の 2 つの方法のどちらかで第 2 データセンター内のサーバーに自動的に接続します。

  • クライアントは引き続き接続を試み、元の DNS エントリの TTL の有効期限が切れた後、およびクライアントの DNS キャッシュからエントリの有効期限が切れた後に自動的に接続する必要があります。 ユーザーはコマンド プロンプトからコマンドを ipconfig /flushdns 実行して、DNS キャッシュを手動でクリアすることもできます。

  • クライアントの起動または再起動は、スタートアップ時に DNS 参照を実行し、SMTP エンドポイントの新しい IP アドレスを取得します。これは、第 2 データセンター内のメールボックス サーバーです。

すべての適切な構成の変更が完了し、第 2 データセンターのサービスが、プライマリ データセンターのときと同様に機能するように定義および構成されていると仮定し、確立された DNS 構成が正しいと仮定すれば、トランスポート サービスをアクティブ化するためにこれ以上の変更は必要ありません。

Exchange 2016 でのユニファイド メッセージング サービスのアクティブ化

注:

ユニファイド メッセージングは Exchange 2019 では使用できません。

Exchange 2016 のユニファイド メッセージング (UM) サービスは、組織の PBX システムと電話回線に接続します。 PBX システムとユニファイド メッセージング サービス間の論理接続は、IP ゲートウェイによって提供されます。 IP ゲートウェイには高可用性機能が含まれ、障害が検出されたときに IP ゲートウェイは複数のユニファイド メッセージング サービス間で切り替わることができます。

2 つ目のデータセンターに、サイトの回復性ソリューション専用であるために無効状態であったユニファイド メッセージング サービスがある場合は、 Enable-UMService コマンドレット (たとえば Enable-UMService EX4) を使用して有効にすることができます。

IP ゲートウェイが DNS サーバーを使用してユニファイド メッセージング サービスに関連付けられていると仮定した場合、ユニファイド メッセージング ビスのアクティブ化では、第 2 データセンター内のユニファイド メッセージング サービス用に構成される新しい IP アドレスをポイントするように DNS レコードを変更します。 すべての適切な構成の変更が完了し、第 2 データセンターのサービスが、プライマリ データセンターのときと同様に機能するように定義および構成されていると仮定し、確立された DNS 構成が正しいと仮定すれば、ユニファイド メッセージング サービスをアクティブ化するためにこれ以上の変更は必要ありません。

使用中の IP ゲートウェイが DNS 名を使用したユニファイド メッセージング サービスの解決をサポートしない場合は、IP ゲートウェイを第 2 データセンター内のユニファイド メッセージング サービスの IP アドレスに手動でポイントするための追加の構成手順が必要です。

エッジ トランスポート サーバーのアクティブ化

エッジ トランスポート サーバーの役割をアクティブにするための手順は、特定の構成に応じて変化します。 2 つのデータセンター内のエッジ トランスポート サーバーは、アクティブ/パッシブまたはアクティブ/アクティブ構成で構成できます。 アクティブ/パッシブ構成では、第 2 データセンター内のエッジ トランスポート サーバーは、第 2 データセンターがアクティブになるまでアイドルです。 アクティブ/アクティブ構成では、両方のデータセンター内のエッジ トランスポート サーバーが常にメールを配信しています。

アクティブ/アクティブ構成では、第 2 データセンターのエッジ トランスポート サーバーは既に動作しているので、エッジ トランスポート サーバーをアクティブにする手順は必要ありません。 アクティブ/パッシブ構成では、各 SMTP ドメインの DNS MX リソース レコードを、プライマリ データセンターからスタンバイ データセンターへの切り替えの一部として更新する必要があります。 アクティブ/アクティブ構成は単純なデータセンター切り替えソリューションを提供しますが、アクティブ/アクティブ構成には、データセンターの切り替え後に第 2 データセンター内のエッジ トランスポート サーバーが、プライマリ データセンター内のエッジ トランスポート サーバーが使用できなくなった結果として増加した負荷のフローをサポートするための十分な容量を提供できることを確認するため、負荷を注意深く監視する必要があるという欠点があります。

アクティブ/アクティブ構成を使用した場合でも、データセンターの切り替え中にエッジ トランスポート サーバーの MX リソース レコードを更新することが適切な場合もあります。 障害が発生したデータセンターの MX リソース レコードで障害が発生したデータセンターをポイントし続けることを許可すると、データセンターが回復を開始したときに、そのエッジ トランスポート サーバーへの接続を試行し始める可能性があります。 これは、エッジ トランスポート サービスが (たとえば、データセンター内の依存サービスが復元中のため) 不安定な状態のときに発生します。

DNS レコードが組織の制御下にあると仮定すると、エッジ トランスポート サーバーのアクティブ化では、サーバーによってホストされる各 SMTP ドメインの MX リソース レコードを更新します。

注:

組織によって使用される MX リソース レコードが組織の制御下にある DNS サーバーによってホストされていない場合は、MX リソース レコードの CNAME レコードを参照し、更新可能な組織の制御下の CNAME レコードを使用することを考慮する必要があります。

DNS 更新は着信トラフィックを有効にし、発信トラフィックが、機能するエッジ トランスポート サーバーを持つサイトでメールボックス データベースのアクティブ化によって処理されます。

  • 着信 SMTP 接続が更新済みの名前解決情報を使用して開始されると、SMTP クライアントが第 2 データセンター内のエッジ トランスポート サーバーに接続します。 トラフィックがエッジ トランスポート サーバーによって適切にルーティングされ、これ以上の変更は必要ありません。

  • 発信 SMTP 接続が開始されると、ローカルで使用できるエッジ トランスポート サーバーを試み、これらのメッセージが、受信サーバーの状態に応じてキューに入れられるか、すぐに送信されます。

サービスのプライマリ データセンターへの復元

一般に、データセンターの障害は一時的または永続的です。 プライマリ データセンターの永続的な破壊を引き起こすイベントなど、永続的なエラーの場合、プライマリ データセンターがアクティブになる見込みはありません。 しかし、一時的なエラー (たとえば、長時間の電力消失や広範囲に及ぶものの修理可能な破損) の場合、プライマリ データセンターが最終的に完全サービスに復元される見込みがあります。

以前に障害が発生したデータセンターにサービスを復元するプロセスをスイッチバックといいます。 データセンターのスイッチバックの実行に使用する手順は、データセンターの切り替えの実行に使用する手順と似ています。 主な違いは、データセンターのスイッチバックはスケジュールされており、停止期間が通常、はるかに短い点です。

Exchange のインフラストラクチャとの依存関係が再アクティブ化され、機能し、安定しており、検証されるまで、スイッチバックを実行しないことが重要です。 これらの依存関係が使用できないか、または正常でない場合は、スイッチバック プロセスが必要な停止よりも長くなり、プロセスが完全に失敗する可能性があります。

メールボックス サーバーの役割のスイッチバック

メールボックス サーバーの役割は、プライマリ データセンターにスイッチバックされる最初の役割である必要があります。 次の手順で、メールボックス サーバーの役割のスイッチバック プロセスを詳しく示します。

  1. データセンターの切り替えプロセスの一部として、プライマリ データセンター内のメールボックス サーバーは停止状態に置かれました。 環境 (プライマリ データセンター、Exchange 依存関係、ワイド エリア ネットワーク (WAN) 接続など) が整っている場合、最初の手順は、復元されたプライマリ データセンターのメールボックス サーバーを開始状態に置き、それらを DAG に組み込むことです。 これを実行する方法は、DAG が DAC モードであるかどうかによって異なります。

    1. DAG が DAC モードである場合、Start-DatabaseAvailabilityGroup コマンドレットを使用して、DAG メンバーをプライマリ サイトに再度組み込むことができます。 次に、DAG で適切なクォーラム モデルが使用されていることを確認するために、DAG に対してパラメーターを指定せずに Set-DatabaseAvailabilityGroup コマンドレットを実行します。

    2. DAG が DAC モードでない場合、Add-DatabaseAvailabilityGroupServer コマンドレットを使用して、DAG メンバーを再度組み込むことができます。

  2. プライマリ データセンター内のメールボックス サーバーが DAG に組み込まれたら、データベース コピーを同期する必要があります。 障害の性質、停止の長さ、停止中に管理者が行った操作に応じて、データベース コピーの再シードが必要になる場合があります。 たとえば、停止中、第 2 データセンターの存続するアクティブなコピー用にログ ファイルの切り詰めを許可するため、障害が発生したプライマリ データセンターからデータベース コピーを削除する場合、再シードが必要になります。 各データベースは、個別にこのポイントから前方に進むことができます。 プライマリ データセンター内のレプリケートされるデータベース コピーが正常になったら、次の手順に進むことができます。

    注:

    このプロセスでは、すべてのデータベースを同時に移動する必要はありません。 組織の大部分のデータベースを一度に移動することをお勧めしますが、プライマリ データセンターにデータベース コピーに関連する問題がある場合は一部のデータベースを第 2 データセンターに残すことができます。

  3. プライマリ データセンターのデータベースの大部分が正常な状態になった後、スイッチバック停止をスケジュールできます。 スケジュールされた時刻に達したときに、次の手順を実行する必要があります。

    1. データセンターの切り替えプロセス中、DAG は代替監視サーバーを使用するように構成されました。 DAG は、プライマリ データセンター内の監視サーバーを使用するように再構成する必要があります。 プライマリ データセンターの停止前に使用されていたのと同じ監視サーバーと監視ディレクトリを使用している場合は、コマンドを Set-DatabaseAvailabilityGroup -Identity DAGName 実行できます。 元の監視サーバーや監視ディレクトリとは別の監視サーバーまたは監視ディレクトリを使用する予定の場合は、 Set-DatabaseAvailabilityGroup コマンドを使用して、監視サーバーと監視ディレクトリのパラメーターを適切な値で構成します。

    2. プライマリ データセンターで再アクティブ化するデータベースは、第 2 データセンターでマウント解除する必要があります。 Dismount-Database コマンドレットを使用して、データベースのマウントを解除することができます。

    3. データベースがマウント解除されたら、クライアント アクセス サービスを実行してる各サーバーの URL を第 2 データセンターからプライマリ データセンターに移動する必要があります。 この移動は、各 URL の DNS レコードを、プライマリ データセンター内のクライアント アクセス サービスのサーバーまたはアレイをポイントするように変更することで行います。 これにより、システムは、移動されるデータベースごとにデータベース フェールオーバーが発生したかのように動作します。

    重要

    クライアント アクセス サービスを実行してる各サーバーの URL が移動され、DNS TTL およびキャッシュ エントリの期限が切れるまで、次の手順に進まないでください。 各 URL をプライマリ データセンターに移動する前にプライマリ データセンターの各データベースをアクティブにすると、構成が無効になります (たとえば、マウントされたデータベースには、Active Directory サイトで実行中のクライアント アクセス サービスがない)。

  4. プライマリ データセンター内の各データベースは正常な状態であるため、データベースの切り替えを実行することでプライマリ データセンターでアクティブ化できます。 これには、アクティブにする各データベースに対して Move-ActiveMailboxDatabase コマンドレットを使用します。

  5. 各データベースをプライマリ データセンターに移動したら、Mount-Database コマンドレットを使用してマウントできます。

1 つ以上のデータベースがアクティブになり、プライマリ データセンターにマウントされたら、他のサーバーの役割のスイッチバック手順を実行できます。

クライアント アクセス サービスの切り替え

切り替え (スイッチオーバー) プロセスの一部として、クライアント アクセス サービス、トランスポートおよびユニファイド メッセージング サービス、エッジ トランスポート サーバーのサービス エンドポイントを解決するために、クライアント、他のサーバー、IP ゲートウェイによって使用される内部および外部 DNS レコードが、第 2 データセンターの対応するエンドポイントをポイントするように変更されました。 他のサーバーの役割のスイッチバック プロセスでは、プライマリ データセンターの復元されたサービス エンドポイントをポイントするようにこれらのレコードを変更します。

第 2 データセンターへの切り替え中に行われた DNS 変更の場合と同様、クライアント、サーバー、IP ゲートウェイは、引き続き接続を試み、TTL が元の DNS エントリに対して期限切れになった後、およびエントリが DNS キャッシュから期限切れになった後は自動的に接続します。

サイトの復元の再確立

プライマリ データセンターへのスイッチバックが正常に完了したら、第 2 データセンターで各メールボックス データベースのコピーの正常性と状態を確認することで、プライマリ データセンターのサイトの復元を再確立できます。 さらに、第 2 データセンターのデータベース コピーのアクティブ化がもともとブロックされている場合は、この時点で設定を再構成できます。