ハートビート対 ノードマジョリティ:StarWind VSAN フェイルオーバー施策

高可用性（HA）で保護されたワークロードは、本番環境で実現したい機能です。ワークロードが障害発生時にも継続して利用可能（再起動される）ことが保証されることは求められる要件です。HAは障害耐性（Fault Tolerance）とは異なるため、ワークロードはクラスター内の別のノードで再起動される前に一時的なダウンタイムを経験しますが、これは予期可能な範囲であり、事前に計画可能です。ここでは、StarWind VSANのフェイルオーバー施策について紹介します。最新のバージョンでは、3つの異なるフェイルオーバー施策が用意されています – ハートビート、ノードマジョリティ、そしてファイル共有監視です。

ハートビートは、HAクラスターのノードが同期できない状態でも、イニシエーターから独立して書き込みコマンドを受け付け続けることで、いわゆる「スプリットブレイン(split-brain)」シナリオを回避する技術です。この状況は、すべての同期とハートビートチャネルが同時に切断され、パートナーノードがノードの要求に応答しない場合に発生します。

少なくとも1つのハートビートリンクがオンラインの場合、StarWindサービスはこれらのリンク経由で相互に通信できます。優先度が最も低いデバイスは同期未完了としてマークされ、同期チャネルの再開まで以降の読み取りおよび書き込み操作がブロックされます。

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

StarWind Virtual SAN （VSAN） は、クラスター環境における高可用性 （HA） を確保し、データ破損を防止するための2つの主要なフェイルオーバー施策を提供します：ハートビートとノードマジョリティです。ノードマジョリティ（ノード多数決）施策は、2ノード構成でクォーラムを維持するために、ノードウィットネスまたはファイル共有ウィットネスのいずれかを使用して実装できます。これらの施策は、高可用性（HA）デバイス（LUN）の作成時に選択され、その後変更できません。以下は、StarWindのドキュメントおよび関連資料に基づく各施策の詳細な説明です。

この施策は、追加のハートビートリンクなしで同期接続を保証します。ノードがパートナーとの接続の欠如を検出した際に、障害処理プロセスが実行されます。

ノードを正常に動作させるための主な要件は、HAデバイスのノードの過半数（マジョリティ）を超えるアクティブな接続を維持することです。利用可能なパートナーの計算は、その「投票数」に基づいて行われます。

2ノードのHAストレージの場合、ノード自体に問題が発生したり、ノード間の通信に障害が発生した場合、すべてのノードが接続を喪失します。したがって、2つの同期ノードのみの場合、ノードマジョリティ・フェイルオーバー施策は機能しません。この問題を解決するには、ノードのマジョリティにカウントされるが、データを含まず、クライアントのリクエスト処理にも関与しない3番目のウィットネス(Witness)ノードを追加する必要があります。

HAデバイスが2ノード間でレプリケーションされている場合、ノードマジョリティ・フェイルオーバー施策を使用するHAデバイスには、ウィットネス・ノードを別途構成する必要があります。HAデバイスが3ノード間でレプリケーションされている場合、ウィットネス・ノードは不要です。

1. ハートビートフェイルオーバー施策

ハートビートフェイルオーバー施策は、「スプリットブレイン」シナリオを防止するために設計されています。このシナリオでは、HAクラスターノードが同期を失いながら独立して書き込みコマンドを受け付け続けるため、データ破損が発生する可能性があります。以下にその動作を説明します：

メカニズム： ハートビートは、ノード間の接続を維持するために追加の通信チャネル（ハートビートリンク）に依存しています。

すべての同期とハートビートチャネルが同時に失敗し、パートナーノードが応答しない場合、StarWindはパートナーがオフラインであると判断します。残りのノードは、自身に書き込まれたデータを使用してシングルノードモードで動作を継続します。

少なくとも1つのハートビートリンクがアクティブのままの場合、StarWindサービスはこのリンク経由で通信します。優先度が最も低いノード上のデバイスは「not synchronized(同期未完了)」としてマークされ、同期が再開されるまで読み取り/書き込み操作がブロックされます。一方、同期済みのノードはデータ整合性を確保するため、キャッシュをディスクにフラッシュします。

安定性を向上させるため、StarWindは複数の独立したハートビートチャネル（例：別々のネットワークインターフェース）を設定することを推奨します。これにより、スプリットブレインのリスクを軽減できます。

主要な機能：追加のウィットネス不要： ハートビートにより、3つ目のウィットネスノードやファイル共有なしで2ノードクラスターを運用可能。小規模な環境においてコスト効率に優れます。

