Windows Server 2025でHyper-Vクラスターの構築とライブマイグレーションを試してみる

# 本記事について
次期Windows Serverのバージョンである2025ではワークグループクラスターでのライブマイグレーションがサポートされる予定です。
ワークグループクラスター自体はWindows Server 2016からサポートされていたものの、これまではライブマイグレーションができなかったことが一つネックになっていました。
この記事ではワークグループクラスターでのライブマイグレーションをクラスターの構築から試していきたいと思います。

なお、Windows Server OSでのHyper-VクラスターはHCI構成、3-Tier構成と任意の構成が取れ構成の自由度が高いものとなりますが、本記事ではHCI構成をベースに構築、検証しています。
構築手順や設定は推奨からズレがあるかもしれませんがご了承ください。

# 構成と前提
## クラスターの構成
今回はHyper-V上に構築した仮想マシン2台を利用して仮想環境でワークグループクラスターを構築します。
また、外部にDNSサーバとAzure上にクラスタークォーラム用のストレージアカウントを用意しています。
![zu-zentaikousei.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/6c61bbec-84e6-9be1-7d5b-121470519346.png)

## 導入バージョン
Windows Server 2025のプレビューバージョンを利用しています。
プレビューバージョンは現在Windows Insider Programと評価センターからダウンロードできます。

