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

Exchange 2016
[このトピックはリリース前のドキュメントであり、将来のリリースで変更されることがあります。空白のトピックがプレースホルダーとして含まれています。フィードバックがある場合、ぜひお送りください。ExchangeHelpFeedback@microsoft.com 宛に電子メールを送信してください。]  

適用先:Exchange Server 2016

概要:Exchange 2016 でのデータベース可用性グループ (DAG) について

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

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

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

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

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

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

noteメモ:
サーバーとソリューションが Exchange 2016 のシステム要件 に準拠していて、かつ Exchange 2016 仮想化 で要件が満たされている場合は、物理メールボックス サーバーと仮想メールボックス サーバーの組み合わせを持つ 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 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 を実行しているなら、管理アクセス ポイントなしの DAG を作成することをお勧めします。これにより DAG 構成作業が簡素化され、1 つ以上の IP アドレスの必要がなくなり、また DAG の攻撃面が少なくなります。

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

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

DAG が作成されると、メールボックス サーバーを DAG に追加できます。DAG に 1 番目のサーバーが追加されると、DAG が使用するためにクラスターが形成されます。DAG は、クラスター ハートビート、クラスター ネットワーク、およびクラスター データベースなど、Windows フェールオーバー クラスタリング テクノロジを使用します。クラスター データベースは、アクティブとパッシブ、マウントとマウント解除の切り替えなど、データベース状態を変更するデータの格納に使用されます。2 台目以降の各サーバーが DAG に追加される際、それが基になるクラスターに追加され、Exchange によってクラスターのクォーラム モデルが自動的に調整されて、サーバーが Active Directory の DAG オブジェクトに追加されます。

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

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

このモードでは、すべての DAG が Windows フェールオーバー クラスターです。フェールオーバー クラスターではクォーラムという概念が使用され、クラスター メンバーの一部のみ (すべてのメンバーであることも、大多数のメンバーであることもある) が同時に機能していることを確認するため、投票者の総意が使用されます。クォーラムは Exchange 2016 での新しいコンセプトではありません。前のバージョンの Exchange でも、高可用性メールボックス サーバーはフェールオーバー クラスターとそのクォーラムの概念を使用しています。クォーラムはメンバーとリソースの共有表示を表します。クォーラムという用語は、すべてのクラスター メンバー間で共有されるクラスター内の構成を表す物理データを説明する目的でも用いられます。結果としてすべての DAG では、クォーラムを保持するために、基盤となるフェールオーバー クラスターが必要となります。クラスターがクォーラムを喪失すると、すべての DAG 操作は終了し、DAG でホストされているマウント済みのすべてのデータベースはマウント解除されます。この場合は管理者が介入し、クォーラムの問題を解決して DAG 操作を復元する必要があります。

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

  • 一貫性の確保   各メンバーが、常に他のメンバーと共通のクラスターを表示できるのが、Windows フェールオーバー クラスターの基本要件です。クラスター ハイブは、クラスターに関連するすべての構成情報の最終リポジトリとして動作します。クラスター ハイブをローカルで DAG メンバーに読み込みことができない場合は、クラスター サービスが開始されません。これは、そのメンバーが他のメンバーと共通のクラスターを表示するという要件に適合することが保証できないためです。

  • タイ ブレーカーとしての機能   クォーラム監視リソースは、偶数のメンバーが含まれる DAG 内で使用されます。このリソースの用途は、スプリット ブレイン現象のシナリオを回避し、DAG のメンバーの 1 つのコレクションのみが公式と見なされるようにすることです。クォーラムでミラーリング監視サーバーが必要な場合、ミラーリング監視サーバーと通信できる DAG のメンバーは、ミラーリング監視サーバーの witness.log ファイルにサーバー メッセージ ブロック (SMB) ロックをかけることができます。(ロッキング ノードと呼ばれる) ミラーリング監視サーバーをロックする DAG メンバーは、クォーラムのための追加票を保持しています。ロッキング ノードとやり取りする DAG メンバーが大多数であり、このメンバーはクォーラムを保持しています。ロッキング ノードとやり取りできない DAG メンバーは少数です。このメンバーはロッキング ノードとやり取りできないため、クォーラムを失います。

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

偶数のメンバーが含まれる DAG は、フェールオーバー クラスターのノードとファイル共有マジョリティ クォーラム モードを使用します。この場合、タイ ブレーカーとして機能する外部のミラーリング監視サーバーが使用されます。このクォーラム モードでは、各 DAG メンバーが投票権を取得します。また、ある DAG メンバーに荷重投票権を提供する (1 票ではなく 2 票というように) ためにミラーリング監視サーバーが使用されます。既定で、各 DAG メンバーのシステム ディスクにクラスター クォーラム データが格納され、ディスク間で一貫性が保たれます。ただし、クォーラム データのコピーはミラーリング監視サーバーに格納されません。ミラーリング監視サーバー上のファイルは、どのメンバーがデータの最新コピーを持っているかを追跡するために使用されますが、ミラーリング監視サーバーにはクラスター クォーラム データのコピーがありません。このモードでは、クォーラムを保持するために、投票者 ( DAG メンバーとミラーリング監視サーバー) の大多数が動作可能で、相互に通信できる必要があります。大多数の投票者が相互に通信できない場合は、DAG の基盤となるクラスターがクォーラムを喪失します。この場合は、管理者が介入して DAG を再度動作可能にする必要があります。

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

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

 
表示: