高可用性とサイト復元の展開

[アーティクル]
04/04/2023

製品: Exchange Server 2013

Microsoft Exchange Server 2013 では、高可用性とサイトの回復性の両方に増分展開と呼ばれる概念が使用されます。 2 台以上の Exchange 2013 メールボックスサーバーをスタンドアロンサーバーとして設置し、必要に応じてそれらのメールボックスサーバーとメールボックスデータベースの高可用性とサイト復元を増分的に構成します。

展開プロセスの概要

各組織が用いる実際のステップは若干異なることがありますが、高可用性またはサイト復元構成で Exchange 2013 を展開するための全体的な処理は一般的に違いはありません。データベース可用性グループ (DAG) の構築と展開、およびメールボックスデータベースのコピーの作成に必要となる計画と設計のタスクの実行後、以下の作業を実行します。

DAG を作成します。詳細な手順については、「データベース可用性グループを作成する」を参照してください。
必要に応じて、クラスタ名オブジェクト (CNO) を事前に設定します。 CNO の事前設定が必要になるのは、メールボックスサーバーで Windows Server 2012 を実行する DAG を展開する場合です。 Windows Server 2012 R2 を実行するメールボックスサーバーを使用して、管理アクセスポイントのない DAG を展開する場合は、CNO の事前設定は不要です。コンピューターアカウント作成が制限されるか、コンピューターアカウントが既定のコンピューターコンテナー以外のコンテナーで作成される環境でも、事前設定が必要です。詳細な手順については、「データベース可用性グループのクラスター名オブジェクトを事前設定する」を参照してください。
DAG に複数のメールボックスサーバーを追加します。詳細な手順については、「データベース可用性グループのメンバーシップを管理する」を参照してください。
必要に応じて、DAG プロパティを構成します。
1. オプションで、DAG の暗号化と圧縮、レプリケーションポート、DAG IP アドレス、およびその他の DAG プロパティを構成します。詳細な手順については、「データベース可用性グループのプロパティを構成する」を参照してください。
2. DAG に対してデータセンターアクティブ化調整 (DAC) モードを有効にします。これにより、データセンター切り替えが実行され、組み込みの DAG 回復コマンドレットの使用が有効になった後、プライマリデータセンターへのスイッチバック中に、データベースレベルのスプリットブレイン状態から DAG を保護できます。詳細については、「データセンターライセンス認証調整モード」を参照してください。
DAG 内のメールボックスサーバー全体にメールボックスデータベースのコピーを追加します。詳細な手順については、「メールボックスデータベースコピーを追加する」を参照してください。

展開の例:2 つのデータセンターでの 4 メンバー DAG

この例では、組織 Contoso, Ltd. が 2 つの物理的な場所にまたがる 4 メンバー DAG を構成して展開する方法の詳細を示します。Redmond (Washington 州) および Portland (Oregon 州)。

基本のインフラストラクチャ

各場所には、Exchange 2013 をベースとしたメッセージングインフラストラクチャを運用するのに必要となる、以下のインフラストラクチャ要素が含まれます。

ディレクトリサービス (Active Directory または Active Directory ドメインサービス (AD DS) のいずれか)
ドメインネームシステム (DNS) の名前解決
複数の Exchange 2013 クライアントアクセスサーバー
複数の Exchange 2013 メールボックスサーバー

次の図は、Contoso の構成を示しています。

データベース可用性グループが 2 つのサイトに拡張されました。

ネットワーク構成

前の図にあるように、ソリューションでは複数サブネットと複数ネットワークが使用されます。 DAG 内の各メールボックスサーバーは、個別のサブネットに 2 つのネットワークアダプターを備えます。各メールボックスサーバーでは、MAPI ネットワーク (192.168) に 1 つのネットワークアダプターが使用されます。x。x) と 1 つのネットワークアダプターがレプリケーションネットワーク (10.0) に使用されます。x。x)。 MAPI ネットワークのみが Active Directory、DNS サービス、その他の Exchange サーバーとクライアントへの接続を提供します。各メンバー内のレプリケーションネットワーク用アダプターは、DAG 内のその他のメンバーのレプリケーションネットワークアダプターへの接続のみを提供します。

各ノードの各ネットワークアダプターの設定を以下の表にまとめます。