Insider Programの開始方法とライセンスキー（2024/9/15まで有効）はこちらを参照。
[Microsot Learn | Windows Server Insiders Preview を開始する](https://learn.microsoft.com/ja-jp/windows-server/get-started/get-started-with-windows-server-insiders-preview)

## クラスターノード用Hyper-V VMの構築
Hyper-V VMとしてクラスターノードを構築する際にはいくつかの仮想化機能の有効化が必要になります。
この記事では詳述しませんが、以下の設定をおこなっています。
- CPUで仮想化機能を有効化（ExposeVirtualizationExtensions）
- ホストの管理用通信に用いるNICのMACアドレススプーフィングの有効化（Enable MAC address spoofing）

クラスターノード用Hyper-V VMには以下の4つのNICを構成し、OSディスク（200GB）とデータディスク（500GB×2）を付与しています。
![zu-hyper-v-vm.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/c355698f-fce8-56f6-70c0-60ba2e50a9f8.png)

# クラスターの構築
## 流れ
以下の流れで2台のノードを構築していきます。
1. OSインストール
2. Hyper-V、Failover Clusteringのインストール
3. ネットワーク設定
4. ホスト名・DNS等設定
5. クラスター構築
6. クラスタークォーラム設定
7. ストレージプール・クラスター共有ボリューム構築
8. クラスター対応更新設定（オプション）

## 1. OSインストール
特にWindows Server 2022以前と比べても大きく変わったところはありません。
プロダクトキーは先述のページを参照してDatacenter Editionのものを入力し、デスクトップエクスペリエンスでインストールします。
インストール先はOSディスク用に作成している200GBのディスクを選択します。
![productkey.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/4ed4e5f2-b38b-de74-8388-dc5b8acc1ef4.png)

![desktopexperience.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/21055c84-8e8f-64ce-1e37-07853f6229ac.png)

![osdisk.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/16733a23-1eeb-a953-6102-6f121c16ffe4.png)

## 2. Hyper-V、Failover Clusteringのインストール
Hyper-VとFailover Clusteringをインストールします。
- Hyper-V
![hyper-v.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/b969a30d-222a-f95e-dfde-02a01a4fcb4e.png)

- Failover Clustering
![failoverclustering.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/5cccfb09-c837-d196-8546-b15893b907b9.png)

## 3. ネットワーク設定
今回は4つのNICの内2つをストレージ通信用、残り2つをチーミングして管理用兼VM用で使います。
そのため、まずは管理用兼VM用の仮想スイッチを作成します。
![vmswitch.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/74cf4f47-f01a-916d-99b2-b8a01aded364.png)

仮想スイッチを作成すると仮想スイッチに接続された仮想NICが作られるため、仮想NICとストレージ通信用の2つのNICにアドレスを割り当てます。
今回は仮想NICのみデフォルトゲートウェイとDNSを設定し、ストレージ通信用NICはアドレスとサブネットマスクのみ設定しています。
ストレージ通信用はクラスターノード同士の通信ができればOKです。
- 仮想スイッチ作成後のNIC構成
![zu-hyper-v-vm-vmswitch.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/f2b6812c-dcf6-5168-f175-a5127cf6dc1f.png)

## 4. ホスト名・DNS等設定
クラスターノードのホスト名とワークグループ名、DNSサフィックスを設定します。
ワークグループ名とDNSサフィックスは両ノードで共通の設定を登録します。
クラスターノード同士がWinRMでリモート接続するために、TrustedHostsに両ノードのホスト名を登録します。念のためDNSサフィックス付きも登録しておきます。（DNSサフィックス付きの名前を登録しないとストレージプール構成後のクラスター検証でアラートが発生していました）
加えてhostsファイルにも両ノードとクラスター名のIPアドレスを登録しておきます。
- ホスト名、ワークグループ名、DNSサフィックス設定
![hostname.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/2f115e5d-bd52-6f23-9742-4a59084c39a7.png)

- TrustedHosts登録
![trustedhosts.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/f62d68f9-fe54-4b6e-f937-3d3824a9ad16.png)

- hostsファイル設定
![hosts.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/d74be073-62d8-df02-ffec-8c497e161371.png)

## 5. クラスター構築
Test-Clusterコマンドでクラスター構築前の検証を実行します。
![test-cluster.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/b8b0e2d7-715a-4911-7811-fd639f1d73b4.png)

今回は両ノードがドメイン参加していないこととノード間でWindows Updateの適用状況の差異があることが警告として上がってきました。
ドメイン参加していないことは想定通りで問題なしなので無視しますが、Windows Updateの適用状況は合わせておくべきでしょう。
今回はDefenderのプラットフォームのアップデートの適用に差異があるものの、検証なので無視して進めます。
- ドメイン参加していない状態に対する警告
![validate_ad.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/6efefacc-9c4e-459d-a4fd-ecd0b5f10e2b.png)

- Windows Updateの適用状況の不一致に対する警告
![validate_su.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/78efdca1-8fbc-7db4-d85e-46b3dee87c1d.png)

New-Clusterコマンドでクラスターを構築します。
この時、ワークグループクラスターを構築する場合は"AdministrativeAccessPoint"オプションで"Dns"を指定します。
![new-cluster.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/2ec1611a-51e2-1061-0f56-bfdb65e68498.png)

無事クラスター構築に成功しました。
![cluster_check_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/8ac93ff6-6911-6446-2154-94d2c0724d46.png)

![cluster_check_2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/b4738a35-ebaf-3422-6bb6-fa5ffb784df0.png)

![cluster_check_3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/f4118182-f951-800c-cdb4-d037056b8ef2.png)

## 6. クラスタークォーラム設定
2ノードクラスターですのでクラスタークォーラムを設定します。
今回はAzureのストレージアカウントを用意してクラウド監視を設定することにします。
ストレージアカウント自体はBlobストレージを使えればOKですので、特殊な設定はせずに作成しています。
ストレージアカウントの名前とアクセスキーを用意して、以下の通りクラスタークォーラム設定のコマンドを実行します。
成功すればCloud WitnessがOnlineになっていることが確認できます。
![quorum_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/22fe96bd-8e76-685c-dbdc-4d0caedac6ce.png)

![quorum_2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/4b4cce6b-060f-fc2e-35d1-4fac56afcd74.png)

## 7. ストレージプール・クラスター共有ボリューム構築
今回2つのノードにそれぞれ2つの500GBのデータディスクを用意しています。
この4つのディスクを組み合わせてストレージプールを構成します。
![S2D.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/c35b235d-2c88-a0cb-6a23-67e999ac6787.png)

![S2D_check.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/cb4bc3dd-8285-73ce-e65c-c331fcba52e7.png)

続けてストレージプール上にクラスター共有ボリューム（CSV）を作成します。
CSVはノード数の倍数作成することが推奨になります。今回は2つのCSVを作成しています。
2ノードですのでデフォルトで2-way mirrorの可用性で作成されます。
![CSV.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/8c9f8084-82ba-2980-2ecb-93b05ce1a7d1.png)

![CSV_check.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/6a45c47b-04ed-a169-f52e-cd8ce0c4b6b2.png)

## 8. クラスター対応更新設定（オプション）
最後に、今回単純なライブマイグレーションに加えてクラスター対応更新実行時にも自動でライブマイグレーションされるかを確認したいためクラスター対応更新を設定しておきます。
先にリモートシャットダウンのためのファイアウォールルールを許可しておきます（今回検証のためDomain, Private, Public開けていますが最小限にしましょう）。
※今回の検証では再起動が必要な更新が存在しなかったため結果的にはクラスター対応更新でのライブマイグレーションは試せませんでした。。。
- リモートシャットダウン用ファイアウォールルール設定
![CAU_firewall.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/4847dd94-8a44-80c2-b36d-ba9d865d03e9.png)

- クラスター対応更新設定
![CAU_configuration.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/a6f58bc2-7f99-e211-b20a-771227eda321.png)

![CAU_resource.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/3d44ef4b-bd09-e46c-416f-2f19d449adae.png)

# ライブマイグレーションの検証
ライブマイグレーションを試すためにVMを1台用意しました。
VMにSSHで接続してPing実行している状態でライブマイグレーションを実行したところ、今回はSSHのセッションも切れずPingも1つも欠けずにクラスターノードを移動したことが確認できました。
- VMをWG-N01からWG-N02へライブマイグレーション実行
![VM_migrate.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/9e1ad30d-25ca-194b-cbe2-da64b01f8f03.png)

- SSHのセッションとPing実行状況
![VM_migarete_ping.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/b3be93b9-ba97-5ff9-ca8c-d28b9c6a25ac.png)

# おまけ
今回hostsにクラスターノードとクラスター名を登録した状態で検証していましたが、この状態では定期的にクラスターイベントログにID:1256のエラーが出ていました。
クラスター名をDNSサーバに登録できないことを示すエラーで、これを解消するにはDNSサーバで今回用意したワークグループ用のDNSサフィックスのゾーンを作成し、動的更新を許可することで解消することができました。
- エラーメッセージ
![dns_error.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/85d5496c-0ddd-5bcd-6d40-ca27c72dd3ae.png)

- DNSサーバで動的更新を許可
![dns_dynamic.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/481267/96c1c048-e2c4-47c4-1188-efb627c72585.png)

# まとめ
クラスターの構築手順をまとめつつライブマイグレーション機能を試してみました。
ライブマイグレーション自体は特に問題なく動作しており、AD DSの無い環境でも可用性の高いHyper-V基盤の運用ができそうです。
残念ながらクラスター対応更新は今回試せませんでしたので、別途確認してみたいと思います。