フェールオーバー クラスターでは、クォーラム監視は、クォーラム投票プロセスに参加することによってクラスターの高可用性を維持するのに役立つコンポーネントです。 クォーラムは、クラスターが稼働したままで維持できる障害の数を決定するために使用される概念です。
クラスターでは、各ノードが投票権を持ち、クォーラム監視もまた投票権を持つことができます。 投票の合計数によってクォーラムが決まります。 クラスターを運用するには、投票の半分以上がアクティブである必要があります。 投票数がこのしきい値を下回ると、クラスターの 2 つの部分がアクティブな部分であると見なされ、データの破損につながるスプリット ブレイン シナリオを回避するために、クラスターの実行が停止します。
クォーラム監視の役割は、偶数のノードがある場合、または特定のノードが失敗した場合に、過半数を達成または維持するための追加の投票を提供することです。 アクティブな投票数が必要な過半数を下回った場合、クラスターは "スプリット ブレイン" 状態を防ぐために操作を停止します。 スプリット ブレインは、クラスターの個別のセクションがそれぞれ独立して機能していると思われる場合に、データの不整合や破損が発生する可能性があるシナリオです。
クォーラムの証人の種類
高可用性を維持し、スプリットブレイン状態を防ぐために構成できる Quorum 監視には、3 つの異なる種類があります。 それぞれが、クラスターのクォーラムの正常性における公平な投票として機能します。
- Cloud witness - A cloud-based service like Azure Blob Storage
- Disk witness - A shared disk accessible by all nodes
- ファイル共有監視 - すべてのノードからアクセスできる共有フォルダー
継続的な運用とデータの整合性を確保するために、これらのクォーラム監視は、クラスター操作に対する過半数の投票を達成するための独自の方法を提供します。 ベスト プラクティスとして、奇数個の投票要素を持つクォーラムを構成します。 クラスターに偶数の投票ノードがある場合は、ディスク監視またはファイル共有監視を追加します。 この構成により、クラスターは 1 つの追加ノード障害を許容できます。 さらに、監視投票を追加すると、クラスター ノードの半分が同時に失敗したり、接続が失われる場合でも、クラスターの動作を継続できます。 選択したクォーラム構成に応じて、クラスターは次のいずれかのクォーラム モードで構成されます。
| Mode | Description |
|---|---|
| ノード マジョリティ (証人なし) | ノードにのみ投票があります。 クォーラム監視は構成されません。 クラスター クォーラムは、アクティブなクラスター ノードからの過半数の投票に依存します。 |
| ノード マジョリティと監視 (ディスクまたはファイル共有) | ノードには投票があります。 さらに、クォーラム監視も票を持ちます。 クラスター クォーラムは、監視投票を含め、アクティブなクラスター ノードからの過半数の投票に依存します。 クォーラム証人には、ディスク証人やファイル共有証人を指定できます。 |
| 非マジョリティ (ディスク監視のみ) | ノードには投票がありません。 票を持つのはディスク監視のみです。 クラスター クォーラムは、ディスク監視の状態に依存します。 一般に、このモードはお勧めしません。クラスターの単一障害点が作成されるため、このモードは選択しないでください。 |
Note
ファイル共有監視またはクラウド監視を使用している場合は、メンテナンスのためにすべてのクラスター ノードをシャットダウンする前に、最後のアクティブ ノードでクラスター サービスを再起動することを忘れないでください。 これにより、クラスターがオンラインに戻ったときに操作をスムーズに再開できます。 このような監視の種類では、最新のクラスター データベースが格納されないため、デバイスの起動時にエラーが発生する可能性があります。 To learn more, see Event 1561.
Tip
You can verify the dynamic vote assigned to a node by checking the DynamicWeight property of the cluster node using the Get-ClusterNode cmdlet. A DynamicWeight value of 0 means the node doesn't have a quorum vote, while a value of 1 indicates that the node has a quorum vote.
Cloud witness
クラウド監視は、物理データセンターではなく、クラウド内の Azure 仮想マシン (VM) をクォーラム監視として使用するため、従来のクラスター クォーラム監視構成とは異なります。 クラウド監視では、Azure Blob Storage を使用して、クォーラムを達成するための決定投票としてシステムで使用する BLOB ファイルの読み取りと書き込みを行います。 次の図は、クラウド監視を使用する構成例を示しています。
クラウド監視構成では、3 つ目の独立したデータセンターは必要ありません。また、他のデータセンターの 1 つがオフになっている場合、シャットダウンの合計を防ぐために追加の投票が行われます。 クォーラム監視を格納するための追加のサイトは必要なく、オンサイト データセンターに必要な定期的な物理メンテナンスも必要ありません。
冗長性に加えて、クラウド監視機能を使用する利点は他にもあります。
Azure Blob Storage を使うと、パブリック クラウドで VM をホストする場合に通常必要になる余分なメンテナンス オーバーヘッドが不要になります。
複数のクラスターに同じ Azure ストレージ アカウントを使用できます。 唯一の要件は、クラスターごとに 1 つの BLOB のみを使用し、クラスターの一意 ID の後に BLOB ファイル名を指定することです。
BLOB ファイルは、必要なデータが多くなく、クラスター ノードの状態が変化した場合にのみ更新されるため、ストレージ アカウントの継続的なコストが削減されます。
Azure には、クラウド監視リソースの種類が組み込まれています。
クラウド監視では、クラスター データベースのコピーは格納されません。
Disk witness
ディスク監視は、クラスターの高可用性を維持するためにフェールオーバー クラスターで使用されるクォーラム監視の一種です。 クラスター内のすべてのノードがアクセスできる共有ディスクとして、ディスク証人があります。 ディスク監視には、クラスター構成データベースの格納に使用される少量の記憶域が含まれています。 この記憶域スペースには、各ノードの状態やクラスター リソースの所有権など、クラスターに関する重要な情報が含まれます。 ここでは、そのしくみを示します:
ディスク監視は、すべてのノードがアクセスできる共有ストレージとして構成されますが、ただし、特定の時点では 1 つのノードだけが書き込みを行います。
クラスター サービスが開始されると、各ノードはディスク監視と通信して、最新のクラスター構成を読み取ります。
ディスク監視は、Quorum 投票プロセスに参加します。 ノードに障害が発生した場合、ディスク監視は追加の投票を提供し、スプリットブレイン シナリオを防ぐのに役立ちます。
ネットワーク パーティションがある場合、最も多くの票を持つディスク監視にアクセスできるパーティション側が引き続き実行され、クラスターの整合性が維持されます。
ディスク監視は、ノード数が偶数のクラスターで役立ちます。この場合、ノードはタイブレーカーとして機能し、常に多数決が行われるようにすることができます。 また、ディスク監視がクォーラムの維持に役立つ可能性があるため、複数のノードが同時に失敗するシナリオでも役立ちます。
ディスク監視を使用する主な利点は、すべてのノードがクラスターの現在の状態に同意するための一貫性のある信頼性の高い方法を提供することです。 一貫性は、フェールオーバー クラスターが適切に機能していることを確認するために重要です。 ディスク監視はユーザーまたはアプリケーション データを格納せず、クラスター構成データベースとクォーラム投票専用であることに注意することが重要です。
ファイル共有監視
クラスターに偶数の投票ノードが含まれている場合は、監視を構成する必要があります。 証人投票を追加することで、クラスター ノードの半分が同時にダウンするか切断されても、クラスターを引き続き実行し続けることができます。 ファイル共有監視は、サーバー メッセージ ブロック (SMB) ファイル共有を使用してクラスター情報をログ ファイルに保持するクォーラム監視の一種です。 このファイル共有は、サーバー、USB ストレージ、またはネットワーク接続ストレージ (NAS) でホストできます。
ファイル共有監視は、レプリケートされたストレージを持つマルチサイト クラスターにも役立ちます。 ファイル共有監視は、次の場合に使用できます。
クラスター ノードに信頼性の高いインターネット接続やインターネット接続がないため、クラウド監視を使用できません。
ディスク監視に使用する共有ドライブがないため、ディスク監視を使用できません。 たとえば、記憶域スペース ダイレクト クラスター、SQL Server Always On 可用性グループ (AG)、Exchange Database 可用性グループ (DAG) などです。 これらの種類のクラスターでは、共有ディスクは使用されません。
この例は、2 つのオンサイト データセンターの 2 つのノードを含む簡略化された構成です。 一般的なクラスターでは、各ノードに1つの投票権があり、ファイル共有ウィットネスがクォーラムウィットネスに追加で1つの投票権を与えます。 この追加投票権により、データセンターの 1 つが稼働しなくなっても、クラスターは実行し続けることができます。 この例では、クラスター クォーラムには 5 つの投票権があり、実行を継続するために必要な投票は 3 つだけです。
ただし、2 つのデータセンターに加えて、ファイル共有監視として機能する 3 つ目のデータセンターもあります。 このデータセンターは、他の 2 つのサイトから独立して維持されており、システム ファイル共有をバックアップするファイル サーバーをホストします。 ファイル共有監視は、このクラスター クォーラム構成ではクォーラム監視として機能し、データセンターの 1 つが予期せずシャットダウンした場合でもシステムが実行し続けるようにします。
ファイル共有監視を設けると、ファイル サーバーの高可用性を維持するのに十分な冗長性が提供されます。 ただし、別サイトの別サーバーでファイル共有監視をホストするには、セットアップ、定期的なメンテナンス、他サイトへの独立した接続が必要であることに注意が必要です。
Witness configuration
ベスト プラクティスとして、奇数個の投票要素を持つクォーラムを構成します。 クラスターに偶数の投票ノードがある場合は、高可用性を確保するためにディスク監視またはファイル共有監視を追加します。 この構成により、クラスターは 1 つの追加ノードの障害を許容できます。 さらに、監視投票を追加すると、クラスター ノードの半分が同時に失敗したり、接続が失われる場合でも、クラスターの動作を継続できます。
通常、ディスク監視は、すべてのクラスター ノードが共有ディスクにアクセスできる場合に推奨されます。 一方、レプリケートされたストレージを含むマルチサイト ディザスター リカバリー シナリオでは、ファイル共有監視が推奨されます。 レプリケートストレージを使用してディスク監視を構成できるのは、ストレージ ソリューションがすべてのサイトからレプリケートされたストレージへの読み取り/書き込みアクセスをサポートしている場合のみです。 監視構成の種類の詳細については、「 クォーラム監視の展開」を参照してください。
ノードの投票の割り当て
高度なクォーラム構成では、個々のノードのクォーラム投票を割り当てたり削除したりできます。 既定では、クラスター内のすべてのノードに投票が割り当てられます。 ただし、ノードの投票が削除された場合でも、そのノードはクラスターに参加し、クラスター データベースの更新プログラムを受け取り、アプリケーションをホストできます。
特定のディザスター リカバリー シナリオでは、特定のノードから投票を削除することを検討できます。 たとえば、マルチサイト クラスターでは、バックアップ サイトにあるノードから投票を削除して、クォーラム計算に影響を与えないようにすることができます。 通常、この方法は、サイト間の手動フェールオーバーを計画する場合にのみ推奨されます。 ノード投票の割り当ては、投票ノードの数を奇数にすることを推奨されていません。 代わりに、ディスク監視またはファイル共有監視を構成する必要があります。
動的クォーラム管理
動的クォーラム管理は、クラスターがクォーラムマジョリティ要件を動的に調整できるようにする高度な構成オプションです。 この機能を使用すると、ノードが順番にシャットダウンされた場合でも、クラスターを操作し続けることができ、クラスターは最後に存続しているノードで実行できます。
動的クォーラム管理により、フェールオーバー クラスターの柔軟性と回復性が向上し、動的環境での高可用性を維持するための重要な機能になります。 動的クォーラム管理を有効にすると、クラスターは現在のクラスターの状態に基づいてノードに割り当てられた投票を自動的に調整でき、クォーラムを維持しながら、クラスターでノードの障害や計画的なシャットダウンを維持できます。 動的クォーラム管理が有効になっている場合、ノードの投票を割り当て済みとして構成されているノードのみが、その投票を動的に割り当てたり削除したりできます。
Key considerations:
- 動的クォーラム管理では、ほとんどの投票メンバーが同時に失敗してもクラスターは存続できません。 ノードの障害またはシャットダウン時に、クラスターの実行を継続するには、クォーラムマジョリティが引き続き必要です。
- ノードの投票が明示的に削除された場合、クラスターはその投票を動的に追加または削除することはできません。
- 記憶域スペース ダイレクトが有効になっているクラスターでは、クラスターは最大 2 つのノード障害のみを許容できます。
クォーラム構成に関する一般的な推奨事項
クラスター ソフトウェアは、ノードの数と共有ストレージの可用性に基づいて、新しいクラスターのクォーラム構成を自動的に決定します。 この既定の構成は、通常、クラスターに最適です。 クラスターが作成された後、運用環境にデプロイする前に、クォーラム設定を確認することをお勧めします。
詳細なクォーラム構成を調べるには、構成の 検証ウィザード または Test-Cluster コマンドレットを使用して 、クォーラム構成の検証 テストを実行できます。 フェールオーバー クラスター マネージャーでは、選択したクラスターの概要セクションに基本的なクォーラム構成が表示されます。 Alternatively, you can retrieve detailed information about quorum resources by running the Get-ClusterQuorum cmdlet.
クォーラム 構成の検証 テストをいつでも実行して、クォーラム設定がクラスターに最適であることを確認できます。 テスト結果は、構成の変更が推奨されるかどうかを示し、最適な設定を提供します。 調整が必要な場合は、 クラスター クォーラムの構成ウィザードを使用して、推奨される変更を適用できます。 クラスターが運用環境になったら、クラスターの特定の要件に対して変更が必要であることを十分に評価して確認しない限り、クォーラム構成の変更は避けてください。 次の状況でクォーラム構成を変更することを検討してください。
- ノードの追加または削除
- ストレージの追加または削除
- ノードまたは監視の障害が長期にわたっている。
- マルチサイト ディザスター リカバリー シナリオでのクラスターの復旧
See also
Azure Local でクラスター監視を設定する