名前	IPv4 アドレス	サブネットマスク .	既定のゲートウェイ
MBX1 (MAPI)	192.168.1.4	255.255.255.0	192.168.1.1
MBX2 (MAPI)	192.168.1.5	255.255.255.0	192.168.1.1
MBX3 (MAPI)	192.168.2.4	255.255.255.0	192.168.2.1
MBX4 (MAPI)	192.168.2.5	255.255.255.0	192.168.2.1
MBX1 (レプリケーション)	10.0.1.4	255.255.0.0	なし
MBX2 (レプリケーション)	10.0.1.5	255.255.0.0	なし
MBX3 (レプリケーション)	10.0.2.4	255.255.0.0	なし
MBX4 (レプリケーション)	10.0.2.5	255.255.0.0	なし

前の表にあるように、レプリケーションネットワークに使用されるアダプターはデフォルトゲートウェイを使用しません。各レプリケーションネットワークアダプター間にネットワーク接続を提供するために、Contoso は Netsh.exe ツールを使用して構成する固定の静的ルートを使用します。

MBX1 および MBX2 のレプリケーションネットワークアダプターのルーティングを構成するため、各サーバー上で以下のコマンドを実行します。

netsh interface ipv4 add route 10.0.2.0/24 <NetworkName> 10.0.1.254

MBX3 および MBX4 のレプリケーションネットワークアダプターのルーティングを構成するため、各サーバー上で以下のコマンドを実行します。

netsh interface ipv4 add route 10.0.1.0/24 <NetworkName> 10.0.2.254

次の追加のネットワーク設定も構成されています。

[この接続のアドレスを DNS に登録する] チェックボックスは、各 DAG メンバーの MAPI ネットワークアダプターに対してはオンにし、各レプリケーションネットワークアダプターに対してはオフになっています。
少なくとも 1 つの DNS サーバーアドレスは各 DAG メンバーの MAPI ネットワークアダプターに対して構成され、レプリケーションネットワークアダプターに対しては何も構成されていません。冗長性のため、Contoso は MAPI ネットワークアダプターに複数の DNS サーバーアドレスを使用します。
Contoso は Windows ファイアウォールを使用せず、サーバー上で無効になっています。

ネットワークアダプターを構成すると、Contoso は DAG を作成して、DAG にメールボックスサーバーを追加する準備が整います。

データベース可用性グループを作成して構成する

管理者は、いくつかのタスクを実行する Windows PowerShell コマンドラインインターフェイススクリプトを作成することにしました。

スクリプトは New-DatabaseAvailabilityGroup コマンドレットを使用して DAG を作成します。 REDMOND がプライマリデータセンターと見なされることから、Contoso は同一データセンター内に CAS1 という監視サーバーを使用することにしました。
スクリプトは Set-DatabaseAvailabilityGroup コマンドレットを使用して、データセンターの切り替えが必要となる場合に備え、代替監視サーバーと代替監視ディレクトリを事前構成します。
スクリプトは Add-DatabaseAvailabilityGroupServer コマンドレットを使用して、DAG に 4 つのメールボックスサーバーをそれぞれ追加します。
スクリプトは Set-DatabaseAvailabilityGroup コマンドレットを使用して、DAC モードの DAG を構成します。 DAC モードの詳細については、「データセンターライセンス認証調整モード」を参照してください。

スクリプトで使用するコマンドを次に示します。

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer CAS1 -WitnessDirectory C:\DAGWitness\DAG1.contoso.com -DatabaseAvailabilityGroupIPAddresses 192.168.1.8,192.168.2.8

上記のコマンドは DAG DAG1 を作成し、ミラーリング監視サーバーとして機能するように CAS1 を構成し、特定のミラーリング監視ディレクトリ (C:\DAGWitness\DAG1.contoso.com) を構成し、DAG 用の 2 つの IP アドレス (MAPI ネットワークの各サブネット用) に構成します。

Set-DatabaseAvailabilityGroup -Identity DAG1 -AlternateWitnessDirectory C:\DAGWitness\DAG1.contoso.com -AlternateWitnessServer CAS4

上記のコマンドは、CAS4 という代替ミラーリング監視サーバーと、CAS1 で構成されたのと同じパスを使用する CAS4 上の代替ミラーリング監視ディレクトリを使用するように、DAG1 を構成します。

注:

同じパスを使用することは必須ではありません。Contoso は同じパスを使用することで構成を標準化することを選択しました。

Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX3
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX4

このコマンドは、各メールボックスサーバーを 1 回に付き 1 つずつ DAG に追加します。上記のコマンドはまた、各メールボックスサーバーに Windows フェールオーバークラスタリングコンポーネントをインストールし (未インストールの場合)、フェールオーバークラスターを作成し、新しく作成したクラスターに各メールボックスサーバーを参加させます。

