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

[アーティクル]
02/22/2024

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

Windows Server フェールオーバークラスタリングは、Azure Stack HCI および Windows Server クラスターで実行されているワークロードの高可用性を実現します。これらのリソースは、リソースをホストするノードが稼働していると可用性が高いと見なされます。ただし、クラスターでは通常、半分を越えるノードが実行されている必要があり、その場合に "クォーラム" を持つとされます。

クォーラムは、ネットワークにパーティションがあり、ノードのサブセットが相互に通信できない場合に発生する可能性がある スプリットブレイン シナリオを防ぐために設計されています。これにより、ノードの両方のサブセットがワークロードを所有し、同じディスクに書き込もうとするため、多数の問題が発生する可能性があります。ただし、フェールオーバークラスタリングのクォーラムの概念ではこれを防ぐことができます。これにより、これらのノードグループの 1 つだけが強制的に実行され続けるので、これらのグループの 1 つだけがオンラインのままです。

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

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

クラスタークォーラム:これはクラスターレベルで動作します (つまり、ノードが停止した場合、クラスターは稼働状態を維持できます)
プールクォーラム: プールレベルで動作する (つまり、ノードとドライブが停止した場合、プールが稼働状態を維持できる) 。記憶域プールは、クラスター化と非クラスター化の両方のシナリオで使用するように設計されているため、異なるクォーラムメカニズムを持ちます。

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

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

サーバーノード	1 つのサーバーノード障害に耐えることができる	1 つのサーバーノード障害に耐えた後、別の障害にも耐えることができる	同時に発生する 2 つのサーバーノード障害に耐えることができる
2	50/50	いいえ	いいえ
2 + 監視	はい	いいえ	いいえ
3	はい	50/50	いいえ
3 + 監視	はい	はい	いいえ
4	はい	はい	50/50
4 + 監視	はい	Yes	はい
5 以上	はい	Yes	はい

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

2 つのノードがある場合、監視は必須です。
3 つまたは 4 つのノードがある場合は、監視を強く推奨します。
ノードが 5 つ以上ある場合、監視は必要ありません。また、追加の回復性も提供されません。
インターネットに接続している場合は、クラウド監視を使用します。
他のマシンおよびファイル共有のある IT 環境の場合は、ファイル共有監視を使用します。

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

ノードで障害が発生した場合、またはノードのサブセットが別のサブセットとの接続を失った場合、オンライン状態を維持するには、残りのノードがクラスターの "過半数" を占めることを確認する必要があります。これを確認できない場合、これらはオフラインになります。

ただし、"過半数" の概念は、ノードの合計数が奇数 (たとえば、5 つのノードのうち 3 つのノード) である場合にのみ正常に機能します。それでは、ノード数が偶数であるクラスター (たとえば、4 つのノードを持つクラスター) の場合はどうなるでしょうか。

クラスターで "投票の合計数" を奇数にできる方法は 2 つあります。

まず、追加の投票として "監視" を追加することにより、1 つ "増やす" ことができます。これには、ユーザーによる設定が必要です。
または、1 つのノードの投票をゼロにすることで、1 つ "減らす" ことができます (必要に応じて、自動的に実行されます)。

残りのノードが マジョリティであることを正常に確認するたびに、 大部分 の定義が生存者の間に含まれるように更新されます。これにより、クラスターでは、1 つのノードが停止し、その後別のクラスターが順次停止することを許容できます。連続する障害の発生後に適用される、この "投票の合計数" の概念は "動的クォーラム" と呼ばれます。

動的監視

動的監視では、"投票の合計数" が奇数になるように監視の投票が切り替えられます。投票数が奇数の場合、監視は投票を持ちません。偶数の投票がある場合、ミラーリング監視サーバーには投票があります。動的監視を使用すると、監視エラーが原因でクラスターがダウンするリスクが大幅に軽減されます。クラスターでは、クラスター内で使用可能な投票ノード数に基づいて、監視の投票を使用するかどうかが決定されます。

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

動的クォーラムの動作

