クラスターとプールクォーラムについて

適用対象: 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 ノードの投票は 0 に設定されるため、 その過半数 は合計 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 ストレージ。 クラスタリング情報は 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 つのノードと別のノード上のディスクがダウンしている場合、ボリュームはデータの 3 つのコピーすべてにアクセスできないため、オフラインになり、使用できなくなる可能性があります。 ボリューム内のすべてのデータの回復性を最大限に高めるために、サーバーを取り戻すか、ディスクをすばやく交換することをお勧めします。

次のステップ

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