Set-DatabaseAvailabilityGroup -Identity DAG1 -DatacenterActivationMode DagOnly

上記のコマンドは、DAG の DAC モードを有効にします。

メールボックスデータベースとメールボックスデータベースのコピー

DAG を作成して DAG にメールボックスサーバーを追加した後、Contoso はメールボックスデータベースとメールボックスデータベースのコピーを作成する準備を行います。障害耐性の基準に合わせるため、Contoso は各メールボックスデータベースを 3 つの時間差のないデータベースコピーと 1 つの時間差データベースコピーと構成することにします。時間差コピーには、3 日間のログ再生時間差が構成されます。

この構成により、各データベースに対して合計で 4 つのコピーが提供されます (1 つのアクティブ、2 つの時間差なしパッシブ、および時間差ありパッシブ)。 Contoso は 1 サーバーあたり 4 つのアクティブデータベースを所有する予定です。 1 つのサーバーあたり 4 つのアクティブなデータベースと、各データベースに 3 つのパッシブコピーがあるため、Contoso ソリューションには、合計で 16 のデータベースコピーが含まれます。

以下の図にあるように、Contoso はデータベースレイアウトに均等なアプローチを取ります。

Contoso, Ltd. のデータベースコピーレイアウト

各メールボックスサーバーは、1 つのアクティブメールボックスコピー、2 つの時間差なしパッシブデータベースコピー、および 1 つの時間差ありパッシブデータベースコピーをホストします。各アクティブメールボックスデータベースの時間差コピーは、もう一方のサイトのメールボックスサーバーにホストされます。

この構成を作成するのに、管理者はいくつかのコマンドを実行します。

MBX1 では、次のコマンドを実行します。

Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX2
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX4
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX3 -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB1\MBX3 -SuspendComment "Seed from MBX4" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB1\MBX3 -SourceServer MBX4
Suspend-MailboxDatabaseCopy -Identity DB1\MBX3 -ActivationOnly

MBX2 では、次のコマンドを実行します。

Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX3
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX4 -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB2\MBX4 -SuspendComment "Seed from MBX3" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB2\MBX4 -SourceServer MBX3
Suspend-MailboxDatabaseCopy -Identity DB2\MBX4 -ActivationOnly

MBX3 では、次のコマンドを実行します。

Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX4
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX2
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX1 -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1 -SuspendComment "Seed from MBX2" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB3\MBX1 -SourceServer MBX2
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1 -ActivationOnly

MBX4 では、次のコマンドを実行します。

Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX3
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX1
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX2 -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2 -SuspendComment "Seed from MBX1" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB4\MBX2 -SourceServer MBX1
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2 -ActivationOnly

Add-MailboxDatabaseCopy コマンドレットの前の例では、ActivationPreference パラメーターが指定されていませんでした。タスクは、追加される各コピーと共にアクティベーション優先番号を自動的に増大させます。元データベースは、常に優先番号 1 を持ちます。 Add-MailboxDatabaseCopy コマンドレットによって最初に追加されたコピーには、自動的に優先番号 2 が割り当てられます。コピーが削除されなければ、次に追加されるコピーには優先番号 3 が割り当てられるというように続きます。このため、上記の例では、アクティブコピーと同じデータセンターのパッシブコピーはアクティベーション優先番号 2 を、リモートデータセンターの時間差なしパッシブコピーはアクティベーション優先番号 3 を、リモートデータセンターの時間差パッシブコピーはアクティベーション優先番号 4 を持ちます。

WAN 全体の各アクティブデータベースのコピーは、他の場所には 2 つありますが、WAN 経由でのシード処理は 1 回だけ実行されました。これは、Contoso が Exchange 2013 の機能を利用して、シード処理のソースとしてデータベースのパッシブコピーを使用しているためです。 SeedingPostponed パラメーターで Add-MailboxDatabaseCopy コマンドレットを使用すると、作成中の新しいデータベースコピーをタスクが自動的にシード処理できなくなります。その後、管理者はシードなしのコピーを中断できます。管理者は、SourceServer パラメーターを指定して Update-MailboxDatabaseCopy コマンドレットを使用して、シード処理のソースとしてデータベースのローカルコピーを指定できます。その結果、各場所に追加された 2 番目のデータベースコピーのシード処理は、WAN 経由ではなくローカルで行われます。

注:

