データベース可用性グループ (DAG)

適用対象: yes-img-162016 yes-img-192019 yes-img-seサブスクリプション エディション

データベース可用性グループ (DAG) は、Microsoft Exchange Server に組み込まれているメールボックス サーバーの高可用性とサイト復元フレームワークの基本コンポーネントです。 DAG とは、一連のデータベースをホストし、個々のサーバーまたはデータベースに影響を与える障害からデータベース レベルを自動回復させる、最大 16 台のメールボックス サーバーからなるグループのことです。

重要

DAG 内のすべてのサーバーでは、同じバージョンの Exchange を実行している必要があります。 たとえば、Exchange 2013 サーバーと Exchange 2016 サーバーを同じ DAG に混在させることはできません。

DAG はメールボックス データベースのレプリケーション、データベースとサーバーの切り替えとフェールオーバー、Active Manager と呼ばれる内部コンポーネントの境界です。 Active Manager は DAG のすべてのメールボックス サーバーで実行され、DAG 内の切り替えとフェールオーバーを管理します。 Active Manager の詳細については、「 アクティブ マネージャー」を参照してください。

DAG 内のサーバーは、DAG 内の他のサーバーからのメールボックス データベースのコピーをホストできます。 サーバーは DAG に追加されると、DAG 内の他のサーバーと連動して、ディスク、サーバー、ネットワークの障害などのメールボックス データベースに影響を与える障害からの自動的な回復を提供します。

注:

DAG の作成、DAG メンバーシップの管理、DAG プロパティの構成、メールボックス データベース コピーの作成と監視、および切り替えの実行の詳細については、「高可用性とサイト復元の管理」を参照してください。

データベース可用性グループのライフサイクル

DAG は増 分展開の概念を利用します。これは、Exchange をインストールした後、すべてのメールボックス サーバーとデータベースのサービスとデータの可用性を展開する機能です。 Exchange Server メールボックス サーバーを展開した後、DAG を作成し、メールボックス サーバーを DAG に追加して、DAG メンバー間でメールボックス データベースをレプリケートできます。

注:

サーバーとソリューションが Exchange Server のシステム要件および Exchange Server の仮想化で規定されている要件に準拠していれば、物理メールボックス サーバーと仮想化されたメールボックス サーバーの組み合わせを含む DAG を作成することはサポートされています。 すべての Exchange 高可用性構成の場合と同様、スケジュールされた停止およびスケジュールされていない停止時に必要な負荷を処理するように DAG のすべてのメールボックス サーバーが適切にサイジングされていることを確認する必要があります。

New-DatabaseAvailabilityGroup コマンドレットを使用して DAG が作成されます。 Active Directory に空のオブジェクトとして最初に DAG が作成されます。 このディレクトリ オブジェクトは、サーバー メンバーシップ情報や一部の DAG 構成設定など、DAG についての関連情報を格納するために使用されます。 最初のサーバーを DAG に追加すると、フェールオーバー クラスターが DAG 用に自動作成されます。 このフェールオーバー クラスターは DAG によって排他的に使用される DAG 専用のものである必要があります。 このクラスターの他の目的での使用はサポートされていません。

フェールオーバー クラスターが作成されるほか、ネットワーク障害またはサーバー障害がないかサーバーを監視するインフラストラクチャが開始されます。 フェールオーバー クラスターのハートビート機構とクラスター データベースは、データベース マウント状態、レプリケーション状態、および最終マウント位置など、急速に変化する DAG 関連情報を追跡および管理するために使用されます。

