データセンター切り替えDatacenter switchovers

サイトの復元構成では、サイト レベルのエラーに対する自動回復が DAG 内で発生する場合があります。これにより、メッセージング システムは機能した状態のままになります。この設定では、DAG メンバーを 2 か所に展開し、DAG のミラーリング監視サーバーを残りの 1 か所に展開する必要があるため、少なくとも 3 つの場所が必要です。In a site resilient configuration, automatic recovery in response to a site-level failure can occur within a DAG, allowing the messaging system to remain in a functional state. This configuration requires at least three locations, as it requires deploying DAG members in two locations and the DAG's witness server in a third location.

3 つの場所が存在しない場合、または存在するものの、データセンター レベルの回復処理を制御したい場合は、サイト レベルの障害が発生した場合に備えて手動回復用に DAG を設定できます。If you don't have three locations, or even if you do have three locations but you want to control datacenter-level recovery actions, you can configure a DAG for manual recovery in the event of a site-level failure. その場合、データセンター切り替え と呼ばれるプロセスを実行します。In that event, you would perform a process called a datacenter switchover. 多くの障害回復シナリオと同様に、データセンターの切り替えを事前に計画および準備すると、回復プロセスを簡略化して停止期間を短縮できます。As with many disaster recovery scenarios, prior planning and preparation for a datacenter switchover can simplify your recovery process and reduce the duration of your outage.

