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

  • [アーティクル]

データベース可用性グループ (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 メンバー間でメールボックス データベースをレプリケートできます。

注:

物理メールボックス サーバーと仮想化メールボックス サーバーの組み合わせを含む DAG の作成がサポートされています。ただし、サーバーとソリューションは、Exchange Serverのシステム要件と仮想化に関する要件Exchange Server準拠している必要があります。 すべての 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 をサポートするサード パーティのデータ レプリケーションを使用している場合は、ThirdPartyReplication パラメーターを使用して New-DatabaseAvailabilityGroup コマンドレットを使用して、サードパーティのレプリケーション モードで DAG を作成する必要があります。 このモードを有効にすると、無効にすることはできません。

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

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

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

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

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

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

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

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

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

メンバー数が偶数の DAG では、フェールオーバー クラスターの Node および File Share Majority クォーラム モードが使用されます。このモードでは、タイ ブレーカーとして機能する外部監視サーバーが使用されます。 このクォーラム モードでは、各 DAG メンバーが投票を取得します。 さらに、監視サーバーは、重み付けされた投票を 1 つの DAG メンバーに提供するために使用されます (たとえば、1 つではなく 2 つの投票を取得します)。 クラスター クォーラム データは既定で DAG の各メンバーのシステム ディスクに格納され、それらのディスク間で一貫性が維持されます。 ただし、クォーラム データのコピーはミラーリング監視サーバーに格納されません。 監視サーバー上のファイルは、データの最も更新されたコピーを持つメンバーを追跡するために使用されますが、監視サーバーにはクラスター クォーラム データのコピーがありません。 このモードでは、大多数の有権者 (DAG メンバーとミラーリング監視サーバー) が操作可能であり、クォーラムを維持するために相互に通信できる必要があります。 大多数の有権者が互いに通信できない場合、DAG の基になるクラスターはクォーラムを失い、DAG は管理者の介入を再度操作する必要があります。 詳細については、「 データセンターの切り替え 」と「 Restore-DatabaseAvailabilityGroup」を参照してください。

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

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