DAG には作成時に一意の名前が付けられ、1 つ以上の固定 IP アドレスが割り当てられるか、動的ホスト構成プロトコル (DHCP) を使用するよう構成されるか、クラスター管理アクセス ポイントなしで作成されます。 管理アクセス ポイントのない DAG は、Windows Server 2012 R2 Standard または Datacenter エディションで Exchange 2019、Exchange 2016、または Exchange 2013 Service Pack 1 以降を実行しているサーバー上でのみ作成できます。 クラスター管理アクセス ポイントなしの DAG には、次のような特性があります。

  • クラスター/DAG には IP アドレスが割り当てられないため、クラスター コア リソース グループに IP アドレス リソースは含まれません。

  • クラスターにはネットワーク名アドレスが割り当てられないため、クラスター コア リソース グループにネットワーク名リソースは含まれません。

  • クラスター/DAG の名前は DNS に登録されず、ネットワーク上で解決可能ではありません。

  • Active Directory にクラスター名オブジェクト (CNO) は作成されません。

  • フェールオーバー クラスター管理ツールを使用してクラスターを管理することはできません。 Windows PowerShell を使用して管理し、PowerShell コマンドレットを個々のクラスターのメンバーに対して実行する必要があります。

この例では、Exchange 管理シェル を使用することにより、サーバーが 3 つあるクラスター管理アクセス ポイントを伴う DAG を作成する方法を示します。 2 台のサーバー (EX1 および EX2) が同じサブネット上 (10.0.0.0) にあり、3 台目のサーバー (EX3) が別のサブネット上 (192.168.0.0) にあります。

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EX4 -DatabaseAvailabilityGroupIPAddresses 10.0.0.5,192.168.0.5
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3

クラスター管理アクセス ポイントなしで DAG を作成するコマンドは、非常によく似ています。

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EX4 -DatabaseAvailabilityGroupIPAddresses ([System.Net.IPAddress])::None
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3

DAG1 のクラスターは、EX1 が DAG に追加される際に作成されます。 クラスターの作成中に、 Add-DatabaseAvailabilityGroupServer コマンドレットによって DAG 向けに構成された IP アドレスが取得され、EX1 で見つかったサブネットのいずれにも一致しない IP アドレスは無視されます。 上記の最初の例では、DAG1 のクラスターは IP アドレス 10.0.0.5 で作成され、192.168.0.5 は無視されます。 上の 2 番目の例では、 DatabaseAvailabilityGroupIPAddresses パラメーターの値を使用して、管理アクセス ポイントを持たない DAG のフェールオーバー クラスターを作成するようにタスクに指示します。 このように、コア クラスター リソース グループ内に IP アドレスまたはネットワーク名リソースを指定してクラスターが作成されます。

次に EX2 が追加され、 Add-DatabaseAvailabilityGroupServer コマンドレットで DAG 向けに構成された IP アドレスを再取得します。 EX2 は EX1 と同じサブネット上にあるため、クラスターの IP アドレスは変更されません。

次に EX3 が追加され、 Add-DatabaseAvailabilityGroupServer コマンドレットで DAG 向けに構成された IP アドレスを再取得します。 EX3 に「192.168.0.5」と一致するサブネットがあるため、アドレス「192.168.0.5」はクラスター グループの IP アドレス リソースとして追加されます。 また、各 IP アドレス リソースのネットワーク名リソースに OR の依存関係が自動的に構成されます。 192.168.0.5 というアドレスは、クラスター コア リソース グループが EX3 に移動する際に、クラスターによって使用されます。

クラスター管理アクセス ポイントのある DAG では、ネットワーク名リソースがオンラインになる際に、Windows フェールオーバー クラスタリングによって、ドメイン ネーム システム (DNS) にクラスターの IP アドレスが登録されます。 さらに、EX1 がクラスターに追加されると、クラスター名オブジェクト (CNO) が Active Directory に作成されます。 ネットワーク名、IP アドレス、クラスターの CNO は、DAG 機能では使用されません。 管理者とエンドユーザーが、クラスター/DAG 名または IP アドレスとインターフェイスしたり接続したりする必要がある理由はありません。 一部のサード パーティ アプリケーションは、クラスター管理アクセス ポイントに接続して、バックアップや監視などの管理タスクを実行します。 クラスター管理アクセス ポイントを必要とするサード パーティ製アプリケーションを使用せず、DAG が Windows Server 2012 R2 で Exchange 2016 または Exchange 2019 を実行している場合は、管理アクセス ポイントなしで DAG を作成することをお勧めします。 これにより DAG 構成作業が簡素化され、1 つ以上の IP アドレスの必要がなくなり、また DAG の攻撃面が少なくなります。