シングルノード運用： クラスターは1つのノードのみで動作可能。1つのノードが故障しても高可用性を維持します。

ネットワーク要件： ハートビートは堅牢なネットワーク接続が必要です。StarWindは、管理/ハートビート用に少なくとも100 Mbpsのネットワーク、iSCSI/ハートビート用に1 Gbps（できれば10 Gbps）のネットワークを推奨します。これにより、信頼性の高い通信が確保されます。

使用例：シンプルさとコスト削減が優先され、3番目のウィットネスノードや外部ファイル共有が不可能な2ノードクラスターに最適です。

高可用性が critical で、インフラストラクチャが複数のハートビートリンクをサポートし、スプリットブレインシナリオを回避できる環境に適しています。

電源障害時にノードの同時シャットダウンを防止するため、無停電電源装置（UPS）の構成を推奨します。これにより、同期が中断される可能性があります。

構成： HA デバイス作成時に、StarWind Management Console または Web UI でハートビートフェイルオーバー施策を選択します。

同期とハートビートインターフェースを指定し、スプリットブレインを回避するため、異なるネットワークアダプターに配置してください。

例： StarWindサーバーを右クリックし、「Add Device (advanced):デバイスを追加（詳細）」を選択、 「Synchronous Two-Way Replication;同期型双方向レプリケーション」を選択し、フェイルオーバース施策として「Heartbeat(ハートビート)」を選択します。

メリット：

• 追加のハードウェアや外部リソースを必要としないため、展開が簡素化されます。
• 単一のノードでクラスターの動作を維持し、可用性を向上させます。
• 小規模環境での複雑さを軽減します。

制限事項：

・ハートビートチャネルが独立かつ堅牢であることを確保するため、ネットワーク構成に注意が必要です。

・ネットワークの信頼性に依存度が高く、すべてのハートビートリンクが失われると単一ノード動作になり、適切に管理されない場合、データの一致不一致のリスクが増加します。

2. ノードマジョリティ・フェイルオーバー施策

ノードマジョリティ・フェイルオーバー施策は、クォーラム（quorum：出席者）を維持するためにノードの過半数（半数を超える）が接続された状態を要求することで、クラスターの動作を保証します。この施策は、データ整合性と厳格な同期が最優先される場合に使用されますが、2ノード構成では追加のコンポーネントが必要です。

クラスターは、HAデバイスのノードの過半数が接続されている場合にのみ動作します。これは、各ノードが「投票権」を持つ投票システムによって決定されます。

2ノードのHA構成では、奇数票を確保するために3つ目のコンポーネント（ノードウィットネスまたはファイルシェアウィットネス）が必要です。これにより、過半数を確立できます。このコンポーネントがない場合、通信が途絶えると両ノードが接続を解除し、過半数を達成できないためです。ノードが過半数と接続を失った場合、クライアントのリクエスト処理を停止し、スプリットブレインシナリオを防止します。

3ノードのHA構成では、追加のウィットネスは不要です。3つのノードが自然に奇数票を提供するため、クラスターは1つのノードの障害を耐容できます。

ハートビートリンク不要：ハートビート施策とは異なり、ノード・マジョリティは投票メカニズムのみに依存するため、追加のハートビートチャネルが不要です。

単一ノードの障害耐性：ウィットネスを含む2ノード構成または3ノード構成では、クラスターは1ノードの障害を耐えられます。ただし、2ノードが障害を起こした場合、残りのノードはクライアントから利用できなくなります。

同期ジャーナル： StarWindは、特定のシナリオで完全な同期を回避するため、RAMベース（デフォルト）またはディスクベースのジャーナルをサポートします。ディスクベースのジャーナルは、パフォーマンスを維持するため、別々の高速ディスク（例： SSDまたはNVMe）に配置する必要があります。

使用例： データの一貫性が厳格に要求される環境で、インフラストラクチャが3番目の証人コンポーネントまたは3ノード構成をサポートする場合に適しています。

大規模なクラスターや地理的に分散したクラスターで、ネットワークの信頼性が変動する可能性があり、投票ベースのクォーラムが好まれる場合に最適です。

構成： HA デバイス作成時にフェイルオーバー施策として「Node Majority」を選択します。

2ノード構成の場合、ノード・ウィットネス(Node Witness)またはファイルシェアーウィットネス（File Share Witness)のいずれかを設定します。

パートナーノードのホスト名、IPアドレス、ポート番号を指定し、「Synchronous Two-Way Replication」を選択します。

メリット：

