Windows Server フェールオーバー クラスター（WSFC）は 1 枚の NIC でも技術的に動作しますが、拠点分散や高負荷の現場では誤フェールオーバーや切り分け困難が致命傷になります。本記事では、Windows Server 2016/2019 の VM 2 台構成を前提に、NIC 設計とハートビート最適化、クォーラム/AG 連動の要点から、現場で実効性のある対策と検証手順まで具体的に解説します。
想定シナリオと疑問への短答
- 構成：Windows Server 2016/2019 の VM 2 台を 1 NIC だけで WSFC 化。これは「ベストプラクティス」か？ → 動くが推奨ではない。運用・冗長・切り分けの観点から最低 2 NIC を推奨。
- 代替案：データ通信用とハートビート通信用に NIC を分けるべきか？ → 分離は有効（専用 VLAN 含む）。ただし専用ハードは必須ではない。
- 拠点分散：異なるサイト間（本番/DR）のストレッチ クラスターで心拍断による AG 誤フェールオーバーが発生。対策は？ → 専用経路 or QoS でネットワーク品質を上げる、あわせて CrossSubnet* 閾値を段階的に緩和。
- 関連疑問：ハートビート欠損＝クォーラム喪失？ → 必ずしもそうではない。
WSFC が止まっても AG は動く？ → AG は WSFC の管理下。WSFC が不安定/停止すると AG リスナー/フェールオーバーにも影響。
WSFC ハートビートの基礎を最短で理解する
WSFC のハートビートは軽量（およそ 134 バイト）かつ高頻度で送出され、ノード間の生存監視と投票（クォーラム）に必要な通信の健全性を判断します。クラスタ スタック（NetFT）が Delay × Threshold の条件を超える未達を検知すると、ノード隔離やグループ移動（フェールオーバー）が発生します。サブネット内とサブネットを跨ぐ場合で閾値は分かれており、ストレッチ クラスターでは後者（CrossSubnet*）が効きます。
| プロパティ | 意味 | 一般的な初期値（2016/2019 目安） | 調整の勘所 |
|---|---|---|---|
| SameSubnetDelay | 同一サブネット間の HB 間隔（秒） | 1 | 原則 1 のまま。輻輳が酷い場合のみ 2 まで。 |
| SameSubnetThreshold | 同一サブネットの未達許容回数 | 5 | スタンドアロンのネットワークなら既定で十分。 |
| CrossSubnetDelay | 異なるサブネット間の HB 間隔（秒） | 1 | WAN 品質が悪ければ 1–2 で検証。 |
| CrossSubnetThreshold | 異サブネットの未達許容回数 | 10 | 誤検知がある場合 12–15 へ段階的に引上げ。 |
判定時間の目安は Delay × Threshold 秒です。例えば CrossSubnetDelay=1、CrossSubnetThreshold=15 なら、約 15 秒連続で心拍が欠損した時に「切り離し判定」へ進みます。閾値を上げすぎると 本当の障害検知が遅延する点に注意してください。
「1 NIC 構成」は動くが、運用では 2 NIC 以上が現実解
1 NIC は最小構成のデモや限られた環境では成立します。しかし、障害時の切り分け・性能分離・冗長化の観点で最低 2 NICを推奨します（データ/管理＋ハートビート）。ハートビートは帯域をほとんど消費しないため「専用 NIC が必須」というわけではありませんが、パケットロスや遅延の影響から心拍を守るために経路を分ける効果は小さくありません。
| 構成 | 長所 | 短所/リスク | 向くケース |
|---|---|---|---|
| 1 NIC（共有） | 構成が最もシンプル、コスト最小 | 輻輳/ロスで誤切替。切り分け困難。単一障害点。 | 検証環境/一時的回避策 |
| 2 NIC（データ＋HB/管理） | 分離・冗長・切り分けが容易。現実的コスト。 | NIC と vSwitch、配線の追加が必要。 | 小〜中規模本番、VM 環境全般 |
| 3 NIC 以上（データ/バックアップ/HB） | 用途別に最適化、性能と安定性を最大化 | 運用複雑度とコストが上昇。 | ミッションクリティカル、大規模分散 |
VM（仮想マシン）でのネットワーク設計ポイント
- vNIC を 2 枚以上。可能なら 異なる vSwitch/物理アップリンクへ接続し、仮想レイヤの単一故障を回避。
- ハートビート専用 VLANは必須ではないが、混雑ドメインから隔離できるなら有効。
- ゲスト OS 側の NIC チーミングは原則不要。行う場合は仮想基盤ベンダーの推奨モードに厳密に合わせる（不一致はループ/ドロップの温床）。
- 「クラスター専用」ネットワークは DNS 登録を無効にし、クライアントから誤って到達できないようにする。
- vMotion/ライブマイグレーション、スナップショット、バックアップの「一時停止」が 心拍途切れのトリガになり得る。メンテ時間帯と閾値設定を連携させる。
ストレッチ クラスター特有の対策（本番/DR 別サイト）
サイト間 WAN はレイテンシやジッタ、偶発的なロスが避けられません。最初にやるべきは ネットワーク品質の底上げ、次に 閾値の微調整です。
| 対策 | 主効果 | 注意点 | おすすめ度 |
|---|---|---|---|
| 専用 NIC＋専用 VLAN（可能なら別経路） | ロス/遅延の影響を最小化。障害切り分け容易。 | ポート/アップリンクの冗長化が前提。 | 高 |
| QoS（ポート/DSCP）で NetFT/SQL を優先 | 輻輳時の心拍保護。AG データ移送の安定化。 | ネットワークチームとポリシー整合が必要。 | 中〜高 |
| CrossSubnetThreshold＝10→12→15 と段階調整 | 誤検知の抑制。設備増強なし。 | 障害検知の遅延リスク。段階的に検証する。 | 中 |
| CrossSubnetDelay＝1→2 | 未達連鎖の確率を低減。 | 総合判定時間がさらに伸びる。 | 低〜中 |
実践ヒント：「WAN の平均遅延 20–40ms、0.1–0.3% 程度の短期ロス」があるケースでは、まずネットワークチームとともに ルーティング迂回/再送チューニング/優先制御で品質を上げ、それでも誤検知が残るなら CrossSubnetThreshold=12→15 と段階的に上げます。各段階で 障害注入テスト（後述）を必ず実施してください。
ファイアウォールとポート整備（最短チェックリスト）
WSFC/AG に関係する代表的なポートの確認は次の通りです。特にストレッチ構成では サイト間の双方向疎通を事前に監査してください。
| 用途 | プロトコル/ポート | メモ |
|---|---|---|
| クラスター ハートビート/制御 | UDP 3343 | NetFT（最重要）。優先/除外設定の対象。 |
| リモート プロシージャ コール | TCP 135 + 動的 RPC | クラスタ制御・マネジメントで利用。 |
| ファイル共有ウィットネス | TCP 445 | SMB 通信。クラウド ウィットネスなら HTTPS。 |
| SQL Server（既定） | TCP 1433 | 実際は固定/動的ポートを設計に合わせて。 |
| AG エンドポイント | TCP 5022（例） | ミラーリング/AG の Database Mirroring Endpoint。 |
PowerShell で確認・設定する（コピペ可）
現状の閾値と遅延を確認する：
# 現在値の確認
Get-Cluster | Format-List SameSubnetDelay,SameSubnetThreshold,CrossSubnetDelay,CrossSubnetThreshold
# ネットワーク役割とメトリックの確認
Get-ClusterNetwork | Select-Object Name, Role, Metric | Format-Table -Auto ストレッチ クラスターでの安全側調整（例）：
# 段階的に上げること。変更は即時反映される
(Get-Cluster).CrossSubnetThreshold = 12
# 問題が続く場合のみ
(Get-Cluster).CrossSubnetThreshold = 15
# ここまでしても誤検知が止まらないなら Delay を要検討
# (ただし実障害の検出が遅くなるため運用合意が前提)
# (Get-Cluster).CrossSubnetDelay = 2
「クラスター専用」ネットワークの役割設定（クライアントからの到達を遮断）：
# Role: 0=None / 1=ClusterOnly / 3=ClusterAndClient
Set-ClusterNetwork -Name "Cluster Network HB" -Role 1
クォーラム設計：2 ノード＋ウィットネスが基本
ストレッチ クラスターの 2 ノード構成では、ファイル共有ウィットネスまたはクラウド ウィットネスを必ず追加して票数を奇数化します。ダイナミック クォーラム/ダイナミック ウィットネスにより、票のオン/オフが自動調整され、過半数の維持確率が上がります。
- ハートビート欠損＝クォーラム喪失ではない。一方のノードが隔離されても、もう一方が ウィットネスと通話可能であれば票の過半数を保持し、クラスターは継続します。
- 隔離側はクラスター メンバーから外れるため、AG のプライマリ維持はできない（意図しない切替やサービス停止が発生し得る）。
- サイト障害時の 強制クォーラム（ForceQuorum） や 強制プライマリは最終手段。データ分断（スプリットブレイン）と整合性の手順を事前に手順化・訓練しておく。
SQL Server Always On AG との関係（挙動の本質）
AG は WSFC のリソース（ロール）として管理され、WSFC のヘルス/フェールオーバー判断に依存します。WSFC が不安定化またはクラスタ サービスが停止すると、AG リスナーがオフラインになり、自動フェールオーバーも実行されません。一方、元プライマリの SQL Server インスタンス自体は生き続ける場合があり、リスナーを経由しない直接接続では稼働して見えることがありますが、クラスタ管理外での運用は 意図しない二重書き込みやデータ不整合を招きます。したがって、WSFC の安定性確保が AG 安定運用の前提です。
運用で効く実践手順（ネットワーク×クラスタ×SQL）
- ネットワーク診断から着手：クラスタ ログ（FailoverClustering/Operational）で「missed heartbeat」「node removed（イベント 1135 など）」の時刻を洗い出し、vSwitch/物理スイッチのログ（ポートフラップ、エラーカウンタ、CPU/バッファ）と相関を取る。
- NIC 冗長化：各 VM に vNIC を 2 枚以上付与し、異なる vSwitch/物理アップリンクに接続。可能であれば HB 用 VLAN を分ける。
- タイムアウト微調整：
SameSubnet*/CrossSubnet*を 小刻みに（例：10→12→15）上げ、各段階で障害注入テストを実施。検知遅延のリスクは必ず関係者と共有。 - 監視強化：SCOM/LogAnalytics/監視基盤や SQL Agent を使い、ノード隔離・クォーラム変化・AG ロール変更を 即時通知。WAN 品質（遅延・ジッタ・ロス）のトレンド監視も並行。
- 障害テスト：片側 vNIC ダウン、vSwitch リンク遮断、サイト間ルーティング遮断、ノード再起動、SQL サービス停止などを 手順化して定期演習。RTO/RPO と運用判断（手動フェールオーバー/待機）を整合。
ハートビート専用ネットワークをどう作るか（現場の設計パターン）
以下は「作って終わり」ではなく、運用で回る現実的な組み合わせです。
| パターン | ネットワーク | WSFC 設定 | ポイント |
|---|---|---|---|
| A：2 NIC 分離 | NIC1=データ/管理（VLAN 10）、NIC2=HB（VLAN 20） | NIC2 のクラスター ネットワーク Role=1（Cluster Only） | DNS 登録は NIC2 で無効。切り分け容易。 |
| B：2 NIC＋QoS | A に加えて 3343/5022 を高優先に | 閾値は既定→様子見→必要なら軽微に増 | 輻輳時でも HB/AG を守る。まずはこの形。 |
| C：3 NIC（バックアップ分離） | バックアップ/レプリケーションを専用 NIC | バックアップ帯域を QoS で低優先 | 夜間の帯域食いによる誤切替を抑止。 |
WAN 品質の見取り図と閾値の考え方
「10 秒に 1 回、200ms のスパイクが出る」「1 分に 0.1% の連続ロスが出る」といった 断続的な悪化は、短い Threshold の既定値だと心拍欠損に直結します。
一方で、閾値を上げすぎると 本当の障害（リンクダウン/機器フリーズ）検知が遅れるため、以下の考え方を基本にします。
- WAN の「最悪ケース」連続ロス/スパイク時間を把握（観測）。
- その 1.5〜2 倍を目安に
Delay × Thresholdを設定（まずは 1.2 倍程度から）。 - 必ず障害注入テストで「本当の障害」を想定時間内に検知できるか確認。
ログ/メトリクスの読み方（誤フェールの根拠を掴む）
- Event Viewer → Applications and Services Logs → Microsoft-Windows-FailoverClustering/Operational
「missed heartbeat」「The Cluster service has removed node…（1135）」「…added node…（1137）」など。発生時刻を中核ログに。 - クラスタ診断ログ（ClusDiag/Cluster.log）
ハートビートのラウンドトリップや切断理由、投票の流れが追える。 - スイッチ/ファイアウォール
インタフェースの CRC/ドロップ/ポートフラップ、CPU/メモリ逼迫、コントロールプレーン保護（CoPP）によるレート制限など。 - SQL Server エラーログ
AG ロール変更、レプリカ切断、セッション再接続の兆候と時刻照合。
よくある落とし穴と回避策
- HB 専用 VLAN を作ったのに誤切替が止まらない：仮想/物理で同じアップリンクに乗っていないか、Storm Control/ポートセキュリティ/ACL による一時的ドロップがないか確認。
- ゲスト OS 側でむやみにオフロード機能を無効化：基盤設計と整合が取れているか。無分別な無効化は逆効果（CPU 上昇→輻輳）。
- バックアップ時間帯の誤フェール：バックアップ流量を別 NIC/低優先 QoS に逃がす。AG の圧縮/スロットリングも検討。
- DNS のマルチサブネット遅延：AG リスナーのマルチサブネット設定（RegisterAllProvidersIP/TTL）とクライアント側の接続文字列（MultiSubnetFailover）を設計。HB 自体とは別問題だが、復旧体感を大きく左右。
段階的な改善ロードマップ（そのまま使える）
- 現状把握（1 週間のログ）：心拍欠損の時刻を抽出し、WAN/SW/SQL のイベントと相関。
- 最小変更で効果測定：QoS 導入、HB VLAN 分離、vNIC の冗長化。
- 閾値微調整（安全側）：
CrossSubnetThresholdを 10→12。効果あれば 12→15 を検討。 - テストと承認：リンクダウン/ノード停止/サイト断を模擬し、RTO/RPO と検知時間を共有・承認。
- 恒久化：設計書/運用手順/監視閾値/アラートフローを一式更新。
サンプル：構成チェック・変更・検証の一連コマンド
# 1) ネットワークの健全性（WSFC 観点）
Get-ClusterNetwork | ft Name, Role, Address, Metric, AutoMetric -Auto
# 2) 「クライアント不可」の HB ネットワーク確認（Role=1）
Get-ClusterNetwork | Where-Object Role -eq 1 | ft Name, Address
# 3) ハートビート閾値の段階的調整
(Get-Cluster).CrossSubnetThreshold = 12
Start-Sleep -Seconds 5
(Get-Cluster).CrossSubnetThreshold = 15 # 継続する場合のみ
# 4) 変更後の値を記録
Get-Cluster | fl SameSubnetDelay,SameSubnetThreshold,CrossSubnetDelay,CrossSubnetThreshold > C:\Temp\wsfc_hb_after.txt
# 5) 意図的な NIC ダウン/ルート遮断を実施し、検知時間を実測
# （作業手順・承認・リカバリ手順を整えてから実行）
設計判断の要点をもう一度
- 1 NIC でも動作するが、誤フェールと切り分け困難が付きまとう。2 NIC 以上が良いプラクティス。
- ストレッチ構成はネットワーク品質が本丸。専用経路（VLAN/優先制御）＋軽微な閾値緩和の組み合わせが現実解。
- ハートビート欠損 ≠ クォーラム喪失。ウィットネス設計で多重故障に備える。
- AG は WSFC 管理下。WSFC 不安定＝AG も不安定。まずは WSFC を安定させる。
- 「設定して終わり」ではなく、監視・演習・改善のループで本番耐性が育つ。
チェックリスト（配布して現場で使える版）
| 項目 | Yes/No | 備考 |
|---|---|---|
| VM ごとに vNIC 2 枚以上・別 vSwitch/物理 UP へ接続 | ||
| HB 用 VLAN（任意）・Role=ClusterOnly・DNS 未登録 | ||
| UDP 3343/SMB/SQL/AG エンドポイントの双方向疎通 | ||
| クォーラムに FS/クラウド ウィットネスを採用 | ||
| CrossSubnetThreshold を段階調整（10→12→15） | ||
| 障害注入テストで検知時間とアプリ影響を測定 | ||
| 監視（HB 欠損/ノード隔離/AG ロール変更）を即時通知 |
ケーススタディ（誤フェールが止まらない拠点分散）
症状：本番（Site-A）と DR（Site-B）間で、深夜バッチ時間帯に AG が交互に切り替わる。クラスタ ログに「missed heartbeat」が散見。
対応：バックアップと ETL をバックアップ専用 NIC に移設し QoS 低優先に。HB は VLAN 分離し Role=ClusterOnly。さらに CrossSubnetThreshold 10→12 に引上げ。
結果：誤フェールは解消。本当の Site-B 回線断（計画停止）時には 12–15 秒で確実にフェールオーバーを確認。RTO 要件（30 秒以内）を満たした。
トラブル時の意思決定フロー（運用標準）
- 切替の原因分類：クラスタ ログ時刻を起点に、ネットワーク/SQL/OS のイベントを並べる。
- ネットワーク起因なら：優先制御/分離/経路再設計を優先。クラスタ閾値は微調整で止める。
- クラスタ/OS 起因なら：ドライバ/VM 設定/パッチ整備。クラスタ サービスの安定化なくして AG 安定なし。
- SQL 起因なら：ロック/IO 待ち/CPU 高騰が HB に干渉していないか（帯域共用や IRQ 競合）。
- 再発防止：手順・監視・閾値・設計書に反映し、次回演習のシナリオへ組み込む。
まとめ（意思決定の背骨）
- 「1 NIC でも動作するが、冗長 NIC と適切な閾値調整が現実解」。
- ストレッチ クラスターの誤フェールはネットワーク設計（分離/QoS/冗長）とCrossSubnet* の緩和で止める。緩めすぎは厳禁、段階的に。
- ハートビート欠損はクォーラム喪失とイコールではない。ウィットネスを含めた票の設計がカギ。
- WSFC が不安定なら AG も不安定。まず WSFC を安定—AG はその上で期待通りに動く。
- 診断→対策→検証→文書化のループを組織化することが、可用性を本当に高める唯一の道。
コメント