次の方法で共有

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

  • [アーティクル]

製品: Exchange Server 2013

Exchange Server 2013 の Exchange DAG について説明します。 データベース可用性グループ (DAG) のライフ サイクルと、高可用性とサイト回復のための DAG の使用について取り上げます。

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

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

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

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

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

注:

サーバーとソリューションが Exchange 2013 のシステム要件と Exchange 2013仮想化で規定されている要件に準拠している場合、物理メールボックス サーバーと仮想化メールボックス サーバーの組み合わせを含む 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 2013 Service Pack 1 以降を実行しているサーバーでのみ作成できます。 クラスター管理アクセス ポイントなしの DAG には、次のような特性があります。

  • クラスター/DAG には IP アドレスが割り当てられないため、クラスター コア リソース グループに IP アドレス リソースは含まれません。
  • クラスターにはネットワーク名アドレスが割り当てられないため、クラスター コア リソース グループにネットワーク名リソースは含まれません。
  • クラスター/DAG の名前は DNS に登録されず、ネットワーク上で解決可能ではありません。
  • Active Directory にクラスター名オブジェクト (CNO) は作成されません。
  • フェールオーバー クラスター管理ツールを使用してクラスターを管理することはできません。 Windows PowerShell を使用して管理し、PowerShell コマンドレットを個々のクラスターのメンバーに対して実行する必要があります。

この例では、シェルを使用することにより、サーバーが 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 が Exchange 2013 SP1 以降を Windows Server 2012 R2 で実行している場合は、管理アクセス ポイントを使用せずに DAG を作成することをお勧めします。 これにより DAG 構成作業が簡素化され、1 つ以上の IP アドレスの必要がなくなり、また DAG の攻撃面が少なくなります。

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

DAG は既定で、DAG 内のサーバー間でのメールボックス データベースのレプリケートに、組み込みの連続レプリケーション機能を使用するよう設計されています。 Exchange 2013 でサード パーティ レプリケーション 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 の作成、DAG メンバーシップの管理、DAG プロパティの構成、メールボックス データベース コピーの作成と監視、および切り替えの実行の詳細については、「高可用性とサイト復元の管理」を参照してください。

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

すべての DAG の下には Windows フェールオーバー クラスターがあります。 フェールオーバー クラスターはクォーラムの概念を使用します。これは、有権者の合意を使用して、クラスター メンバーのサブセット (すべてのメンバーまたはメンバーの過半数を意味する可能性があります) が一度に機能していることを確認します。 クォーラムは Exchange 2013 の新しい概念ではありません。 以前のバージョンの 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 は管理者の介入を再度操作する必要があります。

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

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

高可用性を実現するためのデータベース可用性グループ (DAG) の使用

DAG によるメールボックス データベースの高可用性の実現方法を理解するため、5 つのメンバーを持つ DAG を使用する次の例を考えてみます。 この DAG を以下の図に示します。

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

上の図では、緑色のデータベースはアクティブなメールボックス データベース コピーであり、青いデータベースはパッシブ メールボックス データベース コピーです。 この例では、データベース コピーは各サーバーにミラー化されず、複数のサーバーに分散されています。 これにより、DAG 内の 2 つのサーバーに同じデータベース コピーのセットが存在することが保証され、定期的なメンテナンスの結果として他のコンポーネントが使用できない間に発生する障害など、障害に対する回復性が向上します。

上の例の DAG を使用して、次のシナリオで複数のデータベースおよびサーバーの障害に対する復元性について説明します。

最初は、すべてのデータベースとサーバーが正常です。 サーバーをメンテナンス モードにするため、EX2 にオペレーティング システムの更新をインストールする必要があります。 これによりサーバーの切り替えが実行され、他のメールボックス サーバー上にある DB4 のコピーがアクティブになります。 サーバーの切り替えを実行すると、現在のサーバーのスケジュールされた停止に備えて、DAG 内のすべてのアクティブ メールボックス データベースのコピーが、現在のサーバーから他の 1 つ以上のメールボックス サーバーに移動されます。 この例では、EX2 (DB4) にアクティブ メールボックス データベースが 1 つしかないので、アクティブ メールボックス データベースのコピーが 1 つだけ移動します。

