Exchange Serverでデータベース可用性グループを管理する
データベース可用性グループ (DAG) は、データベース/サーバー/ネットワーク障害からのデータベース レベルの自動復旧を提供する最大 16 台の Exchange メールボックス サーバーのセットです。 DAG は連続レプリケーションおよび Windows フェールオーバー クラスター化テクノロジのサブセットを使用して、高可用性およびサイトの復元を提供します。 DAG 内のメールボックス サーバーは、障害を相互に監視します。 メールボックス サーバーが DAG に追加されると、そのサーバーは DAG 内の他のサーバーと連携して、データベース障害からの自動的なデータベース レベルの回復を実施します。
DAG を作成すると、最初は空です。 最初のサーバーを DAG に追加すると、フェールオーバー クラスターが DAG 用に自動作成されます。 さらに、ネットワーク障害またはサーバー障害がないかサーバーを監視するインフラストラクチャが開始します。 その後、フェールオーバー クラスター ハートビート メカニズムとクラスター データベースを使用して、データベースのマウント状態、レプリケーションの状態、最後にマウントされた場所など、迅速に変更できる DAG に関する情報を追跡および管理します。
DAG の作成
DAG を作成するには、Exchange 管理センター (EAC) でデータベース可用性グループの新規作成ウィザードを使用するか、Exchange 管理シェルで New-DatabaseAvailabilityGroup コマンドレットを実行します。 DAG を作成するときは、DAG の名前と、オプションの監視サーバーと監視ディレクトリの設定を指定します。 さらに、静的 IP アドレスを使用するか、動的ホスト構成プロトコル (DHCP) を使用して DAG に必要な IP アドレスを自動的に割り当てることで、1 つ以上の IP アドレスを DAG に割り当てることができます。 DatabaseAvailabilityGroupIpAddresses パラメーターを使用すると、DAG に手動で IP アドレスを割り当てることができます。 このパラメーターを省略すると、DAG はネットワーク上の DHCP サーバーを使用することで IP アドレスの取得を試行します。
R2 Windows Server 2012実行されているメールボックス サーバーを含む DAG を作成する場合は、クラスター管理アクセス ポイントなしで DAG を作成することもできます。 その場合、クラスターには Active Directory にクラスター名オブジェクト (CNO) が存在せず、クラスター コア リソース グループにはネットワーク名リソースまたは IP アドレス リソースが含まれません。
DAG を作成する方法の詳細な手順については、「データベース可用性グループを作成する」を参照してください。
DAG を作成すると、指定した名前の DAG を表す空のオブジェクトと 、msExchMDBAvailabilityGroup のオブジェクト クラスが Active Directory に作成されます。
DAG は、Windows Server 2008 R2 以降の Windows フェールオーバー クラスタリング テクノロジのサブセット (クラスター ハートビート、クラスター ネットワーク、クラスター データベースなど) を使用します (データベース状態の変更 (アクティブからパッシブ、リバース、マウントからマウント解除、逆に変更など) をすばやく変更または変更できるデータを格納します。 そのため、WINDOWS フェールオーバー クラスタリングを含む、サポートされているバージョンの Windows にインストールされている Exchange メールボックス サーバーでのみ DAG を作成できます。
注:
DAG によって作成および使用されるフェールオーバー クラスターは、DAG 専用である必要があります。 このクラスターは、他の高可用性ソリューションや別の目的のために使用することはできません。 たとえば、フェールオーバー クラスターは、他のアプリケーションやサービスをクラスター化するためには使用できません。 DAG 以外の目的で DAG の基になるフェールオーバー クラスターを使用することは、サポートされません。
DAG ミラーリング監視サーバーおよび監視ディレクトリ
DAG を作成するときは、Active Directory フォレスト内で一意の 15 文字以下の DAG の名前を指定する必要があります。 さらに、各 DAG はミラーリング監視サーバーとミラーリング監視ディレクトリで構成されます。 ミラーリング監視サーバーとそのディレクトリは、DAG に偶数のメンバーがある場合にのみ使用され、クォーラムの目的でのみ使用されます。 監視ディレクトリを事前に作成する必要はありません。 Exchange は、ミラーリング監視サーバー上に必要なディレクトリを作成してセキュリティで保護します。 ミラーリング監視ディレクトリは、DAG ミラーリング監視サーバー以外の目的に使用しないでください。
注:
データベース ミラーリング トポロジでは、"ミラーリング監視" と呼ばれる 3 つ目のサーバーを使用できます。 ミラーリング監視サーバーを使用すると、プリンシパルからミラー サーバーへの自動フェールオーバー、またはその逆が可能になります。 プリンシパル サーバーとミラー サーバーとは異なり、ミラーリング監視サーバーはデータベースを処理しません。 監視の役割は、特定のパートナー サーバーが稼働していて機能しているかどうかを確認することです。 自動フェールオーバーのサポートはミラーリング監視サーバーの唯一の機能であり、プリンシパル コピーを保持するサーバーと、データベースのミラー コピーを保持するサーバーを識別します。
ミラーリング監視サーバーの要件は、以下のとおりです。
DAG のメンバーでないミラーリング監視サーバーを指定する必要があります。
監視サーバーを DAG と同じ Active Directory フォレスト内に配置する必要があります。
ミラーリング監視サーバーが Windows Server 2008 以降を実行している必要があります。
1 台のサーバーが、複数の DAG のミラーリング監視サーバーとして動作できます。 ただし、各 DAG には独自の監視ディレクトリが必要です。
監視サーバーとして使用されるサーバーに関係なく、目的の監視サーバーで Windows ファイアウォールが有効になっている場合は、ファイルとプリンターの共有に対して Windows ファイアウォール例外を有効にする必要があります。 ミラーリング監視サーバーは、SMB ポート 445 を使用します。
重要
指定したミラーリング監視サーバーが Exchange 2010 以降のサーバーではない場合は、DAG を作成する前に、監視サーバーのローカル Administrators グループに Exchange Trusted Subsystem ユニバーサル セキュリティ グループ (USG) を追加する必要があります。 必要に応じて、Exchange がディレクトリを作成し、ミラーリング監視サーバーで共有できることを確認するには、これらのセキュリティ アクセス許可が必要です。
ミラーリング監視サーバーおよびミラーリング監視ディレクトリは、フォールト トレラントである必要はなく、冗長性または高可用性の形式を使用する必要がありません。 クラスター化されたファイル サーバーをミラーリング監視サーバー用に使用する必要はなく、ミラーリング監視サーバーのその他の復元形式を採用する必要もありません。 これには、さまざまな理由があります。 DAG の規模が大きい場合は (例: 6 メンバー以上)、数か所で障害が発生しない限り、ミラーリング監視サーバーは必要になりません。 6 メンバーの DAG は、2 つまでの投票者障害ではクォーラムを失わないため、3 つの投票者に障害が発生して初めて、クォーラムを維持するためにミラーリング監視サーバーが必要になります。 また、現在のミラーリング監視サーバーに影響を与える障害がある場合 (例: ハードウェア障害のためにミラーリング監視サーバーを失う場合)、クォーラムがあることを前提として、Set-DatabaseAvailabilityGroup コマンドレットを使用して新しいミラーリング監視サーバーと監視ディレクトリを構成できます。
注:
ミラーリング監視サーバーでそのストレージが失われたか、監視ディレクトリまたは共有アクセス許可が変更された場合は、 Set-DatabaseAvailabilityGroup コマンドレットを使用して、元の場所のミラーリング監視サーバーおよび監視ディレクトリを構成することもできます。
ミラーリング監視サーバーの配置に関する留意点
DAG のミラーリング監視サーバーの配置は、ビジネス要件と組織で使用可能なオプションによって異なります。 Exchange には、Exchange 2010 では推奨されない、または不可能な新しい DAG 構成オプションのサポートが含まれるようになりました。 これらのオプションには、第 3 のデータセンター、ブランチ オフィス、または Microsoft Azure 仮想ネットワークなどの第 3 の場所の使用が含まれています。
下の表に、さまざまな展開シナリオに関する一般的なミラーリング監視サーバーの配置に関する推奨事項を示します。
| 展開シナリオ | 推奨事項 |
|---|---|
| 単一のデータセンターに展開された単一の DAG | ミラーリング監視サーバーを DAG メンバーと同じデータセンターに設置する |
| 2 つのデータセンターにまたがって展開された単一の DAG、使用可能な追加の場所なし | ミラーリング監視サーバーを Microsoft Azure 仮想ネットワークに設置してデータセンターの自動フェールオーバーを有効にするか、 ミラーリング監視サーバーをプライマリ データセンターに設置する |
| 単一のデータセンターに展開された複数の DAG | ミラーリング監視サーバーを DAG メンバーと同じデータセンターに設置する。 追加のオプションには以下が含まれます。
|
| 2 つのデータセンターにまたがって展開された複数の DAG | ミラーリング監視サーバーを Microsoft Azure 仮想ネットワークに設置してデータセンターの自動フェールオーバーを有効にするか、 各 DAG のプライマリと見なされるデータセンター内の監視サーバーを見つけます。 追加のオプションには以下が含まれます。
|
| 3 つ以上のデータセンターにまたがって展開された単一または複数の DAG | この構成では、ミラーリング監視サーバーを大部分のクォーラム投票が存在するデータセンターに設置する必要があります。 |
DAG が 2 つのデータセンターに展開されている場合は、監視サーバーをホストするために 3 番目の場所を使用できるようになりました。 ORGANIZATIONに 3 つ目の場所があり、DAG が展開されている 2 つのデータセンターに影響を与えるネットワーク 障害から分離されたネットワーク インフラストラクチャがある場合は、その 3 番目の場所に DAG の監視サーバーを展開し、データセンター レベルの障害イベントに応答してデータベースを他のデータセンターに自動的にフェールオーバーできるように DAG を構成できます。 物理的な場所が組織に 2 つしかない場合、Microsoft Azure 仮想ネットワークを第 3 の場所として使用して、ミラーリング監視サーバーを配置できます。
DAG 作成時のミラーリング監視サーバーおよびミラーリング監視ディレクトリの指定
DAG を作成するときは、DAG の名前を指定する必要があります。 必要に応じて、ミラーリング監視サーバーと監視ディレクトリも指定できます。
DAG を作成するときに、オプションと動作の次の組み合わせを使用できます。
DAG の名前のみを指定でき、 監視サーバー と ミラーリング監視ディレクトリ のフィールドは空白のままにします。 このシナリオでは、ウィザードはローカル Active Directory サイトで、メールボックス サーバーがインストールされていないクライアント アクセス サーバーを検索し、既定のディレクトリ (%SystemDrive%:\DAGFileShareWitnesses\<DAGFQDN) とそのサーバー上に既定の共有 (<DAGFQDN>>) を自動的に作成し、そのクライアント アクセス サーバーを監視サーバーとして使用します。 たとえば、オペレーティング システムがドライブ C にインストールされている監視サーバー CAS3 を考えてみましょう。contoso.com ドメインの DAG1 という名前の DAG では、C:\DAGFileShareWitnesses\DAG1.contoso.com の既定の監視ディレクトリが使用されます。これは \CAS3\DAG1.contoso.com として共有されます。
DAG の名前、使用するミラーリング監視サーバー、およびミラーリング監視サーバーで作成して共有するディレクトリを指定できます。
DAG の名前および使用するミラーリング監視サーバーを指定して、[監視ディレクトリ] フィールドを空白のまま残すことができます。 この場合、ウィザードでは、指定のミラーリング監視サーバーに既定のディレクトリを作成します。
DAG の名前を指定し、[監視サーバー] フィールドを空白のまま残して、ミラーリング監視サーバーで作成して共有するディレクトリを指定できます。 この場合、ウィザードでは、メールボックス サーバーがインストールされていないクライアント アクセス サーバーを検出し、指定の DAG をそのサーバーに自動的に作成してディレクトリを共有し、クライアント アクセス サーバーをミラーリング監視サーバーとして使用します。
DAG が作成される場合、最初にノード マジョリティ クォーラム モデルを使用します。 2 番目のメールボックス サーバーが DAG に追加される場合、クォーラムが自動的にノードとファイル共有マジョリティ クォーラム モデルに変更されます。 この変更がなされると、DAG のクラスターはクォーラムを保持するためにミラーリング監視サーバーの使用を開始します。 監視ディレクトリが存在しない場合は、Exchange によりそれが自動で作成および共有され、DAG の CNO コンピューター アカウント用のフル コントロール アクセス許可で共有がプロビジョニングされます。
注:
ファイル共有を分散ファイル システム (DFS) 名前空間の一部として使用する機能は、サポートされていません。
DAG が作成される前にミラーリング監視サーバー上で Windows ファイアウォールが有効になると、Windows ファイアウォールが DAG の作成をブロックすることがあります。 Exchange は Windows Management Instrumentation (WMI) を使用して、ミラーリング監視サーバー上にディレクトリとファイル共有を作成します。 ミラーリング監視サーバー上で Windows ファイアウォールが有効であり、WMI 向けのファイアウォールの例外が構成されていない場合、 New-DatabaseAvailabilityGroup コマンドレットは失敗し、エラーが発生します。 ミラーリング監視サーバーを指定してもミラーリング監視ディレクトリを指定しない場合は、次のエラー メッセージが表示されます。
The task was unable to create the default witness directory on server <Server Name>. Please manually specify a witness directory.
ミラーリング監視サーバーと監視ディレクトリを指定すると、次の警告メッセージが表示されます。
Unable to access file shares on witness server '<ServerName>'. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: The network path was not found.
DAG が作成された後で、サーバーが追加される前に Windows ファイアウォールがミラーリング監視サーバー上で有効になると、Windows ファイアウォールは DAG メンバーの追加や削除をブロックすることがあります。 ミラーリング監視サーバーで Windows ファイアウォールが有効になっていて、WMI 用に構成されたファイアウォール例外がない場合、 Add-DatabaseAvailabilityGroupServer コマンドレットは次の警告メッセージを表示します。
Failed to create file share witness directory 'C:\DAGFileShareWitnesses\DAG_FQDN' on witness server '<ServerName>'. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: WMI exception occurred on server '<ServerName>': The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
上記のエラーと警告を解決するには、次のいずれかの手順を実行します。
手動でミラーリング監視サーバー上に監視ディレクトリと共有を作成し、そのディレクトリと共有に対して DAG フル コントロールの CNO を割り当てます。
Windows ファイアウォールで WMI の例外を有効にします。
Windows ファイアウォールを無効にします。
DAG メンバーシップ
DAG が作成されたら、EAC のデータベース可用性グループの管理ウィザード、または Exchange 管理シェルの Add-DatabaseAvailabilityGroupServer コマンドレットまたは Remove-DatabaseAvailabilityGroupServer コマンドレットを使用して、DAG にサーバーを追加したり、DAG からサーバーを削除したりできます。 DAG メンバーシップを管理する方法の詳細な手順については、「 データベース可用性グループのメンバーシップを管理する」を参照してください。
注:
DAG のメンバーである各メールボックス サーバーは、DAG で使用する基になるクラスター内のノードでもあります。 その結果、メールボックス サーバーは任意の時点で、1 つの DAG のみのメンバーにすることができます。
DAG に追加しているメールボックス サーバーにフェールオーバー クラスタリング コンポーネントがインストールされていない場合は、サーバーを追加するために使用する方式 (例: Add-DatabaseAvailabilityGroupServer コマンドレットまたはデータベース可用性グループの管理ウィザード) によってフェールオーバー クラスタリング機能がインストールされます。
最初のメールボックス サーバーが DAG に追加されると、次のイベントが発生します。
まだインストールされていない場合は、Windows フェールオーバー クラスタリング コンポーネントがインストールされます。
フェールオーバー クラスターは、DAG の名前を使用して作成されます。 このフェールオーバー クラスターは DAG によって排他的に使用される DAG 専用のものである必要があります。 このクラスターの他の目的での使用はサポートされていません。
CNO が既定のコンピューター コンテナーに作成されます。
DAG の名前および IP アドレスがドメイン ネーム システム (DNS) 内のホスト (A) レコードとして登録されます。
サーバーは Active Directory の DAG オブジェクトに追加されます。
追加サーバーにマウントされたデータベースの情報で、クラスター データベースが更新されます。
大規模、または複数サイト環境、特に DAG が複数の Active Directory サイトに拡張されている環境では、最初の DAG メンバーを含む DAG オブジェクトの Active Directory レプリケーションが完了するのを待機する必要があります。 この Active Directory オブジェクトが環境全体にレプリケートされていない場合、2 つ目のサーバーを追加すると、DAG 用に新しいクラスター (および新しい CNO) が作成される可能性があります。 この作成は、追加される 2 番目のメンバーの観点から DAG オブジェクトが空に見えるので、 Add-DatabaseAvailabilityGroupServer コマンドレットによって、これらのオブジェクトが既に存在していても、DAG のクラスターと CNO が作成されます。 最初の DAG サーバーを含む DAG オブジェクトがレプリケートされたことを確認するには、追加する 2 番目のサーバー上で Get-DatabaseAvailabilityGroup コマンドレットを使用して、追加した最初のサーバーが DAG のメンバーとして一覧されていることを確認します。
2 番目以降のサーバーが DAG に追加されると、次のイベントが発生します。
サーバーが DAG の Windows フェールオーバー クラスターに参加します。
クォーラム モデルが次のように自動調整されます。
ノード マジョリティ クォーラム モデルは、奇数のメンバーを持つ DAG に使用されます。
ノードおよびファイル共有マジョリティ クォーラム モデルは、偶数のメンバーを持つ DAG に使用されます。
ミラーリング監視ディレクトリと共有は、必要に応じて Exchange によって自動作成されます。
サーバーは Active Directory の DAG オブジェクトに追加されます。
マウントされたデータベースに関する情報で、クラスター データベースが更新されます。
注:
クォーラム モデル変更は、自動的に実行されます。 ただし、クォーラム モデルが適切なモデルに自動的に変更されない場合は、ID パラメーターのみを使用して Set-DatabaseAvailabilityGroup コマンドレットを実行して、DAG のクォーラム設定を修正できます。
DAG のクラスター名オブジェクトの事前設定
CNO は、Active Directory で作成され、クラスターの名前リソースに関連付けられているコンピューター アカウントです。 クラスターの Name リソースは CNO に関連付けられています。これは、クラスターの ID として機能し、クラスターのセキュリティ コンテキストを提供する Kerberos 対応オブジェクトです。 DAG の基になるクラスターとそのクラスターの CNO の形成は、最初のメンバーが DAG に追加されるときに実行されます。 最初のサーバーが DAG に追加されると、リモート PowerShell は、追加するメールボックス サーバー上の Microsoft Exchange レプリケーション サービスに接続します。 Microsoft Exchange レプリケーション サービスは、フェールオーバー クラスタリング機能 (まだインストールされていない場合) をインストールし、クラスター作成プロセスを開始します。 Microsoft Exchange レプリケーション サービスは、LOCAL SYSTEM セキュリティ コンテキストで実行され、クラスターの作成が実行されるこのコンテキストの下にあります。
注意
DAG メンバーが Windows Server 2012 を実行している場合は、最初のサーバーを DAG に追加する前に CNO を事前に設定する必要があります。 DAG メンバーが R2 Windows Server 2012実行していて、クラスター管理アクセス ポイントのない DAG を作成した場合、CNO は作成されず、DAG の CNO を作成する必要はありません。
コンピューター アカウントの作成が制限されているか、コンピューター アカウントが既定のコンピューター コンテナーではないコンテナーに作成される環境では、CNO の事前設定と準備が可能です。 CNO のコンピューター アカウントを作成して無効にしてから、次のいずれかの手順を実行します。
DAG に追加している最初のメールボックス サーバーのコンピューター アカウントに対して、コンピューター アカウントのフル コントロールを割り当てます。
Exchange Trusted Subsystem USG にコンピューター アカウントのフル コントロールを割り当てます。
DAG に追加する最初のメールボックス サーバーのコンピューター アカウントにコンピューター アカウントの完全な制御を割り当てると、LOCAL SYSTEM セキュリティ コンテキストで事前にステージングされたコンピューター アカウントを管理できるようになります。 Exchange 信頼されたサブシステム USG には、ドメイン内のすべての Exchange サーバーのマシン アカウントが含まれているため、代わりに、コンピューター アカウントの完全な制御を Exchange 信頼されたサブシステム USG に割り当てることができます。
DAG の CNO の事前設定と準備の詳細な手順については、「データベース可用性グループのクラスター名オブジェクトを事前設定する」を参照してください。
DAG からのサーバーの削除
メールボックス サーバーを DAG から削除するには、EAC 内のデータベース可用性グループの管理ウィザードを使用するか、Exchange 管理シェル内の Remove-DatabaseAvailabilityGroupServer コマンドレットを使用します。 メールボックス サーバーを DAG から削除するためには、レプリケートされたすべてのメールボックス データベースを最初にサーバーから削除する必要があります。 レプリケートされたメールボックス データベースと共にメールボックス サーバーを DAG から削除しようとすると、タスクが失敗します。
特定の操作を実行する前にメールボックス サーバーを DAG から削除しなくてはならないシナリオがあります。 これらのシナリオには、次のものがあります。
サーバーの回復操作の実行: DAG のメンバーであるメールボックス サーバーが失われた場合、または障害が発生し、回復不可能であり、交換が必要な場合は、 セットアップ /m:RecoverServer スイッチを使用してサーバーの回復操作を実行できます。 ただし、回復操作を実行するためには、まず ConfigurationOnly パラメーターを指定して Remove-DatabaseAvailabilityGroupServer コマンドレットを使用することによって DAG からサーバーを削除する必要があります。
データベース可用性グループの削除: DAG を削除する必要がある場合があります (たとえば、サードパーティのレプリケーション モードを無効にする場合)。 DAG を削除しなければならない場合、まず DAG からすべてのサーバーを削除する必要があります。 メンバーが含まれる DAG を削除しようとすると、タスクが失敗します。
DAG プロパティの構成
サーバーを DAG に追加した後に、EAC または Exchange 管理シェルを使用することによって、DAG で使用されるミラーリング監視サーバーおよび監視ディレクトリ、DAG に割り当てられる IP アドレスなどの DAG プロパティを構成できます。
構成可能なプロパティは、次のとおりです。
監視サーバー: ファイル共有監視のファイル共有をホストするサーバーの名前。 クライアント アクセス サーバーをミラーリング監視サーバーとして指定することをお勧めします。 この名前付けにより、システムは必要に応じて共有を自動的に構成、セキュリティで保護、使用でき、メッセージング管理者はミラーリング監視サーバーの可用性を認識できます。
監視ディレクトリ: ファイル共有監視データの格納に使用されるディレクトリの名前。 このディレクトリは、指定されたミラーリング監視サーバー上で自動的に作成されます。
データベース可用性グループの IP アドレス: DAG メンバーが R2 Windows Server 2012実行されていて、IP アドレスのない DAG を作成している場合を除き、1 つ以上の IP アドレスを DAG に割り当てる必要があります。 DAG の IP アドレスは、手動で割り当てられた静的 IP アドレスを使って構成するか、組織内の DHCP サーバーを使って DAG に自動で割り当てることができます。
Exchange 管理シェルを使用すると、DAG IP アドレスなど、EAC で使用できない DAG プロパティを構成できます。ネットワーク暗号化と圧縮の設定。ネットワーク検出。レプリケーションに使用される TCP ポート。代替ミラーリング監視サーバーとミラーリング監視ディレクトリの設定。と を使用して、Datacenter ライセンス認証調整モードを有効にします。
DAG プロパティを構成する方法の詳細な手順については、「データベース可用性グループのプロパティを構成する」を参照してください。
DAG ネットワーク暗号化
DAG は、Windows Server オペレーティング システムの暗号化機能を活用することによって、暗号化の使用をサポートします。 DAG は Exchange サーバー間に Kerberos 認証を使用します。 Microsoft Kerberos セキュリティ サポート プロバイダー (SSP) EncryptMessage および DecryptMessage API は、DAG ネットワーク トラフィックの暗号化を処理します。 Microsoft Kerberos SSP は、複数の暗号化アルゴリズムをサポートします (完全な一覧については、「Kerberos プロトコル拡張機能https://go.microsoft.com/fwlink/p/?linkId=179131」のセクション 3.1.5.2「暗号化タイプ」を参照)。 (完全な一覧については、 Kerberos プロトコル拡張機能のセクション 3.1.5.2「暗号化の種類」を参照してください)。Kerberos 認証ハンドシェイクでは、一覧でサポートされている最強の暗号化プロトコル (通常は Advanced Encryption Standard (AES) 256 ビット、場合によっては SHA ハッシュベースのメッセージ認証コード (HMAC) を使用してデータの整合性を維持します。 詳細については、「 HMAC」を参照してください。
ネットワーク暗号化は DAG のプロパティであり、DAG ネットワークのプロパティではありません。 DAG ネットワーク暗号化を構成するには、Exchange 管理シェル内の Set-DatabaseAvailabilityGroup コマンドレットを使用します。 DAG ネットワーク通信に使用できる暗号化設定を次の表に示します。
| 設定 | 説明 |
|---|---|
| 無効 | ネットワーク暗号化が使用されません。 |
| 有効 | ネットワーク暗号化がすべての DAG ネットワーク上でレプリケーションおよびシード処理に使用されます。 |
| InterSubnetOnly | ネットワーク暗号化が別々のサブネット間でレプリケートするときに DAG ネットワーク上で使用されます。 この設定は既定の設定です。 |
| SeedOnly | ネットワーク暗号化がシード処理専用ですべての DAG ネットワーク上で使用されます。 |
DAG ネットワーク圧縮
DAG では、組み込みの圧縮がサポートされます。 圧縮が有効になっている場合、DAG ネットワーク通信では XPRESS が使用されます。これは、LZ77 アルゴリズムの Microsoft 実装です。 この圧縮は、多くの Microsoft プロトコルで使用されるのと同じ種類の圧縮です。特に、Microsoft Outlook と Exchange の間の MAPI RPC 圧縮です。
ネットワーク暗号化と同様に、ネットワーク圧縮は DAG ネットワークではなく DAG のプロパティでもあります。 Exchange 管理シェル内で Set-DatabaseAvailabilityGroup コマンドレットを使用することによって、DAG ネットワーク圧縮を構成します。 DAG ネットワーク通信に使用できる圧縮設定を次の表に示します。
| 設定 | 説明 |
|---|---|
| 無効 | ネットワーク圧縮が使用されません。 |
| 有効 | ネットワーク圧縮がすべての DAG ネットワーク上でレプリケーションおよびシード処理に使用されます。 |
| InterSubnetOnly | ネットワーク圧縮が別々のサブネット間でレプリケートするときに DAG ネットワーク上で使用されます。 この設定は既定の設定です。 |
| SeedOnly | ネットワーク圧縮がシード処理専用ですべての DAG ネットワーク上で使用されます。 |
DAG ネットワーク
DAG ネットワークは、レプリケーション トラフィックまたは MAPI トラフィックのいずれかに使用する 1 つまたは複数のサブネットの集合です。 DAG ごとに、最大 1 つの MAPI ネットワークと 0 または 1 つ以上のレプリケーション ネットワークが含まれます。 単一ネットワーク アダプター構成の場合、そのネットワークは MAPI とレプリケーション トラフィックの両方で使用されます。 単一ネットワーク アダプターおよびパスがサポートされていますが、各 DAG は最小 2 つの DAG ネットワークを持つことを推奨します。 2 つのネットワーク構成で、1 つのネットワークは通常、レプリケーション トラフィック専用であり、その他のネットワークは主に MAPI トラフィック用に使用されます。 各 DAG メンバーにネットワーク アダプターを追加して、追加の DAG ネットワークをレプリケーション ネットワークとして構成することも可能です。
注:
複数のレプリケーション ネットワークを使用する場合、ネットワーク使用の優先順位を指定する方法はありません。 Exchange はログ配布に使用するレプリケーション ネットワークのグループからレプリケーション ネットワークをランダムに選択します。
Exchange 2010 では、DAG ネットワークの手動構成が多くのシナリオで必要でした。 既定では、それ以降のバージョンの Exchange では、DAG ネットワークはシステムによって自動的に構成されます。 DAG ネットワークを作成または変更する前に、最初に次のコマンドを実行して、手動 DAG ネットワーク制御を有効にする必要があります。
Set-DatabaseAvailabilityGroup <DAGName> -ManualDagNetworkConfiguration $true
手動 DAG ネットワーク構成を有効にした後には、Exchange 管理シェル内の New-DatabaseAvailabilityGroupNetwork コマンドレットを使用して、DAG ネットワークを作成できます。 DAG ネットワークを作成する方法の詳細については、「 データベース可用性グループのネットワークを作成する」を参照してください。
Exchange 管理シェル内の Set-DatabaseAvailabilityGroupNetwork コマンドレットを使用して DAG ネットワーク プロパティを構成できます。 DAG ネットワーク プロパティを構成する方法の詳細な手順については、「 データベース可用性グループのネットワーク プロパティを構成する」を参照してください。 各 DAG ネットワークには、次に示す構成対象の必須および省略可能のパラメーターがあります。
ネットワーク名: 最大 128 文字の DAG ネットワークの一意の名前。
ネットワークの説明: 最大 256 文字の DAG ネットワークの説明 (省略可能)。
ネットワーク サブネット: IPAddress/Bitmask (インターネット プロトコル バージョン 4 (IPv4) サブネットの場合は 192.168.1.0/24 など)、インターネット プロトコル バージョン 6 (IPv6) の場合は 2001:DB8:0:C000::/64 の形式で入力された 1 つ以上のサブネット。
レプリケーションを有効にする: EAC で、DAG ネットワークをレプリケーション トラフィックに専用にし、MAPI トラフィックをブロックするチェック ボックスをオンにします。 レプリケーションで DAG ネットワークが使用されないようにし、MAPI トラフィックを有効にするには、チェック ボックスをオフにします。 Exchange 管理シェルで、Set-DatabaseAvailabilityGroupNetwork コマンドレットの ReplicationEnabled パラメーターを使用して、レプリケーションを有効または無効にします。
注:
MAPI ネットワーク上でレプリケーションを無効にしても、その MAPI ネットワークをレプリケーション用に使用しないことは保証されません。 構成されたすべてのレプリケーション ネットワークがオフラインになるか、それらに障害が発生した場合 (または他の原因で使用不可能になった場合)、レプリケーションが無効に設定されている MAPI ネットワークのみが残っていると、システムではその MAPI ネットワークがレプリケーションに使用されます。
システムによって作成される最初の DAG ネットワーク (MapiDagNetwork や ReplicationDagNetwork01 など) は、クラスター サービスによって列挙されるサブネットに基づきます。 各 DAG メンバーは、同じ数のネットワーク アダプターを保持する必要があり、各ネットワーク アダプターは、一意のサブネット上で IPv4 アドレス (およびオプションで IPv6 アドレス) を保持する必要があります。 複数の DAG メンバーに同じサブネット上の複数の IPv4 アドレスを割り当てることが可能ですが、特定の DAG メンバーにおけるネットワーク アダプターと IP アドレスの各ペアは、一意のサブネット上に存在する必要があります。 また、MAPI ネットワークに使用されるアダプターのみをデフォルト ゲートウェイで構成する必要があります。 レプリケーション ネットワークは、デフォルト ゲートウェイで構成しないでください。
たとえば、各メンバーが 2 つのネットワーク アダプター (1 つが MAPI ネットワーク専用で、もう 1 つがレプリケーション ネットワーク専用) を保持する 2 メンバーの DAG である、DAG1 があるとします。 IP アドレス構成設定の例を次の表に示します。
ネットワーク アダプター設定の例
| サーバー-ネットワーク アダプター | IP アドレス/サブネット マスク | 既定のゲートウェイ |
|---|---|---|
| EX1-MAPI | 192.168.1.15/24 | 192.168.1.1 |
| EX1-レプリケーション | 10.0.0.15/24 | 該当なし |
| EX2-MAPI | 192.168.1.16 | 192.168.1.1 |
| EX2-レプリケーション | 10.0.0.16 | 該当なし |
次の構成では、DAG に 192.168.1.0 と 10.0.0.0 という 2 つのサブネットが構成されています。 EX1 と EX2 が DAG に追加されると、2 つのサブネットが列挙され、MapiDagNetwork (192.168.1.0) と ReplicationDagNetwork01 (10.0.0.0) の 2 つの DAG ネットワークが作成されます。 これらのネットワークは、次の表に示すように構成されます。
単一サブネットの DAG で列挙される DAG ネットワーク設定
| 名前 | サブネット | インターフェイス | MAPI アクセスが有効 | レプリケーションが有効 |
|---|---|---|---|---|
| MapiDagNetwork | 192.168.1.0/24 | EX1 (192.168.1.15) EX2 (192.168.1.16) |
True | True |
| ReplicationDagNetwork01 | 10.0.0.0/24 | EX1 (10.0.0.15) EX2 (10.0.0.16) |
False | True |
専用レプリケーション ネットワークとして ReplicationDagNetwork01 の構成を完了するには、次のコマンドを実行して MapiDagNetwork のレプリケーションを無効にします。
Set-DatabaseAvailabilityGroupNetwork -Identity DAG1\MapiDagNetwork -ReplicationEnabled:$false
MapiDagNetwork に対してレプリケーションが無効になると、Microsoft Exchange Replication サービスは ReplicationDagNetwork01 を連続レプリケーションに使用するようになります。 ReplicationDagNetwork01 に障害が発生した場合、Microsoft Exchange Replication サービスは元どおり MapiDagNetwork を連続レプリケーションに使用します。 MapiDagNetwork への戻りは、高可用性を維持するためにシステムによって意図的に実行されます。
DAG ネットワークおよび複数サブネット展開
前の例では、異なる 2 つのサブネット (192.168.1.0 と 10.0.0.0) が DAG によって使用されていましたが、各メンバーでは同じサブネットを使用して MAPI ネットワークを構成するため、DAG は単一サブネットの DAG と見なされます。 DAG メンバーが MAPI ネットワークで異なるサブネットを使用する場合、その DAG は複数サブネットの DAG と呼ばれます。 複数サブネットの DAG では、適切なサブネットが各 DAG ネットワークに自動的に関連付けられます。
たとえば、DAG2 は、各メンバーに 2 つのネットワーク アダプター (1 つは MAPI ネットワーク専用、もう 1 つはレプリケーション ネットワーク用) を持ち、各 DAG メンバーは別のサブネット上の MAPI ネットワークを持つ別の Active Directory サイトに配置されている 2 つのメンバー DAG であるとします。 IP アドレス構成設定の例を次の表に示します。
複数サブネットの DAG のネットワーク アダプター設定の例
| サーバー-ネットワーク アダプター | IP アドレス/サブネット マスク | 既定のゲートウェイ |
|---|---|---|
| EX1-MAPI | 192.168.0.15/24 | 192.168.0.1 |
| EX1-レプリケーション | 10.0.0.15/24 | 該当なし |
| EX2-MAPI | 192.168.1.15 | 192.168.1.1 |
| EX2-レプリケーション | 10.0.1.15 | 該当なし |
次の構成では、DAG に 192.168.0.0、192.168.1.0、10.0.0.0、10.0.1.0 の 4 つのサブネットが構成されています。 EX1 と EX2 が DAG に追加されると、4 つのサブネットが列挙されますが、MapiDagNetwork (192.168.0.0、192.168.1.0) と ReplicationDagNetwork01 (10.0.0.0、10.0.1.0) の 2 つの DAG ネットワークのみが作成されます。 これらのネットワークは、次の表に示すように構成されます。
複数サブネットの DAG で列挙される DAG ネットワーク設定
| 名前 | サブネット | インターフェイス | MAPI アクセスが有効 | レプリケーションが有効 |
|---|---|---|---|---|
| MapiDagNetwork | 192.168.0.0/24 192.168.1.0/24 |
EX1 (192.168.0.15) EX2 (192.168.1.15) |
True | True |
| ReplicationDagNetwork01 | 10.0.0.0/24 10.0.1.0/24 |
EX1 (10.0.0.15) EX2 (10.0.1.15) |
False | True |
DAG ネットワークおよび iSCSI ネットワーク
既定では、DAG は、検出されたすべてのネットワークの検出を実行し、基になるクラスターで使用するように構成されます。 この検出には、1 つ以上の DAG メンバーに iSCSI ストレージを使用した結果として使用されているインターネット SCSI (iSCSI) ネットワークの検出が含まれます。 ベスト プラクティスとして、iSCSI ストレージでは専用ネットワークとネットワーク アダプターを使用する必要があります。 これらのネットワークは、DAG またはそのクラスターによって管理したり、DAG ネットワーク (MAPI またはレプリケーション) として使用したりしないでください。 代わりに、これらのネットワークは、iSCSI ストレージ トラフィック専用になるように、DAG による使用を手動で無効にする必要があります。 iSCSI ネットワークが検出されて DAG ネットワークとして使用されないようにするには、次の例に示すように 、Set-DatabaseAvailabilityGroupNetwork コマンドレットを使用して、現在検出されている iSCSI ネットワークを無視するように DAG を構成します。
Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork02 -ReplicationEnabled:$false -IgnoreNetwork:$true
また、このコマンドは、ネットワークがクラスターに使用されないようにします。 iSCSI ネットワークは引き続き DAG ネットワークとして表示されますが、上記のコマンドを実行した後は、MAPI またはレプリケーション トラフィックに使用されません。
DAG メンバーの構成
DAG のメンバーであるメールボックス サーバーには、以下の説明どおりに構成する必要のある高可用性に固有のいくつかのプロパティがあります。
自動データベース マウント ダイヤル
AutoDatabaseMountDial パラメーターには、データベース フェールオーバー後の自動データベース マウント動作を指定します。 Set-MailboxServer コマンドレットを使用して、次の任意の値で AutoDatabaseMountDial パラメーターを構成できます。
BestAvailability: この値を指定すると、コピー キューの長さが 12 以下の場合、フェールオーバー直後にデータベースが自動的にマウントされます。 コピー キューの長さは、パッシブ コピーによって認識されるレプリケートが必要なログの数です。 コピー キューの長さが 12 を超える場合、データベースは自動的にマウントされません。 コピー キューの長さが 12 以下の場合、Exchange は残りのログをパッシブ コピーにレプリケートし、データベースをマウントします。GoodAvailability: この値を指定すると、コピー キューの長さが 6 以下の場合、フェールオーバー直後にデータベースが自動的にマウントされます。 コピー キューの長さは、パッシブ コピーによって認識されるレプリケートが必要なログの数です。 コピー キューの長さが 6 を超える場合、データベースは自動的にマウントされません。 コピー キューの長さが 6 以下の場合、Exchange は残りのログのパッシブ コピーへのレプリケートを試みてデータベースをマウントします。Lossless: この値を指定した場合、アクティブ コピーで生成されたすべてのログがパッシブ コピーにコピーされるまで、データベースは自動的にマウントされません。 また、この設定によって、アクティブ マネージャーの最適なコピーの選択アルゴリズムでは、コピー キューの長さではなく、データベース コピーのアクティブ化優先順位の値に基づいてアクティブ化の対象候補が並べ替えられます。
既定値は GoodAvailability です。 または GoodAvailabilityをBestAvailability指定した場合、アクティブなコピーのすべてのログをアクティブ化されているパッシブ コピーにコピーできないと、メールボックス データが失われる可能性があります。 ただし、(既定で有効になっている) セーフティ ネット機能を利用すると、セーフティ ネット キューにあるメッセージを再送信することで、ほとんどのデータ損失を防止することができます。
例: 自動データベース マウント ダイヤルの構成
次の例では、 の AutoDatabaseMountDial 設定を使用してメールボックス サーバーを構成 GoodAvailabilityします。
Set-MailboxServer -Identity EX1 -AutoDatabaseMountDial GoodAvailability
データベース コピーの自動アクティブ化ポリシー
DatabaseCopyAutoActivationPolicy パラメーターには、選択されているメールボックス サーバー上のメールボックス データベース コピーに対して可能な自動アクティブ化の種類を指定します。 Set-MailboxServer コマンドレットを使用して、次の任意の値で DatabaseCopyAutoActivationPolicy パラメーターを構成できます。
Blocked: この値を指定した場合、選択したメールボックス サーバーでデータベースを自動的にアクティブ化することはできません。IntrasiteOnly: この値を指定すると、同じ Active Directory サイト内のサーバーでデータベース コピーをアクティブ化できます。 このアクティブ化により、クロスサイト フェールオーバーまたはアクティブ化が防止されます。 このプロパティは受信メールボックス データベース コピーが対象です (たとえば、パッシブ コピーのアクティブ コピー化)。 別の Active Directory サイトでアクティブなデータベース コピーについては、このメールボックス サーバーではデータベースをアクティブ化できません。Unrestricted: この値を指定した場合、選択したメールボックス サーバーでメールボックス データベース のコピーをアクティブ化することに特別な制限はありません。
例: データベース コピーの自動アクティブ化ポリシーの構成
次の例では、 の DatabaseCopyAutoActivationPolicy 設定を使用してメールボックス サーバーを構成 Blockedします。
Set-MailboxServer -Identity EX1 -DatabaseCopyAutoActivationPolicy Blocked
最大アクティブ データベース
MaximumActiveDatabases パラメーター (これも Set-MailboxServer コマンドレットで使用される) には、メールボックス サーバーにマウントできるデータベースの数を指定します。 個々のメールボックス サーバーに過剰な負荷がかからないようにして、展開に関する要件を満たすようにメールボックス サーバーを構成できます。
MaximumActiveDatabases パラメーターは、整数値で構成します。 最大数に達したとき、フェールオーバーまたは切り替え操作が発生した場合はサーバー上のデータベース コピーはアクティブ化されません。 コピーがサーバー上で既にアクティブな場合は、サーバーはデータベースのマウントを許可しません。
例: アクティブ データベースの最大数の構成
次の例では、最大 20 個のアクティブ なデータベースをサポートするようにメールボックス サーバーを構成します。
Set-MailboxServer -Identity EX1 -MaximumActiveDatabases 20
DAG メンバーに対するメンテナンスの実行
DAG メンバーに対してどのような種類のソフトウェアまたはハードウェア メンテナンスを実行する場合も、その前に必ず DAG メンバーをメンテナンス モードにしてください。 次のスクリプトは、DAG メンテナンス手順を支援するExchange Serverで提供されます。
StartDagServerMaintenance.ps1: すべてのアクティブなデータベースをサーバーから移動します。 また、プライマリ アクティブ マネージャー (PAM) の役割など、すべての重要な DAG サポート機能も移動して、メンテナンスが完了する前にサーバーに戻らないようにします。
StopDagServerMaintenance.ps1: DAG メンバーをメンテナンス モードから外し、すべてのデータベースとすべての重要な DAG サポート機能のアクティブ ターゲットにすることを支援します。
上記のどちらのスクリプトも 、ServerName パラメーター (DAG メンバーのホスト名または完全修飾ドメイン名 (FQDN) のいずれか) と WhatIf パラメーターを受け入れます。 どちらのスクリプトもローカルまたはリモートで実行できます。 スクリプトを実行するサーバーには、Windows フェールオーバー クラスター管理ツール (RSAT-Clustering) がインストールされている必要があります。
注:
RedistributeActiveDatabases.ps1 スクリプトも使用できます。これは、各データベースのライセンス認証設定番号で示されているように、特定の DAG メンバーにメールボックス データベースをマウントする際に役立ちます。 ただし、Exchange 2016 CU2 以降では、 PreferenceMoveFrequency という名前の新しい DAG プロパティによって、DAG 全体のデータベース コピーのバランスが自動的に調整されます。 そのため、この機能を無効にした場合、またはデータベース のコピーの バランスを手動で調整する場合にのみ、RedistributeActiveDatabases.ps1スクリプトを使用する必要があります。
StartDagServerMaintenance.ps1 スクリプトは、次のタスクを実行します。
DAG メンバーの DatabaseCopyAutoActivationPolicy パラメーターの値を に
Blocked設定します。これにより、データベース コピーがサーバー上でアクティブ化されなくなります。クラスターのノードを一時停止して、ノードの PAM を抑止し、再度 PAM になることを防ぎます。
DAG メンバーで現在ホストされているすべてのアクティブなデータベースを他の DAG メンバーに移動します。
DAG メンバーが既定のクラスター グループを現在所有している場合、その既定のクラスター グループ (および PAM の役割) は、スクリプトによって別の DAG メンバーに移動されます。
前のタスクのいずれかが失敗すると、成功したデータベース移動操作を除くすべての操作がスクリプトによって元に戻されます。
トランスポート キューのフラッシュやクライアント接続の中断など、DAG メンバーのメンテナンス手順を開始するには、次のタスクを実行します。
トランスポート キューを空にするには、次のコマンドを実行します。
Set-ServerComponentState <ServerName> -Component HubTransport -State Draining -Requester Maintenanceトランスポート キューのドレインを開始するには、次のコマンドを実行します。
Restart-Service MSExchangeTransportすべてのユニファイド メッセージング呼び出し (Exchange 2016 のみ) をドレインするプロセスを開始するには、次のコマンドを実行します。
Set-ServerComponentState <ServerName> -Component UMCallRouter -State Draining -Requester MaintenanceDAG メンテナンス スクリプトにアクセスするには、次のコマンドを実行します。
CD $ExScriptsStartDagServerMaintenance.ps1 スクリプトを実行するには、次のコマンドを実行します。
.\StartDagServerMaintenance.ps1 -ServerName <ServerName> -MoveComment Maintenance -PauseClusterNodeMoveComment パラメーターの値については、任意の表記を作成できます。 上記の例では、"メンテナンス" を使用しています。
注:
このスクリプトの実行には時間がかかる場合があります。この間、画面にアクティビティが表示されない場合があります。
ローカル キュー内の配信待ちメッセージを Target パラメーターで指定された Exchange サーバーにリダイレクトするには、次のコマンドを実行します。
Redirect-Message -Server <ServerName> -Target <Server FQDN>サーバーをメンテナンス モードにするには、次のコマンドを実行します。
Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Inactive -Requester Maintenance
サーバーのメンテナンスの準備ができていることを確認するには、以下のタスクを実行します。
サーバーがメンテナンス モードになっていることを確認するには、次のコマンドを実行するときに、サーバーのみが
MonitoringRecoveryActionsEnabledアクティブな状態であることを確認します。Get-ServerComponentState <ServerName> | Format-Table Component,State -Autosizeサーバーがアクティブなデータベース コピーをホストしていないことを確認するには、次のコマンドを実行します。
Get-MailboxServer <ServerName> | Format-List DatabaseCopyAutoActivationPolicyクラスター ノードが一時停止されていることを確認するには、次のコマンドを実行します。
Get-ClusterNode <ServerName> | Format-Listすべてのトランスポート キューが空になっていることを確認するには、次のコマンドを実行します。
Get-Queue
メンテナンスが完了し、DAG メンバーがサービスに戻る準備ができたら、 StopDagServerMaintenance.ps1 スクリプトを使用すると、DAG メンバーをメンテナンス モードから取り出して運用環境に戻すのに役立ちます。 StopDagServerMaintenance.ps1 スクリプトは、次のタスクを実行します。
クラスターのノードを再開し、DAG メンバーのすべてのクラスター機能を有効にします。
DAG メンバーの DatabaseCopyAutoActivationPolicy パラメーターの値を に
Unrestricted設定します。DAG メンバーでホストされているデータベース コピーごとに Resume-MailboxDatabaseCopy コマンドレットを実行します。
トランスポート キューとクライアント接続の再開など、DAG メンバーを完全な運用状態に復元する準備ができたら、次のタスクを実行します。
サーバーをメンテナンス不足モードにして、クライアント接続を受け入れる準備をするように構成するには、次のコマンドを実行します。
Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Maintenanceサーバーがユニファイド メッセージング呼び出しを受け入れるようにするには (Exchange 2016 のみ)、次のコマンドを実行します。
Set-ServerComponentState <ServerName> -Component UMCallRouter -State Active -Requester MaintenanceDAG メンテナンス スクリプトにアクセスするには、次のコマンドを実行します。
CD $ExScriptsStopDagServerMaintenance.ps1 スクリプトを実行するには、次のコマンドを実行します。
.\StopDagServerMaintenance.ps1 -serverName <ServerName>トランスポート キューがメッセージの受け入れと処理を再開できるようにするには、次のコマンドを実行します。
Set-ServerComponentState <ServerName> -Component HubTransport -State Active -Requester Maintenanceトランスポート アクティビティを再開するには、次のコマンドを実行します。
Restart-Service MSExchangeTransport
サーバーが運用環境で使用できる状態であることを確認するには、次のタスクを実行します。
サーバーがメンテナンス モードになっていないことを確認するには、次のコマンドを実行します。
Get-ServerComponentState <ServerName> | Format-Table Component,State -Autosize
Exchange 更新プログラムをインストールしていて、更新プロセスが失敗した場合、一部のサーバー コンポーネントが非アクティブ状態のままになる可能性があります。これは、上記 Get-ServerComponentState のコマンドレットの出力に表示されます。 この問題を解決するには、次のコマンドを実行します。
Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester FunctionalSet-ServerComponentState <ServerName> -Component Monitoring -State Active -Requester FunctionalSet-ServerComponentState <ServerName> -Component RecoveryActionsEnabled -State Active -Requester Functional
DAG メンバーのシャットダウン
Exchange 高可用性ソリューションは、Windows シャットダウン プロセスと統合されています。 1 つまたは複数の DAG メンバーにレプリケートされたマウント済みデータベースがある DAG 内で Windows サーバーのシャットダウンを管理者またはアプリケーションが開始すると、システムではシャットダウン プロセスの完了を許可する前に、マウント済みデータベースの別のコピーをアクティブ化しようとします。
ただし、この新しい動作では、シャットダウン中のサーバー上のすべてのデータベースでアクティブ化が発生 lossless することは保証されません。 そのため、サーバー切り替えを実行してから、DAG のメンバーであるサーバーをシャットダウンすることをお勧めします。
DAG メンバーに対する更新プログラムのインストール
DAG のメンバーであるサーバーに Exchange 更新プログラムをインストールすることは、比較的簡単なプロセスです。 DAG のメンバーであるサーバー上に更新プログラムをインストールすると、すべての Exchange サービスとクラスター サービスを含むいくつかのサービスがインストール時に停止します。 DAG メンバーに更新プログラムを適用する一般的なプロセスは、次のとおりです。
上記手順を使用して、DAG メンバーをメンテナンス モードにします。
更新プログラムをインストールします。
上記手順を使用して DAG メンバーのメンテナンス モードを解除して、実稼働環境に戻します。
必要に応じて、 RedistributeActiveDatabases.ps1 スクリプトを使用して、DAG 全体でアクティブなデータベース コピーを再調整します。
最新の Exchange 更新プログラムの詳細については、「ビルド番号とリリース日Exchange Server」を参照してください。
注:
すべての DAG メンバーは、常に同じバージョンの Exchange サーバー (累積的な更新プログラムやセキュリティ更新プログラムを含む) で実行する必要があります。 すべての DAG メンバーの "ローリング更新" を実行し、別の Exchange バージョンのメンバーと共に DAG を長時間実行しないでください。