ノード数が偶数であり、監視がない場合、"1 つのノードの投票がゼロに設定されます"。たとえば、4 つのノードのうち 3 つだけが投票を取得して "投票の合計数" が 3 である場合、投票を持つ 2 つのノードが残ると過半数と見なされます。
ノード数が奇数であり、監視がない場合、すべてが投票を持ちます。
ノード数が偶数であり、監視がある場合、"監視が投票する" ため、合計は奇数になります。
ノード数が奇数であり、監視がある場合、"監視は投票しません"。

動的クォーラムにより、ノードに動的に投票を割り当て、投票の過半数を失うことを回避できます。また、クラスターを 1 つのノード (最後に残ったもの) で実行できます。例として、4 つのノードのクラスターを見ていきましょう。クォーラムでは、3 票が必要であるとします。

この場合、クラスターは 2 つのノードが停止するとダウンします。

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

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

例

監視なしの 2 つのノード。

1 票の合計から投票の "過半数" が決定されるように、1 つのノードの投票がゼロに設定されます。投票しないノードが予期せず停止した場合、残りのノードは 1/1 となり、クラスターは存続します。投票するノードが予期せず停止した場合、残りのノードは 0/1 となり、クラスターは停止します。投票するノードの電源が正常に切断されると、投票はもう一方のノードに譲渡され、クラスターは存続します。 監視を構成することが重要であるのは、このためです。

1 つのサーバー障害に耐えることができる:50% の確率。
1 つのサーバー障害に耐えた後、別の障害にも耐えることができる:いいえ。
同時に発生する 2 つのサーバー障害に耐えることができる:いいえ。

監視ありの 2 つのノード。

両方のノードが投票し、さらに監視も投票します。これにより、3 票の合計から "過半数" が決定されます。いずれかのノードが停止した場合、残りのノードは 2/3 となり、クラスターは存続します。

1 つのサーバー障害に耐えることができる:はい。
1 つのサーバー障害に耐えた後、別の障害にも耐えることができる:いいえ。
同時に発生する 2 つのサーバー障害に耐えることができる:いいえ。

監視なしの 3 つのノード

すべてのノードが投票するため、"過半数" は 3 票の合計から決定されます。いずれかのノードが停止した場合、残りのノードは 2/3 となり、クラスターは存続します。この時点で、クラスターは監視なしの 2 つのノードとなり、シナリオ 1 になります。

1 つのサーバー障害に耐えることができる:はい。
1 つのサーバー障害に耐えた後、別の障害にも耐えることができる:50% の確率。
同時に発生する 2 つのサーバー障害に耐えることができる:いいえ。

監視ありの 3 つのノード

すべてのノードが投票するため、監視は最初は投票しません。 "過半数" は 3 票の合計から決定されます。 1 つの障害が発生した後に、クラスターには監視ありの 2 つのノードが残ります。これで、シナリオ 2 に戻ります。これで、2 つのノードとなり、監視が投票します。

1 つのサーバー障害に耐えることができる:はい。
1 つのサーバー障害に耐えた後、別の障害にも耐えることができる:はい。
同時に発生する 2 つのサーバー障害に耐えることができる:いいえ。

監視なしの 4 つのノード

1 つのノードの投票がゼロに設定され、"過半数" は 3 票の合計から決定されます。 1 つの障害が発生した後に、クラスターは 3 つのノードになり、シナリオ 3 になります。

1 つのサーバー障害に耐えることができる:はい。
1 つのサーバー障害に耐えた後、別の障害にも耐えることができる:はい。
同時に発生する 2 つのサーバー障害に耐えることができる:50% の確率。

監視ありの 4 つのノード

すべてのノードと監視が投票し、5 票の合計から "過半数" が決定されます。 1 つの障害が発生した後、シナリオ 4 になります。 2 つの障害が同時に発生すると、シナリオ 2 になります。

1 つのサーバー障害に耐えることができる:はい。
1 つのサーバー障害に耐えた後、別の障害にも耐えることができる:はい。
同時に発生する 2 つのサーバー障害に耐えることができる:はい。

5 つ以上のノード

