寄稿：米国サイオス カスタマーエクスペリエンス担当バイスプレジデント Cassius Rhue
※この記事は翻訳されたものです。本記事の原文はこちら
最近の商談の中で、あるお客様から高可用性（HA）とQuorum/Witnessの必要性について質問を受けました。質問は、「Quorum/Witnessを導入するための最良の方法は？」というものでしたが、その質問に対する答えはシンプルです。Quorumを導入する唯一かつ最適な方法など存在しません。その理由を理解するために、まず3つの重要なこと、Witness リソースとは何か、Quorumリソースとは何か、そしてスプリットブレインとは何か、を定義しましょう。
Contents
スプリットブレインとは
通常のクラスター環境では、保護対象のアプリケーションはクラスターのプライマリーノードで実行されています。プライマリーノードでアプリケーションに障害が発生した場合、クラスタリングソフトウェアがアプリケーションの実行をセカンダリーノードまたはリモートノードに移動し、プライマリーノードの役割を担います。プライマリーノードは常に1つのみです。
スプリットブレインとは、クラスターのメンバーが互いに通信できない状態でありながら、実行中で操作可能な状態にあり、双方が共通のリソースの所有権を同時に取得した場合に発生する状態です。これは、2人のバス運転手がハンドルを取り合っているようなものです。スプリットブレインは、その破壊的な性質から、データ損失やデータ破損を引き起こす可能性があり、フェンシング、Quorum、Witness 、または Quorum/Witness 機能でプライマリノードが複数起動しないよう調停することで、スプリットブレインを回避するのがベストな方法です。
ほとんどのクラスターマネージャーでは、Quorumは次の場合に維持されます。
- すべてのサーバーは、すべてのクラスターピアとWitnessに対して同じ状態を確認できる
- すべてのサーバーは、すべてのクラスターピアについて同じ状態を確認できるが、Witnessは確認できない
- すべてのサーバーは、相互に確認はできないがWitnessリソースを確認でき、スプリットブレインを回避できる
ほとんどのクラスターマネージャでは、次の場合にQuorumが失われます。
- サーバーがすべてのクラスターピアとWitnessサーバーを確認できない
- サーバーはWitnessサーバーは確認できるが、クラスターピアの大部分を確認できない
- サーバーがQuorumリソースにアクセスできない、またはアクセスを維持できず、Quorumメンバーシップとリソースアクセスの調停が正常に行えない
Witnessリソース（またはサーバー）とは
Witnessリソースとは、クラスターのメンバーが偶数の場合にQuorumを達成および維持するために使用されるサーバー、ネットワークエンドポイント、またはデバイスのことです。 クラスターマジョリティを使用する奇数のメンバーのクラスターでは、マジョリティメンバーシップを調停するためにクラスターのすべてのメンバーがWitnessリソースを使用する必要はありません。
QuorumおよびQuorumリソースとは
Quorumリソースは、クラスターの状態とメンバーシップを調停する手段として機能するリソース（デバイス、システム、ブロックストレージ、ファイルストレージ、ファイル共有など）です。一部のクラスターマネージャーでは、Quorumはクラスターの状態とクラスターメンバーシップの決定を支援するリソース、または決定に必要なクラスター内のリソースです。他のクラスターマネージャーでは、Quorumはスプリットブレインを回避するためのタイブレーカーとなります。
Quorumを導入するための６つの注意点
Quorumの重要性を考えると、HAアーキテクチャではQuorum/Witness リソースを適切に配置することが不可欠です。幸いにも（あるいは残念ながら）、Quorumを配置するための唯一かつ最善の方法というのは存在しないのです。WitnessとQuorumのリソースの動作方法を形作っている要因には、次のようなものがあります。
1. オンプレミス、クラウド、ハイブリッドのいずれで展開するか
ファイバーチャネルストレージ、電源制御装置や接続装置、従来のstonithデバイスなどの追加のストレージデバイスのあるオンプレミスのデータセンターに導入すれば、クラウドにはないQuorumとWitnessの機能を追加でお客様に提供できるようになります。同様に、クラウド環境とハイブリッド環境では、何を導入できるのか、そしてQuorumを導入することで防止できるユースケースに違いがあります。さらに、レイテンシーの要件や違いによって、Quorum/Witness構成に使用できるデバイスやリソースの種類が制限される場合があります。
2. 復旧目標
また、QuorumやWitnessのリソースを設計・構築する際には、復旧目標を考慮することも重要です。2ノードクラスター（ノードAとノードB）の例で、ノードAがノードBへの接続を失った場合、復旧の最優先事項は何でしょうか。Quorum/WitnessリソースがノードAと同じネットワークにある場合、ノードAはオンラインのままですがクライアントから切り離され、ノードBはQuorumの評価と引き継ぎができない状態になる可能性があります。同様に、QuorumデバイスがノードBのあるリージョン、データセンター、ネットワークにのみ存在する場合、喪失により、機能しなくなったネットワークやセンターにリソースがフェイルオーバーしたり、機能・運用上のプライマリーノードからの離脱が発生する可能性があります。
3. インフラ内で利用可能なデータセンター（またはリージョン）の冗長化
データセンターまたはリージョンの冗長性も、Quorum/Witnessを使ったHAトポロジーでは重要な要素です。データセンターに2レベルの冗長性しかない場合、Quorum/Witnessをプライマリーまたはスタンバイのクラスターノードと同じデータセンターに配置することによるデメリットを理解する必要があります。3番目のアベイラビリティゾーンや2つ目のリージョンへのアクセスなど、データセンターに3つ以上の冗長層がある場合、クラスターでは高いレベルの冗長性が得られます。
4. ディザスターリカバリーの要件
真のディザスターリカバリー要件を理解することも、設計における重要な要素です。クラスター管理ソフトウェアが、データセンターの完全な停止（またはリージョンの障害）から復旧するためにQuorum/Witnessへのアクセスを必要とする場合、これが設計に及ぼす影響を理解する必要があります。多くの高可用性ソフトウェアパッケージには、このシナリオに対応するツールや方法が用意されていますが、お使いのソフトウェアにない場合は、Quorum/Witnessの設計と配置を対応させる必要があります。
5. クラスター内のメンバー数とその位置
クラスターのノードが奇数の場合、追加のQuorum/Witnessサーバーは通常必要ありません。 しかし、クラスター内で2つのノードしか使用していない場合や、常に利用できるわけではないDRノードをデプロイしている場合は、アーキテクチャを変更する必要がある場合があります。私はカスタマーエクスペリエンス担当者として、3ノードアーキテクチャを導入しているお客様と仕事をしたことがありますが、そのお客様ではコスト削減のために、3番目のサーバーの定期的なシャットダウンを自動化しました。
6. オペレーティングシステムとクラスターマネージャー
Quorum/Witnessに関する最後の要素は、クラスターマネージャとオペレーティングシステムです。Quorum/Witnessのデプロイやクォーラムのステータスの調停に関しては、すべてのHAソフトウェアとクラスターマネージャーで同じというわけではありません。クラスタリングソフトウェアによっては、調停に共有ディスクを必要とするものもあれば、より柔軟に共有できるものもあります（NFS、SMB、EFS、Azure Files、S3など）。クラスターマネージャーが必要とするものと、Quorumに関してサポートするモード（シンプルな多数決、Witness、ファイル共有など）を認識しておくことは、何をデプロイするかだけでなく、どのようにデプロイするかにも影響します。
まとめ
Quorum/Witnessサーバーを導入する最善の方法は、ベンダーのQuorum/Witnessの定義とそのオプションを理解し、要件を把握し、データセンター（またはクラウド環境）による制限や機会を考慮した上で、クリティカルなシステムをスプリットブレイン、誤ったフェールオーバー、そしてダウンタイムから最高レベルで保護するソリューションを構築することです。
HAクラスタソフト「LifeKeeper for Linux」におけるQuorum/Witnessの仕様
→ https://docs.us.sios.com/spslinux/9.6.1/ja/topic/quorum-witness