DAG は、監視サーバーおよび監視ディレクトリを使用するようにも構成されています。 ミラーリング監視サーバーとミラーリング監視ディレクトリは、システムによって自動的に構成されるか、管理者によって手動で構成されます。 上記の例では、EX4 (DAG のメンバーではなく、今後もそうなる予定がないサーバー) は、DAG の監視サーバーとして手動で構成されています。

DAG は既定で、DAG 内のサーバー間でのメールボックス データベースのレプリケートに、組み込みの連続レプリケーション機能を使用するよう設計されています。 Exchange Serverでサード パーティ レプリケーション API をサポートするサード パーティのデータ レプリケーションを使用している場合は、New-DatabaseAvailabilityGroup コマンドレットと ThirdPartyReplication パラメーターを使用して、サード パーティ レプリケーション モードで DAG を作成する必要があります。 このモードを有効にすると、無効にすることはできません。

DAG が作成されたら、メールボックス サーバーを DAG に追加できます。 最初のサーバーが DAG に追加されると、DAG が使用するクラスターが形成されます。 DAG は、クラスター ハートビート、クラスター ネットワーク、クラスター データベースなどの Windows フェールオーバー クラスタリング テクノロジを利用します (データベースの状態がアクティブからパッシブに、またはその逆、またはマウントからマウント解除された状態に変化するなど、変化するデータを格納するため)。 後続の各サーバーが DAG に追加されると、基になるクラスターに参加し、クラスターのクォーラム モデルが Exchange によって自動的に調整され、サーバーが Active Directory の DAG オブジェクトに追加されます。

メールボックス サーバーが DAG に追加されると、DAG でのデータベース レプリケーションにネットワーク暗号化やネットワーク圧縮を使用するかどうかなど、さまざまな DAG プロパティを構成できます。 また、DAG ネットワークの構成および追加の DAG ネットワークの作成を行うことができます。

DAG にメンバーを追加して DAG を構成した後、各サーバー上のアクティブ メールボックス データベースを他の DAG メンバーにレプリケートできます。 メールボックス データベースのコピーを作成した後、さまざまな組み込みの監視ツールを使用してコピーの正常性と状態を監視できます。 また、データベースとサーバーの切り替えも実行できます。

データベース可用性グループのクォーラム モデル

すべての DAG の下には、Windows フェールオーバー クラスターがあります。 フェールオーバー クラスターでは、クォーラムの概念を使用します。クォーラムの概念は、投票者のコンセンサスを使用して、クラスター メンバーの 1 つのサブセット (すべてのメンバーまたはメンバーの過半数を意味する場合があります) が同時に機能することを保証します。 クォーラムは、Exchange Server にとって新しい概念ではありません。 以前のバージョンの Exchange の高可用性メールボックス サーバーも、フェールオーバー クラスタリングとそのクォーラムの概念を使用します。 クォーラムはメンバーとリソースの共有ビューを表し、クォーラムという用語は、すべてのクラスター メンバー間で共有されるクラスター内の構成を表す物理データを記述するためにも使用されます。 その結果、すべての DAG では、基になるフェールオーバー クラスターにクォーラムが必要です。 クラスターがクォーラムを失うと、すべての DAG 操作が終了し、DAG でホストされているマウントされているすべてのデータベースがマウント解除されます。 この場合、クォーラムの問題を修正し、DAG 操作を復元するには、管理者の介入が必要です。

