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

適用対象: 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 つあります。

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

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

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

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

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

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

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

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

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

1. まず、追加の投票として "監視" を追加することにより、1 つ "増やす" ことができます。 これには、ユーザーによる設定が必要です。
2. または、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 ファイルに保持されますが、クラスター データベースのコピーは格納されません。
• ディスク監視 - クラスターで使用可能な記憶域グループ内の小さなクラスター化されたディスク。 このディスクは高可用性であり、ノード間でフェールオーバーできます。 クラスター データベースのコピーが格納されます。 記憶域スペース ダイレクトでは、ディスク監視はサポートされていません。

プール クォーラムの概要

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

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

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

ドライブに障害が発生した場合、またはドライブの一部のサブセットが別のサブセットとの接触を失った場合、メタデータをホストしている残りのドライブは、それらがオンライン状態を維持するためにプールの 大部分 を構成していることを確認する必要があります。 これを確認できない場合、これらはオフラインになります。 プールは、クォーラム用に十分なディスク (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 つのコピーすべてにアクセスできなくなるため、オフラインになり、使用できなくなります。 ボリューム内のすべてのデータの回復性を最大限に高めるために、サーバーを取り戻すか、ディスクをすばやく交換することをお勧めします。

次の手順

• クォーラムを構成して管理する
• クラスター監視をセットアップする