フェールオーバークラスター検証でネットワーク警告が出たら、最初に見るべきは ノード間通信の遮断、クラスター ネットワークの Role 設定、AD/DNS の CNO・VCO 権限、WMI 接続 です。黄色い警告は即失敗ではなく、Microsoft では「ベストプラクティスから外れている可能性がある状態」として扱われます。ただし、そのまま本番に入れると、管理アクセスポイントの Online 失敗やノード間通信トラブルとして後から表面化し得るため、警告文の種類ごとに切り分けるのが最短です。(Microsoft Learn)
この記事では、起きやすい条件、まず確認すべき設定、更新や権限の影響、警告が消えないときの復旧フローまで、現場でそのまま使える順番で整理します。
ネットワーク警告の意味を先に整理する
Validate a Configuration ウィザードと Test-Cluster は、サーバー群に対してネットワーク、IP アドレス、Windows Firewall、更新レベル、サービス設定などを検証します。検証レポートは %systemroot%\cluster\Reports に保存され、Microsoft サポートでも重要な資料として扱われます。(Microsoft Learn)
判断基準はシンプルです。赤い失敗は解消必須、黄色い警告は「動く可能性はあるが、理由の確認が必要」 です。Microsoft は黄色警告を、環境や役割に対してベストプラクティスに合っていない状態として説明しています。(Microsoft Learn)
警告の出方から原因を絞る
- ノード間通信テストの警告
3343/TCP・UDP、445/TCP、135/TCP、RPC の動的高位ポート、ICMP が途中で遮断されているパターンです。ホスト ファイアウォールだけでなく、セグメント間ファイアウォール、ACL、VLAN、ルーティング不整合も疑います。(Microsoft Learn) - クラスター ネットワーク構成の警告
Role 設定ミス、クラスター通信に使えるネットワークが実質 1 本、クライアント接続を許可すべきネットワークで client access が無効、という構成ミスが典型です。(Microsoft Learn) - Network Name / 管理アクセスポイント周りの警告
CNO または VCO の権限不足、DNS 更新失敗、書き込み可能なドメイン コントローラーに到達できない、といった AD/DNS 側の問題で起きやすいです。(Microsoft Learn) - WMI 関連の警告
Create Cluster Wizard がリモート ノードから情報を取得できない場合は、単なる疎通不良ではなく WMI 接続やroot\MSCluster名前空間の異常が原因のことがあります。(Microsoft Learn) - 更新後だけ出る警告
NIC 交換、driver / firmware 更新、Windows Update 適用後は再検証が前提です。変更差分が片系だけに入っていると、検証で引っかかりやすくなります。(Microsoft Learn)
誤解しやすい点として、Windows Server 2016 以降では、同一スイッチ・同一サブネット上の複数 NIC は自動認識され、複数 NIC が同一サブネットにあること自体では検証警告を出さない と Microsoft は案内しています。古い解説だけを見て「同一サブネットだから警告」と決めつけるのは危険です。一方で、クラスター通信に使えるネットワークを 1 つだけにする設計は、いまでも単一障害点 として避けるべきです。(Microsoft Learn)
最短で切り分ける手順
レポートを確定し、必要なテストだけ再実行する
既存クラスターの切り分けでは、いきなりフルテストを回すより、まず最新レポートで対象テスト名を確認し、Test-Cluster -List でカテゴリ名を把握してからネットワーク関連だけを再実行する方が安全です。Test-Cluster はクラスター作成前後のどちらでも使えます。Storage テストは状況によってクラスターロールやディスクに影響するため、ネットワーク切り分け時は不要に触らない方がよいです。(Microsoft Learn)
Test-Cluster -List
# 例: 表示されたカテゴリ名が Network の場合
Test-Cluster -Node "NODE1","NODE2" -Include "Network"Role 設定と NIC の紐付けを確認する
Failover Cluster Manager の Networks で、各ネットワークが「クラスター通信なし」「クラスター通信のみ」「クラスター通信 + クライアント接続」のどれになっているかを確認します。PowerShell の Role 値は次の対応です。(Microsoft Learn)
| Role 値 | 意味 |
|---|---|
| 0 | クラスター通信を許可しない |
| 1 | クラスター通信のみ |
| 3 | クラスター通信とクライアント接続 |
管理用ネットワークは通常 Role 3、専用のクラスター通信ネットワークは Role 1 が基本です。IP Address リソースや client access point を置くネットワークで client access が無効だと、Event ID 1223 のように「そのネットワークはクライアント アクセスを許可していない」というエラーになります。(Microsoft Learn)
Get-ClusterNetwork
Get-ClusterNetworkInterfaceGet-ClusterNetwork でネットワーク一覧、Get-ClusterNetworkInterface でどの物理 NIC がどのクラスター ネットワークに属しているかを確認できます。GUI だけで判断しづらいときに有効です。(Microsoft Learn)
3343 だけでなく、445・135・ICMP もまとめて確認する
クラスター サービスは UDP/TCP 3343 を使い、ノード参加時は 445/TCP、135/TCP、ICMP Echo、さらに RPC の動的高位ポートも関係します。Microsoft は、クラスター検証成功のために ICMP4 / ICMP6 と 445/TCP の inbound / outbound 許可も明記しています。つまり、3343 だけ通れば十分 ではありません。(Microsoft Learn)
Test-NetConnection NODE2 -Port 3343
Test-NetConnection NODE2 -Port 445
Test-NetConnection NODE2 -Port 135
Test-NetConnection NODE2 -InformationLevel DetailedTest-NetConnection は ping 相当の到達性、TCP ポート、経路情報をまとめて確認できます。分離ネットワークがある環境では、ホスト側の設定だけでなく、中間機器の ACL やルートも同時に見てください。(Microsoft Learn)
Network Name 系の警告は、ネットワークより AD/DNS を先に見る
警告やイベントが Cluster network name resource、Event ID 1207 / 1211 / 1212 付近なら、CNO / VCO の権限、DNS 更新、書き込み可能なドメイン コントローラーへの到達性を優先確認します。特に、CNO を独自 OU に prestage した環境では、その OU に対して CNO に Create Computer objects 権限 を与えないと、clustered role 用の VCO を自動作成できません。(Microsoft Learn)
ここは本番前に見落としやすいポイントです。既定の Computers コンテナーなら、クラスター管理者は追加設定なしで最大 10 個の VCO を作成できますが、OU 分離運用では別途権限付与が必要です。権限を直したら、CNO 側の問題であれば Repair を実行して AD パスワードを再同期し、リソースを再度 Online にします。(Microsoft Learn)
権限制約が強い特殊環境では、PowerShell で AD-detached cluster を作る回避策もあります。ただし Microsoft も「特定シナリオ向け」としており、通常は CNO / VCO 権限を正しく整える方が運用しやすいです。(Microsoft Learn)
WMI や Invalid namespace は、ネットワーク設定変更だけでは直らない
Create Cluster Wizard がリモート ノードに到達できずデータ取得に失敗するケースでは、WMI 接続自体が原因のことがあります。さらに root\MSCluster に対して Invalid namespace が返るなら、単なる疎通不良ではなく MSCluster WMI 名前空間の破損 を疑います。(Microsoft Learn)
# 管理者権限のコマンド プロンプト
cd %systemroot%\system32\wbem
regsvr32 cluswmi.dll
mofcomp ClusWMI.mofこの修復は、wbemtest などで root\MSCluster の異常を確認してから実施します。WMI が壊れているのに NIC や VLAN だけ触っても、警告は消えません。(Microsoft Learn)
更新や NIC 変更の後なら、修正より先に差分確認をする
Microsoft は、Failover Clustering 機能のインストール後に最新の Windows Update を適用することを推奨しています。また、ネットワーク アダプターの変更、driver / firmware 更新など major 変更の後は、validation を再実行する前提です。(Microsoft Learn)
「昨日までは警告がなかったのに今日出た」なら、まず全ノードで NIC ドライバー、firmware、チーミング設定、仮想スイッチ、Windows 更新レベルが揃っているかを見てください。検証は個別サーバーではなく サーバー群全体の接続性 を見るため、片系だけ差分がある状態は警告の温床になります。(Microsoft Learn)
見落としやすいポイント
- 「警告だから作成は進められる」と判断して、単一ネットワークのまま終える
現行ドキュメントでも、少なくとも 2 つのネットワークを使うことがベストプラクティスです。単一ネットワークは単一障害点になります。(Microsoft Learn) - 古い記事を見て、同一サブネットの複数 NIC を真犯人だと決めつける
Windows Server 2016 以降は、この点だけでは検証警告を出さない案内に変わっています。(Microsoft Learn) - 業務時間中に Storage まで含めてフル validation を回す
Microsoft 自身が、ネットワーク切り分けでは対象を絞って実行するケースを示しており、Storage テストはディスク関連リソースをオフラインにする可能性があります。(Microsoft Learn) - CNO / VCO の権限だけ直して、Repair や再 Online をしない
権限修正後に Repair で CNO の AD パスワードを再同期しないと、状態が戻らないことがあります。(Microsoft Learn)
警告が消えないときの復旧フロー
%systemroot%\cluster\Reportsの最新レポートを開き、どのテストが黄警告なのか、どのネットワークやリソースが対象なのかを確定します。(Microsoft Learn)Get-ClusterLog -TimeSpan 5 -UseLocalTime -Destination C:\Temp\ClusterLogsなどで fresh log を採取し、Event Viewer の時刻と合わせます。(Microsoft Learn)- Event ID 1135 が出ているなら、Microsoft も初動として validation と network tests の再取得を推奨しています。通信断の兆候があるなら、まずそこからやり直します。(Microsoft Learn)
- Network Name 系なら CNO / VCO 権限 → DNS 更新 → 書き込み可能 DC → Repair の順で戻します。IP Address 系なら Role と client access 設定 を見直します。(Microsoft Learn)
- WMI 系なら
root\MSClusterを確認し、異常があれば WMI 修復後に再検証します。(Microsoft Learn) - 修正後はネットワーク テストだけで終えず、最後に validation を取り直してレポートを残します。変更後の再検証は Microsoft の運用前提です。(Microsoft Learn)
まとめ
フェールオーバークラスター検証のネットワーク警告は、ほとんどが 通信、Role、AD/DNS、WMI、更新差分 のどれかに分解できます。最短手順は、最新レポート確認 → Networks の Role と client access 確認 → 3343 / 445 / 135 / ICMP の確認 → Network Name 系なら CNO/VCO と DNS → WMI 系なら root\MSCluster → 修正後に再検証 です。(Microsoft Learn)
次にやることは、まず Test-Cluster -List と最新の validation report の確認です。警告を「ネットワーク全般が怪しい」で終わらせず、どのテストが、どの NIC / どのリソースで、何を失敗したのか まで落とし込めれば、復旧はかなり速くなります。(Microsoft Learn)
コメント