クラスターとプール クォーラムの概要

適用対象: Azure Stack HCI バージョン 22H2 および 21H2。Windows Server 2022、Windows Server

Windows Server フェールオーバー クラスタリング は、Azure Stack HCI および Windows Server クラスターで実行されているワークロードに高可用性を提供します。 These resources are considered highly available if the nodes that host resources are up; however, the cluster generally requires more than half the nodes to be running, which is known as having quorum.

Quorum is designed to prevent split-brain scenarios that can happen when there's a partition in the network and subsets of nodes can't communicate with each other. これにより、ノードの両方のサブセットがワークロードを所有し、同じディスクに書き込もうとするため、多数の問題が発生する可能性があります。 ただし、フェールオーバー クラスタリングのクォーラムの概念ではこれを回避できます。これにより、これらのノード グループの 1 つだけが強制的に実行され続けるので、これらのグループの 1 つだけがオンラインのままです。

クォーラムは、クラスターがオンラインのまま維持できる障害の数を決定します。 クォーラムは、クラスター ノードのサブセット間の通信に問題がある場合にシナリオを処理するように設計されているため、複数のサーバーが同時にリソース グループをホストし、同じディスクに同時に書き込もうとしません。 このクォーラムの概念を持つことにより、クラスター サービスはノードのサブセットの 1 つで停止し、特定のリソース グループの真の所有者が 1 人だけであることを確認します。 停止されたノードは、ノードのメイン グループと再び通信でき、自動的にクラスターに再参加し、クラスター サービスを開始します。

Azure Stack HCI と Windows Server 2019 には、独自のクォーラム メカニズムを持つシステムの 2 つのコンポーネントがあります。

• Cluster Quorum: This operates at the cluster level (i.e. you can lose nodes and have the cluster stay up)
• Pool Quorum: This operates on the pool level (i.e. you can lose nodes and drives and have the pool stay up). 記憶域プールは、クラスター化されたシナリオとクラスター化されていないシナリオの両方で使用されるように設計されているため、クォーラム メカニズムが異なります。

クラスター クォーラムの概要

次の表は、シナリオごとのクラスター クォーラムの結果の概要を示しています。

クラスター クォーラムの推奨事項

• If you have two nodes, a witness is required.
• If you have three or four nodes, witness is strongly recommended.
• ノードが 5 つ以上ある場合、監視は必要なく、また、追加的な回復性も提供されません。
• If you have internet access, use a cloud witness.
• 他のマシンおよびファイル共有のある IT 環境の場合は、ファイル共有監視を使用します。

クラスター クォーラムのしくみ

When nodes fail, or when some subset of nodes loses contact with another subset, surviving nodes need to verify that they constitute the majority of the cluster to remain online. 検証できない場合は、オフラインになります。

But the concept of majority only works cleanly when the total number of nodes in the cluster is odd (for example, three nodes in a five node cluster). では、偶数のノード (たとえば、4 つのノード クラスター) を持つクラスターはどうでしょうか。

クラスターで 投票総数 を奇数にする方法は 2 つあります。

1. First, it can go up one by adding a witness with an extra vote. これには、ユーザーのセットアップが必要です。
2. Or, it can go down one by zeroing one unlucky node's vote (happens automatically as needed).

Whenever surviving nodes successfully verify they're the majority, the definition of majority is updated to be among just the survivors. これにより、クラスターは 1 つのノード、次に別のノード、別のノードなどを失うことになります。 この概念は、連続する失敗後に適応する 投票の合計数 を 動的クォーラムと呼びます。

Dynamic witness

動的監視では、監視の投票を切り替えて、投票の合計数 が確実に奇数になるようにします。 奇数の投票がある場合、証人には投票権がありません。 偶数の投票数の場合、証人が投票する権利を持ちます。 動的監視は、監視エラーが原因でクラスターがダウンするリスクを大幅に軽減します。 クラスターは、クラスターで使用可能な投票ノードの数に基づいて、監視投票を使用するかどうかを決定します。

動的クォーラムは、以下で説明する方法で動的監視と連携します。

動的クォーラム動作