• マジョリティ投票を必須とすることで、スプリットブレインのリスクを完全に排除し、データの一貫性を確保します。
• ハートビートリンクに依存しないため、一部のシナリオでネットワーク構成を簡素化できます。
• 3ノード構成では追加設定なしで動作します。

制限事項：

2ノード構成では3つ目のコンポーネント（Node WitnessまたはFile Share Witness）が必要となり、複雑さとコストが増加します。

3ノード構成で2ノードが故障した場合、または2ノード構成でウィットネスと1ノードが故障した場合、クラスターが利用不能になります。

ノード・ウィットネス(Node Witness)

説明： Node Witnessは、Node Majority施策の投票プロセスに参加する3番目のStarWindサーバーですが、ユーザーデータやクライアントリクエストを保存または処理しません。

2ノードHA構成で奇数票を確保し、1ノードが故障した場合でもクォーラムを維持します。

構成： StarWind Management Console（サーバーを右クリック > サーバーの追加）で、新しいStarWindサーバーを証人ノードとして追加します。

HAデバイスでは、Replication Managerを開き、「レプリカを追加」を選択し、「証人ノード」を選択し、証人ノードのホスト名またはIPアドレス（デフォルトポート： 3261）を指定します。

証人ノードの同期チャネルを構成し、両方のプライマリノードからアクセス可能であることを確認します。

例： 2ノード構成では、ウィットネスノードを追加して3つ目の投票権を提供し、1つのノードが失われた場合でもクラスターが正常に動作するようにします。

要件：

• ウィットネスノードはデータやクライアントのリクエストを処理しないため、最小限のリソースが必要です。
• ネットワーク接続は信頼性が高く、同期用に少なくとも1 Gbpsのリンク（10 Gbps推奨）が必要です。
• 証人ノードは、物理マシンまたは仮想マシンとして構成可能な独立した StarWind サーバーでなければなりません。

使用ケース：

既存のインフラストラクチャでサポート可能な場合、専用サーバーまたは仮想マシンを証人として使用する場合に推奨されます。

データの一貫性を優先し、3つ目のノードへの投資を厭わない組織に適しています。

利点：

• 外部ストレージや複雑なネットワーク構成を必要とせずに厳格なクォーラムを保証します。
• StarWindのエコシステムとシームレスに統合されます。

制限事項：

• ハードウェアまたは仮想マシンのオーバーヘッドを追加し、ハートビート施策と比較してコストが増加します。
• ウィットネスノードがアクセス可能であることを確保するための慎重なネットワーク計画が必要です。

3. ファイル共有ウィットネス

ファイル共有ウィットネス（FSW:File Share Witness）は、ノードマジョリティ施策における投票メンバーとして使用されるSMBファイル共有で、専用のウィットネスノードの必要性を置き換えます。

ファイル共有はStarWindノードの外側に配置され、両方のノードからサービスアカウントで書き込み権限を持ってアクセス可能である必要があります。

構成： StarWindノード以外のサーバーまたはデバイスに共有フォルダーを作成し、SMB共有として構成します。

両方のStarWindノードからローカルまたはドメインアカウントで書き込み権限を持ってアクセス可能であることを確認します。

C：\Program Files\StarWind Software\StarWind\StarWindX\Samples\powershell にある 「CreateHASmbWitness.ps1 PowerShell 」スクリプトを使用して FSW を構成します。スクリプトを編集して、両ノードのファイル共有パス、資格情報、同期インターフェースを指定します。

スクリプトを実行して、FSW を HA デバイスと統合します。

例： 2ノードのHAデバイスでは、FSWが3つ目の投票を提供し、1つのノードが故障した場合でもクォーラムを保証します。

要件： ファイル共有は、別システム（例： ドメインに参加したWindowsサーバーまたはWindows Server 2019クラスターでSMB 2以降をサポートするデバイス）にホストする必要があります。

共有は高可用性を確保し、単一障害点にならないようにする必要があります。FSWをクラスターノードとは別の場所に配置することを推奨します。

最小限のストレージが必要です（例：投票メタデータ用の小さなフォルダー）。

使用例： 3番目のサーバーが利用できないが、信頼性の高いSMB共有を構成できる環境（例：既存のファイルサーバーやNAS）に最適です。

コスト意識の高い環境で、専用のウィットネス ノードのオーバーヘッドを回避したい場合に適しています。

メリット：

• 既存のインフラストラクチャ（例： ファイル サーバー）を活用することでハードウェア コストを削減できます。
• 追加のノードを配置するリソースが限られた環境での展開を簡素化できます。
• FSW がオフラインになっても、2 つのノードが接続されていればクラスターは引き続き動作します。FSW はクォーラム自体ではなく投票メンバーであるためです。