サーバーがオフラインのデータベース可用性グループ (DAG)。

EX2 での保守の実行時に、EX3 で致命的なハードウェア障害が発生しオフラインになります。 オフラインになる前に、EX3 は DB2 のアクティブ コピーをホストします。 この障害から回復するため、システムは自動的に、EX1 でホストされている DB2 のコピーを 30 秒以内にアクティブ化します。 これを以下の図で説明します。

サーバーがオフラインで、サーバーが失敗した DAG。

EX2 のスケジュールされたメンテナンスが終了したら、サーバーをオンラインにし、メンテナンス モードを終わらせます。 EX2 が使用可能になると DAG の他のメンバーに通知され、EX2 上でホストされている DB1、DB4、および DB5 のコピーが自動的に各データベースのアクティブ コピーと同期されます。 これを以下の図で説明します。

復元されたサーバーがデータベースを再同期する DAG。

EX3 で障害の発生したハードウェア コンポーネントが新しいコンポーネントと置き換えられると、EX3 がオンラインになります。 EX3 が使用可能になると、DAG の他のメンバーに通知され、EX3 上でホストされている DB2、DB3、および DB4 のコピーが自動的に各データベースのアクティブ コピーと同期されます。 これを以下の図で説明します。

メンバーがデータベース コピーを再同期する DAG。

サイト回復を実現するためのデータベース可用性グループ (DAG) の使用

データセンター内で高可用性を提供するだけでなく、1 つまたは複数のデータセンターにサイトの回復性を提供する構成で、DAG を 1 つ以上のデータセンターに拡張することもできます。 上の図の例では、DAG は単一のデータセンターと単一の Active Directory サイトにあります。 増分展開を使用すると、メールボックス サーバーと必要なサポート リソース (1 つ以上の Active Directory サーバー、DNS サービス) を展開することで、この DAG を 2 つ目のデータセンター (および 2 つ目の Active Directory サイト) に拡張できます。 次の図に示すように、メールボックス サーバーが DAG に追加されます。

DAG は 2 つの Active Directory サイト間で拡張されます。

この例では、Redmond データセンター内の各アクティブ データベースのパッシブ コピーが、Dublin データセンターの EX6 上で構成されます。 ただし、サイト復元を実現する DAG 構成の例は、他にもたくさんあります。 次に例を示します。

  • EX6 は、パッシブ データベース コピーのみをホストするのではなく、すべてのアクティブ コピー、またはアクティブ コピーとパッシブ コピーの組み合わせをホストできます。

  • EX6 のほか、複数の DAG メンバーを Dublin データセンターに展開し、別の障害に対して保護することができます。 この構成によって追加容量も提供されるため、Redmond データセンターで障害が発生しても、Dublin データセンターを使用することでずっと多くのユーザー群をサポートできます。

サイト回復を実現するための複数のデータベース可用性グループ (DAG) の使用

上記の例では、1 つの DAG を複数のデータセンターに拡張して、片方または両方のデータセンターでのサイト復元を実現していました。 DAG の拡張先である各データセンターにアクティブ ユーザー群がある環境で、サイト復元に 1 つの DAG を使用する場合は、広域ネットワーク (WAN) 接続に単一障害点があります。 これはクォーラムで、大多数の投票者がアクティブであり相互に通信できる必要があるためです。

上記の例では、大多数の投票者が Redmond データセンターに配置されています。 Dublin データセンターがアクティブ メールボックス データベースをホストしており、Dublin データセンターにローカル ユーザー群が含まれる場合、WAN が停止すると Dublin ユーザーのメッセージング サービスが停止します。 WAN 接続が切断されると、Redmond データセンターの DAG メンバーのみがクォーラムを保持して引き続きメッセージング サービスを提供することになります。

アクティブ ユーザー群が含まれる複数のデータセンターでサイト復元が必要な場合に、WAN が単一障害点にならないようにするには、複数の DAG を展開し、各 DAG が別々のデータセンターに大多数の投票者を持つようにする必要があります。 WAN が停止すると、接続が復元されるまでレプリケーションがブロックされます。 各 DAG が引き続き自身のローカル ユーザー群に対してサービスを提供するため、ユーザーはメッセージング サービスを利用できます。