【Hyper-V/Windows Server 2025】 HCI 構成:S2D での仮想マシンの作成と障害時の動作確認

記憶域スペース ダイレクト(S2D)のボリュームに高可用性の仮想マシンを作り、ライブ マイグレーション、ストレージ用の物理 NIC の故障、ノードの停止と復旧(データの再同期)の動作を確認した手順と結果です。

目次

この記事の前提

参照した公式ドキュメント

構成

項目内容
クラスタHVDOC-S2D(DOC-HV1/DOC-HV2/DOC-HV3)。S2D クラスタの構築手順で作成済み
ボリュームVolume01(80 GB、3 方向ミラー、C:\ClusterStorage\Volume01)
仮想マシンrocky-s2d01(Rocky Linux 9.8、第 2 世代、2 vCPU、メモリ 2 GB、IP アドレス 192.168.1.127)

仮想マシンの作成

仮想マシンの作り方は 3Tier 構成と同じです。クラスタでの仮想マシンの作成手順の手順で、[Location] に S2D のボリューム(C:\ClusterStorage\Volume01\)を指定します。

この検証では、3Tier 構成で作った仮想マシンの仮想ディスク(VHDX)を S2D のボリュームにコピーし、PowerShell で仮想マシンを作りました。

New-Item -ItemType Directory -Force 'C:\ClusterStorage\Volume01\rocky-s2d01\Virtual Hard Disks'
Copy-Item C:\VMKeep\rocky-hv01.vhdx 'C:\ClusterStorage\Volume01\rocky-s2d01\Virtual Hard Disks\rocky-s2d01.vhdx'
New-VM -Name rocky-s2d01 -Generation 2 -MemoryStartupBytes 2GB -Path C:\ClusterStorage\Volume01 -VHDPath 'C:\ClusterStorage\Volume01\rocky-s2d01\Virtual Hard Disks\rocky-s2d01.vhdx' -SwitchName VMSwitch
Set-VMProcessor -VMName rocky-s2d01 -Count 2
Set-VMFirmware -VMName rocky-s2d01 -SecureBootTemplate MicrosoftUEFICertificateAuthority
Add-ClusterVirtualMachineRole -Cluster HVDOC-S2D -VMName rocky-s2d01
Start-ClusterGroup -Cluster HVDOC-S2D -Name rocky-s2d01

3.2 GB の VHDX のコピーに約 230 秒かかりました。3 方向ミラーでは、書き込んだデータを 3 台のノードに送るため、ストレージのネットワーク(この検証では RDMA なしの 1 Gbps 相当の仮想 NIC)が書き込みの速さに影響します。

ライブ マイグレーション

DOC-HV1 で動いている rocky-s2d01 を、DOC-HV2 にライブ マイグレーションしました(GUI の操作は3Tier 構成の手順と同じです)。

Move-ClusterVirtualMachineRole -Cluster HVDOC-S2D -Name rocky-s2d01 -Node DOC-HV2 -MigrationType Live
ライブ マイグレーション後
項目結果
所要時間約 29 秒(Hyper-V-VMMS のイベント 20413 → 20415)
停止時間(blackout time)3.5 秒(イベント 20415 の記録)
ping の欠落(0.2 秒間隔)466 回中 15 回(約 3 秒)
使われたネットワークLiveMigration(10.20.85.0/24。イベント 20418 の送信元 IP アドレス)

画面の [Computer Name] が rocky-hv01 になっているのは、コピー元の仮想マシンのホスト名です。起動後にゲストでホスト名を rocky-s2d01 に変更しましたが、この時点ではまだ反映されていませんでした(ゲストの KVP デーモンが報告する値です)。

仮想マシンのディスクは S2D のボリュームにあり、全ノードから同じパスで見えるので、移動するのはメモリと状態だけです。

ストレージ用の物理 NIC の故障

仮想マシンが動いている DOC-HV2 で、SET スイッチの物理 NIC の 1 本(SET1)のリンクを切りました。SET1 には、ストレージ用の仮想 NIC「SMB」を割り当てています(S2D クラスタの構築手順の「ストレージ ネットワークの冗長化」)。

確認したこと結果
SET1 の状態Disconnected
仮想 NIC「SMB」(10.20.83.124)への疎通応答あり(SET が残りの SET2 に移しました)
S2D の SMB マルチチャネル(Get-SmbMultichannelConnection -SmbInstance SBL)10.20.83.x・10.20.84.x とも接続を維持
仮想ディスクの状態(Get-VirtualDisk)Volume01・ClusterPerformanceHistory とも Healthy
仮想マシンの ping(0.2 秒間隔)欠落 0 回
仮想マシンのディスク書き込み(200 MB、dd oflag=direct)正常に完了(17 MB/s)

リンクを戻すと SET1 は Up になり、仮想 NIC と物理 NIC の対応(SMB→SET1、SMB2→SET2)も元のままでした。この間も、仮想マシンの ping の欠落はありませんでした。

確認に使ったコマンドです。

Get-NetAdapter -Name SET1,SET2
Get-VMNetworkAdapterTeamMapping -ManagementOS
Get-SmbMultichannelConnection -SmbInstance SBL
Get-VirtualDisk

ノードの停止と復旧

仮想マシンが動いている DOC-HV2 の電源を強制的に切りました。S2D のノードが停止すると、そのノードのディスクにあるデータのコピーも使えなくなります。3 方向ミラーなので、残りの 2 台にあるコピーでボリュームは使い続けられます。

(1) ノードの停止中も、Volume01 の CSV は [Online] のままでした。

ノードの停止中のディスク

PowerShell で確認すると、仮想ディスクは「Warning」(Degraded、Incomplete)になり、修復のジョブ(Repair)がノードの復帰を待つ状態(Suspended)で作られていました。

Get-VirtualDisk -CimSession HVDOC-S2D | Format-Table FriendlyName,HealthStatus,OperationalStatus
Get-StorageJob -CimSession HVDOC-S2D
仮想ディスクHealthStatusOperationalStatus
Volume01WarningDegraded, Incomplete
ClusterPerformanceHistoryWarningDegraded, Incomplete

(2) 仮想マシンは DOC-HV1 で自動的に再起動されました。ping が戻るまでの時間は 315 秒でした。3Tier 構成と同じく、既定では応答しなくなったノードをまず分離(Isolated)の状態として扱い、240 秒待ってからフェールオーバーするためです(設定は3Tier 構成の手順の「ノード障害時のフェールオーバー」を参照)。

フェールオーバー後

(3) DOC-HV2 を起動すると、停止中に書き込まれたデータを DOC-HV2 のディスクに同期する修復(Repair・Regeneration)のジョブが自動で実行されます。この検証では、DOC-HV2 の起動(SSH の応答)から約 4 分で、2 つの仮想ディスクとも Healthy/OK に戻りました。

時刻状態
13:56:27DOC-HV2 の電源を切る
約 1 分後仮想ディスクが Warning(Degraded)、修復ジョブは Suspended。CSV は Online
315 秒後仮想マシンが DOC-HV1 で再起動し、ping が戻る
14:02:58DOC-HV2 が起動
約 4 分後修復ジョブが完了し、仮想ディスクが Healthy/OK に戻る

修復中にもう 1 台のノードを停止すると、データのコピーが 1 つだけになる時間ができます(3 方向ミラーは 2 台の故障まで耐えますが、修復が終わるまでは余裕が減ります)。メンテナンスでノードを止めるときは、Get-StorageJob と Get-VirtualDisk で修復が終わり、すべて Healthy になってから次のノードを止めます。

次の手順

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

目次