制限事項：

Node Witnessと比較してStarWindのエコシステムとの統合度が低く、外部SMBサービスに依存しています。

信頼性の高いSMB共有を別途用意する必要があり、外部インフラへの依存が生じます。

FSWは、アクセス可能性を確保し不正アクセスを防止するため、適切に保護され監視する必要があります。

適切な施策の選択

ハートビートを選択する場合：

• 2ノード構成でコストと複雑さを最小限に抑えたい場合。
• 複数のハートビートリンクで信頼性の高いネットワーク接続を確保できる場合。
• 単一ノードでの高可用性が最優先であり、電源障害リスク（例： UPSを使用）を軽減できる場合。

ノードマジョリティとノード証人を選択する場合：

• 厳格なデータ一貫性が必須であり、スプリットブレインリスクを完全に排除したい場合。
• 3番目のサーバー（物理または仮想）を証人として使用できるリソースがある場合。
• 3ノードクラスターを展開し、証人が不要な場合。

Node Majority with File Share Witnessを選択する場合：

• 3番目のサーバーがないが、信頼性の高いSMB共有（例： ファイルサーバーやNAS）にアクセスできる場合
• 専用ハードウェアなしでコスト効果の高いクォーラムソリューションを希望する場合
• ファイル共有の高可用性とセキュリティを保証できます。

追加の考慮事項

ネットワーク設計： ハートビートには、同期とハートビート用に別々のネットワークアダプターを使用し、単一障害点を回避します。Node Majorityでは、ウィットネス（ノードまたはファイル共有）を耐障害性を確保するため、別サブネットまたは別拠点に配置します。

同期ジャーナル： 両方の施策は、RAMベース（高速だが揮発性）またはディスクベース（耐障害性が高い）のジャーナルをサポートします。ディスクベースのジャーナルは、2-wayレプリケーションの場合、HAデバイスサイズ1TBあたり2MB（3-wayの場合は4MB）が必要です。ジャーナルは、StarWindデバイスとは別の高速ディスク（SSD/NVMe）に配置してパフォーマンスを最適化してください。

パフォーマンス： ハートビートは、単一ノードで動作できるため、2ノード構成ではより高いパフォーマンスを提供する場合があります。ただし、ノードマジョリティはより厳格な一貫性を確保するため、SQL Serverのようなアプリケーションでは重要になる場合があります。

クラスタークォーラム： ノードマジョリティでは、証人（ノードまたはファイル共有）はクォーラムを維持するための投票メンバーとして機能し、クォーラムそのものではありません。証人が失われた場合でも、2つのノードが接続されていればクラスターは機能し続けます。

最終的な注意点

Heartbeatは、単一ノードでの動作が許容され、複数のハートビートリンクでネットワーク信頼性を確保できるコスト効率の良い2ノード構成に最適です。

Node Majority with Node Witnessは、3ノード構成または専用証人サーバーが利用可能な環境で、データ一貫性を優先する場合に適しています。

Node Majority with File Share Witnessは、既存のSMB共有にアクセス可能な2ノード構成で、コストとクォーラム要件のバランスを重視する場合に最適です。

詳細な設定手順については、StarWindの公式ドキュメントが準備されています。特定の環境（例：Hyper-V、vSphere）で展開する場合、StarWindはこれらのフェイルオーバー施策の設定用にカスタマイズされたガイドを準備しています。選択した施策をサポートするために、ネットワークと電源インフラが堅牢であることを確認し、複雑な展開の場合は事前に相談することを検討してください。

関連トピックス

• StarWindサーバのHA構築（概要編）【StarWind　SAN & NAS V6】
• SDS(Software-Defined Storage)の2ノード構成でのQuorum(クォーラム）の必要性は？
• Hyper-V対応のStarWind Virtual SAN（StarWind VSAN for Hyper-V）
• StarWind VSAN Plugin for vSphereのインストール
• バックアップの自動復旧検証機能: SureBackupについて [Veeam B&R]
• ファイバーチャネルStarWind VSAN構成の利点
• StarWindを使用したvSphereのHA構築（詳細編）【StarWind SAN & NAS】
• StarWind Virtual SAN (VSAN): VMware vSphere [ESXi] 構成ガイド – Web UIでCVMを構成
• StarWind Virtual HCI Appliance (vHCI)
• StarWindでのHA構成のベストプラクティス その3: ネットワークの構築