SDS(Software-Defined Storage)の2ノード構成でのQuorum(クォーラム）の必要性は？

投稿日: 2023年4月28日 作成者: climb
このエントリーをはてなブックマークに追加
LINEで送る

もしユーザが2ノードクラスタ構成のSDS(Software-Defined Storage)ソリューションを考えている場合、課題の1つは、スプリットブレイン(split-brain)シナリオをどのように処理するかということでしょう。スプリットブレイン・シナリオとは、クラスタにノード障害が発生した場合、または2つのノード間でネットワーク障害が発生した場合、その後両方のシステムが再びオンラインになることを指します。どちらが最新のデータを持っているか？　誰が決めるか？　通常、Quorum(クォーラム：定足数)が関係しており、接続に関するいくつかの要素、アクセスの日付と時間などを保存している第3のシステムがあります。Quorumは、Split-Brainを回避し、ディスクの破損を防ぐために存在するものです。

つまり、これらの要素を保存するための第3のシステム、VMware vSANやStarWind vSANではWitnessと呼ばれるシステムが必要なのです。VMware vSAN 2ノードの場合、v7 U1以降、複数の2-Nodeデプロイメントで共有されたWitnessアプライアンスインスタンスを使用する機能があります。しかし、このWitnessはどこかで動作していなければならず、ノードとWitnessの間のネットワーク接続を維持しなければならない、などの問題があります。

Quorumなしで2-ノード・クラスタを実行することはできるでしょうか？

StarWind vSANがハートビート(Heartbeat)フェイルオーバーポリシーを使用するように構成されていれば、それは可能です。その場合、同期型の「Two-Way」レプリケーションを選択することができます。

1つのノードが故障した場合、VMware vSphere HAは残りのノード上のVMを再起動します。しかしこの機能を利用するには、少なくとも vSphere Essentials Plus が必要です。Essentials のみでは HA 機能はありません。

ハートビートフェイルオーバー機能では、利用可能なStarWindノードが1つしかなくても、ストレージクラスタは動作を継続します。

ノードが修復されてオンラインに戻った後、2つのノード間のデータの同期は StarWind によって自動的に行われます。ただしStarWindアプライアンスが実際に自動起動するように、各ホストでStarWindアプライアンスの自動起動VMを構成する必要があります。

注：Mode:Synchronus、Failover Strategy: Hearbeatになります。

しかし、環境内にすでに第3のシステムがある場合、明らかにそれをWitnessノードとして構成することができます。これは、StarWind VSANのもう一つの戦略である「Node Majority Failover Strategy（ノード・マジョリティ・フェイルオーバー機能）」によって行われます。

この機能では、ハートビート・リンクを追加することなく同期接続が可能ですが、3番目のWitnessノードを追加する必要があり、これは多数派のノード数に参加します。障害処理プロセスは、ノードがパートナーとの接続がないことを検出したときに発生します。

ノードの運用を維持するための主な条件は、HA装置の半分以上のノードとアクティブな接続があることです。利用可能なパートナーの計算は、その「票」に基づいて行われる。2ノードHAストレージの場合、ノード自身やノード間の通信に問題があると、すべてのノードが切断されます。そのため、同期ノードが2台だけの場合、ノードマジョリティによるフェイルオーバーは機能しません。この問題を解決するには、3番目のWitnessノードを追加する必要があります。このノードは、マジョリティのノードカウントに参加しますが、その上にデータを格納したり、クライアントのリクエストを処理したりすることはありません。

注：Node Majorityフェイルオーバー戦略では、1つのノードの障害のみを許容することができます。2つのノードに障害が発生した場合、3つ目のノードもクライアントのリクエストに応えられなくなります。

関連トピックス