Hyper-V ホスト 3 台のローカル ディスクを、記憶域スペース ダイレクト（Storage Spaces Direct、S2D）で 1 つの共有ストレージにまとめ、ハイパーコンバージド（HCI）構成のクラスタを作る手順です。外部ストレージは使いません。ストレージの通信は、2 本の物理 NIC に 1 本ずつ割り当てた 2 本の仮想 NIC（SMB マルチチャネル）で冗長化します。
この記事の前提
参照した公式ドキュメント
- Deploy Storage Spaces Direct on Windows Server（Microsoft Learn）
- Storage Spaces Direct hardware requirements（Microsoft Learn）
- Set-VMNetworkAdapterTeamMapping（Microsoft Learn）
構成
| 項目 | 内容 |
|---|---|
| ノード | DOC-HV1／DOC-HV2／DOC-HV3（Windows Server 2025 Datacenter。S2D は Datacenter エディションの機能です） |
| S2D に使うディスク | 各ノードのローカル ディスク 4 本（40 GB、SATA、SSD）。合計 12 本、480 GB |
| クラスタ名 | HVDOC-S2D（192.168.1.128） |
| 監視 | ファイル共有監視（DOC-DC の \\DOC-DC\S2DWitness） |
| ストレージの通信 | SET スイッチ上の仮想 NIC「SMB」（10.20.83.0/24、物理 NIC SET1）と「SMB2」（10.20.84.0/24、物理 NIC SET2） |
この検証では、3Tier 構成で使った 3 台のホストをそのまま使いました。S2D のクラスタには、iSCSI などの外部の共有ストレージを混在させません。3Tier のクラスタを解除し、iSCSI の接続を削除してから構築します（手順は下の「3Tier 構成からの切り替え」）。新しいホストで構築する場合は、インストール手順とネットワーク設定手順の後、「ディスクの確認」から進めてください。
3Tier 構成からの切り替え
(1) 3Tier のクラスタの仮想マシンを停止し、クラスタを解除します。仮想マシンのファイルは iSCSI の LUN に残ります。必要な仮想ディスクは、解除の前にコピーしておきます。
Stop-ClusterGroup rocky-hv01
Copy-Item 'C:\ClusterStorage\Volume1\rocky-hv01\Virtual Hard Disks\rocky-hv01.vhdx' C:\VMKeep\
Remove-ClusterGroup rocky-hv01 -RemoveResources -Force
Remove-Cluster -Force -CleanupAD(2) 各ノードで、iSCSI の接続を削除します。[Favorite Targets]（永続的なターゲット）に登録した接続は、Disconnect-IscsiTarget で切断しても再起動で再接続されるので、iscsicli で削除してから再起動します。
iscsicli ListPersistentTargets
iscsicli RemovePersistentTarget ROOT\ISCSIPRT\0000_0 iqn.2026-10.local.lab:hyperv-lun 2 10.20.81.10 3260
iscsicli RemovePersistentTarget ROOT\ISCSIPRT\0000_0 iqn.2026-10.local.lab:hyperv-lun 3 10.20.82.10 3260
Get-IscsiTargetPortal | Remove-IscsiTargetPortal -Confirm:$false
Restart-ComputerRemovePersistentTarget の引数（Initiator Name・Target Name・Port Number・アドレス・ポート）は、ListPersistentTargets の表示のとおりに指定します。iSCSI イニシエーターの [Favorite Targets] タブで [Remove] しても同じです。
ディスクの確認
S2D は、各ノードのローカル ディスクのうち、パーティションのない空のディスクをプールに使います。各ノードで、使うディスクが [CanPool] = True になっていることを確認します。
Get-PhysicalDisk | Sort-Object DeviceId | Format-Table DeviceId,SerialNumber,UniqueId,BusType,MediaType,CanPool,Size| 確認すること | この検証環境の値 |
|---|---|
| BusType | SATA（S2D は SATA・SAS・NVMe に対応。iSCSI・FC・USB などは使えません） |
| MediaType | SSD（キャッシュ用のディスクはなく、すべてを容量用に使う構成です） |
| ディスクの本数 | 各ノード 4 本（SSD だけの構成で 2 本にしたところ、クラスタの検証で「at least 4 SSD disks are required」の警告が出たため） |
| SerialNumber・UniqueId | クラスタ全体で重複しないこと |
使い回しのディスクにパーティションやプールの情報が残っている場合は、[CanPool] が False になります。公式ドキュメントの「Clean drives」の手順で初期化してから使います（ディスクの中身はすべて消えます）。
入れ子の仮想化の検証環境では、仮想ディスクのシリアル番号や UniqueId が全ノードで同じになることがあります（この検証の Proxmox VE の SATA ディスクでは、シリアルが全ノードで「QM00007」などになり、UniqueId はすべて「ATAQEMU HARDDISK」でした）。仮想ディスクの設定でシリアル番号と WWN を個別に付けてから構築しました。また、最初は各ノード 2 本で構成し、クラスタの検証で「For this system configuration at least 4 SSD disks are required」の警告が出たため、4 本に増やしました。
ストレージ ネットワークの冗長化
S2D は、ノード間のディスクの読み書きを SMB（SMB Direct／SMB マルチチャネル）で行います。ネットワーク設定手順で作った SET スイッチに、ストレージ用の仮想 NIC を 2 本用意し、それぞれを別の物理 NIC に割り当てます。SMB マルチチャネルが 2 本を同時に使い、どちらかの物理 NIC が故障しても、もう 1 本で通信が続きます。
(1) 各ノードで、2 本目のストレージ用の仮想 NIC（SMB2）を追加し、IP アドレスを設定します（DOC-HV1 の例。SMB は作成済み）。
Add-VMNetworkAdapter -ManagementOS -SwitchName SETswitch -Name SMB2
New-NetIPAddress -InterfaceAlias 'vEthernet (SMB2)' -IPAddress 10.20.84.123 -PrefixLength 24
Set-DnsClient -InterfaceAlias 'vEthernet (SMB2)' -RegisterThisConnectionsAddress $false(2) 仮想 NIC と物理 NIC を 1 対 1 で対応付けます。対応付けをしないと、SET が 2 本の仮想 NIC を同じ物理 NIC に載せることがあります。
Set-VMNetworkAdapterTeamMapping -ManagementOS -VMNetworkAdapterName SMB -PhysicalNetAdapterName SET1
Set-VMNetworkAdapterTeamMapping -ManagementOS -VMNetworkAdapterName SMB2 -PhysicalNetAdapterName SET2
Get-VMNetworkAdapterTeamMapping -ManagementOS| 仮想 NIC | サブネット | 物理 NIC |
|---|---|---|
| SMB | 10.20.83.0/24 | SET1 |
| SMB2 | 10.20.84.0/24 | SET2 |
| LM（ライブ マイグレーション） | 10.20.85.0/24 | SET が自動で割り当て |
実機では、RDMA（RoCE v2 または iWARP）に対応した NIC を使い、SMB Direct で通信するのが推奨です。RoCE の場合はスイッチと各ノードで DCB（PFC・ETS）の設定も必要です。この検証環境の NIC は RDMA に対応していないため、TCP の SMB で動作を確認しました。
S2D 向けのクラスタの検証
S2D のクラスタでは、Storage Spaces Direct のテストを含めて検証します。作業は、ドメインの管理者（HVDOC\Administrator）でサインインしたノードで行います。
ローカルの Administrator でサインインしていると、Storage Spaces Direct のテストが WinRM の Kerberos 認証のエラー（0x8009030e「A specified logon session does not exist」）で失敗します。この検証でも最初はローカルの Administrator で実行してしまい、テストが [Failed] になりました。サインインの画面で [Other user] を選び、「HVDOC\Administrator」でサインインし直すと成功しました。
(1) フェールオーバー クラスター マネージャーの [Validate Configuration] で、3 台のノードを追加して [Next] をクリックします。
(2) [Run only tests I select] を選んで [Next] をクリックします。
(3) [Inventory]・[Network]・[Storage Spaces Direct]・[System Configuration] をオンにし、[Hyper-V Configuration] と [Storage] をオフにして [Next] をクリックします。公式ドキュメントの検証コマンドと同じ組み合わせです（[Storage] は SAN などの共有ディスク用のテストです）。
(4) 確認画面で [Next] をクリックすると、検証が始まります。この環境では約 10 分かかりました。
(5) 結果が表示されます。この検証環境では警告のみで、Storage Spaces Direct のテストはすべて成功しました（「Minimum disk requirements are met on all nodes.」）。警告は、SET の NIC の判定不能（クラスタの作成手順と同じ理由）と、更新プログラムの差でした。
PowerShell で検証する場合は、次のコマンドです。
Test-Cluster -Node DOC-HV1,DOC-HV2,DOC-HV3 -Include "Storage Spaces Direct","Inventory","Network","System Configuration"クラスタの作成（ストレージなし）
(1) [Create Cluster] で 3 台のノードを追加して [Next] をクリックします。
(2) クラスタの名前（HVDOC-S2D）と IP アドレス（192.168.1.128）を入力して [Next] をクリックします。[Address] は最後の数字だけを入力する形式なので、入力後に表示を確認します。
(3) 確認画面で [Add all eligible storage to the cluster] をオフにして [Next] をクリックします。S2D のディスクは、クラスタのディスクとしてではなく、次の手順で S2D のプールに入れます。
(4) クラスタが作成されます。[Summary] を確認して [Finish] をクリックします。共有ディスクがないので、この時点ではクォーラムの監視はありません。
PowerShell で作成する場合は、次のコマンドです。
New-Cluster -Name HVDOC-S2D -Node DOC-HV1,DOC-HV2,DOC-HV3 -StaticAddress 192.168.1.128 -NoStorageクォーラムの監視（ファイル共有監視）
S2D のクラスタには共有ディスクがないので、監視にはファイル共有かクラウド（Azure のストレージ アカウント）を使います。ここでは、ドメイン コントローラー（DOC-DC）の共有フォルダーを使いました。
(1) DOC-DC で共有フォルダーを作り、クラスタのコンピューター アカウント（HVDOC-S2D$）にフル コントロールを与えます。
New-Item -ItemType Directory C:\S2DWitness
New-SmbShare -Name S2DWitness -Path C:\S2DWitness -FullAccess 'HVDOC\Domain Admins','HVDOC\HVDOC-S2D$'
$acl = Get-Acl C:\S2DWitness
$acl.AddAccessRule((New-Object System.Security.AccessControl.FileSystemAccessRule('HVDOC\HVDOC-S2D$','FullControl','ContainerInherit,ObjectInherit','None','Allow')))
Set-Acl C:\S2DWitness $acl監視の共有は、クラスタのノード以外のサーバーに置きます。本番では、ドメイン コントローラーではなく、別のファイル サーバーに置くのが一般的です。
(2) フェールオーバー クラスター マネージャーで、クラスタを右クリックして [More Actions] → [Configure Cluster Quorum Settings] をクリックします。ウィザードの最初のページで [Next] をクリックします。
(3) [Select the quorum witness] を選んで [Next] をクリックします。
(4) [Configure a file share witness] を選んで [Next] をクリックします。
(5) [File Share Path] に \\DOC-DC\S2DWitness を入力して [Next] をクリックします。
(6) 確認画面で [Next] をクリックします。
(7) [Witness Type] が [File Share Witness] になったことを確認して [Finish] をクリックします。
(8) クラスタの概要の [Witness] が、ファイル共有監視（\\DOC-DC\S2DWitness）になります。
PowerShell で設定する場合は、次のコマンドです。
Set-ClusterQuorum -Cluster HVDOC-S2D -FileShareWitness \\DOC-DC\S2DWitnessS2D の有効化
S2D の有効化は PowerShell で行います（Windows Admin Center でもできます）。クラスタのノードの 1 台で、次のコマンドを実行します。
Enable-ClusterStorageSpacesDirect -CimSession HVDOC-S2D12 本のディスクがプール「S2D on HVDOC-S2D」にまとめられます。この環境では約 3 分 20 秒で完了しました。すべてのディスクが SSD なので、キャッシュ用のディスクはありません（実行ログに「No disks found to be used for cache」と表示されます）。
(1) フェールオーバー クラスター マネージャーのツリーで [Storage] → [Pools] を開くと、プール（Cluster Pool 1）が表示されます。下の [Summary] で、物理ディスクの数・空き容量・正常性を確認します。
| 項目 | この環境の値 |
|---|---|
| Pool Name | S2D on HVDOC-S2D |
| Physical Disk Number(s) | 12 本（各ノード 4 本） |
| Health Status／Operational Status | Healthy／OK |
| 容量 | 468 GB（ボリュームの作成後の空きは 150 GB） |
ボリュームの作成
(1) プールにボリュームを作ります。CSVFS_ReFS を指定すると、CSV として全ノードの C:\ClusterStorage\Volume01 にマウントされます。3 ノード以上のクラスタでは、回復性は既定で 3 方向ミラー（データを 3 つのノードに 1 つずつ持ち、2 台の故障まで耐える）になります。
New-Volume -CimSession HVDOC-S2D -FriendlyName Volume01 -FileSystem CSVFS_ReFS -StoragePoolFriendlyName 'S2D on HVDOC-S2D' -Size 80GB
Get-VirtualDisk -CimSession HVDOC-S2D | Format-Table FriendlyName,ResiliencySettingName,NumberOfDataCopies,PhysicalDiskRedundancy,HealthStatus,Size,FootprintOnPool| ボリューム | 回復性 | データのコピー数 | 耐えられる故障 | サイズ | プール上の使用量 |
|---|---|---|---|---|---|
| Volume01 | Mirror | 3 | 2 | 80 GB | 242 GB |
| ClusterPerformanceHistory | Mirror | 3 | 2 | 24 GB | 74 GB |
3 方向ミラーでは、ボリュームの約 3 倍の容量をプールで使います。また、ディスクが故障したときにデータを作り直せるよう、プールには「各サーバーの容量ドライブ 1 本分（最大 4 本分）」の空きを残すのが推奨です（Plan volumes（Microsoft Learn） の「Reserve capacity」）。この環境では 40 GB × 3 = 120 GB です。最初に 100 GB で作ったところ空きが 90 GB になったため、80 GB で作り直しました（空き 150 GB）。ClusterPerformanceHistory は、S2D を有効にすると自動で作られる性能履歴用のボリュームです。
(2) ツリーの [Storage] → [Disks] を開くと、Volume01 が [Cluster Shared Volume] として表示されます。
クラスタ ネットワークの設定
3Tier 構成と同じように、クラスタ ネットワークに用途がわかる名前を付け、ライブ マイグレーションに使うネットワークを指定します。使わない iSCSI のネットワークは、クラスタの通信に使わない設定（Role = None）にしました。
$map = @{ '192.168.1.0'='Management'; '10.20.81.0'='iSCSI-A'; '10.20.82.0'='iSCSI-B'; '10.20.83.0'='SMB'; '10.20.84.0'='SMB2'; '10.20.85.0'='LiveMigration' }
foreach ($n in Get-ClusterNetwork -Cluster HVDOC-S2D) { $n.Name = $map[$n.Address] }
foreach ($n in 'iSCSI-A','iSCSI-B') { (Get-ClusterNetwork -Cluster HVDOC-S2D -Name $n).Role = 0 }ライブ マイグレーションに使うネットワークは、LiveMigration → SMB → SMB2 の優先順にし、Management と iSCSI を除外しました。ここでは PowerShell で設定しました（[Networks] の [Live Migration Settings] で設定しても同じです。画面はクラスタの作成手順を参照）。
$vm = Get-ClusterResourceType -Cluster HVDOC-S2D -Name 'Virtual Machine'
$ids = @{}; Get-ClusterNetwork -Cluster HVDOC-S2D | ForEach-Object { $ids[$_.Name] = $_.Id }
$vm | Set-ClusterParameter -Name MigrationExcludeNetworks -Value (($ids['Management'],$ids['iSCSI-A'],$ids['iSCSI-B']) -join ';')
$vm | Set-ClusterParameter -Name MigrationNetworkOrder -Value (($ids['LiveMigration'],$ids['SMB'],$ids['SMB2'],$ids['Management'],$ids['iSCSI-A'],$ids['iSCSI-B']) -join ';')S2D のノード間の通信は、SMB マルチチャネルの接続で確認できます。
Get-SmbMultichannelConnection -SmbInstance SBLこの検証環境では、SMB（10.20.83.x）と SMB2（10.20.84.x）の両方に接続が張られていました。あわせて、LiveMigration（10.20.85.x）と管理用（192.168.1.x）の NIC からの接続も表示されました。SMB マルチチャネルが、通信できる NIC を自動で選んで使うためです。