クォーラムは次のように、一貫性を確保し、分割を回避するためのタイ ブレーカーとして機能し、クラスターの応答を確保するために重要です。

  • 一貫性の確保: Windows フェールオーバー クラスターの主な要件は、各メンバーが他のメンバーと整合性のあるクラスターのビューを常に持つことです。 クラスター ハイブは、クラスターに関連するすべての構成情報の最終的なリポジトリとして機能します。 クラスター ハイブを DAG メンバーにローカルに読み込めない場合、クラスター サービスは開始されません。これは、メンバーが他のメンバーと一貫性のあるクラスターのビューを持つという要件を満たしていることを保証できないためです。

  • タイブレーカーとして機能する: メンバー数が偶数の DAG では、クォーラム監視リソースを使用して、スプリットブレイン症候群のシナリオを回避し、DAG 内のメンバーの 1 つのコレクションのみが公式と見なされるようにします。 監視サーバーがクォーラムに必要な場合、監視サーバーと通信できる DAG のメンバーは、監視サーバーの witness.log ファイルにサーバー メッセージ ブロック (SMB) ロックを配置できます。 監視サーバーをロックする DAG メンバー ( ロック ノードと呼ばれます) は、クォーラム目的で追加の投票を保持します。 ロック ノードと接触している DAG メンバーは過半数であり、クォーラムを維持します。 ロック ノードに接続できない DAG メンバーは少数派であるため、クォーラムを失います。

  • 応答性の確保: 応答性を確保するために、クォーラム モデルは、クラスターが実行されているときは常に、分散システムの十分なメンバーが動作して通信可能であり、クラスターの現在の状態の少なくとも 1 つのレプリカを保証できることを確認します。 メンバーを通信状態にしたり、特定のレプリカが保証されているかどうかを確認するのに、特に時間はかかりません。

偶数のメンバーを持つ DAG は、タイ ブレーカーとして機能する外部監視サーバーを使用する、フェールオーバー クラスターのノードとファイル共有のマジョリティ クォーラム モードを使用します。 このクォーラム モードでは、各 DAG メンバーは投票を取得します。 さらに、監視サーバーは、1 人の DAG メンバーに加重投票を提供するために使用されます (たとえば、1 票ではなく 2 票を取得します)。 クラスター クォーラム データは既定で DAG の各メンバーのシステム ディスクに格納され、これらのディスク間で一貫性が保たれます。 ただし、クォーラム データのコピーは監視サーバーには保存されません。 監視サーバー上のファイルは、どのメンバーが最新のデータのコピーを持っているかを追跡するために使用されますが、監視サーバーにはクラスター クォーラム データのコピーがありません。 このモードでは、クォーラムを維持するために、投票者の過半数 (DAG メンバーと監視サーバー) が操作可能であり、相互に通信できる必要があります。 投票者の過半数が互いに通信できない場合、DAG の基盤となるクラスターはクォーラムを失い、DAG が再び動作するようになるには管理者の介入が必要になります。 詳細については、「Datacenter スイッチオーバーとRestore-DatabaseAvailabilityGroup を参照してください。

奇数のメンバーが含まれる DAG は、フェールオーバー クラスターのノード マジョリティ クォーラム モードを使用します。 このモードでは、各メンバーが票を取得し、各メンバーのローカル システム ディスクを使用してクラスター クォーラム データが格納されます。 DAG の構成が変更されると、その変更が別のディスクにも反映されます。 メンバーの半数 (切り捨て) + 1 のディスクで変更が行われた場合にのみ、その変更はコミットされたと見なされて永続的なものになります。 たとえば、DAG のメンバー数が 5 である場合は、2 + 1、つまり合計 3 のメンバーで変更が行われる必要があります。

クォーラムでは、投票者の大多数が互いに通信できる必要があります。 メンバー数が 4 である DAG の場合を考えてみましょう。 この DAG には偶数のメンバーが含まれるため、外部のミラーリング監視サーバーを使用して 5 番目のタイ ブレーク票がいずれかのクラスター メンバーに提供されます。 大多数の投票者 (およびクォーラム) を保持するには、3 つ以上の投票者が互いに通信できる必要があります。 サービスおよびデータ アクセスを中断せずにオフラインにできるのは、常に 2 つの投票者までです。 3 つ以上の投票者がオフラインになると、DAG がクォーラムを喪失し、問題が解決されるまでサービスとデータ アクセスが中断されます。

  • Last updated on