Windows Server 2016 のフェールオーバー クラスターを維持したまま、SQL Server Always On 可用性グループ（AG）も止めずに 2022 世代へ上げたい――そんな要望は今とても多くなっています。本記事では、「2016 から 2022 へ直接行けるのか？」「2019 を挟む必要は？」「AG への影響は？」という疑問に、実務担当者目線で具体的なステップとチェックポイントを交えて解説します。
Windows Server 2016 クラスターを 2022 へ更新する結論
まず、最も気になるポイントからはっきりさせておきます。
- Windows Server フェールオーバー クラスター（WSFC）の Cluster OS Rolling Upgrade では、一度に上げられる OS バージョン差は「1」まで に制限されています。
- そのため、2016 ノードと 2022 ノードを同一クラスターに混在させる構成はサポートされません。
- 現実的なアップグレードパスは、2016 → 2019 → 2022 の段階的アップグレードです。
- 各ステップで全ノードの OS をそろえた後、
Update-ClusterFunctionalLevelを実行して Cluster Functional Level（機能レベル） を引き上げます。 - 機能レベルを上げる操作は元に戻せません。旧バージョン OS のノードを再度参加させることもできなくなります。
SQL Server Always On 可用性グループ（AG）は、あくまで Windows Server フェールオーバー クラスター上の機能 として動作します。したがって、クラスターのアップグレード戦略に AG の運用をうまく乗せることが重要です。
Cluster OS Rolling Upgrade と機能レベルの基本
Cluster OS Rolling Upgrade（クラスタ OS ローリングアップグレード） は、クラスターを止めずに OS をアップグレードするための仕組みです。ざっくり言うと、次のようなイメージです。
- 古い OS（例：2016）と新しい OS（例：2019）のノードを一時的に混在させる。
- 新しい OS ノードは、一時的に「古い OS と同等の機能レベル」で動作する互換モードになる。
- 全ノードが新 OS になったら、
Update-ClusterFunctionalLevelで機能レベルを引き上げ、新 OS のクラスタ機能を有効化する。
この「混在」が許されるのは 隣り合うメジャーバージョン同士のみ という点が重要です（2016 と 2019、2019 と 2022 は可）。2016 と 2022 のように 2 世代離れた OS を同じクラスターに混在させるシナリオは、Cluster OS Rolling Upgrade の対象外とされています。
混在可能な OS バージョンのイメージ
| OS 組み合わせ | 混在サポート | 主な用途 |
|---|---|---|
| 2016 + 2019 | 〇（ローリングアップグレード中のみ） | 2016 クラスターを 2019 へ更新する際の一時的な状態 |
| 2019 + 2022 | 〇（ローリングアップグレード中のみ） | 2019 クラスターを 2022 へ更新する際の一時的な状態 |
| 2016 + 2022 | ×（サポート外） | Cluster OS Rolling Upgrade では利用できない組み合わせ |
また、Cluster Functional Level は次のように扱います。
- クラスター作成時は「もっとも古い OS バージョン」に合わせた機能レベルで動作します。
- 新しい OS ノードを追加しても、機能レベルを上げるまでは旧バージョン互換モード のままです。
- すべてのノードが新 OS になった段階で
Update-ClusterFunctionalLevelを実行し、新 OS のクラスタ機能を解放します。 - 機能レベルを上げると、旧 OS ノードの追加はできなくなります。
プランA：既存クラスターをローリングアップグレード（推奨）
もっとも現実的で安全性が高いのは、既存の WSFC を維持したままノード単位で OS を入れ替えていくプランA です。SQL Server Always On AG を利用していても、設計と手順をしっかり準備すれば、ダウンタイムをかなり小さく抑えることができます。
全体フローのイメージ
| フェーズ | 主な作業 | 主な影響範囲 |
|---|---|---|
| 事前準備 | バックアップ、互換性確認、リハーサル | 本番影響なし |
| Step1: 2016 → 2019 | ノード単位で OS 更新、AG フェールオーバー | 短時間のフェールオーバー |
| Step2: 機能レベル 2019 化 | Update-ClusterFunctionalLevel | コマンド実行時に軽微な影響の可能性 |
| Step3: 2019 → 2022 | 再度ノード単位で OS 更新 | 短時間のフェールオーバー |
| Step4: 機能レベル 2022 化 | 再度 Update-ClusterFunctionalLevel | 新機能利用可能、旧 OS へは戻れない |
事前準備：やらないと後悔するポイント
まずは、「ここをサボると後で泣く」ポイントから整理します。
| 項目 | 内容 | 備考 |
|---|---|---|
| バックアップ | DB フルバックアップ、システム DB、クラスター構成メモ、証明書・鍵などを保全 | 暗号化・TDE 利用時は特に注意 |
| OS 互換性 | Windows Server 2019 / 2022 で HW・ドライバーがサポートされるか確認 | HBA / NIC / ストレージドライバーは要チェック |
| SQL 互換性 | 利用中の SQL Server バージョンが 2019 / 2022 上で正式サポートか確認 | SQL 2012/2014 など古いバージョンは特に要注意 |
| 周辺ツール | バックアップ製品、監視エージェント、ウイルス対策ソフトなどの対応バージョン確認 | 古いエージェントがブロッカーになるケース多し |
| リハーサル | 検証環境（縮小構成で可）で手順書を一通り実行 | フェールオーバー手順・所要時間を計測 |
あわせて、事前に次の PowerShell コマンドで現状を確認しておくと安心です。
# クラスターの健全性の簡易チェック
Test-Cluster
# クラスタ名と現在の機能レベルを確認
Get-Cluster | Format-List Name, ClusterFunctionalLevel
Step1：2016 → 2019 へノード単位でアップグレード
ここから実際の作業ステップです。例として 3 ノード構成（Node1, Node2, Node3）を想定しますが、基本はノード数に関わらず同じです。
1. AG プライマリの退避
- アップグレード対象ノード上にある AG プライマリ を、別ノードに手動フェールオーバーします。
- データロスゼロを狙う場合、対象 AG を 同期コミット + 手動フェールオーバー にしてから切り替えます。
-- 対象 AG のフェールオーバー（同期コミット前提）
ALTER AVAILABILITY GROUP [AG名] FAILOVER;
2. クラスターからノードを一時的に退避
対象ノードのクラスター上の役割を整理してから、ノードを一時退避します。
# 対象ノードから役割を退避し、クラスターから一時的に外す
Suspend-ClusterNode -Name "Node1" -Drain
- このタイミングで、対象ノード上の SQL Server サービスを計画停止します。
- 必要に応じて、OS レベルのスナップショット（仮想環境の場合）を取得しておくとロールバックが楽になります。
3. OS のアップグレード（2016 → 2019）
OS の上げ方は大きく 2 パターンあります。
- インプレースアップグレード：既存 OS を上書きアップグレード（構成・インストール済みソフトは基本的に引き継がれる）
- クリーンインストール：OS を入れ直し、必要なコンポーネントを再構成
| 方式 | メリット | デメリット |
|---|---|---|
| インプレース | 作業が比較的早い、アプリ再インストールが少ない | 過去の設定・ゴミが残りやすく、トラブル切り分けが難しくなることも |
| クリーンインストール | クリーンな環境を構築できる、長期的に安定しやすい | 再インストール・再設定の工数が増える |
どちらを選ぶかはポリシー次第ですが、長く使う基盤であればクリーンインストールを検討する価値は高いです。
4. クラスターへ再参加し、AG を復帰
OS アップグレードが完了したら、フェールオーバー クラスター機能を有効化し、クラスターへ再参加させます。
# フェールオーバー クラスター機能の有効化（必要に応じて）
Install-WindowsFeature Failover-Clustering, RSAT-Clustering-PowerShell
# クラスターへの再参加（例）
Add-ClusterNode -Name "Node1" -Cluster "ClusterName"
# 役割を戻す
Resume-ClusterNode -Name "Node1"
SQL Server 側では、必要に応じて AG レプリカの状態を確認し、同期状態（Synchronizing / Synchronized）になっているかを SSMS や DMV で確認します。
Step2：全ノードが 2019 になったら機能レベルを更新
すべてのノードが Windows Server 2019 に置き換わったら、Cluster Functional Level を更新できます。
# 再度、機能レベルを確認
Get-Cluster | Format-List Name, ClusterFunctionalLevel
# 2019 に対応する機能レベルへ引き上げ
Update-ClusterFunctionalLevel
- このコマンドを実行すると、クラスターは 「2019 クラスター」としての新機能を利用可能 になります。
- 同時に、Windows Server 2016 ノードをクラスターに戻すことはできなくなります。
ここが 1 回目の「大きな戻れないポイント」なので、実行前に必ず次を確認してください。
- すべてのノードが 2019 で動作している。
- AG が正常に同期し、プライマリをどのノードへフェールオーバーしても問題なく稼働する。
- バックアップ・監視ツールが 2019 環境で正常動作している。
Step3：2019 → 2022 へのアップグレード
2019 クラスターとして安定稼働していることを確認したら、同じ手順を使って 2019 → 2022 のアップグレードを行います。
- AG プライマリを別ノードへ退避。
Suspend-ClusterNode -Drainでノードを退避。- OS を 2022 へアップグレード（インプレースまたはクリーンインストール）。
- クラスタへ再参加し、AG レプリカを確認。
このとき、OS 2022 でのみサポートされる新機能（SMB 圧縮やセキュリティ拡張など）を利用する場合は、周辺コンポーネントとの組み合わせも事前に検証しておきましょう。
Step4：全ノードが 2022 になったら再度機能レベルを更新
全ノードの OS が 2022 になったら、再度 Cluster Functional Level を更新します。
Get-Cluster | Format-List Name, ClusterFunctionalLevel
Update-ClusterFunctionalLevel
- ここまで到達すれば、「Windows Server 2022 クラスター」＋「SQL Server Always On AG」 という最新構成が完成です。
- 同時に、2019 も含めて旧 OS ノードをクラスターへ戻すことはできません。
最終検証：AG と周辺をまとめて確認
最後に、次のような観点で検証を行い、手順書に結果を残しておくと安心です。
- フェールオーバー クラスター
Test-Clusterの結果に重大なエラーがないか。- 各ノードへの手動フェールオーバーが正常に完了するか。
- SQL Always On AG
- プライマリ／セカンダリを各ノードに切り替えてもアプリケーションが正常動作するか。
- 同期コミット／非同期コミットの設定が意図どおりになっているか。
- 周辺システム
- バックアップジョブ（SQL Agent / バックアップソフト）が成功しているか。
- 監視ツール（死活監視・性能監視・ログ監視）のアラートが正しく上がるか。
- アプリケーション側の接続文字列（リスナー名・ポート）が最新構成に一致しているか。
プランB：新規 Windows Server 2022 クラスターを作成して切り替え
もう一つの選択肢は、新しい Windows Server 2022 クラスターを別途構築し、そちらへ移行してから切り替える プランBです。AG 未導入環境の新規設計や、ストレージ構成を大きく変えたい場合には有効です。
プランB の特徴
| 観点 | プランA（ローリング） | プランB（新規クラスター） |
|---|---|---|
| ダウンタイム | フェールオーバー時の数十秒〜数分単位に抑えやすい | 最終切替時にまとまった停止を設ける設計になりがち |
| リスク分散 | 既存クラスター上で段階的に作業 | 新環境で十分に検証してから切り替え可能 |
| 設計の自由度 | 既存設計に縛られやすい | ネットワーク・ストレージ・ネーミングなどを再設計できる |
| 手順の複雑さ | ノードごとの OS 入れ替えが中心 | AD オブジェクトや CNO / IP の再利用、移行計画がやや複雑 |
典型的なプランB の流れ（イメージ）
- 新しい Windows Server 2022 ノード群を用意し、別クラスターとして WSFC を構築。
- 新クラスター上に SQL Server をインストールし、AG を構成。
- 旧クラスターのデータベースをバックアップ／復元、あるいはログ配送や Always On の Distributed AG などを用いてデータ同期を確保。
- 十分に同期・動作確認した上で、計画停止を伴う切替ウィンドウを設ける。
- アプリケーションの接続先を新クラスターの AG リスナーへ切り替える。
「どうしても現在のクラスターを触りたくない」「ストレージ／ネットワークを含めて大規模に刷新したい」といったケースでは有力な選択肢ですが、移行手順はどうしても長く複雑になりがちです。AG を既に利用中で、現行構成に大きな不満がない場合は、まずプランAを検討するのがおすすめです。
SQL Server Always On 可用性グループ運用時のポイント
ここからは、SQL Server Always On AG 観点での具体的な注意点を整理します。
フェールオーバー戦略とコミットモード
OS アップグレード作業中は、AG のフェールオーバー戦略を意識的に設計する必要があります。
- データロスを許容しない重要な AG は、作業中は 同期コミット + 手動フェールオーバー にする。
- レポート用など、多少のラグや一時的な停止が許容される AG は、非同期のままにするか、必要に応じて同期化してから作業する。
-- コミットモードの変更例（簡略例）
ALTER AVAILABILITY GROUP [AG名]
MODIFY REPLICA ON N'ノード名'
WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
また、OS アップグレードの直前には、対象ノードがプライマリになっていないことを必ず確認してください。意図しない自動フェールオーバーが起こらないよう、メンテナンス中は一時的に自動フェールオーバーを無効化する運用もよく行われます。
SQL Server バージョンと OS サポートの確認
意外と見落とされがちですが、「今使っている SQL Server が、本当に Windows Server 2022 クラスター上でサポートされるか」は必ず確認が必要です。特に次のポイントに注意してください。
- SQL Server のメジャーバージョンだけでなく、Service Pack / CU レベル までサポート条件に含まれる場合がある。
- Standard / Enterprise などのエディションによって Always On 機能の制限が異なる。
- サポート対象外の組み合わせで稼働させると、不具合が出た際にサポートを受けられない可能性がある。
代表的なイメージを、あくまで「傾向」として整理すると次のようになります（正確な情報は必ず公式のサポートマトリクスで確認してください）。
| SQL Server バージョン | 2016 クラスター | 2019 クラスター | 2022 クラスター |
|---|---|---|---|
| SQL Server 2012 / 2014 | 一部構成でサポート | 制限・非推奨となるケースが多い | サポート外の可能性が高い（要公式確認） |
| SQL Server 2016 / 2017 | 多くの構成でサポート | 最新の CU 適用が前提となるケースあり | 組み合わせによりサポート有無が分かれる |
| SQL Server 2019 / 2022 | クラスター側が古いため新機能に制約あり | もっとも一般的な組み合わせ | 2022 世代として最もバランスが良い |
特に、Windows Server 2022 クラスター上で古い SQL Server を動かしたい場合は、「そもそもサポート対象かどうか」を必ず確認し、必要に応じて SQL Server 自体もアップグレードする計画を立ててください。
AG リスナー・クォーラム・周辺コンポーネント
OS アップグレードそのものに加えて、次のようなコンポーネントも合わせて確認が必要です。
- AG リスナー
- リスナー名が DNS 上で正しく解決できるか。
- 必要なポート（既定では 1433、カスタムポートを利用している場合はそのポート）がファイアウォールで許可されているか。
- クォーラム構成
- ノード多数決＋ファイル共有ウィットネスなど、クラスターが常に多数決を維持できる構成になっているか。
- ノードを一時的にクラスターから外す際に、クォーラムを失わないよう票の配分を調整する。
- バックアップ・監視
- エージェントが OS 2019 / 2022 に対応しているか。
- フェールオーバー後も、バックアップが「新プライマリ」に対して動作するように設定されているか。
SQL Agent ジョブ・メンテナンスの再点検
最後に忘れがちなポイントが、SQL Agent ジョブやメンテナンススクリプトの動作確認です。
- バックアップジョブが AG 対応（プライマリのみ実行） になっているか。
- ファイルパス（バックアップ先やログ出力先）が OS アップグレード後も有効か。
- 異常時に送信されるメール通知や SNMP 通知が、新環境でも正常に送信できているか。
OS アップグレード後は、少なくとも 1〜2 日程度はログを意識してモニタリングし、怪しいワーニングやエラーが出ていないかを確認することをおすすめします。
代表的な PowerShell / SQL コマンドまとめ
| 目的 | コマンド例 | 補足 |
|---|---|---|
| クラスター健全性チェック | Test-Cluster | 事前・事後の両方で実行して差分を確認 |
| 機能レベル確認 | Get-Cluster | Format-List Name, ClusterFunctionalLevel | アップグレード前後の状態を記録しておくとよい |
| ノード退避 | Suspend-ClusterNode -Drain | 対象ノードの役割を他ノードへ移した上で退避 |
| ノード復帰 | Resume-ClusterNode | OS アップグレード・設定反映後に実行 |
| 機能レベル更新 | Update-ClusterFunctionalLevel | 全ノードが同一 OS になった後、慎重に実行 |
| AG 手動フェールオーバー | ALTER AVAILABILITY GROUP [AG名] FAILOVER; | 同期コミット構成で実施すればデータロスゼロを実現可能 |
上記に加えて、必要に応じて各ノードのイベントログ（System / FailoverClustering / MSSQLSERVER など）を確認するコマンドや、性能カウンター取得の仕組みも用意しておくと、トラブルシュートがスムーズになります。
ロールバック方針と注意点
アップグレード作業を設計する際は、「うまくいかなかった場合にどこまで戻せるか」を事前に決めておくことが重要です。
- Cluster Functional Level 更新前
- 旧 OS ノードがまだ存在していれば、AG をそちらへ戻し、新 OS ノードを再構築することでロールバックが比較的容易です。
- Cluster Functional Level 更新後
- 旧 OS ノードはクラスターへ再参加できません。
- どうしても戻したい場合は、新 OS でクラスターを作り直す／バックアップから環境を再構築する、といった大掛かりな対応になります。
作業中にクォーラムを失ってクラスター全体が停止する、という事態は絶対に避けたいところです。ノード数や Witness の有無に応じて、作業前に票の数（Node Vote）や Witness の設定を見直し、「常に多数決が成立する」状態を維持できるよう調整しておきましょう。
チェックリスト：作業前・作業中・作業後
最後に、現場でそのまま使えるよう簡易チェックリストとして整理します。
| タイミング | チェック項目 |
|---|---|
| 作業前 | DB・システム・クラスター構成のバックアップ取得済み OS / SQL / ドライバー / ツールの互換性を確認済み 検証環境で一通りのリハーサルを実施済み ロールバック方針・判断ポイントを明文化済み |
| 作業中 | 対象ノードに AG プライマリが存在しないことを確認 同期コミット／非同期コミットの設定見直し済み Suspend-ClusterNode -Drain で役割退避してから OS アップグレード 各ノードごとにアップグレード後の Test-Cluster 実行 |
| 作業後 | 全ノードの OS バージョンが期待どおり（2019 → 2022）になっている Update-ClusterFunctionalLevel 実行後もフェールオーバーテストが成功 バックアップジョブ・監視・バッチ処理が正常動作している アプリケーションの接続テストが完了し、必要に応じて性能テストも完了 |
まとめ：迷ったらプランA（ローリングアップグレード）から検討
本記事のポイントを整理すると次のとおりです。
- 2016 と 2022 を同一クラスターに混在させるローリングアップグレードはサポートされない ため、2016 → 2019 → 2022 の段階的アップグレードが前提となります。
- 各ステップで全ノードの OS がそろった段階で
Update-ClusterFunctionalLevelを実行し、機能レベルを引き上げます（戻せない操作なのでタイミングに注意）。 - SQL Server Always On AG は、フェールオーバーとコミットモードを計画的に制御することで、データロスを避けつつサービス停止時間を最小化できます。
- 構成を一気に刷新したい場合は、新規クラスターを構築するプランBも選択肢ですが、手順が複雑になるため十分な検証と設計が必要です。
「どこから手を付ければいいかわからない」という場合は、まず現状のクラスター構成と SQL バージョンを棚卸しし、プランAに沿ったステップを検証環境で一周やってみる ところから始めるのが現実的です。そのうえで、要件や制約に応じてプランBも視野に入れ、自組織にとって最適なアップグレードパスを選択していきましょう。
コメント