Windows Server フェールオーバー クラスターをローリング アップグレードすると、途中で Mixed-OS（混在OS）状態になります。「Update-ClusterFunctionalLevel は必須？」「混在のまま運用できる期間は？」「2016→2022は直行できる？」を、公式ガイダンスと現場の運用目線で整理します。
結論：Mixed-OS は“互換モードの移行期間”。全ノード更新後は機能レベル更新まで完了させる
まず押さえるべきポイントは次の3つです。
- Mixed-OS（混在OS）状態は一時的に許容される互換モードであり、恒久運用は推奨されません。Microsoft は4週間以内にクラスターのアップグレード工程を完了することを推奨しています。
- 全ノードの OS 更新が終わったら、
Update-ClusterFunctionalLevelを実行して Mixed-OS を抜けるのがベストプラクティスです。機能レベル更新により新機能が有効になり、一部のクラスター操作（例：ドレイン）も改善されます。 - Windows Server 2016 → 2022 を“直接”ローリング アップグレードはできません。ローリング アップグレードは「次の新しい OS へ 1 世代ずつ」が原則なので、2016→2019→2022と段階的に行うか、新規クラスターを構築して移行します。
Cluster OS Rolling Upgrade（ローリング アップグレード）とは
Cluster OS Rolling Upgrade は、クラスターを止めずにノードを 1 台ずつアップグレードし、最終的にクラスター全体を新しい Windows Server バージョンへ移行する仕組みです。大事なのは、クラスター全体が新 OS に揃うまで、クラスターは Mixed-OS（互換モード）で動き続ける点です。
「Hyper-V / SOFS 以外は対象外？」と心配されがちですが、公式 FAQ では、Cluster OS Rolling Upgrade 自体は SQL Server を含む“どのクラスター ワークロードでも動作する”とされています。ただし、ゼロダウンタイムで進められるのは Hyper-V と SOFS が中心で、それ以外のワークロードはフェールオーバーが少なくとも 1 回以上必要となり、通常は数分程度の停止が発生し得ます。運用設計では「無停止で終わる前提」ではなく、計画停止（短時間）を許容する設計にしておくのが安全です。
| フェーズ | 状態 | 運用上の意味 |
|---|---|---|
| アップグレード前 | 単一 OS（例：2016） | 従来どおり。機能・管理ツールも同一世代で統一。 |
| アップグレード途中 | Mixed-OS | 新 OS ノードは互換モードで稼働。長期運用は非推奨。 |
| 全ノード更新後（まだ機能レベル更新前） | 全ノード同一 OS だが「論理的には混在扱い」 | この段階でも Mixed-OS 相当の扱いが残るため、機能や運用上の制約が残り得る。 |
| 機能レベル更新後 | 新 OS 世代のクラスターとして確定 | 新機能が利用可能。後戻り不可（旧 OS ノードを追加できない）。 |
Mixed-OS（混在OS）状態とは：互換モードで稼働する“移行期間”
ローリング アップグレードで最初に新しい OS ノードがクラスターへ復帰すると、クラスターは Mixed-OS mode に入ります。Mixed-OS クラスターは稼働自体は可能ですが、OS が混在する以上、最適化されない機能が残ることが前提です。
Microsoft の公式ガイダンスでは、Mixed-OS を長く引っ張らないことが強く推奨されています。さらに、運用上の注意として管理作業は新しい OS 側ノードから実施することが明記されています（古い OS の UI/管理ツールが新しい OS を扱えないケースがあるため）。
Mixed-OS 中に避けたい操作（“やると詰む”系を先に潰す）
Mixed-OS は「動く」けれど「何をしても安全」ではありません。特にストレージまわりは要注意です。公式ドキュメントでは、Mixed-OS 中に新しい Windows Server ノードでストレージを作成・拡張（リサイズ）しないよう注意が示されています。新→旧へフェールオーバーした際に互換性問題を起こし得るためです。
| 操作 | Mixed-OS 中の推奨 | 理由（要点） |
|---|---|---|
| クラスター管理（役割移動、設定変更、GUI 操作） | 新 OS ノードから実施 | 旧 OS の管理ツールが新 OS を正しく扱えない可能性。 |
| ストレージ作成・拡張（特に新 OS 側で） | できるだけ避ける | 新→旧へのフェールオーバーで互換性問題のリスク。 |
| 運用を長期化 | 避ける（短期で完了） | 一部機能が最適化されない／想定外の不具合が起き得る。 |
Update-ClusterFunctionalLevel は実行必須？“動く”と“終わっている”は別物
よくある誤解は「全ノードの OS を上げ終わったなら、それで完了」というものです。しかし、クラスターには “OS が揃った” とは別に “クラスターとして新世代に確定する” 作業があります。それがクラスター機能レベル（Cluster Functional Level）の更新です。
公式ドキュメントでは、ローリング アップグレードの手順として最終段でクラスター機能レベルを更新することが示されています。更新によって新機能が利用可能になるだけでなく、Mixed-OS での実行だとノードが一時的に孤立しうるような操作（例：ドレイン）が改善される、と説明されています。
「今すぐ実行できない」ケースはある？
実務では「万が一に備えて、短期間は“戻せる状態”を残したい」という判断もあります。ローリング アップグレードは、機能レベル更新を行うまでは可逆（旧 OS ノードを戻せる）と説明されています。つまり、切り戻しの可能性を残したい場合は、全ノードを更新しても、短期間だけ機能レベル更新を待つという選択肢はあり得ます。
ただし、待つにしても Mixed-OS の推奨期限は意識すべきです。Microsoft Learn と Microsoft Q&A の回答では、4週間以内に Update-ClusterFunctionalLevel を実行して Mixed-OS を抜けることが推奨され、超過すると「クラスター マネージャーで管理できない」などの未知のエラーが起き得る旨が述べられています。
実行する／しないで何が違う？（運用判断のための比較表）
| 観点 | 機能レベル更新を実行しない（Mixed 相当を維持） | 機能レベル更新を実行する（新世代に確定） |
|---|---|---|
| 新機能の利用 | 制限される（互換モードのため） | 利用可能になる |
| 運用の安定性 | 長期化するほど“最適化されない”領域が残りやすい | 新世代として最適化された状態へ移行 |
| 切り戻し | 可能性を残せる（旧 OS ノードを戻せる余地） | 不可（機能レベルを下げられない） |
| 将来の拡張 | 旧 OS を追加できる余地が残る | 旧 OS ノードは追加不可 |
| 推奨 | 短期間のみに限定 | 全ノード更新後、速やかに実施 |
「4週間」はなぜ重要？Mixed-OS を引き延ばすほど運用リスクが増える
Mixed-OS は“動く”ため、つい後回しにされがちです。しかし、Microsoft は「OS が 2 世代混在しているクラスターでは最適化されない機能がある」ため、アップグレード工程を4週間以内に進めることを推奨しています。公式 FAQ でも同様に、Mixed-OS は 4 週間以内に完了することが促されています。
機能面のリスク：互換モードのままでは“新しくした意味”が薄れる
Mixed-OS では新 OS ノードが互換モードで稼働するため、クラスターの新機能は原則としてフルに使えません。アップグレードの目的が「延命（サポート期限対策）」だけならまだしも、パフォーマンスや運用性改善を狙っている場合、機能レベル更新を先送りするほど効果が出にくくなります。
運用面のリスク：管理ノード縛り・ツール不整合・作業属人化
Mixed-OS 中は「管理は新しい OS 側から」という制約が入ります。これは地味ですが、夜間障害や手順書運用で効いてきます。例えば、運用担当が旧 OS ノードに RDP して GUI で対処する習慣がある場合、Mixed-OS のままでは“いつもの場所でいつもの操作ができない”状況になり、判断ミスや復旧遅延につながります。
障害対応・サポート面のリスク：検証失敗や機能レベル更新失敗の火種
Microsoft Learn のトラブルシューティングでは、クラスター検証や機能レベル更新が失敗する原因としてMixed OS、アップグレード未完了、古いドライバー／ファームウェアが挙げられています。Mixed-OS を長く残すと、OS 更新パッチの適用タイミングもズレやすく、結果として“検証が通らない”“更新が完了できない”状態に陥りやすくなります。
混在OSのまま運用できる期間：実務上は「計画として4週間以内」を前提にする
「何週間まで絶対に動くか」という意味での期限を断言するのは難しい一方、Microsoft の公式ガイダンスとしては4週間以内にアップグレード工程を完了することが繰り返し推奨されています。Q&A では、4週間を超過すると管理不能などの未知の不具合が起き得る、という具体的な懸念も示されています。
なお、公式 FAQ では「Hyper-V と SOFS のクラスターなら、無停止でのアップグレードは合計 4 時間以内で完了し得る」という目安も示されています。もちろん環境差はありますが、“混在期間を長期化させない”ための根拠として、工程設計時に意識するとよいポイントです。
4週間に収めるためのサンプル工程（例：3ノード構成）
| 週 | やること | ポイント |
|---|---|---|
| 第1週 | 事前確認（容量/バックアップ/更新停止/検証計画） | 工程遅延の原因を先に潰す。夜間の監視強化もこのタイミング。 |
| 第2週 | ノード1を Drain → OS更新 → 復帰 | この時点で Mixed-OS 開始。管理は新 OS ノードから。 |
| 第3週 | ノード2、ノード3を順次更新 | ストレージ変更など“余計な作業”を入れない。 |
| 第4週 | 全ノード同一化 → 機能レベル更新 → 後続作業（VM/Pool等） | ポイント・オブ・ノーリターン。事前に切り戻し要件を合意。 |
2016 → 2022 は直行できる？ローリング アップグレードは「1世代ずつ」
Windows Server 2016 クラスターから 2022 へ、ローリング アップグレードで“飛ばす”ことはできません。公式ドキュメントでは「次の新しい OS へ 1 世代ずつ」アップグレードし、複数世代を跨ぐ場合は各バージョンで手順を繰り返す（例：2016→2019→2022→2025）か、新規クラスターへ移行すると示されています。
現実的な選択肢
- ローリングで段階的に上げる：2016→2019（機能レベル更新）→2022（機能レベル更新）
- 新規クラスターを構築して移行：時間が分散する／構成変更も同時にしたい／検証を厚くしたい場合に向く
クラスター機能レベル（Cluster Functional Level）を“見える化”する
アップグレードの進捗管理で便利なのが、クラスター機能レベルの確認です。公式ドキュメントでは、Get-Cluster | Select ClusterFunctionalLevel で確認でき、値と OS の対応表も示されています。
Get-Cluster | Select ClusterFunctionalLevel| 値 | 対応する Windows Server |
|---|---|
| 8 | Windows Server 2012 R2 |
| 9 | Windows Server 2016 |
| 10 | Windows Server 2019 |
| 11 | Windows Server 2022 |
| 12 | Windows Server 2025 |
推奨手順：2016→2019→2022 のローリング アップグレードを“事故らず”進めるチェックリスト
ここからは現場での事故を減らすための、実務寄りチェックリストです。実装方法は環境（Hyper-V、SOFS、SQL Always On、S2D など）で変わりますが、考え方は共通です。
事前準備：アップグレード前にやるべきこと
- クラスターの健全性確認（全ノード Up、役割 Online、容量に余裕がある）
- バックアップ完了（ワークロードだけでなく、必要に応じて System State でクラスター DB の保全も検討）
- CAU（Cluster Aware Updating）等の自動更新を一時停止（工程中に勝手に再起動しないように）
- ドライバー／ファームウェアの更新方針を決める（機能レベル更新や検証失敗の原因になりやすい）
- 2 ノード構成なら一時的な増設も検討（1 ノード停止で冗長性が落ちるため）
ノード単位の作業：Drain → OS 更新 → 復帰
ローリング アップグレードでは、ノードを 1 台ずつ「役割退避（Drain）」してから OS を更新し、クラスターへ戻します。代表的なコマンド例は次の通りです。
# 例：対象ノードから役割を退避（Drain）
Suspend-ClusterNode -Name <NodeName> -Drain
# OS 更新（インプレース アップグレード または クリーンインストール）
# 例：ノードをクラスターへ復帰
Resume-ClusterNode -Name <NodeName> -Failback Immediateクリーンインストールの場合は、機能（Failover Clustering 等）を入れ直した上で Add-ClusterNode で再参加させます。インプレース アップグレードの場合は、ノードはクラスターに残ったままなので、復帰操作が中心になります。
全ノード更新後：機能レベル更新（最終関門）
全ノードが新しい OS になったら、次に機能レベル更新です。更新前に「全ノード Up」「役割 Online」を確認し、問題がなければ実行します。公式 FAQ では、ノードが Off または Pause の状態では Update-ClusterFunctionalLevel は実行できない（全ノードが稼働し、クラスターにアクティブ参加している必要がある）と明記されています。
# 現在の機能レベル確認
Get-Cluster | Select ClusterFunctionalLevel
# 事前に “実行できそうか” だけ確認（破壊的変更を避ける）
Update-ClusterFunctionalLevel -WhatIf
# 実行（後戻り不可）
Update-ClusterFunctionalLevel機能レベル更新後に“起きがち”な落とし穴と対策
後戻りできない（旧 OS ノード追加も不可）
機能レベル更新後は、機能レベルを元に戻せず、旧 OS ノードを追加することもできません。ここがいわゆる「ポイント・オブ・ノーリターン」です。実行前に、切り戻し要件（いつまで戻せる必要があるか）を関係者と合意しておくと安心です。
“検証が通らない／更新できない”は Mixed-OS とドライバーが原因になりやすい
機能レベル更新でエラーが出る場合、原因としてありがちなのが「ノードが全て揃っていない」「混在が残っている」「ドライバー／ファームウェアが古い」です。Microsoft のトラブルシューティングでも同様の観点が示され、対策として“全ノード更新→ドライバー更新→機能レベル更新”の順で整理されています。
Hyper-V クラスター：VM 構成バージョン（Configuration Version）の扱い
Hyper-V クラスターを 2022 以降へ上げる場合、VM 側にも注意点があります。公式ドキュメントでは、VM 構成バージョンが 8.0 未満の VM は Windows Server 2022 上で動かせないとされています。まずは各ノードがサポートする VM バージョンを Get-VMHostSupportedVersion で揃っているか確認し、計画メンテナンスで VM の構成バージョンを更新していくのが安全です。
# ノードがサポートする VM バージョン確認（例）
Get-VMHostSupportedVersion -ComputerName <NodeName>Hyper-V クラスター：LBFO チーミング廃止と SET への移行
ネットワーク周りでは、Windows Server 2022 以降の Hyper-V でLBFO チームがサポートされない点が引っかかりやすいです。該当構成の場合、アップグレード前にチームを外し、アップグレード後に SET（Switch Embedded Teaming）を用いた vSwitch を作り直す、といった手当が必要になります。
「ローリングでやる」か「新規クラスターへ移行」かの判断基準
Mixed-OS 期間を 4 週間以内に収められるなら、ローリングはダウンタイムを抑えやすく有効です。一方で、次の条件があるなら新規クラスター移行の方が事故が少なくなることが多いです。
| 状況 | おすすめ | 理由 |
|---|---|---|
| 要員が確保でき、短期集中で作業できる | ローリング アップグレード | Mixed-OS 期間を短くでき、手順通りに終わらせやすい。 |
| 業務都合で作業日が分散し、4週間を超えそう | 新規クラスターへ移行 | Mixed-OS 長期化のリスクを避けられる。 |
| 世代飛ばし（2016→2022）をしたい | 新規クラスターへ移行（または 2019 を挟む） | ローリングは 1 世代ずつが原則。飛ばすなら移行が現実的。 |
| ネットワーク/ストレージ構成変更も同時にしたい | 新規クラスターへ移行 | アップグレードと設計変更の同時実施はリスクが高い。 |
よくある質問（現場で詰まりやすいところ）
機能レベル更新をしないと、すぐに障害が起きる？
すぐに停止するとは限りません。Mixed-OS は互換モードで稼働するため“動く”ことは多いです。ただし、公式には Mixed-OS を長期運用することは推奨されず、4週間を超えると管理不能などの未知の不具合が起き得るという情報もあります。つまり、「今すぐ壊れる」より「運用と障害対応が難しくなる」タイプのリスクが大きいと捉えるのが現実的です。
Update-ClusterFunctionalLevel はいつ打つ？誰が打つ？
基本は「全ノードが新 OS になり、役割が安定稼働しているのを確認した直後」です。Mixed-OS 中の管理は新 OS ノードから、というルールがあるため、実行担当も新 OS ノードにサインインして実行する運用が安全です。
Active Directory の機能レベル（ドメイン/フォレスト）も上げる必要がある？
混同されがちですが、今回の話はフェールオーバー クラスターの機能レベルです。Active Directory のドメイン/フォレスト機能レベルとは別概念なので、クラスター機能レベルを上げるからといって AD 側の機能レベルを同時に上げる必要はありません（もちろん AD 側に別要件がある場合は別途検討してください）。
機能レベル更新の前に確認すべき最小セットは？
Get-ClusterNodeで全ノードが UpGet-ClusterGroupで役割が期待通り OnlineGet-Cluster | Select ClusterFunctionalLevelで現状把握- ノードが Off / Pause ではない（全ノードがクラスターにアクティブ参加している）
- （可能なら）
Update-ClusterFunctionalLevel -WhatIfで事前評価
まとめ：Mixed-OS は“短期限定”で使い、機能レベル更新までをアップグレード完了とする
ローリング アップグレードは強力ですが、Mixed-OS はあくまで「移行を成立させるための互換モード」です。計画段階で Mixed-OS 期間を短く設計し、全ノード更新後は Update-ClusterFunctionalLevel を実行して新世代のクラスターへ確定させることが、もっとも安全で再現性の高い進め方です。
参考資料
- Microsoft Learn: Upgrade a Windows Server failover cluster with a cluster OS rolling upgrade
- Microsoft Learn: Troubleshoot Rolling Upgrade Issues
- Microsoft Q&A: Cluster Functional Level
コメント