• If you have an even number of nodes and no witness, one node gets its vote zeroed. たとえば、4 つのノードのうち 3 つのノードのみが投票を受け取るので、 投票の総数 は 3 つであり、投票を持つ 2 人の生存者は過半数と見なされます。
• If you have an odd number of nodes and no witness, they all get votes.
• If you have an even number of nodes plus witness, the witness votes, so the total is odd.
• If you have an odd number of nodes plus witness, the witness doesn't vote.

動的クォーラムを使用すると、ノードに投票を動的に割り当てることで、投票の過半数が失われないようにしたり、クラスターを 1 つのノード (最後の人の立ち位置と呼ばれる) で実行したりできるようになります。 例として、4 ノードクラスターを見てみましょう。 クォーラムには 3 つの投票が必要であるとします。

この場合、2 つのノードを失った場合、クラスターはダウンします。

ただし、動的クォーラムは、この問題を回避します。 クォーラムに必要な 投票の合計数 は、使用可能なノードの数に基づいて決定されるようになりました。 そのため、動的クォーラムでは、3 つのノードを失ってもクラスターは稼働し続けます。

上記のシナリオは、記憶域スペース ダイレクトが有効になっていない一般的なクラスターに適用されます。 ただし、記憶域スペース ダイレクトが有効になっている場合、クラスターは 2 つのノード障害のみをサポートできます。 詳細については、 プール クォーラムのセクションを参照してください。

Examples

監視なしの 2 つのノード

One node's vote is zeroed, so the majority vote is determined out of a total of 1 vote. 投票以外のノードが予期せずダウンした場合、サバイバーは 1/1 になり、クラスターは存続します。 投票ノードが予期せずダウンした場合、サバイバーは 0/1 になり、クラスターはダウンします。 投票ノードの電源が正常に切れている場合、投票は他のノードに転送され、クラスターは存続します。 これが、監視を構成することが重要な理由です。

• 1 台のサーバー障害から生き残ることができます: 50% の確率。
• Can survive one server failure, then another: No.
• Can survive two server failures at once: No.

ノード 2 つで監視あり

Both nodes vote, plus the witness votes, so the majority is determined out of a total of 3 votes. いずれかのノードがダウンした場合、サバイバーには 2/3 があり、クラスターは存続します。

• Can survive one server failure: Yes.
• Can survive one server failure, then another: No.
• Can survive two server failures at once: No.

監視なしの 3 つのノード

All nodes vote, so the majority is determined out of a total of 3 votes. ノードがダウンした場合、サバイバーは 2/3 で、クラスターは存続します。 クラスターは監視なしで 2 つのノードになります。その時点で、シナリオ 1 になります。

• Can survive one server failure: Yes.
• 1 台のサーバー障害を乗り切り、次に別のサーバー障害を解決できる: 50% の確率。
• Can survive two server failures at once: No.

証人を含む3つのノード

すべてのノードが投票するため、当初、監視は投票しません。 The majority is determined out of a total of 3 votes. 1 つの障害が発生した後、クラスターには監視付きの 2 つのノードがあるので、これはシナリオ 2 に戻ります。 そのため、ここでは 2 つのノードと監視による投票が行われます。

• Can survive one server failure: Yes.
• Can survive one server failure, then another: Yes.
• Can survive two server failures at once: No.

証人なしの4つのノード

One node's vote is zeroed, so the majority is determined out of a total of 3 votes. 1 つの障害が発生すると、クラスターは 3 つのノードになり、シナリオ 3 になります。

• Can survive one server failure: Yes.
• Can survive one server failure, then another: Yes.
• 2 つのサーバー障害を一度に存続させることができます: 50% の確率。

証人ノードを含む4つのノード

All nodes votes and the witness votes, so the majority is determined out of a total of 5 votes. 1 つの障害が発生すると、シナリオ 4 になります。 2 つの同時エラーが発生した後、シナリオ 2 に進みます。

• Can survive one server failure: Yes.
• Can survive one server failure, then another: Yes.
• Can survive two server failures at once: Yes.

5 ノード以上

すべてのノードが投票するか、または1つを除くすべてのノードが投票し、合計が奇数になるようにします。 ストレージ スペース ダイレクトでは、2つ以上のノードをダウンした状態で処理することができないため、この時点では、証人は必要ないし、有用ではありません。