上記の例では、時間差なしデータベースコピーは WAN 経由でシードされ、その後、そのコピーを使用して時間差なしコピーと同じデータセンターにあるデータベースの時間差コピーをシードします。

Contoso は、各メールボックスデータベースのパッシブコピーの 1 つを時間差データベースコピーとして構成することで、まれに発生する壊滅的なデータベースの論理的破損に対する保護を確立します。その結果、管理者は、ActivationOnly パラメーターを持つ Suspend-MailboxDatabaseCopy コマンドレットを使用して、遅延コピーをアクティブ化のブロックとして構成しています。これにより、データベースやサーバーのフェールオーバーが発生しない限り、時間差データベースコピーがアクティブにならないようにします。

ソリューションを検証する

ソリューションの展開および構成後、管理者は、運用メールボックスを DAG 内のデータベースに移動する前に、ソリューションの準備が整っていることを検証するいくつかのタスクを実行します。ソリューションは、障害シミュレーションを含むいくつかの方法を使用してテストして検査する必要があります。ソリューションを検証するため、管理者はいくつかのタスクを実行します。

DAG の総合的な正常性を確認するため、管理者は Test-ReplicationHealth コマンドレットを実行します。このコマンドレットは、レプリケーションと再生の状態のいくつかの側面を確認することで、DAG 内の各メールボックスサーバーとデータベースコピーに関する情報を提供します。

レプリケーションと再生の動作を確認するため、管理者は Get-MailboxDatabaseCopyStatus コマンドレットを実行します。このコマンドレットは、特定のメールボックスデータベースコピー、または特定サーバー上のすべてのメールボックスデータベースコピーに関するリアルタイム状態情報を提供できます。 DAG 内のレプリケーションされたデータベースの正常性と状態の監視の詳細については、「データベース可用性グループの監視」を参照してください。

切り替えが期待通りに機能することを確認するため、管理者は Move-ActiveMailboxDatabase コマンドレットを使用して、一連のデータベース切り替えとサーバー切り替えを実行します。これらのタスクが正常に完了したら、管理者は同じコマンドレットを使用して、アクティブデータベースコピーを元の場所に戻します。

さまざまな障害シナリオでの期待される動作を確認するため、管理者は障害をシミュレートした李、実際に障害を発生させるいくつかのタスクを実行します。たとえば、管理者は以下の操作を実行する場合があります。

MBX1 の電源コードを抜き取り、サーバーフェールオーバーをトリガーします。その後、管理者はもう 1 つのサーバーで DB1 がアクティブになることを確認します (アクティベーションの優先の値から、MBX2 が望ましい)。
MBX2 の MAPI ネットワークアダプターのネットワークケーブルを引き抜き、サーバーフェールオーバーをトリガーします。その後、管理者はもう 1 つのサーバーで DB2 がアクティブになることを確認します (アクティベーションの優先の値から、MBX1 が望ましい)。
DB3 のアクティブコピーに使用されるディスクをオフラインで取り外し、データベースフェールオーバーをトリガーします。その後、管理者はもう 1 つのサーバーで DB3 がアクティブになることを確認します (アクティベーションの優先の値から、MBX4 が望ましい)。

ビジネスニーズに応じて、組織がテストする障害シナリオは他にも挙げられます。単一障害 (電源プラグの引き抜きなど) をシミュレートし、ソリューションの回復動作を確認したら、管理者はソリューションを本来の構成へと戻すことができます。場合によっては、複数同時障害についてソリューションをテストする場合があります。ソリューションテスト計画では、最終的には各障害シミュレーションの完了後、ソリューションを本来の構成へと戻す必要があります。

さらに、管理者は、2 つのデータセンター間のネットワーク接続を切断し、サイト障害をシミュレートすることを決定できます。データセンターの切り替えの実行は、はるかに複雑で調整されたプロセスです。ただし、展開されるソリューションがメッセージングサービスとデータにサイトの回復性を提供することを目的としている場合は、このプロセスをお勧めします。

運用に移行する

ソリューションをデプロイした後は、増分デプロイを使用してさらに拡張できます。この時点で、ソリューションの管理も操作プロセスに移行し、次のタスクが実行されます。

DAG とメールボックスデータベースコピーの正常性と状態を監視します。詳細については、「データベース可用性グループの監視」を参照してください。
必要に応じて、データベースの切り替えを実行します。データベース切り替えを実行する方法の詳細手順については、「メールボックスデータベースコピーをアクティブにする」を参照してください。

ソリューションの管理の詳細については、「高可用性とサイト復元の管理」を参照してください。