データベース可用性グループの管理

  • [アーティクル]

製品: Exchange Server 2013

データベース可用性グループ (DAG) は、データベース、サーバー、またはネットワーク障害からのデータベース レベルの自動復旧を提供する最大 16 Microsoft Exchange Server 2013 メールボックス サーバーのセットです。 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 アドレスの取得を試行します。

作成する DAG に、Windows Server 2012 R2 を実行するメールボックス サーバーを含める場合は、クラスター管理アクセス ポイントのない DAG を作成するオプションもあります。 その場合、そのクラスターは Active Directory 内にクラスター名オブジェクト (CNO) を持たず、クラスターのコア リソース グループにネットワーク名リソースまたは IP アドレス リソースは含まれません。

DAG を作成する方法の詳細な手順については、「データベース可用性グループを作成する」を参照してください。

DAG を作成する場合、指定した名前の DAG を表す空のオブジェクトと、 msExchMDBAvailabilityGroup のオブジェクト クラスが Active Directory に作成されます。

DAG は、クラスター ハートビート、クラスター ネットワーク、クラスター データベースなどの Windows フェールオーバー クラスタリング テクノロジのサブセットを使用します (データベースの状態の変更 (アクティブからパッシブ、リバース、マウントからマウント解除、逆など) など、変更または迅速に変更できるデータを格納します。 DAG は Windows フェールオーバー クラスタリングに依存するため、Windows Server 2008 R2 Enterprise または Datacenter オペレーティング システム、Windows Server 2012 Standardまたは Datacenter オペレーティング システム、または R2 Standard または Datacenter オペレーティング システムWindows Server 2012を実行している Exchange 2013 メールボックス サーバーでのみ作成できます。

注:

DAG によって作成および使用されるフェールオーバー クラスターは、DAG 専用である必要があります。 このクラスターは、他の高可用性ソリューションや別の目的のために使用することはできません。 たとえば、フェールオーバー クラスターは、他のアプリケーションやサービスをクラスター化するためには使用できません。 DAG 以外の目的で DAG の基になるフェールオーバー クラスターを使用することは、サポートされません。

DAG ミラーリング監視サーバーおよび監視ディレクトリ

DAG を作成するときには、Active Directory フォレスト内で一意になる 15 文字以内の DAG 名を指定する必要があります。 また、各 DAG はミラーリング監視サーバーとミラーリング監視ディレクトリで構成されます。 ミラーリング監視サーバーとそのディレクトリは、DAG 内のメンバーが偶数の場合にクォーラムの目的でのみ使用されます。 監視ディレクトリを事前に作成する必要はありません。 Exchange は、ミラーリング監視サーバー上に必要なディレクトリを作成してセキュリティで保護します。 ディレクトリは、DAG ミラーリング監視サーバー以外の目的で使用しないでください。

ミラーリング監視サーバーの要件は以下のとおりです。

  • DAG のメンバーでないミラーリング監視サーバーを指定する必要があります。
  • 監視サーバーを DAG と同じ Active Directory フォレスト内に配置する必要があります。
  • ミラーリング監視サーバーでは、サポートされているバージョンの Windows Server を実行している必要があります。 詳細については、「 Exchange 2013 のシステム要件」を参照してください。
  • 1 台のサーバーが、複数の DAG のミラーリング監視サーバーとして動作できます。 ただし、各 DAG には独自の監視ディレクトリが必要です。

どのサーバーをミラーリング監視サーバーとして使用するかにかかわらず、目的のミラーリング監視サーバーで Windows ファイアウォールを有効にする場合は、ファイルとプリンターの共有に対する Windows ファイアウォールの例外を設定する必要があります。

重要

指定したミラーリング監視サーバーが Exchange 2013 または Exchange 2010 サーバーではない場合は、DAG を作成する前に、監視サーバーのローカル Administrators グループに Exchange Trusted Subsystem ユニバーサル セキュリティ グループ (USG) を追加する必要があります。 必要に応じて、Exchange がディレクトリを作成し、ミラーリング監視サーバーで共有できることを確認するには、これらのセキュリティ アクセス許可が必要です。

ミラーリング監視サーバーは、SMB ポート 445 を使用します。

ミラーリング監視サーバーおよびミラーリング監視ディレクトリは、フォールト トレラントである必要はなく、冗長性または高可用性の形式を使用する必要がありません。 クラスター化されたファイル サーバーをミラーリング監視サーバー用に使用する必要はなく、ミラーリング監視サーバーのその他の復元形式を採用する必要もありません。 これには、さまざまな理由があります。 DAG の規模が大きい場合は (例: 6 メンバー以上)、数か所で障害が発生しない限り、ミラーリング監視サーバーは必要になりません。 6 メンバーの DAG は、2 つまでの投票者障害ではクォーラムを失わないため、3 つの投票者に障害が発生して初めて、クォーラムを維持するためにミラーリング監視サーバーが必要になります。 また、現在のミラーリング監視サーバーに影響を与える障害がある場合 (例: ハードウェア障害のためにミラーリング監視サーバーを失う場合)、クォーラムがあることを前提として、Set-DatabaseAvailabilityGroup コマンドレットを使用して新しいミラーリング監視サーバーと監視ディレクトリを構成できます。

注:

ミラーリング監視サーバーでそのストレージが失われたか、監視ディレクトリまたは共有アクセス許可が変更された場合は、 Set-DatabaseAvailabilityGroup コマンドレットを使用して、元の場所のミラーリング監視サーバーおよび監視ディレクトリを構成することもできます。

ミラーリング監視サーバーの配置に関する留意点

DAG のミラーリング監視サーバーの配置は、ビジネス要件と組織で使用可能なオプションによって異なります。 Exchange 2013 には、以前のバージョンの Exchange で推奨されていないか利用できない新しい DAG 構成オプションのサポートが含まれています。 これらのオプションには、第 3 のデータセンター、ブランチ オフィス、または Microsoft Azure 仮想ネットワークなどの第 3 の場所の使用が含まれています。

下の表に、さまざまな展開シナリオに関する一般的なミラーリング監視サーバーの配置に関する推奨事項を示します。

展開シナリオ 推奨事項
単一のデータセンターに展開された単一の DAG ミラーリング監視サーバーを DAG メンバーと同じデータセンターに設置する
2 つのデータセンターにまたがって展開された単一の DAG、使用可能な追加の場所なし ミラーリング監視サーバーを Microsoft Azure 仮想ネットワークに設置してデータセンターの自動フェールオーバーを有効にするか、

ミラーリング監視サーバーをプライマリ データセンターに設置する
単一のデータセンターに展開された複数の DAG ミラーリング監視サーバーを DAG メンバーと同じデータセンターに設置する。 追加のオプションには以下が含まれます。
  • 複数の DAG に対する同じミラーリング監視サーバーの使用
  • 別の DAG 用のミラーリング監視サーバーとして機能する DAG メンバーの使用
2 つのデータセンターにまたがって展開された複数の DAG ミラーリング監視サーバーを Microsoft Azure 仮想ネットワークに設置してデータセンターの自動フェールオーバーを有効にするか、

各 DAG のプライマリと見なされるデータセンター内の監視サーバーを見つけます。 追加のオプションには以下が含まれます。
  • 複数の DAG に対する同じミラーリング監視サーバーの使用
  • 別の DAG 用のミラーリング監視サーバーとして機能する DAG メンバーの使用
3 つ以上のデータセンターにまたがって展開された単一または複数の DAG この構成では、ミラーリング監視サーバーを大部分のクォーラム投票が存在するデータセンターに設置する必要があります。

DAG が 2 つのデータセンターにまたがって展開されている場合の Exchange 2013 の新しい構成オプションは、ミラーリング監視サーバーをホストするための第 3 の場所を使用することです。 組織内にある第 3 の場所のネットワーク インフラストラクチャが、DAG の展開先の 2 つのデータセンターに影響を与えるネットワーク障害からは分離されている場合、DAG のミラーリング監視サーバーをその第 3 の場所に展開して、データセンターレベルの障害イベントに対応してデータベースを他のデータセンターに自動的にフェールオーバーする機能を伴う 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 コマンドレットは失敗し、エラーが発生します。 ミラーリング監視サーバーを指定して監視ディレクトリを指定しないと、以下のエラー メッセージが表示されます。

|タスクは、サーバー <サーバー名>に既定の監視ディレクトリを作成できませんでした。 ミラーリング監視ディレクトリを手動で指定してください|

ミラーリング監視サーバーと監視ディレクトリを指定すると、以下の警告メッセージが表示されます。

|ミラーリング監視サーバー 'ServerName' のファイル共有にアクセスできません。 この問題を修正するまで、データベース可用性グループは、障害に対する脆弱性が増す可能性があります。 Set-DatabaseAvailabilityGroup を使用して操作を再試行してください。 エラー: ネットワーク パスが見つかりませんでした。|

DAG が作成された後で、サーバーが追加される前に Windows ファイアウォールがミラーリング監視サーバー上で有効になると、Windows ファイアウォールは DAG メンバーの追加や削除をブロックすることがあります。 ミラーリング監視サーバー上で Windows ファイアウォールが有効であり、WMI 向けのファイアウォールの例外が構成されていない場合、 Add-DatabaseAvailabilityGroupServer コマンドレットでは以下の警告メッセージが表示されます。

|ミラーリング監視サーバー ' ServerName' にファイル共有監視ディレクトリ 'C:\DAGFileShareWitnesses\DAG_FQDN' を作成できませんでした。 この問題を修正するまで、データベース可用性グループは、障害に対する脆弱性が増す可能性があります。 Set-DatabaseAvailabilityGroup を使用して操作を再試行してください。 エラー: サーバー 'ServerName' で WMI 例外が発生しました:RPC サーバーが使用できません。 (HRESULT からの例外: 0x800706BA)|

このようなエラーと警告を解決するには、次のいずれかを実行します。

  • 手動でミラーリング監視サーバー上に監視ディレクトリと共有を作成し、そのディレクトリと共有に対して DAG フル コントロールの CNO を割り当てます。
  • Windows ファイアウォールで WMI の例外を有効にします。
  • Windows ファイアウォールを無効にします。

DAG メンバーシップ

DAG が作成されたら、EAC のデータベース可用性グループの管理ウィザード、またはシェルの 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 オブジェクトが空と見なされるため、DAG のクラスターと CNO が既に存在しているにもかかわらず、 Add-DatabaseAvailabilityGroupServer コマンドレットがこれらのオブジェクトを作成してしまうためです。 最初の DAG サーバーを含む DAG オブジェクトがレプリケートされたことを確認するには、追加する 2 番目のサーバー上で Get-DatabaseAvailabilityGroup コマンドレットを使用して、追加した最初のサーバーが DAG のメンバーとして一覧されていることを確認します。

2 番目以降のサーバーが DAG に追加されると、次のアクションが実行されます。

  • サーバーが DAG の Windows フェールオーバー クラスターに参加します。
  • クォーラム モデルが次のように自動調整されます。
    • ノード マジョリティ クォーラム モデルは、奇数のメンバーを持つ DAG に使用されます。
    • ノードおよびファイル共有マジョリティ クォーラム モデルは、偶数のメンバーを持つ DAG に使用されます。
  • ミラーリング監視ディレクトリと共有は、必要に応じて Exchange によって自動作成されます。
  • サーバーは Active Directory の DAG オブジェクトに追加されます。
  • マウントされたデータベースに関する情報で、クラスター データベースが更新されます。

注:

クォーラム モデル変更は、自動的に実行されます。 ただし、クォーラム モデルが自動的に適切なモデルに変わらない場合は、DAG 用のクォーラム設定を修正する Identity パラメーターのみを指定して Set-DatabaseAvailabilityGroup コマンドレットを実行します。

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 メンバーが Windows Server 2012 R2 を実行している場合に、クラスター管理アクセス ポイントを持たない DAG を作成すると、CNO は作成されないため、DAG 用の CNO を作成する必要はありません。

コンピューター アカウントの作成が制限されているか、コンピューター アカウントが既定のコンピューター コンテナーではないコンテナーに作成される環境では、CNO の事前設定と準備が可能です。 CNO のコンピューター アカウントを作成して無効にし、以下の作業のいずれかを実行します。

  • DAG に追加している最初のメールボックス サーバーのコンピューター アカウントに対して、コンピューター アカウントのフル コントロールを割り当てます。
  • Exchange Trusted Subsystem USG にコンピューター アカウントのフル コントロールを割り当てます。

DAG に追加する最初のメールボックス サーバーのコンピューター アカウントにコンピューター アカウントの完全な制御を割り当てると、LOCAL SYSTEM セキュリティ コンテキストで事前にステージングされたコンピューター アカウントを管理できるようになります。 Exchange 信頼されたサブシステム USG には、ドメイン内のすべての Exchange サーバーのマシン アカウントが含まれているため、代わりに、コンピューター アカウントの完全な制御を Exchange 信頼されたサブシステム USG に割り当てることができます。

DAG の CNO の事前設定と準備の詳細な手順については、「データベース可用性グループのクラスター名オブジェクトを事前設定する」を参照してください。

DAG からのサーバーの削除

EAC のデータベース可用性グループの管理ウィザードまたはシェルの Remove-DatabaseAvailabilityGroupServer コマンドレットを使用して、メールボックス サーバーを DAG から削除できます。 メールボックス サーバーを DAG から削除するためには、レプリケートされたすべてのメールボックス データベースを最初にサーバーから削除する必要があります。 レプリケートされたメールボックス データベースと共にメールボックス サーバーを DAG から削除しようとすると、タスクが失敗します。

特定の操作を実行する前にメールボックス サーバーを DAG から削除しなくてはならないシナリオがあります。 これらのシナリオには、次のものがあります。

  • サーバーの回復操作の実行: DAG のメンバーであるメールボックス サーバーが失われた場合、または障害が発生し、回復不可能であり、交換が必要な場合は、 セットアップ /m:RecoverServer スイッチを使用してサーバーの回復操作を実行できます。 ただし、回復操作を実行するためには、まず ConfigurationOnly パラメーターを指定して Remove-DatabaseAvailabilityGroupServer コマンドレットを使用することによって DAG からサーバーを削除する必要があります。

  • データベース可用性グループの削除: DAG を削除する必要がある場合があります (たとえば、サードパーティのレプリケーション モードを無効にする場合)。 DAG を削除しなければならない場合、まず DAG からすべてのサーバーを削除する必要があります。 メンバーが含まれる DAG を削除しようとすると、タスクが失敗します。

DAG プロパティの構成

サーバーが DAG に追加されたら、EAC またはシェルを使用して、DAG で使用される監視サーバーと監視ディレクトリ、DAG に割り当てられた IP アドレスなど、DAG のプロパティを構成できます。

構成可能なプロパティは、次のとおりです。

  • 監視サーバー: ファイル共有監視のファイル共有をホストするサーバーの名前。 クライアント アクセス サーバーをミラーリング監視サーバーとして指定することをお勧めします。 これにより、システムは必要に応じて共有を自動的に構成、セキュリティで保護、使用でき、メッセージング管理者はミラーリング監視サーバーの可用性を認識できるようになります。

  • 監視ディレクトリ: ファイル共有監視データの格納に使用されるディレクトリの名前。 このディレクトリは、指定されたミラーリング監視サーバー上で自動的に作成されます。

  • データベース可用性グループの IP アドレス: DAG メンバーが R2 Windows Server 2012実行されていて、IP アドレスのない DAG を作成している場合を除き、1 つ以上の IP アドレスを DAG に割り当てる必要があります。 DAG の IP アドレスは、手動で割り当てられた静的 IP アドレスを使って構成するか、組織内の DHCP サーバーを使って DAG に自動で割り当てることができます。

シェルを使用すると、DAG IP アドレス、ネットワーク暗号化と圧縮設定、ネットワーク検出、レプリケーションに使用される TCP ポート、代替監視サーバーと監視ディレクトリの設定など、EAC で使用できない DAG プロパティを構成し、データセンター のアクティブ化調整モードを有効にすることができます。

DAG プロパティを構成する方法の詳細な手順については、「データベース可用性グループのプロパティを構成する」を参照してください。

DAG ネットワーク暗号化

DAG は、Windows Server オペレーティング システムの暗号化機能を活用することによって、暗号化の使用をサポートします。 DAG は Exchange サーバー間に Kerberos 認証を使用します。 Microsoft Kerberos セキュリティ サポート プロバイダー (SSP) EncryptMessage および DecryptMessage API は、DAG ネットワーク トラフィックの暗号化を処理します。 Microsoft Kerberos SSP は、複数の暗号化アルゴリズムをサポートします (完全な一覧については、「Kerberos プロトコル拡張機能」のセクション 3.1.5.2「暗号化タイプ」を参照)。 Kerberos 認証ハンドシェイクは、リスト内でサポートされている最も強力な暗号化プロトコルを選択します。 通常は、Advanced Encryption Standard (AES) 256 ビットであり、場合によってはデータの整合性を保持するために SHA ハッシュ ベースのメッセージ認証コード (HMAC) を使用します。 詳細については、「HMAC」を参照してください。

ネットワーク暗号化は、DAG ネットワークではなく DAG のプロパティです。 シェルの Set-DatabaseAvailabilityGroup コマンドレットを使用して、DAG ネットワーク暗号化を構成できます。 DAG ネットワーク通信に使用可能な暗号化設定を次の表に示します。

DAG ネットワーク通信暗号化の設定

Setting 説明
無効 ネットワーク暗号化が使用されません。
有効 ネットワーク暗号化がすべての DAG ネットワーク上でレプリケーションおよびシード処理に使用されます。
InterSubnetOnly ネットワーク暗号化が別々のサブネット間でレプリケートするときに DAG ネットワーク上で使用されます。 これは既定の設定です。
SeedOnly ネットワーク暗号化がシード処理専用ですべての DAG ネットワーク上で使用されます。

DAG ネットワーク圧縮

DAG では、組み込みの圧縮がサポートされます。 圧縮が有効な場合、DAG ネットワーク通信では XPRESS が使用されます。これは、LZ77 アルゴリズムの Microsoft 実装です。 詳細については、ワイヤーフォーマットプロトコル仕様の「デフレートアルゴリズムの説明」およびセクション3.1.4.11.1.2.1「LZ77圧縮アルゴリズム」を参照してください。 これは、多くの Microsoft プロトコルで使用されるのと同じ種類の圧縮です。特に、Microsoft Outlook と Exchange の間の MAPI RPC 圧縮です。

ネットワーク暗号化と同様に、ネットワーク圧縮も DAG ネットワークではなく DAG のプロパティです。 DAG ネットワークの圧縮は、シェルの Set-DatabaseAvailabilityGroup コマンドレットを使用して構成します。 DAG ネットワーク通信に使用可能な圧縮設定を次の表に示します。

DAG ネットワーク通信圧縮設定

Setting 説明
無効 ネットワーク圧縮が使用されません。
有効 ネットワーク圧縮がすべての DAG ネットワーク上でレプリケーションおよびシード処理に使用されます。
InterSubnetOnly ネットワーク圧縮が別々のサブネット間でレプリケートするときに DAG ネットワーク上で使用されます。 これは既定の設定です。
SeedOnly ネットワーク圧縮がシード処理専用ですべての DAG ネットワーク上で使用されます。

DAG ネットワーク

DAG ネットワークは、レプリケーション トラフィックまたは MAPI トラフィックのいずれかに使用する 1 つまたは複数のサブネットの集合です。 それぞれの DAG には 1 つまでの MAPI ネットワークと、任意の数のレプリケーション ネットワークが含まれます。

単一ネットワーク アダプター構成

単一ネットワーク アダプター構成の場合、同じネットワークが MAPI トラフィックとレプリケーション トラフィックの両方で使用されます。 複雑さを軽減するために、Exchange サーバーには 1 つのネットワーク アダプターを使用することをお勧めします。そのため、MAPI とレプリケーションの両方のトラフィックを同じネットワーク上に配置しても問題ありません。

デュアル ネットワーク アダプター構成

通常、デュアル ネットワーク アダプターを使用する必要があるのは、ネットワーク トラフィックの増加により単一ネットワーク アダプターが飽和状態になる可能性がある場合のみです。

デュアル ネットワーク アダプター構成では、一方のネットワークは通常、レプリケーション トラフィック専用であり、他方のネットワークは主に MAPI トラフィックに使用されます。 各 DAG メンバーにネットワーク アダプターを追加して、追加の DAG ネットワークをレプリケーション ネットワークとして構成することも可能です。

注:

複数のレプリケーション ネットワークを使用する場合、ネットワーク使用の優先順位を指定する方法はありません。 Exchange はログ配布に使用するレプリケーション ネットワークのグループからレプリケーション ネットワークをランダムに選択します。

Exchange 2010 では、DAG ネットワークの手動構成が多くのシナリオで必要でした。 Exchange 2013 では、既定で DAG ネットワークがシステムによって自動的に構成されます。 DAG ネットワークを作成または変更する前に、最初に次のコマンドを実行して、手動 DAG ネットワーク制御を有効にする必要があります。

Set-DatabaseAvailabilityGroup <DAGName> -ManualDagNetworkConfiguration $true

手動の DAG ネットワーク構成を有効にしたら、シェルの New-DatabaseAvailabilityGroupNetwork コマンドレットを使用して DAG ネットワークを作成できます。 DAG ネットワークを作成する方法の詳細については、「 データベース可用性グループのネットワークを作成する」を参照してください。

シェルの 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 トラフィックを有効にするために、このチェック ボックスをオフにします。 シェルで、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 を連続レプリケーションに使用します。 この動作は、高可用性を維持するためにシステムによって意図的に行われます。

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 はい

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 のメンバーであるメールボックス サーバーには、以下の説明どおりに構成する必要のある高可用性に固有のいくつかのプロパティがあります。

  • Automatic database mount dial
  • Database copy automatic activation policy
  • Maximum active databases

自動データベース マウント ダイヤル

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 サポート機能 (たとえば、プライマリ Active Manager (PAM) ロール) が別のサーバーに移動され、サーバーへの移動がブロックされます。 具体的には、次のタスクを実行する必要があります。

  1. トランスポート キューをドレインするプロセスを開始するには、 Set-ServerComponentState <ServerName> -Component HubTransport -State Draining -Requester Maintenance

  2. トランスポート キューのドレインを開始するには、 Restart-Service MSExchangeTransport

  3. すべてのユニファイド メッセージング呼び出しをドレインするプロセスを開始するには、 Set-ServerComponentState <ServerName> -Component UMCallRouter -State Draining -Requester Maintenance

  4. ローカル キュー内の配信待ちメッセージを Target パラメーターで指定されたメールボックス サーバーにリダイレクトするには、 Redirect-Message -Server <ServerName> -Target <MailboxServerFQDN>

  5. ノードが PAM になるのを防ぐクラスター ノードを一時停止するには、 Suspend-ClusterNode <ServerName>

  6. DAG メンバーで現在ホストされているすべてのアクティブ なデータベースを他の DAG メンバーに移動するには、 Set-MailboxServer <ServerName> -DatabaseCopyActivationDisabledAndMoveNow $True

  7. サーバーがアクティブなデータベース コピーをホストしないようにするには、 Set-MailboxServer <ServerName> -DatabaseCopyAutoActivationPolicy Blocked

  8. サーバーをメンテナンス モードにするには、 Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Inactive -Requester Maintenance

サーバーのメンテナンスの準備ができていることを確認するには、以下のタスクを実行します。

  1. サーバーがメンテナンス モードに設定されていることを確認するには、 Get-ServerComponentState <ServerName> | ft Component,State -Autosize

  2. サーバーでアクティブなデータベース コピーがホストされていないことを確認するには、 Get-MailboxServer <ServerName> | ft DatabaseCopy* -Autosize

  3. ノードが一時停止されていることを確認するには、 Get-ClusterNode <ServerName> | fl

  4. すべてのトランスポート キューがドレインされていることを確認するには、 Get-Queue

メンテナンスが完了し、DAG メンバーがサービスに戻る準備ができたら、次のタスクを実行して、DAG メンバーをメンテナンス モードから取り出して運用環境に戻すことができます。

  • サーバーがメンテナンス モードから外れていることを指定するには、 Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Maintenance

  • サーバーがユニファイド メッセージングの呼び出しを受け入れるようにするには、 Set-ServerComponentState <ServerName> -Component UMCallRouter -State Active -Requester Maintenance

  • クラスター内のノードを再開し、サーバーの完全なクラスター機能を有効にするには、 Resume-ClusterNode <ServerName>

  • データベースがサーバー上でアクティブになるようにするには、 Set-MailboxServer <ServerName> -DatabaseCopyActivationDisabledAndMoveNow $False

  • 自動アクティブ化ブロックを削除するには、 Set-MailboxServer <ServerName> -DatabaseCopyAutoActivationPolicy Unrestricted

  • トランスポート キューを有効にし、サーバーがメッセージを受け入れて処理できるようにするには、 Set-ServerComponentState <ServerName> -Component HubTransport -State Active -Requester Maintenance

  • トランスポート アクティビティを再開するには、 Restart-Service MSExchangeTransport

サーバーが運用環境で使用できる状態であることを確認するには、次のタスクを実行します。

  • サーバーがメンテナンス モードでないことを確認するには、 Get-ServerComponentState <ServerName> | ft Component,State -Autosize

  • Exchange 更新プログラムをインストールしていて、更新プロセスが失敗した場合、一部のサーバー コンポーネントが非アクティブ状態のままになる可能性があります。これは、上記の Get-ServerComponentState コマンドレットの出力に表示されます。 これを解決するには、次のコマンドを実行します。

    • Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Functional
    • Set-ServerComponentState <ServerName> -Component Monitoring -State Active -Requester Functional
    • Set-ServerComponentState <ServerName> -Component RecoveryActionsEnabled -State Active -Requester Functional

DAG メンバーのシャットダウン

Exchange 2013 高可用性ソリューションは、Windows シャットダウン プロセスに統合されます。 1 つまたは複数の DAG メンバーにレプリケートされたマウント済みデータベースがある DAG 内で Windows サーバーのシャットダウンを管理者またはアプリケーションが開始すると、システムではシャットダウン プロセスの完了を許可する前に、マウント済みデータベースの別のコピーをアクティブ化しようとします。

ただし、この新しい動作では、シャットダウン中のサーバー上のすべてのデータベースでアクティブ化が発生 lossless することは保証されません。 そのため、サーバー切り替えを実行してから、DAG のメンバーであるサーバーをシャットダウンすることをお勧めします。

DAG メンバーに対する更新プログラムのインストール

DAG のメンバーであるサーバーへの Microsoft Exchange Server 2013 更新プログラムのインストールは、比較的単純なプロセスです。 DAG のメンバーであるサーバー上に更新プログラムをインストールすると、すべての Exchange サービスとクラスター サービスを含むいくつかのサービスがインストール時に停止します。 DAG メンバーに更新プログラムを適用する一般的なプロセスは、次のとおりです。

  1. 上記手順を使用して、DAG メンバーをメンテナンス モードにします。

  2. 更新プログラムをインストールします。

  3. 上記手順を使用して DAG メンバーのメンテナンス モードを解除して、実稼働環境に戻します。

  4. オプションで、RedistributeActiveDatabases.ps1 スクリプトを使って DAG 間でアクティブ データベース コピーのバランスを再調整します。

Microsoft ダウンロードセンターから Exchange 2013 の最新の更新プログラムをダウンロードできます。