• Can survive one server failure: Yes.
• Can survive one server failure, then another: Yes.
• Can survive two server failures at once: Yes.

クォーラムのしくみを理解したので、クォーラムの証人の種類を見てみましょう。

クォーラムの証人の種類

フェールオーバー クラスタリングでは、次の 3 種類のクォーラム 監視がサポートされています。

• Cloud Witness - Blob storage in Azure accessible by all nodes of the cluster. クラスタリング情報は witness.log ファイルに保持されますが、クラスター データベースのコピーは格納されません。
• ファイル共有監視 – Windows Server を実行しているファイル サーバーで構成されている SMB ファイル共有。 クラスタリング情報は witness.log ファイルに保持されますが、クラスター データベースのコピーは格納されません。
• Disk Witness - A small clustered disk that is in the Cluster Available Storage group. このディスクは高可用性であり、ノード間でフェールオーバーできます。 クラスター データベースのコピーが含まれています。 記憶域スペース ダイレクトでは、ディスク監視はサポートされていません。

プール クォーラムの概要

クラスター レベルで動作するクラスター クォーラムについて説明しました。 次に、プール レベルで動作するプール クォーラムについて説明します (つまり、ノードとドライブが失われても、プールは稼働し続けます)。 記憶域プールは、クラスター化されたシナリオとクラスター化されていないシナリオの両方で使用されるように設計されているため、クォーラム メカニズムが異なります。

次の表は、シナリオごとのプール クォーラムの結果の概要を示しています。

プール クォーラムのしくみ

When drives fail, or when some subset of drives loses contact with another subset, surviving drives hosting metadata need to verify that they constitute the majority of the pool to remain online. 検証できない場合は、オフラインになります。 プールは、クォーラムに十分なディスク (50% + 1) があるかどうかに基づいて、オフラインになるかオンラインが維持されるかが決まるエンティティです。 クラスター自体が引用符で囲まれている限り、クラスター データベースは +1 にすることができます。

ただし、プール クォーラムは、次の方法でクラスター クォーラムとは動作が異なります。

• プールは、メタデータをホストするためにノードごとにドライブのサブセットを選択します
• プールはクラスター データベースを使用して同点を解消します。
• プールに動的クォーラムはありません
• プールは、投票を削除する独自のバージョンを実装していません

Examples

対称レイアウトの 4 つのノード

16 個のドライブのそれぞれに 1 つの投票があり、ノード 2 にも 1 つの投票があります (プール リソース所有者であるため)。 The majority is determined out of a total of 16 votes. ノード 3 と 4 がダウンした場合、存続するサブセットには 8 つのドライブとプール リソース所有者 (9/16 投票) があります。 そのため、プールは存続します。

• Can survive one server failure: Yes.
• Can survive one server failure, then another: Yes.
• Can survive two server failures at once: Yes.

対称レイアウトとドライブ障害を持つ 4 つのノード

16 個の各ドライブには 1 つの投票があり、ノード 2 にも 1 つの投票があります (プール リソース所有者であるため)。 The majority is determined out of a total of 16 votes. まず、ディスクドライブ 7 がダウンします。 ノード 3 と 4 がダウンした場合、存続するサブセットには 7 つのドライブとプール リソース所有者 (8/16 投票) があります。 そのため、プールは多数派を占めず、ダウンします。

• Can survive one server failure: Yes.
• Can survive one server failure, then another: No.
• Can survive two server failures at once: No.

プール クォーラムの推奨事項

• クラスター内の各ノードが対称であることを確認します (各ノードのドライブの数が同じ)
• 3 方向ミラーまたはデュアル パリティを有効にして、2 つのノード障害を許容し、仮想ディスクをオンラインに保つことができます。
• 2 つ以上のノードがダウンしている場合、または 2 つのノードと別のノード上のディスクがダウンしている場合、ボリュームはデータの 3 つのコピーすべてにアクセスできないため、オフラインになり、使用できなくなる可能性があります。 ボリューム内のすべてのデータの回復性を最大限に高めるために、サーバーを取り戻すか、ディスクをすばやく交換することをお勧めします。

Next steps

• クォーラムの構成と管理
• クラスター監視を設定する