フェイルオーバークラスタが落ちるのは、たいていノードが壊れたときではなく「多数決の数え方」を読み違えたときです。クォーラムとCSVの内部動作を、Microsoft Learnを引きながら現場目線で整理します。
フェイルオーバークラスタリングは「ノードを足せば冗長になる」という単純な話ではありません。むしろ、ノードを足したことで投票数が偶数になり、たった1ノードの計画停止でクラスタごと落ちる——そんな事故が現場では起こります。本稿では、Windows Server 2025世代のフェイルオーバークラスタを対象に、クォーラム（多数決）とWitness、動的クォーラム、そしてHyper-V/S2Dの心臓部であるCSV（クラスター共有ボリューム）の内部動作を、実際に手を動かした立場から掘り下げます。値やサポート範囲はバージョン依存があるため、要所では必ずMicrosoft Learnで最新を確認してください。
01なぜクォーラムが要るのか — スプリットブレイン回避
クラスタの本質は「ノードの多数決で、生き残る側を1つに絞る」ことです。ネットワークが分断され、ノードの部分集合どうしが通信できなくなったとき、両方の集合が「自分こそが本物のクラスタだ」と思い込んで同じディスクに書き込みにいくと、データが壊れます。これがスプリットブレインです。
Microsoft Learnは、この状況をこう説明しています。「クラスタは一般に半数を超えるノードが稼働していること（=クォーラムを持つこと）を要求する」「クォーラムは、ネットワーク分断時に複数のサーバーが同時に同じリソースグループをホストし、同じディスクに書き込むことを防ぐために設計されている」。つまりクォーラムとは可用性の仕組みである以上に、データ整合性を守るための強制停止ルールだと捉えると腹落ちします。過半数を確認できなかった側は、自らサービスを止めます。
Lost quorumやError 1135が出ていたら、まず疑うのはハードではなくネットワークと投票構成です。
02投票の数え方 — ノード多数決とクォーラムモード
各ノードは原則1票を持ち、稼働に必要なのは「投票総数の過半数」です。ここで厄介なのが偶数ノードです。2ノードや4ノードだと、ちょうど半々に分断されたときにどちらも過半数を取れません。そこでWitness（監視者）に1票を与えて総数を奇数に寄せます。Microsoft Learnはクォーラムモードを次のように整理しています。
- ノード多数決（Witnessなし）：ノードだけが票を持つ。奇数ノード向き。
- ノード多数決＋Witness：ノードに加えWitness（ディスクまたはファイル共有）が1票を持つ。偶数ノードで推奨。
- Witnessのみ（非推奨）：ノードは票を持たずディスクWitnessだけが票を持つ。単一障害点になるため選んではいけない、と明記されています。
ベストプラクティスは明快で、「投票要素の総数を奇数にせよ」です。偶数ノードならディスクWitnessかファイル共有Witnessを足す。これで「もう1ノードの障害」に耐えられ、半数のノードが同時に落ちても稼働を継続できます。
03Witnessの三種 — ディスク／ファイル共有／クラウド
Microsoft LearnはWitnessを3種類に分類しています。それぞれ「クラスタデータベースのコピーを持つか」で性格が分かれる点が実務上の勘所です。
- ディスクWitness：全ノードがアクセスできる小容量の共有ディスク。クラスタデータベースのコピーを保持し、ノード間でフェイルオーバー可能。共有ストレージがある従来型クラスタ向き。ただしS2Dではサポートされません。
- ファイル共有Witness：SMBファイル共有上に
witness.logを持つだけで、クラスタDBのコピーは持たない。共有ディスクを持たないS2D、SQL Server Always On、Exchange DAGなどのマルチサイト構成で使う。 - クラウドWitness：Azure Blob StorageのBlobを決定票に使う。第3のデータセンターを用意せずに済み、1つのストレージアカウントを複数クラスタで共有できる（Blobはクラスタ固有IDで命名）。こちらもクラスタDBのコピーは持ちません。
Event 1561で不整合エラーが出ます。Learnにもわざわざ注記されている、ハマりどころです。
04動的クォーラムと動的Witness — 総票を自動で奇数に
ここがWindows Server 2012 R2以降の白眉です。動的クォーラムは、生存ノードが「自分たちが過半数だ」と確認できるたびに、過半数の定義を生存者だけで数え直します。これにより4ノードクラスタが、1台、また1台と順に落ちても、最後の1台（last-man standing）まで生き延びられます。
これと連携するのが動的Witnessです。Microsoft Learnの記述はシンプルで、「動的Witnessは総票が奇数になるようにWitnessの票をトグルする。票が奇数ならWitnessは投票せず、偶数ならWitnessが投票する」。整理するとこうなります。
- 偶数ノード＋Witnessなし → 1ノードの票がゼロ化され総票が奇数に。
- 奇数ノード＋Witnessなし → 全ノードが投票。
- 偶数ノード＋Witness → Witnessが投票して総票が奇数に。
- 奇数ノード＋Witness → Witnessは投票しない。
あるノードの票が実際に有効かは、Get-ClusterNodeのDynamicWeightプロパティで確認できます。値1なら投票あり、0なら票がゼロ化されている、という具合です。ここを見ずに「なんとなく冗長なはず」と思い込むのが一番危ない。
05ノード数別・耐障害マトリクス
Microsoft Learnの表を、実設計の判断材料として噛み砕くとこうなります。「1台落ちた後さらにもう1台」に耐えるか、「2台同時」に耐えるかを分けて考えるのがポイントです。
- 2ノード：Witnessなしは1台目の障害で50/50（投票側が落ちると停止）。Witnessありなら1台目はYes、ただし連続2台目はNo。2ノードはWitness必須。
- 3ノード：Witnessなしでも1台目はYes、2台目は50/50。Witnessありなら連続2台目までYes（=2ノード＋Witnessの局面に落ちる）。
- 4ノード：Witnessなしは2台同時が50/50。Witnessありなら2台同時障害までYes。
- 5ノード以上：Witnessは不要（追加の耐性を生まない）。ただしS2Dはそもそも2台超の障害を扱えない。
推奨は明確です。2ノードはWitness必須、3〜4ノードは強く推奨、5ノード以上は不要。インターネットがあるならクラウドWitness、社内にファイルサーバーがあるならファイル共有Witnessを選びます。
06CSVの仕組み — 所有権（コーディネーターノード）と同時読み書き
ここからHyper-V基盤の心臓部、CSVです。CSV（クラスター共有ボリューム）は、複数ノードが同一LUNに同時に読み書きできる仕組みで、これにより仮想マシンのフェイルオーバー時にボリュームの所有権変更やアンマウント／再マウントが不要になり、切り替えが速くなります。VHD/VHDXの置き場所として、Hyper-Vクラスタでは事実上の標準です。
ただし「所有権」の概念は残ります。任意の時点で1つのノードだけがLUNに紐づく物理ディスクリソースを所有し、これをコーディネーターノードと呼びます。所有者はFailover Cluster ManagerのOwner NodeやGet-ClusterSharedVolumeで確認できます。通常のデータI/Oは各ノードがSAN等を通じて直接ストレージと通信しますが（Direct I/O）、ファイルシステムのメタデータ変更——VMの作成・削除・起動・マイグレーションなど——は、全ノードで同期する必要があり、これがSMB 3.0でコーディネーターノードを介して並列に同期されます。
Windows Server 2012 R2以降、CSVの所有権は各ノードが持つCSV数に基づいて自動で均等分散され、フェイルオーバーやノードの再参加・再起動、クラスタ起動時に自動リバランスされます。つまり「1台に所有権が偏ってメタデータ処理がボトルネックになる」状況は、放っておいても是正される設計です。
07Direct I/OとI/Oリダイレクト — ReFSとSANの落とし穴
CSVで最も誤解されやすいのがI/Oモードです。Microsoft Learnはフォーマット指針を明確に分けています。
- SANボリューム：NTFSでフォーマットしてからCSVに追加する。NTFSがSAN接続でのDirect I/Oを有効にし、性能が出る。
- S2Dボリューム：ReFSでフォーマットする。ReFSはデータ整合性、ブロッククローン、S2D向け最適化を備える。
落とし穴はここです。SAN上でReFSフォーマットのCSVは、他の条件を満たしていてもDirect I/Oを使わず、リダイレクトI/Oモードで動作します。「ReFSは新しくて良さそうだから」とSAN構成でReFSを選ぶと、知らぬ間に全書き込みがコーディネーターノード経由になり性能が落ちる。SAN＝NTFS、S2D＝ReFS、と機械的に覚えておくのが安全です。
また、あるノードがストレージへ直接到達できなくなると、そのノードはI/Oをクラスタネットワーク経由でコーディネーターノードへリダイレクトします。リダイレクトにはボリューム単位のファイルシステムリダイレクトと、ブロック単位でより高速なブロックリダイレクトがあり、状態はGet-ClusterSharedVolumeStateで「Direct／Redirected／理由」まで確認できます。SMB 3.0のMultichannel/SMB Directに統合されているため、リダイレクトI/Oも複数ネットワークやRDMAに載せられます。CSVをクォーラムのWitnessディスクに流用できない点も、あわせて押さえておきましょう。
08優先所有者・フェイルバックとクラスタネットワーク／ハートビート
VMやCSVといったリソースには優先所有者（Preferred Owner）を設定でき、フェイルオーバー先の順序や、障害復旧後に元ノードへ戻すフェイルバックの挙動を制御します。フェイルバックを「即時」にすると、復旧直後のノードにVMが殺到して二次障害を招くことがあるため、業務時間外の時間帯指定にするのが定石です。
そして見落とされがちなのがハートビートです。クラスタは常時ノード間の到達性を監視しており、規定回数のハートビートが連続で欠落するとそのノードをメンバーシップから除外します。Microsoft Learnによれば、現行のWindows ServerではSameSubnetThresholdの既定値は10、SameSubnetDelayは1000ミリ秒。つまり同一サブネットで約10秒到達性が途切れるとノードが除外され、Error 1135が記録されリソースが別ノードへ移動します。マルチサイトではCrossSubnetThreshold／CrossSubnetDelayを別に持ち、WANの遅延を吸収します（同一サブネット値がクロスサブネット値を超えてはいけません）。
—まとめ
フェイルオーバークラスタリングは、突き詰めれば「投票総数を常に奇数に保ち、分断時に生き残る側を1つに絞る」ための精密な多数決システムです。偶数ノードにはWitness、その票は動的Witnessが自動でトグルし、動的クォーラムが生存者だけで過半数を数え直す。CSVは同時読み書きを実現しつつ所有権（コーディネーターノード）とメタデータ同期を残し、SAN＝NTFSでDirect I/O、S2D＝ReFS、という原則を外すとリダイレクトで性能を落とす。ハートビート閾値は既定で約10秒——このあたりの「数え方」を理解しているかどうかで、基盤の安定は大きく変わります。
そして、このオンプレHyper-V/S2Dで培った可用性設計の勘所は、そのままAWS移行の武器になります。クォーラムとWitnessの多数決モデルはマルチリージョンDRのRPO/RTO設計の考え方に通じ、オンプレADの理解はAWS Managed Microsoft ADへの移行で効いてきます。EMWは実際にS2D（Windows Server 2025 Datacenter）とHyper-V基盤を構築した上で、その資産を活かしたクラウド移行まで一気通貫でご支援しています。導入事例もあわせてご覧ください。
—参考（一次情報）
- What is a failover cluster quorum witness in Windows Server?（Microsoft Learn）
- Understand cluster and pool quorum on Azure Local and Windows Server clusters（Microsoft Learn）
- Cluster Shared Volumes overview（Microsoft Learn）
- Tuning failover cluster network thresholds（Microsoft Learn）