すべてのノードが投票するか、1 つを除いてすべてが投票し、合計が奇数になるようにします。記憶域スペースダイレクトは、2 つ以上のノードを処理できないため、この時点では、監視は必要ありません。

1 つのサーバー障害に耐えることができる:はい。
1 つのサーバー障害に耐えた後、別の障害にも耐えることができる:はい。
同時に発生する 2 つのサーバー障害に耐えることができる:はい。

クォーラムのしくみを理解したところで、クォーラム監視の種類を見てみましょう。

クォーラム監視の種類

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

クラウド監視 - クラスターのすべてのノードからアクセス可能な Azure の Blob Storage。クラスタリング情報は witness.log ファイルに保持されますが、クラスターデータベースのコピーは保存されません。
ファイル共有監視 - Windows Server を実行しているファイルサーバー上で構成される SMB ファイル共有。クラスタリング情報は witness.log ファイルに保持されますが、クラスターデータベースのコピーは格納されません。
ディスク監視 - クラスターで使用可能な記憶域グループ内の小さなクラスター化されたディスク。このディスクは高可用性であり、ノード間でフェールオーバーできます。クラスターデータベースのコピーが格納されます。 記憶域スペースダイレクトでは、ディスク監視はサポートされていません。

プールクォーラムの概要

ここまでは、クラスターレベルで動作するクラスタークォーラムについて説明しました。次に、プールレベルで動作する (つまり、ノードとドライブが停止した場合、プールが稼働状態を維持できる) プールクォーラムについて詳しく見ていきましょう。記憶域プールは、クラスター化と非クラスター化の両方のシナリオで使用するように設計されているため、異なるクォーラムメカニズムを持ちます。

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

サーバーノード	1 つのサーバーノード障害に耐えることができる	1 つのサーバーノード障害に耐えた後、別の障害にも耐えることができる	同時に発生する 2 つのサーバーノード障害に耐えることができる
2	はい	いいえ	いいえ
2 + 監視	はい	いいえ	いいえ
3	はい	いいえ	いいえ
3 + 監視	はい	いいえ	いいえ
4	はい	いいえ	いいえ
4 + 監視	はい	Yes	はい
5 以上	はい	Yes	はい

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

ドライブに障害が発生した場合、またはドライブの一部のサブセットが別のサブセットとの接触を失った場合、メタデータをホストしている残りのドライブは、それらがオンライン状態を維持するためにプールの 大部分 を構成していることを確認する必要があります。これを確認できない場合、これらはオフラインになります。プールは、クォーラム用に十分なディスク (50% + 1) があるかどうかに基づいて、オフラインになるか、またはオンライン状態を維持するエンティティです。クラスター自体がクォートされている限り、クラスターデータベースは +1 にすることができます。

ただし、プールクォーラムのしくみはクラスタークォーラムとは次の点で異なります。

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

例

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

16 個のドライブはそれぞれ 1 つの投票を持ち、ノード 2 にも 1 つの投票があります (これがプールリソースの所有者であるため)。 "過半数" は 16 票の合計から決定されます。ノード 3 と 4 が停止した場合、残りのサブセットには 8 個のドライブとプールリソースの所有者があるため、9/16 票になります。そのため、プールは存続します。

1 つのサーバー障害に耐えることができる:はい。
1 つのサーバー障害に耐えた後、別の障害にも耐えることができる:はい。
同時に発生する 2 つのサーバー障害に耐えることができる:はい。

対称レイアウトでドライブに障害が発生している 4 つのノード

16 個のドライブはそれぞれ 1 つの投票を持ち、ノード 2 にも 1 つの投票があります (これがプールリソースの所有者であるため)。 "過半数" は 16 票の合計から決定されます。最初に、ドライブ 7 が停止します。ノード 3 と 4 が停止した場合、残りのサブセットには 7 個のドライブとプールリソースの所有者があるため、8/16 票になります。ここで、プールには過半数がないため停止します。

1 つのサーバー障害に耐えることができる:はい。
1 つのサーバー障害に耐えた後、別の障害にも耐えることができる:いいえ。
同時に発生する 2 つのサーバー障害に耐えることができる:いいえ。

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

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

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