クラスターとプールのクォーラムについて|Microsoft Docs

01/18/2019
11 読むべき分
- a
- e
- v
- C
- J
- J
- J
- J
- +3

適用先:Windows Server2019、Windows Server2016

Windows Serverフェールオーバークラスタリングは、ワークロードの高可用性を提供します。これらのリソースは、ホストリソースが稼働しているノードが稼働している場合、高可用性と見なされます; ただし、クラスターでは通常、半分以上のノードが実行されている必要があります。

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

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

Windows Server2019およびWindows Server2016には、独自のクォーラムメカニズムを持つシステムの2つのコンポーネントがあります:

クラスタークォーラム:これはクラスターレベルで動作します(つまり、
Pool Quorum:Storage Spaces Directが有効になっている場合(つまり、ノードとドライブを失い、プールを維持することができます)、これはプールレベルで動作します。ストレージプールは、クラスター化シナリオと非クラスター化シナリオの両方で使用するように設計されているため、クォーラムメカニ

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

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

サーバーノード	は1つのサーバーノードの障害から生き残ることができます	は1つのサーバーノードの障害から生き残ることができ、別の	は2つの同時
2	50/50	いいえ	いいえ
2 + 証人	はい	いいえ	いいえ
3	はい	50/50	いいえ
3 + 証人	はい	はい	いいえ
4	はい	はい	50/50
4 + 証人	はい	はい	はい
5 以上	はい	はい	はい

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

ノードが二つある場合は、監視が必要です。
三つまたは四つのノードがある場合は、witnessを強くお勧めします。
インターネットにアクセスできる場合は、クラウド監視を使用します
他のマシンとファイル共有を持つIT環境にいる場合は、ファイル共有監視を使用します

クラスタクォーラムの仕組み

ノードが障害を起こした場合、またはノードの一部のサブセットが別のサブセットとの接触を失った場合、生き残っているノードは、クラスターの大部分を構成していることを確認する必要があります。それを確認できない場合は、オフラインになります。

しかし、マジョリティの概念は、クラスタ内のノードの総数が奇数の場合にのみうまく機能します（たとえば、五つのノードクラスタ内の三つのノード）。では、偶数個のノードを持つクラスター(たとえば、4つのノードのクラスター)はどうでしょうか。

クラスタが投票総数を奇数にするには二つの方法があります:

まず、それは余分な投票で証人を追加することによって一つ上がることができます。これにはユーザーのセットアップが必要です。
または、1つの不運なノードの投票をゼロにすることで1つ下がることができます（必要に応じて自動的に発生します）。

生き残っているノードが過半数であることを正常に確認するたびに、過半数の定義は生存者だけのものに更新されます。これにより、クラスターはあるノードを失い、別のノードを失い、別のノードを失うことができます。連続した失敗の後に適応する投票の合計数のこの概念は、動的クォーラムとして知られています。

Dynamic witness

Dynamic witnessは、witnessの投票を切り替えて、投票の合計数が奇数であることを確認します。投票数が奇数の場合、証人には投票がありません。投票数が偶数の場合、証人には投票があります。動的監視は、監視の失敗のためにクラスターがダウンするリスクを大幅に軽減します。クラスターは、クラスター内で使用できる投票ノードの数に基づいて、ミラーリング監視の投票を使用するかどうかを決定します。

Dynamic quorumは、以下で説明する方法でDynamic witnessと連携します。

動的クォーラム動作

偶数のノードがあり、ミラーリング監視がない場合、一つのノードはその投票をゼロにします。たとえば、4つのノードのうち3つだけが投票を取得するため、投票の総数は3であり、投票を持つ2人の生存者は過半数と見なされます。
奇数のノードがあり、証人がない場合、それらはすべて投票されます。
偶数のノードにwitnessを加えた場合、witnessは投票するので、合計は奇数になります。
奇数のノードに証人を加えた場合、証人は投票しません。

Dynamic quorumを使用すると、投票の過半数を失うことを回避し、クラスタを1つのノードで実行できるようにするために、ノードに投票を動的に割り当てるこ例として、4ノードのクラスターを見てみましょう。定足数には3票が必要とすると仮定します。

この場合、二つのノードを失った場合、クラスタはダウンしていたでしょう。

4つのクラスターノードを示す図で、それぞれが投票を取得します

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

ノードが一度に一つずつ失敗し、各失敗後に必要な投票数が調整された四つのクラスターノードを示す図。

上記のシナリオは、Storage Spaces Directが有効になっていない一般的なクラスターに適用されます。ただし、Storage Spaces Directが有効になっている場合、クラスターは二つのノード障害のみをサポートできます。これについては、pool quorumのセクションで詳しく説明します。

例

証人のない二つのノード。

一つのノードの投票はゼロになっているので、多数決は合計1票のうち決定されます。非投票ノードが予期せずダウンした場合、サバイバーは1/1になり、クラスターはサバイバーになります。投票ノードが予期せずダウンした場合、サバイバーは0/1になり、クラスターはダウンします。投票ノードが正常にパワーダウンされた場合、投票は他のノードに転送され、クラスタは存続します。このため、ミラーリング監視を構成することが重要です。

クォーラムは、証人のない二つのノードの場合に説明しました

一つのサーバー障害を生き残ることができます：五十パーセントのチャンス。
は1つのサーバーの障害から生き残ることができ、別のサーバーの障害から生き残ることができます：いいえ。
は一度に二つのサーバー障害を生き残ることができます：いいえ。

証人を持つ二つのノード。

両方のノードが投票し、証人の投票を加えたので、過半数は合計3票のうち決定されます。いずれかのノードがダウンすると、サバイバーは2/3になり、クラスターはサバイバーになります。

クォーラムは、証人を持つ二つのノードの場合に説明しました

一つのサーバー障害を生き残ることができます：はい。
は1つのサーバーの障害から生き残ることができ、別のサーバーの障害から生き残ることができます：いいえ。
は一度に二つのサーバー障害を生き残ることができます：いいえ。

証人なしの三つのノード。

すべてのノードが投票するため、合計3票のうち過半数が決定されます。いずれかのノードがダウンした場合、生存者は2/3であり、クラスタは生存します。クラスターはミラーリング監視なしで2つのノードになります–その時点で、シナリオ1になります。

クォーラムは、証人のない三つのノードの場合に説明しました

一つのサーバー障害を生き残ることができます：はい。
は、1つのサーバー障害、次に別のサーバー障害を生き残ることができます。
は一度に二つのサーバー障害を生き残ることができます：いいえ。

証人を持つ三つのノード。

すべてのノードが投票するため、witnessは最初は投票しません。過半数は合計3票のうちで決定される。 1つの障害が発生した後、クラスターにはミラーリング監視を持つ2つのノードがあり、これはシナリオ2に戻ります。だから、今、二つのノードと証人の投票。

クォーラムは、証人を持つ三つのノードの場合に説明しました

一つのサーバー障害を生き残ることができます：はい。
は1つのサーバー障害を存続でき、次に別のサーバー障害を存続できます：はい。
は一度に二つのサーバー障害を生き残ることができます：いいえ。

証人のない四つのノード

一つのノードの投票はゼロになっているので、過半数は合計3票のうち決定されます。 1つの障害が発生した後、クラスターは3つのノードになり、シナリオ3になります。

クォーラムは、証人のない四つのノードの場合に説明しました

一つのサーバー障害を生き残ることができます：はい。
は1つのサーバー障害を存続でき、次に別のサーバー障害を存続できます：はい。
は一度に二つのサーバー障害を生き残ることができます。

証人を持つ四つのノード。

すべてのノードが投票し、証人が投票するので、過半数は合計5票のうち決定されます。一つの失敗の後、あなたはシナリオ4にいます。 2つの同時障害が発生した後は、シナリオ2にスキップします。

クォーラムは、証人を持つ四つのノードの場合に説明しました

一つのサーバー障害を生き残ることができます：はい。
は1つのサーバー障害を存続でき、次に別のサーバー障害を存続できます：はい。
は一度に二つのサーバー障害を生き残ることができます：はい。

すべてのノードが投票するか、合計が奇数になるものは何でも、一票を除くすべてのノードが投票します。 Storage Spaces Directは、いずれにしても複数のノードを処理できないため、この時点ではミラーリング監視は必要なく、有用ではありません。

クォーラムは、五つのノードとそれ以降の場合に説明しました

一つのサーバー障害を生き残ることができます：はい。
は1つのサーバー障害を存続でき、次に別のサーバー障害を存続できます：はい。
は一度に二つのサーバー障害を生き残ることができます：はい。

定員会がどのように機能するかを理解したので、定員会の証人の種類を見てみましょう。

クォーラム監視の種類

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

Cloud Witness-クラスターのすべてのノードからアクセス可能なAzure内のBlobストレージ。ミラーリング監視のクラスタリング情報を維持します。ログファイルですが、クラスタデータベースのコピーは保存されません。
ファイル共有監視–WINDOWS Serverを実行しているファイルサーバー上で構成されたSMBファイル共有。ミラーリング監視のクラスタリング情報を維持します。ログファイルですが、クラスタデータベースのコピーは保存されません。
ディスク監視-クラスター使用可能なストレージグループ内にある小さなクラスター化ディスク。このディスクは高可用性であり、ノード間でフェールオーバーすることができます。これには、クラスタデータベースのコピーが含まれています。ディスク監視は、Storage Spaces Directではサポートされていません。

プールクォーラムの概要

クラスターレベルで動作するクラスタークォーラムについて話しました。ここでは、プールレベルで動作するPool Quorumに飛び込みましょう（つまり、ノードとドライブを失い、プールを稼働させることができます）。ストレージプールは、クラスター化シナリオと非クラスター化シナリオの両方で使用するように設計されているため、クォーラムメカニ

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

サーバーノード	は1つのサーバーノードの障害から生き残ることができます	は1つのサーバーノードの障害から生き残ることができ、別の	は2つの同時
2	いいえ	いいえ	いいえ
2 + 証人	はい	いいえ	いいえ
3	はい	いいえ	いいえ
3 + 証人	はい	いいえ	いいえ
4	はい	いいえ	いいえ
4 + 証人	はい	はい	はい
5 以上	はい	はい	はい

プールクォーラムの仕組み

ドライブに障害が発生した場合、またはドライブの一部のサブセットが別のサブセットとの接触を失った場合、存続するドそれを確認できない場合は、オフラインになります。プールは、クォーラムに十分なディスクがあるかどうか(50%+1)に基づいて、オフラインになるか、オンラインのままになるエンティティです。プールリソースの所有者(アクティブなクラスターノード)は+1にすることができます。

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

プールは、クラスター内の一つのノードをタイブレーカーとして監視として使用して、ドライブの半分を存続させます(プールリソース所有者であるこのノード)
プールには動的クォーラムがありません
プールには、投票を削除する独自のバージョンが実装されていません

例

四つのノード対称のレイアウトを使って。

16個のドライブのそれぞれに1票があり、ノード2にも1票があります（プールリソース所有者であるため）。過半数は16票のうち、決定されます。ノード3と4がダウンした場合、残りのサブセットには8つのドライブとプールリソース所有者があり、これは9/16の投票です。だから、プールは生き残っています。

一つのサーバー障害を生き残ることができます：はい。
は1つのサーバー障害を存続でき、次に別のサーバー障害を存続できます：はい。
は一度に二つのサーバー障害を生き残ることができます：はい。

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

16個のドライブのそれぞれには1票があり、ノード2にも1票があります（プールリソース所有者であるため）。過半数は16票のうち、決定されます。まず、ドライブ7がダウンします。ノード3と4がダウンすると、残りのサブセットには7つのドライブとプールリソース所有者があり、これは8/16の投票です。だから、プールは過半数を持っていないし、ダウンします。

一つのサーバー障害を生き残ることができます：はい。
は1つのサーバーの障害から生き残ることができ、別のサーバーの障害から生き残ることができます：いいえ。
は一度に二つのサーバー障害を生き残ることができます：いいえ。

対称でないレイアウトを持つ四つのノード。

24台のドライブのそれぞれに1つの投票があり、ノード2にも1つの投票があります（プールリソース所有者であるため）。過半数は24票のうち、決定されます。 8台のドライブとプールリソースの所有者があり、これは9月24日に投票されます。だから、プールは過半数を持っていないし、ダウンします。

一つのサーバー障害を生き残ることができます：はい。
は、あるサーバーの障害から生き残ることができ、別のサーバーの障害から生き残ることができます。**Depends**(ノードthreeとfourの両方がダウンした場合は生き残ることができませんが、他のすべてのシナリオから生き残ることができます。
は一度に二つのサーバー障害を生き残ることができます: **依存**（ノード三と四の両方がダウンした場合に生き残ることはできませんが、他のすべてのシナリオを生き残ることができます。

Pool quorum recommendations

クラスター内の各ノードが対称であることを確認します(各ノードには同じドライブ数があります)
ノードの障害を許容し、仮想ディスクをオンライ詳細については、ボリュームガイダンスのページを参照してください。
複数のノードがダウンしている場合、または二つのノードと別のノード上のディスクがダウンしている場合、ボリュームはデータの三つのコピーすべてにアクセボリューム内のすべてのデータに対して最大限の回復性を確保するために、サーバーを元に戻すか、ディスクを迅速に交換することをお勧めします。

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