第 2 データセンターをアクティブ化するための初期決定を行った後、4 つの基本手順に従ってデータセンター切り替えの実行を完了します。There are four basic steps that you complete to perform a datacenter switchover, after making the initial decision to activate the second datacenter:

  1. 部分的に実行されているデータセンターを終了する: この手順では、いずれかのサービスが実行中の場合、プライマリデータセンターでの Exchange サービスの終了を行います。Terminate a partially running datacenter: This step involves terminating Exchange services in the primary datacenter, if any services are still running. メールボックス サーバーの役割はアクティブ/パッシブの高可用性モデルを使用するため、メールボックス サーバーの役割には特に重要です。This is particularly important for the Mailbox server role because it uses an active/passive high availability model. 部分的に障害が発生したデータセンターでサービスを停止しないと、プライマリ データセンターに戻る時点で、部分的に障害が発生したデータセンターからの問題が、サービスに悪影響を及ぼす可能性があります。If services in a partially failed datacenter aren't stopped, it's possible for problems from the partially failed datacenter to negatively affect the services during a switchover back to the primary datacenter.

    重要

    プライマリ データセンターの障害の結果としてネットワークまたは Active Directory インフラストラクチャの信頼性が危険にさらされた場合は、これらの依存関係が正常なサービスに復元されるまで、すべてのメッセージング サービスをオフにすることをお勧めします。If network or Active Directory infrastructure reliability has been compromised as a result of the primary datacenter failure, we recommend that all messaging services be off until these dependencies are restored to healthy service.

  2. 2 番目のデータセンターの前提条件を検証して確認します。この手順は、手順1と並行して実行できます。第2データセンターのインフラストラクチャの正常性の検証は、最初のデータセンターから大きく独立しています。Validate and confirm the prerequisites for the second datacenter: This step can be performed in parallel with step 1 because validation of the health of the infrastructure in the second datacenter is largely independent of the first datacenter. 各組織には通常、この手順を実行するための独自の方法が必要です。Each organization typically requires its own method for performing this step. たとえば、インフラストラクチャ監視アプリケーションによって収集およびフィルタリングされた正常性情報を確認するか、組織のインフラストラクチャに固有のツールを使用して、この手順の完了を決定する場合があります。For example, you may decide to complete this step by reviewing health information collected and filtered by an infrastructure monitoring application, or by using a tool that's unique to your organization's infrastructure. これは、第 2 データセンターのインフラストラクチャが正常でなく不安定な状態のときに第 2 データセンターをアクティブ化したくないため、重要な手順です。This is a critical step, because you don't want to activate the second datacenter when its infrastructure is unhealthy and unstable.

  3. メールボックスサーバーをアクティブにする: この手順では、第2データセンターをアクティブ化するプロセスを開始します。Activate the Mailbox servers: This step begins the process of activating the second datacenter. Microsoft Exchange サービスでデータベースの停止と回復を処理できるため、この手順を手順 4 と並行して実行できます。This step can be performed in parallel with step 4 because the Microsoft Exchange services can handle database outages and recover. メールボックス サーバーのアクティブ化のプロセスでは、プライマリ データセンターからの障害のあるサーバーを利用できないようにマークした後、第 2 データセンターのサーバーをアクティブ化します。Activating the Mailbox servers involves a process of marking the failed servers from the primary datacenter as unavailable followed by activation of the servers in the second datacenter. メールボックス サーバーのアクティブ化プロセスは、DAG がデータベース アクティブ化調整 (DAC) モードであるかどうかによって異なります。The activation process for Mailbox servers depends on whether the DAG is in database activation coordination (DAC) mode. 詳細については、「 データセンター ライセンス認証調整モード」を参照してください。See Datacenter Activation Coordination mode for more information.

    DAG が DAC モードの場合、Exchange のサイト復元コマンドレットを使用して、部分的に障害が発生したデータセンターを停止 (必要な場合) し、メールボックス サーバーをアクティブ化できます。たとえば DAC モードでは、この手順を Stop-DatabaseAvailabilityGroup コマンドレットを使用して実行できます。場合によっては、サーバーを利用不可として 2 回マークする必要があります (データセンターごとに 1 回ずつ)。次に、 Restore-DatabaseAvailabilityGroup コマンドレットを実行して第 2 データセンターのデータベース可用性グループ (DAG) の残りのメンバーを復元するため、DAG メンバーをまだ動作しているメンバーまで減らし、それによってクォーラムを再確立します。DAG が DAC モードにない場合は、Windows のフェールオーバー クラスター ツールを使用してメールボックス サーバーをアクティブ化する必要があります。いずれかのプロセスが完了すると、第 2 データセンターでパッシブであったデータベース コピーがアクティブになりマウントできます。この時点で、メールボックス サーバーの復旧は完了です。If the DAG is in DAC mode, you can use the Exchange site resilience cmdlets to terminate a partially failed datacenter (if necessary) and activate the Mailbox servers. For example, in DAC mode, this step is performed by using the Stop-DatabaseAvailabilityGroup cmdlet. In some cases, the servers must be marked as unavailable twice (once in each datacenter). Next, the Restore-DatabaseAvailabilityGroup cmdlet is run to restore the remaining members of the database availability group (DAG) in the second datacenter by reducing the DAG members to those that are still operational, thereby reestablishing quorum. If the DAG isn't in DAC mode, you must use the Windows Failover Cluster tools to activate the Mailbox servers. After either process is complete, the database copies that were previously passive in the second datacenter can become active and be mounted. At this point, Mailbox server recovery is complete.

  4. クライアントアクセスサービスをアクティブ化する: 必要なすべての dns 更新を実行するには、URL マッピング情報とドメインネームシステム (DNS) 変更方法を使用する必要があります。Activate Client Access services: This involves using the URL mapping information and the Domain Name System (DNS) change methodology to perform all required DNS updates. マッピング情報は、実行する DNS 変更について記述します。The mapping information describes what DNS changes to perform. 更新を完了するために必要な時間は、使用される方法および DNS レコードでの TTL (Time to Live) 設定 (および展開のインフラストラクチャが TTL を許可するかどうか) に依存します。The amount of time required to complete the update depends on the methodology used and the Time to Live (TTL) settings on the DNS record (and whether the deployment's infrastructure honors the TTL).

手順 3 および 4 を完了してしばらくしたら、ユーザーがメッセージング サービスにアクセスできるようになります。手順 3 および 4 については、後で詳しく説明します。Users should start to have access to messaging services sometime after steps 3 and 4 are completed. Steps 3 and 4 are described in greater detail later in this topic.

部分的に障害が発生したデータセンターの終了Terminating a Partially Failed Datacenter

障害が発生したデータセンターの DAG メンバーがまだ動作している場合は、サービスを終了する必要があります。If any DAG members in the failed datacenter are still running, they should be terminated.

Exchange DAG が DAC モードの場合、障害が発生したデータセンター内のサーバーを1つのコマンドで無効にすることができます。When the Exchange DAG is in DAC mode, you can disable the servers in a failed datacenter with a single command. これにより、DAG にクォーラムがない場合でも、別のデータセンターにデータベースをマウントできます (DAG のメンバーの半数以上)。This will allow you to mount the databases in another datacenter even if the DAG doesn't have quorum (more than half the members of the DAG available).

DAG が DAC モードの場合、プライマリ データセンターの残存 DAG メンバーを終了するための特定の操作は以下のとおりです。When the DAG is in DAC mode, the specific actions to terminate any surviving DAG members in the primary datacenter are as follows:

  1. プライマリデータセンターの DAG メンバーは、プライマリデータセンターで停止としてマークされている必要があります。The DAG members in the primary datacenter must be marked as stopped in the primary datacenter. [停止] は、データベースがマウントされないようにするアクティブマネージャーの状態で、障害が発生したデータセンターの各サーバーのアクティブマネージャーは、 Stop-databaseavailabilitygroupコマンドレットを使用してこの状態に入ります。Stopped is a state of Active Manager that prevents databases from mounting, and Active Manager on each server in the failed datacenter is put into this state by using the Stop-DatabaseAvailabilityGroup cmdlet. このコマンドレットの_ActiveDirectorySite_パラメーターを使用すると、プライマリデータセンター内のすべてのサーバーを停止として、1つのコマンドでマークできます。The ActiveDirectorySite parameter of this cmdlet can be used to mark all of the servers in the primary datacenter as stopped with a single command. エラーによっては、この手順を実行できない場合があります。This step may not be possible depending on the failure. データセンターの状態によって許可されている場合は、この手順を実行する必要があります。This step should be taken if the state of the datacenter permits it. プライマリデータセンター内のすべてのサーバーに対して、データベースの停止コマンドレットを実行する必要があります。The Stop-DatabaseAvailabilityGroup cmdlet should be run against all servers in the primary datacenter. メールボックスサーバーが利用できないが、Active Directory がプライマリデータセンターで稼働している場合は、この状態のすべてのサーバーに対して_Configurationonly_パラメーターを指定して、 Stop-databaseavailabilitygroupコマンドを実行する必要があります。データセンターまたはメールボックスサーバーの電源をオフにする必要があります。If the Mailbox server is unavailable but Active Directory is operating in the primary datacenter, the Stop-DatabaseAvailabilityGroup command with the ConfigurationOnly parameter must be run against all servers in this state in the primary datacenter, or the Mailbox server must be turned off. 障害が発生したデータセンターのメールボックスサーバーをオフにするか、 **** またはサーバーに対して現象を正常に実行するには、2つのデータセンター間でスプリットブレインが発生する可能性があります。Failure to either turn off the Mailbox servers in the failed datacenter or to successfully perform the Stop-DatabaseAvailabilityGroup command against the servers will create the potential for split-brain syndrome to occur across the two datacenters. この要件を満たすために、コンピューターを電源管理デバイスを使用して個別にオフにする必要がある場合があります。You may need to individually turn off computers through power management devices to satisfy this requirement.

  2. どのプライマリ データセンターのサーバーが停止されているかを表すために第 2 データセンターを更新する必要があります。The second datacenter must now be updated to represent which primary datacenter servers are stopped. これを行うには、同じ_ActiveDirectorySite_パラメーターを使用し、失敗したプライマリで Active Directory サイトの名前を指定して、 _configurationonly_パラメーターを使用して同じStop-databaseavailabilitygroupコマンドを実行します。データセンター.This is done by running the same Stop-DatabaseAvailabilityGroup command with the ConfigurationOnly parameter using the same ActiveDirectorySite parameter and specifying the name of the Active Directory site in the failed primary datacenter. この手順の目的は、第 2 データセンター内のサーバーに、サービスの復元時にどのメールボックス サーバーが使用できるかについて通知することです。The purpose of this step is to inform the servers in the second datacenter about which mailbox servers are available to use when restoring service.

DAG が DAC モードではない場合、プライマリ データセンターの残存 DAG メンバーを終了するための特定の操作は以下のとおりです。When the DAG isn't in DAC mode, the specific actions to terminate any surviving DAG members in the primary datacenter are as follows:

  1. プライマリ データセンターの DAG メンバーは、メンバーごとに次のコマンドを実行して、DAG の基になるクラスターから強制的に削除される必要があります。The DAG members in the primary datacenter must be forcibly evicted from the DAG's underlying cluster by running the following commands on each member:
net stop clussvc
cluster <DAGName> node <DAGMemberName> /forcecleanup
  1. この際、第 2 データセンター内の DAG メンバーを再起動して、第 2 データセンターからの削除プロセスを完了するために使用する必要があります。第 2 データセンター内の各 DAG メンバーで、メンバーごとに次のコマンドを実行してクラスター サービスを停止します。The DAG members in the second datacenter must now be restarted and then used to complete the eviction process from the second datacenter. Stop the Cluster service on each DAG member in the second datacenter by running the following command on each member:
net stop clussvc
  1. 第 2 データセンター内の各 DAG メンバーで、次のコマンドを実行してクラスター サービスのクォーラム開始を強制します。On a DAG member in the second datacenter, force a quorum start of the Cluster service by running the following command:
net start clussvc /forcequorum
  1. フェールオーバー クラスター管理ツールを開き、DAG の基になるクラスターに接続します。クラスターを展開し、 [ノード] を展開します。プライマリ データセンターの各ノードを右クリックし、 [他の操作] に続いて [削除] を選択します。プライマリ データセンターの DAG メンバーの削除を完了後、フェールオーバー クラスター管理ツールを閉じます。Open the Failover Cluster Management tool and connect to the DAG's underlying cluster. Expand the cluster, and then expand Nodes. Right-click each node in the primary datacenter, select More Actions, and then select Evict. When you're done evicting the DAG members in the primary datacenter, close the Failover Cluster Management tool.

エラーが発生したデータセンターでユニファイドメッセージングサービスが使用されている場合は、そのサービスを無効にして、障害が発生したデータセンターへの通話のルーティングを禁止する必要があります。If any Unified Messaging services are in use in the failed datacenter, they must be disabled to prevent call routing to the failed datacenter. Um サービスコマンドレット (たとえば、 Disable-UMService EX1) を使用して、ユニファイドメッセージングサービスを無効にすることができます。You can disable Unified Messaging services by using the Disable-UMService cmdlet (for example, Disable-UMService EX1). または、ボイスオーバー IP (VoIP) ゲートウェイを使用している場合は、voip ゲートウェイからサーバーエントリを削除することも、障害が発生したサーバーの DNS レコードが第2データセンターのサーバーの IP アドレスを指すように変更することもできます (VoIP ゲートウェイの場合)。DNS を使用して通話をルーティングするように構成されます。Alternatively, if you're using a Voice over IP (VoIP) gateway, you can also remove the server entries from the VoIP gateway, or change the DNS records for the failed servers to point to the IP address of the servers in the second datacenter if your VoIP gateway is configured to route calls using DNS.

注意

ユニファイドメッセージングは、Exchange 2019 では使用できません。Unified Messaging is not available in Exchange 2019

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

データセンター切り替えの間にメールボックス サーバーをアクティブ化するために必要な手順もまた、DAG が DAC モードであるかどうかによって異なります。第 2 データセンター内の DAG メンバーをアクティブ化する前に、第 2 データセンターのインフラストラクチャ サービスでメッセージング サービスのアクティブ化の準備ができていることを検証することをお勧めします。The steps needed to activate Mailbox servers during a datacenter switchover also depend on whether the DAG is in DAC mode. Before activating the DAG members in the second datacenter, we recommend that you validate that the infrastructure services in the second datacenter are ready for messaging service activation.

DAG が DAC モードである場合、第 2 データセンター内のメールボックス サーバーのアクティブ化を完了する手順は、次のとおりです。When the DAG is in DAC mode, the steps to complete activation of the mailbox servers in the second datacenter are as follows:

  1. 第 2 データセンターの各 DAG メンバーでクラスター サービスを停止する必要があります。The Cluster service must be stopped on each DAG member in the second datacenter. Stop serviceコマンドレットを使用して、サービスを停止 (たとえば、 Stop-Service ClusSvc)、管理者特権net stop clussvcでのコマンドプロンプトから使用することができます。You can use the Stop-Service cmdlet to stop the service (for example, Stop-Service ClusSvc), or use net stop clussvc from an elevated command prompt.

  2. 次に、Restore-DatabaseAvailabilityGroup コマンドレットを使用してスタンバイ データセンター内のメールボックス サーバーをアクティブにします。The Mailbox servers in the standby datacenter are then activated by using the Restore-DatabaseAvailabilityGroup cmdlet. サービスの復元に使用するサーバーを識別し、DAG での代替監視サーバーの使用を構成するため、スタンバイ データセンターの Active Directory サイトが Restore-DatabaseAvailabilityGroup コマンドレットに渡されます。The Active Directory site of the standby datacenter is passed to the Restore-DatabaseAvailabilityGroup cmdlet to identify which servers to use to restore service and to configure the DAG to use an alternate witness server. 代替ミラーリング監視サーバーが以前に構成されていなかった場合は、 _AlternateWitnessServer_パラメーターと_AlternateWitnessDirectory_パラメーターを使用して、 Restore-databaseavailabilitygroupコマンドレットのパラメーターを構成できます。If the alternate witness server wasn't previously configured, you can configure it by using the AlternateWitnessServer and AlternateWitnessDirectory parameters of the Restore-DatabaseAvailabilityGroup cmdlet. このコマンドが成功した場合、クォーラム条件がスタンバイ データセンターのサーバーに縮小されます。If this command succeeds, the quorum criteria are shrunk to the servers in the standby datacenter. データセンター内のサーバー数が偶数の場合、DAG は、DAG オブジェクトの設定によって識別されるように代替監視サーバーの使用に切り替えます。If the number of servers in that datacenter is an even number, the DAG will switch to using the alternate witness server as identified by the setting on the DAG object.

  3. これで、データベースをアクティブ化できるようになります。組織が使用する特定の構成によっては、自動でない可能性があります。スタンバイ データセンター内のサーバーがアクティブ化ブロックの設定を持つ場合、システムは、データベースのプライマリ データセンターからスタンバイ データセンターへの自動フェールオーバーを実行しません。スタンバイ データセンター内のデータベース コピーに対してフェールオーバーの制限が存在しない場合、システムは、第 2 データセンターのコピーを正常であると仮定してアクティブ化します。データベースが、明示的な手動操作が必要なアクティブ化ブロック設定で構成されている場合、操作には 2 つの選択肢があります。The databases can now be activated. Depending on the specific configuration used by the organization, this may not be automatic. If the servers in the standby datacenter have an activation blocked setting, the system won't do an automatic failover from the primary datacenter to the standby datacenter of any database. If no failover restrictions are present for any of the database copies in the standby datacenter, the system will activate copies in the second datacenter assuming they are healthy. If databases are configured with an activation blocked setting that requires explicit manual action, there are two choices for action:

  4. アクティブ化をブロックする設定をオフにします。これにより、システムが既定の動作に戻り、使用可能なコピーがアクティブ化されます。Clear the setting that blocks activation. This will make the system return to its default behavior, which is to activate any available copy.

  5. 設定を変更せずそのままにし、Move-ActiveMailboxDatabase コマンドレットを使用して、第 2 データセンターでデータベースのアクティブ化を完了します。アクティブ化ブロックが設定されているときに Move-ActiveMailboxDatabase コマンドレットを使用してこの手順を完了するには、移動の対象を明示的に識別する必要があります。Leave the setting unchanged and use the Move-ActiveMailboxDatabase cmdlet to complete the database activation in the second datacenter. To complete this step using the Move-ActiveMailboxDatabase cmdlet when activation blocked is set, you must explicitly identify the target of the move.

  6. 最後の手順は、タスクからのすべてのエラーおよび警告メッセージを確認することです。表示された警告をフォローアップおよび修正する必要があります。これらのコマンドのタスク設計モデルでは、設計の基本的な目標を達成できない場合にのみ失敗するようになっています。たとえば、 Restore-DatabaseAvailabilityGroup コマンドレットは、第 2 データセンター内のサーバーがクォーラムを停止させずにサービスを再開できるよう DAG のクォーラムを縮小できなかった場合に失敗します。ただし、各タスクの出力は、管理者のフォローアップを必要とする問題の識別にも使用されます。すべてのタスク出力を保存し、フォローアップ操作のために確認することを強くお勧めします。The last step is to review all error and warning messages from the tasks. Any indicated warnings should be followed up and corrected. The task design model for these commands is to only fail if they can't achieve the fundamental goal of their design. For example, the Restore-DatabaseAvailabilityGroup cmdlet will fail if it can't shrink the quorum of the DAG to allow a server in the second datacenter to be restarted for servicing without causing a quorum outage. However, each task's output is also used to identify the issues that require administrator follow-up. You're strongly encouraged to save all task output and review it for follow-up actions.

DAG が DAC モードでない場合、第 2 データセンター内のメールボックス サーバーのアクティブ化を完了する手順は、次のとおりです。When the DAG isn't in DAC mode, the steps to complete activation of the mailbox servers in the second datacenter are as follows:

  1. クォーラムは、第 2 データセンター内の DAG メンバー数に基づいて変更される必要があります。The quorum must be modified based on the number of DAG members in the second datacenter.

  2. DAG メンバー数が奇数である場合、次のコマンドを実行して、DAG クォーラム モデルをノードおよびファイル共有マジョリティ クォーラムからノード マジョリティ クォーラムに変更します。If there's an odd number of DAG members, change the DAG quorum model from a Node a File Share Majority to a Node Majority quorum by running the following command:

cluster <DAGName> /quorum /nodemajority
  1. DAG メンバー数が偶数である場合、Exchange 管理シェルで次のコマンドを実行して、監視サーバーおよびディレクトリを再構成します。If there's an even number of DAG members, reconfigure the witness server and directory by running the following command in the Exchange Management Shell:
Set-DatabaseAvailabilityGroup <DAGName> -WitnessServer <ServerName>
  1. 次のコマンドを実行して、第 2 データセンター内の残りの DAG メンバーでクラスター サービスを開始します。Start the Cluster service on any remaining DAG members in the second datacenter by running the following command:
net start clussvc
  1. サーバー切り替えを実行し、DAG メンバーごとに次のコマンドを実行して、DAG 内のメールボックス データベースをアクティブ化します。Perform server switchovers to activate the mailbox databases in the DAG by running the following command for each DAG member:
Move-ActiveMailboxDatabase -Server <DAGMemberinPrimarySite> -ActivateOnServer <DAGMemberinSecondSite>
  1. 次のコマンドを実行して、2 番目のサイトの DAG メンバーごとにメールボックス データベースをマウントします。Mount the mailbox databases on each DAG member in the second site by running the following command:
Get-MailboxDatabase <DAGMemberinSecondSite> | Mount-Database

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

クライアントは、サービス エンドポイント (Web 上の Outlook、自動検出、Exchange ActiveSync、Outlook Anywhere、POP3、IMAP4、RPC クライアント アクセス サービス アレイなど) に接続し、Exchange のサービスとデータにアクセスします。したがって、クライアント アクセス サービスをアクティブ化すると、これらのサービス エンドポイントの DNS レコードのマッピングが、プライマリ データセンターの IP アドレスから新しいサービス エンドポイントとして構成される第 2 データセンターの IP アドレスに変更されます。変更が必要な DNS レコードが同じ DNS ゾーンに存在するかどうかは、DNS 構成によって変わります。Clients connect to service endpoints (for example Outlook on the web, Autodiscover, Exchange ActiveSync, Outlook Anywhere, POP3, IMAP4, and the RPC Client Access services array) to access Exchange services and data. Therefore, activating Client Access services involves changing the mapping of the DNS records for these service endpoints from IP addresses in the primary datacenter to the IP addresses in the second datacenter that are configured as the new service endpoints. Depending on your DNS configuration, the DNS records that need to be modified may or may not be in the same DNS zone.

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

クライアントは、次の 2 つの方法のどちらかで新しいサービス エンドポイントに自動的に接続します。Clients will then automatically connect to the new service endpoints in one of two ways:

  • クライアントは引き続き接続を試み、元の DNS エントリの TTL の期限が切れた後、およびクライアントの DNS キャッシュからエントリが期限切れになった後に自動的に接続します。Clients will continue to try to connect, and should automatically connect after the TTL has expired for the original DNS entry, and after the entry is expired from the client's DNS cache. ユーザーは、コマンドプロンプトipconfig /flushdnsからコマンドを実行して、手動で DNS キャッシュを消去することもできます。Users can also run the ipconfig /flushdns command from a command prompt to manually clear their DNS cache.

  • クライアントが開始または再起動すると、起動時に DNS 参照が実行され、2番目のデータセンターでクライアントアクセスサービスを実行している Exchange サーバーまたはクライアントアクセスサービスのアレイであるサービスエンドポイントの新しい IP アドレスが取得されます。Clients starting or restarting will perform a DNS lookup on startup and will get the new IP address for the service endpoint, which will be an Exchange server running Client Access services, or a Client Access services array, in the second datacenter.

すべての適切な構成の変更が完了し、第 2 データセンターのサービスが、プライマリ データセンターのときと同様に機能するように定義および構成されていると仮定し、確立された DNS 構成が正しいと仮定すれば、クライアント アクセス サービスをアクティブ化するためにこれ以上の変更は必要ありません。Assuming that all appropriate configuration changes have been completed to define and configure the services in the second datacenter to function as they were in the primary datacenter, and assuming that the established DNS configuration is correct, no further changes should be needed to activate Client Access services.

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

メッセージを送信するクライアントおよび他のサーバーは、通常、DNS を使用してこれらのサーバーを識別します。第 2 データセンター内のトランスポート サービスのアクティブ化では、第 2 データセンターのメールボックス サーバーの IP アドレスをポイントするように DNS レコードを変更します。クライアントおよび送信サーバーは、次の 2 つの方法のどちらかで第 2 データセンター内のサーバーに自動的に接続します。Clients and other servers that submit messages typically identify those servers using DNS. Activating transport services in the second datacenter involves changing DNS records to point to the IP addresses of the Mailbox servers in the second datacenter. Clients and sending servers will then automatically connect to the servers in the second datacenter in one of two ways:

  • クライアントは引き続き接続を試み、元の DNS エントリの TTL の期限が切れた後、およびクライアントの DNS キャッシュからエントリが期限切れになった後に自動的に接続します。Clients will continue to try to connect, and should automatically connect after the TTL has expired for the original DNS entry, and after the entry is expired from the client's DNS cache. ユーザーは、コマンドプロンプトipconfig /flushdnsからコマンドを実行して、手動で DNS キャッシュを消去することもできます。Users can also run the ipconfig /flushdns command from a command prompt to manually clear their DNS cache.

  • クライアントの起動または再起動は、スタートアップ時に DNS 参照を実行し、SMTP エンドポイントの新しい IP アドレスを取得します。これは、第 2 データセンター内のメールボックス サーバーです。Clients starting or restarting will perform a DNS lookup on startup and will get the new IP address for the SMTP endpoint, which will be a Mailbox server in the second datacenter.

すべての適切な構成の変更が完了し、第 2 データセンターのサービスが、プライマリ データセンターのときと同様に機能するように定義および構成されていると仮定し、確立された DNS 構成が正しいと仮定すれば、トランスポート サービスをアクティブ化するためにこれ以上の変更は必要ありません。Assuming that all appropriate configuration changes have been completed to define and configure the services in the second datacenter to function as they were in the primary datacenter, and assuming that the established DNS configuration is correct, no further changes should be needed to activate transport services.

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

注意

ユニファイド メッセージングは Exchange 2019 では使用できません。Unified Messaging is not available in Exchange 2019.

Exchange 2016 のユニファイドメッセージング (UM) サービスは、組織の PBX システムと電話回線に接続します。Unified Messaging (UM) services in Exchange 2016 connect to an organization's PBX system and phone lines. PBX システムとユニファイド メッセージング サービス間の論理接続は、IP ゲートウェイによって提供されます。The logical connection between the PBX system and the Unified Messaging service is provided by an IP gateway. IP ゲートウェイには高可用性機能が含まれ、障害が検出されたときに IP ゲートウェイは複数のユニファイド メッセージング サービス間で切り替わることができます。IP gateways include high availability functionality and are able to switch between multiple Unified Messaging services when a failure is detected.

2番目のデータセンターに、サイト復元ソリューション専用になっているために無効になっていたユニファイドメッセージングサービスがある場合は、 Enable-UMServiceコマンドレットを使用しEnable-UMService EX4て有効にすることができます (例:)。If there are Unified Messaging services in the second datacenter that were in a disabled state because they are dedicated to the site resilience solution, they can be enabled by using the Enable-UMService cmdlet (for example, Enable-UMService EX4).

IP ゲートウェイが DNS サーバーを使用してユニファイド メッセージング サービスに関連付けられていると仮定した場合、ユニファイド メッセージング ビスのアクティブ化では、第 2 データセンター内のユニファイド メッセージング サービス用に構成される新しい IP アドレスをポイントするように DNS レコードを変更します。すべての適切な構成の変更が完了し、第 2 データセンターのサービスが、プライマリ データセンターのときと同様に機能するように定義および構成されていると仮定し、確立された DNS 構成が正しいと仮定すれば、ユニファイド メッセージング サービスをアクティブ化するためにこれ以上の変更は必要ありません。Assuming the IP gateways are associated with Unified Messaging services by using DNS servers, activating Unified Messaging services therefore involves changing DNS records to point to the new IP addresses that will be configured for the Unified Messaging service in the second datacenter. Assuming that all appropriate configuration changes have been completed to define and configure the services in the second datacenter to function as they were in the primary datacenter, and assuming that the established DNS configuration is correct, no further changes should be needed to activate Unified Messaging services.

使用中の IP ゲートウェイが DNS 名を使用したユニファイド メッセージング サービスの解決をサポートしない場合は、IP ゲートウェイを第 2 データセンター内のユニファイド メッセージング サービスの IP アドレスに手動でポイントするための追加の構成手順が必要です。If the IP gateway in use doesn't support the use of DNS names to resolve the Unified Messaging services, additional configuration steps will be necessary to manually point the IP gateway to the IP addresses of the Unified Messaging services in the second datacenter.

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

エッジ トランスポート サーバーの役割をアクティブにするための手順は、特定の構成に応じて変化します。2 つのデータセンター内のエッジ トランスポート サーバーは、アクティブ/パッシブまたはアクティブ/アクティブ構成で構成できます。アクティブ/パッシブ構成では、第 2 データセンター内のエッジ トランスポート サーバーは、第 2 データセンターがアクティブになるまでアイドルです。アクティブ/アクティブ構成では、両方のデータセンター内のエッジ トランスポート サーバーが常にメールを配信しています。The steps to activate the Edge Transport server role will vary, depending on the specific configuration. Edge Transport servers in two datacenters can be configured in either an active/passive or an active/active configuration. In an active/passive configuration, the Edge Transport server in the second datacenter is idle until the second datacenter is activated. In an active/active configuration, Edge Transport servers in both datacenters are delivering mail at all times.

アクティブ/アクティブ構成では、第 2 データセンターのエッジ トランスポート サーバーは既に動作しているので、エッジ トランスポート サーバーをアクティブにする手順は必要ありません。アクティブ/パッシブ構成では、各 SMTP ドメインの DNS MX リソース レコードを、プライマリ データセンターからスタンバイ データセンターへの切り替えの一部として更新する必要があります。アクティブ/アクティブ構成は単純なデータセンター切り替えソリューションを提供しますが、アクティブ/アクティブ構成には、データセンターの切り替え後に第 2 データセンター内のエッジ トランスポート サーバーが、プライマリ データセンター内のエッジ トランスポート サーバーが使用できなくなった結果として増加した負荷のフローをサポートするための十分な容量を提供できることを確認するため、負荷を注意深く監視する必要があるという欠点があります。In an active/active configuration, no steps are necessary to activate the second datacenter's Edge Transport servers because they are already running. In an active/passive configuration, the DNS MX resource record for each SMTP domain needs to be updated as part of the switchover from the primary datacenter to the standby datacenter. Although the active/active configuration provides a simple datacenter switchover solution, it has the drawback of requiring careful load monitoring to make sure that after the datacenter switchover, the Edge Transport servers in the second datacenter can provide sufficient capacity to support the increased load now flowing through it, as a result of the Edge Transport servers in the primary datacenter being unavailable.

アクティブ/アクティブ構成を使用した場合でも、データセンターの切り替え中にエッジ トランスポート サーバーの MX リソース レコードを更新することが適切な場合もあります。障害が発生したデータセンターの MX リソース レコードで障害が発生したデータセンターをポイントし続けることを許可すると、データセンターが回復を開始したときに、そのエッジ トランスポート サーバーへの接続を試行し始める可能性があります。これは、エッジ トランスポート サービスが (たとえば、データセンター内の依存サービスが復元中のため) 不安定な状態のときに発生します。Even with an active/active configuration, it may be appropriate to update the MX resource records for your Edge Transport servers during a datacenter switchover. Allowing the MX resource record for the failed datacenter to continue to point at the failed datacenter means that when the datacenter starts recovering, it could start experiencing connection attempts to its Edge Transport servers. This could happen while the Edge Transport services are in an unstable state (for example, because dependent services in the datacenter are being restored).

DNS レコードが組織の制御下にあると仮定すると、エッジ トランスポート サーバーのアクティブ化では、サーバーによってホストされる各 SMTP ドメインの MX リソース レコードを更新します。Assuming the DNS records are under the control of the organization, activating Edge Transport servers involves updating the MX resource record for each SMTP domain hosted by the server.

注意

組織によって使用される MX リソース レコードが組織の制御下にある DNS サーバーによってホストされていない場合は、MX リソース レコードの CNAME レコードを参照し、更新可能な組織の制御下の CNAME レコードを使用することを考慮する必要があります。If the MX resource record used by your organization isn't hosted by a DNS server under your organization's control, you might consider referencing a CNAME record in the MX resource record and using a CNAME record under the organization's control that can then be updated.

DNS 更新は着信トラフィックを有効にし、発信トラフィックが、機能するエッジ トランスポート サーバーを持つサイトでメールボックス データベースのアクティブ化によって処理されます。DNS updates enable incoming traffic, and outgoing traffic is handled by the activation of the mailbox databases in a site that has functioning Edge Transport servers:

  • 着信 SMTP 接続が更新済みの名前解決情報を使用して開始されると、SMTP クライアントが第 2 データセンター内のエッジ トランスポート サーバーに接続します。トラフィックがエッジ トランスポート サーバーによって適切にルーティングされ、これ以上の変更は必要ありません。When incoming SMTP connections are initiated using the updated name resolution information, SMTP clients will connect to the Edge Transport servers in the second datacenter. Traffic will be appropriately routed by the Edge Transport server, and no further changes are required.

  • 発信 SMTP 接続が開始されると、ローカルで使用できるエッジ トランスポート サーバーを試み、これらのメッセージが、受信サーバーの状態に応じてキューに入れられるか、すぐに送信されます。When outgoing SMTP connections are initiated, they will try the locally available Edge Transport server, and those messages will be queued or immediately sent based on the status of the receiving server.

サービスのプライマリ データセンターへの復元Restoring Service to the Primary Datacenter

一般に、データセンターの障害は一時的または永続的です。プライマリ データセンターの永続的な破壊を引き起こすイベントなど、永続的なエラーの場合、プライマリ データセンターがアクティブになる見込みはありません。しかし、一時的なエラー (たとえば、長時間の電力消失や広範囲に及ぶものの修理可能な破損) の場合、プライマリ データセンターが最終的に完全サービスに復元される見込みがあります。Generally, datacenter failures are either temporary or permanent. With a permanent failure, such as an event that has caused the permanent destruction of a primary datacenter, there's no expectation that the primary datacenter will be activated. However, with a temporary failure (for example, an extended power loss or extensive but repairable damage), there's an expectation that the primary datacenter will eventually be restored to full service.

以前に障害が発生したデータセンターにサービスを復元するプロセスをスイッチバックといいます。データセンターのスイッチバックの実行に使用する手順は、データセンターの切り替えの実行に使用する手順と似ています。主な違いは、データセンターのスイッチバックはスケジュールされており、停止期間が通常、はるかに短い点です。The process of restoring service to a previously failed datacenter is referred to as a switchback. The steps used to perform a datacenter switchback are similar to the steps used to perform a datacenter switchover. A significant distinction is that datacenter switchbacks are scheduled, and the duration of the outage is often much shorter.

Exchange のインフラストラクチャとの依存関係が再アクティブ化され、機能し、安定しており、検証されるまで、スイッチバックを実行しないことが重要です。これらの依存関係が使用できないか、または正常でない場合は、スイッチバック プロセスが必要な停止よりも長くなり、プロセスが完全に失敗する可能性があります。It's important that switchback not be performed until the infrastructure dependencies for Exchange have been reactivated, are functioning and stable, and have been validated. If these dependencies aren't available or healthy, it's likely that the switchback process will cause a longer than necessary outage, and the process could fail altogether.

メールボックス サーバーの役割のスイッチバックMailbox Server Role Switchback

メールボックス サーバーの役割は、プライマリ データセンターにスイッチバックされる最初の役割である必要があります。次の手順で、メールボックス サーバーの役割のスイッチバック プロセスを詳しく示します。The Mailbox server role should be the first role that's switched back to the primary datacenter. The following steps detail the Mailbox server role switchback process:

  1. データセンターの切り替えプロセスの一部として、プライマリ データセンター内のメールボックス サーバーは停止状態に置かれました。環境 (プライマリ データセンター、Exchange 依存関係、ワイド エリア ネットワーク (WAN) 接続など) が整っている場合、最初の手順は、復元されたプライマリ データセンターのメールボックス サーバーを開始状態に置き、それらを DAG に組み込むことです。これを実行する方法は、DAG が DAC モードであるかどうかによって異なります。As part of the datacenter switchover process, the Mailbox servers in the primary datacenter were put into a stopped state. When the environment (such as primary datacenter, Exchange dependencies, and wide area network (WAN) connectivity) is ready, the first step is to put the Mailbox servers in the restored primary datacenter into a started state and incorporate them into the DAG. The way in which this is done depends on whether the DAG is in DAC mode.

  2. DAG が DAC モードである場合、Start-DatabaseAvailabilityGroup コマンドレットを使用して、DAG メンバーをプライマリ サイトに再度組み込むことができます。次に、DAG で適切なクォーラム モデルが使用されていることを確認するために、DAG に対してパラメーターを指定せずに Set-DatabaseAvailabilityGroup コマンドレットを実行します。If the DAG is in DAC mode, you can reincorporate the DAG members in the primary site by using the Start-DatabaseAvailabilityGroup cmdlet. Then, to make sure that the proper quorum model is being used by the DAG, run the Set-DatabaseAvailabilityGroup cmdlet against the DAG without specifying any parameters.

  3. DAG が DAC モードでない場合、Add-DatabaseAvailabilityGroupServer コマンドレットを使用して、DAG メンバーを再度組み込むことができます。If the DAG isn't in DAC mode, you can reincorporate the DAG members by using the Add-DatabaseAvailabilityGroupServer cmdlet.

  4. プライマリ データセンター内のメールボックス サーバーが DAG に組み込まれたら、データベース コピーを同期する必要があります。障害の性質、停止の長さ、停止中に管理者が行った操作に応じて、データベース コピーの再シードが必要になる場合があります。たとえば、停止中、第 2 データセンターの存続するアクティブなコピー用にログ ファイルの切り詰めを許可するため、障害が発生したプライマリ データセンターからデータベース コピーを削除する場合、再シードが必要になります。各データベースは、個別にこのポイントから前方に進むことができます。プライマリ データセンター内のレプリケートされるデータベース コピーが正常になったら、次の手順に進むことができます。After the Mailbox servers in the primary datacenter have been incorporated into the DAG, they will need some time to synchronize their database copies. Depending on the nature of the failure, the length of the outage, and actions taken by an administrator during the outage, this may require reseeding the database copies. For example, if during the outage, you remove the database copies from the failed primary datacenter to allow log file truncation to occur for the surviving active copies in the second datacenter, reseeding will be required. Each database can individually proceed from this point forward. After a replicated database copy in the primary datacenter is healthy, it can proceed to the next step.

    注意

    このプロセスでは、すべてのデータベースを同時に移動する必要はありません。組織の大部分のデータベースを一度に移動することをお勧めしますが、プライマリ データセンターにデータベース コピーに関連する問題がある場合は一部のデータベースを第 2 データセンターに残すことができます。This process doesn't require that all databases be moved at the same time. You are encouraged to move the majority of your organization's databases at one time, but some databases many linger in the second datacenter if there are issues associated with the database copies in the primary datacenter.

  5. プライマリ データセンターのデータベースの大部分が正常な状態になった後、スイッチバック停止をスケジュールできます。スケジュールされた時刻に達したときに、次の手順を実行する必要があります。After a majority of the databases are in a healthy state in the primary datacenter, the switchback outage can be scheduled. When the scheduled time arrives, the following steps must be taken:

  6. データセンターの切り替えプロセス中、DAG は代替監視サーバーを使用するように構成されました。During the datacenter switchover process, the DAG was configured to use an alternate witness server. DAG は、プライマリ データセンター内の監視サーバーを使用するように再構成する必要があります。The DAG must be reconfigured to use a witness server in the primary datacenter. プライマリデータセンターの停止前に使用されていたのと同じミラーリング監視サーバーとミラーリング監視ディレクトリを使用Set-DatabaseAvailabilityGroup -Identity DAGNameしている場合は、コマンドを実行できます。If you're using the same witness server and witness directory that was used prior to the primary datacenter outage, you can run the Set-DatabaseAvailabilityGroup -Identity DAGName command. 元の監視サーバーや監視ディレクトリとは別の監視サーバーまたは監視ディレクトリを使用する予定の場合は、 Set-DatabaseAvailabilityGroup コマンドを使用して、監視サーバーと監視ディレクトリのパラメーターを適切な値で構成します。If you plan on using a witness server or witness directory that is different from the original witness server and directory, use the Set-DatabaseAvailabilityGroup command to configure the witness server and witness directory parameters with the appropriate values.

  7. プライマリ データセンターで再アクティブ化するデータベースは、第 2 データセンターでマウント解除する必要があります。Dismount-Database コマンドレットを使用して、データベースのマウントを解除することができます。The databases being reactivated in the primary datacenter should be dismounted in the second datacenter. You can use the Dismount-Database cmdlet to dismount the databases.

  8. データベースがマウント解除されたら、クライアント アクセス サービスを実行してる各サーバーの URL を第 2 データセンターからプライマリ データセンターに移動する必要があります。この移動は、各 URL の DNS レコードを、プライマリ データセンター内のクライアント アクセス サービスのサーバーまたはアレイをポイントするように変更することで行います。これにより、システムは、移動されるデータベースごとにデータベース フェールオーバーが発生したかのように動作します。After the databases have been dismounted, the URLs of the servers running Client Access services should be moved from the second datacenter to the primary datacenter. This is accomplished by changing the DNS record for the URLs to point to the Client Access services server or array in the primary datacenter. This will result in the system acting as though a database failover has occurred for each database being moved.

    重要

    クライアント アクセス サービスを実行してる各サーバーの URL が移動され、DNS TTL およびキャッシュ エントリの期限が切れるまで、次の手順に進まないでください。各 URL をプライマリ データセンターに移動する前にプライマリ データセンターの各データベースをアクティブにすると、構成が無効になります (たとえば、マウントされたデータベースには、Active Directory サイトで実行中のクライアント アクセス サービスがない)。Don't proceed to the next step until the URLs for the servers running Client Access services have been moved and the DNS TTL and cache entries have expired. Activating the databases in the primary datacenter prior to moving the URLs to the primary datacenter will result in an invalid configuration (for example, a mounted database that has no Client Access services running in its Active Directory site).

  9. プライマリ データセンター内の各データベースは正常な状態であるため、データベースの切り替えを実行することでプライマリ データセンターでアクティブ化できます。これには、アクティブにする各データベースに対して Move-ActiveMailboxDatabase コマンドレットを使用します。Because each database in the primary datacenter is in a healthy state, it can be activated in the primary datacenter by performing database switchovers. This is accomplished by using the Move-ActiveMailboxDatabase cmdlet for each database that will be activated.

  10. 各データベースをプライマリ データセンターに移動したら、Mount-Database コマンドレットを使用してマウントできます。After each database is moved to the primary datacenter, it can be mounted by using the Mount-Database cmdlet.

1 つ以上のデータベースがアクティブになり、プライマリ データセンターにマウントされたら、他のサーバーの役割のスイッチバック手順を実行できます。After one or more databases are active and mounted in the primary datacenter, switchback procedures for the other server roles can be performed.

クライアントアクセスサービスのスイッチバックClient Access services switchback

切り替え (スイッチオーバー) プロセスの一部として、クライアント アクセス サービス、トランスポートおよびユニファイド メッセージング サービス、エッジ トランスポート サーバーのサービス エンドポイントを解決するために、クライアント、他のサーバー、IP ゲートウェイによって使用される内部および外部 DNS レコードが、第 2 データセンターの対応するエンドポイントをポイントするように変更されました。他のサーバーの役割のスイッチバック プロセスでは、プライマリ データセンターの復元されたサービス エンドポイントをポイントするようにこれらのレコードを変更します。As part of the switchover process, the internal and external DNS records used by clients, other servers, and IP gateways to resolve the service endpoints for Client Access services, Transport and Unified Messaging services, and Edge Transport servers were modified to point to the corresponding endpoints in the second datacenter. The switchback process for the other server roles involves modifying those records to point to the restored service endpoints in the primary datacenter.

第 2 データセンターへの切り替え中に行われた DNS 変更の場合と同様、クライアント、サーバー、IP ゲートウェイは、引き続き接続を試み、TTL が元の DNS エントリに対して期限切れになった後、およびエントリが DNS キャッシュから期限切れになった後は自動的に接続します。As with the DNS changes that were made during the switchover to the second datacenter, clients, servers, and IP gateways will continue to try to connect, and should automatically connect after the TTL has expired for the original DNS entry, and after the entry is expired from their DNS cache.

サイトの復元の再確立Reestablishing Site Resilience

プライマリ データセンターへのスイッチバックが正常に完了したら、第 2 データセンターで各メールボックス データベースのコピーの正常性と状態を確認することで、プライマリ データセンターのサイトの復元を再確立できます。さらに、第 2 データセンターのデータベース コピーのアクティブ化がもともとブロックされている場合は、この時点で設定を再構成できます。After switchback to the primary datacenter is completed successfully, you can reestablish site resilience for the primary datacenter by verifying the health and status of each mailbox database copy in the second datacenter. In addition, if any database copies in the second datacenter were originally blocked for activation, you can reconfigure those settings at this time.