SANストレージを備えたWindows Server HCIの構築とS2D/SANにおけるストレージライブマイグレーションのIOを確認してみる

本記事について

本記事ではWindows ServerフェールオーバークラスターにおけるS2D + SANのストレージ構成を検証した結果をまとめます。
S2D + SANの構成は2025年12月に正式サポートされました。
実際有効に使えるユースケースがあるのか？という疑問はありますが技術的な興味で試していきます。

後半は若干自己満足な内容ではありますが、ストレージライブマイグレーションをいくつかのパターンで試してS2DとSANのIO処理の違いを見ていますので興味がある方はそちらもご覧ください。

なお、Azure Localでも同様にS2D + SANの構成が2026年4月リリースの2604バージョンからサポートされていますが、サポートの条件はより厳しく、この記事ではWindows Server 2025の構成について説明・検証しています。

参考情報

• Micrsoftのアナウンス記事
  Announcing Support for S2D and SAN Coexistence
• Hitachi Vantaraの検証記事
  Hitachi Vantara | WSFC 2025 (Hyper-V) — Blended Storage Coexistence (S2D + Hitachi VSP One Block SAN)
• フェールオーバークラスターのストレージアーキテクチャ解説記事
  MS Learn | フェールオーバークラスタリングストレージアーキテクチャ
• 参考：Azure Localの外部SANストレージ併用解説記事
  MS Learn | 外部ストレージ (SAN)の接続

Windows ServerフェールオーバークラスターのHCIと3-Tier

まず、Windows Serverにおけるフェールオーバークラスターではハイパーコンバージド構成 (HCI)と3-Tier構成いずれもサポートされています。
HCI構成はWindows Server 2016からサポートされた比較的新しい構成で、後述のS2Dによる高速なストレージインフラとHCIゆえの管理の利便性に優れています。
一方で、3-Tier構成はコンピュティング用のサーバとデータ用のストレージを分ける従来からの構成で、S2Dの限界である16ノードを超えて最大64ノードまでの大規模クラスターが組めたり、構成によってはHCIより安価に組めたりと、今でも十分に使われている構成です。

ストレージアーキテクチャ

HCIと3-Tier構成の大きな違いの1つはストレージのアーキテクチャです。
ストレージアーキテクチャの比較は参考情報に記載したMS Learnのフェールオーバークラスタリングアーキテクチャに詳しい解説がありますのでぜひそちらを参照いただきたく、HCIはMS Learnで"Hyperconverged"、3-Tierは"SANまたはNASストレージ"で示される構成です。

Hyperconvergedではローカルディスクのみを利用し、すべてのクラスターノードに搭載されたローカルディスクで1つのストレージプールを構成し、そこをクラスター共有ボリュームとして利用します。
ノード間でのディスク書き込みを高速化するために、一般的にRDMA対応の高速なネットワークアダプターを搭載します。
クラスター共有ボリュームは2ノードクラスターであれば2-way mirror、3ノード以上であれば3-way mirrorで冗長化するのが一般的です。
ディスクを拡張したい場合はノードのディスクスロットに空きがあればディスクを追加（この場合はすべてのノードに追加必須）、もしくはノード自体の追加をおこないます。

SANまたはNASストレージの構成ではNASストレージやSANを利用し、クラスターの外にクラスター共有ボリュームを持ちます。
文字通りNASストレージやSANを利用することができ、ファイバーチャネルやiSCSIで接続できます（Azure Localの場合はファイバーチャネルのみサポート）。
ストレージがクラスターから独立していることで、コンピューティングとストレージどちらも個別にスケーリングでき、またストレージ製品の高度なディスク圧縮技術や冗長化技術の恩恵を受けることができるのがメリットです。
一方で、外部ストレージやストレージを接続するためのファイバーチャネルスイッチなど、複数の機器の管理が必要になります。
場合によっては複数ベンダーの機器で構成することもあるためトラブル時の切り分け等、運用の負荷も上がります。

S2D + SANストレージ構成

今回検証するS2D + SANの構成ではS2Dの高速なストレージをベースとして利用しつつ、追加で拡張性に優れるSANストレージを持つことができます。
これにより、既存のストレージを活用してHCIクラスターを拡張でき、ワークロードの特性に応じてS2DとSANを使い分け効率的な構成を組むことができます。
そして、このS2DとSANの使い分けは状況に応じて変更できる、つまりストレージライブマイグレーションによりいつでも切り替えることができます。

一方で冒頭述べたようにどの程度この構成の需要があるのかは未知数だと思っています。
一つ現実的にありそうなユースケースとしてはディスク容量が不足してきたS2Dクラスターでノード追加せずにディスクのみを大規模に拡張できるといったケースでしょうか。CPU/メモリに対してディスクを大量に利用したい基盤で可能性があるかもしれません。
なにかこういうケースで嬉しい！という用途があればぜひコメントいただけると嬉しいです。

検証構成の概要・前提条件

今回の構成は3ノードのクラスターに2本ずつのディスクを持たせてS2Dを構成しており、外部ストレージにはWindows Server 2025をiSCSIターゲットとして設定して接続する構成としています。
すべて仮想マシンで構成している環境のためパフォーマンスのテストはできませんが、こちらの環境で構築手順とストレージライブマイグレーションの様子を見ています。
なお、iSCSI用のNICは本来であれば2つ用意してマルチパスIOで冗長化すべきですが今回は構成の検証のためシングル構成としています。

この構成における主な前提条件は以下のとおりです。

• OSはWindows Server 2022 or 2025を利用する
• S2D上のボリュームはReFSでフォーマットする
• SAN上のボリュームはNTFSでフォーマットする

構築手順

構築順序はまずS2Dクラスターを構築して、後からSANをセットアップするという流れになります。
実際の検証時の画面を見ながら説明していきます。

1. S2Dクラスターの構築

通常通りWindows ServerにHyper-Vの設定をおこない、以下のコマンドでクラスターを構築し、S2Dの有効化、S2D上のCSV作成と一通りクラスターの構築を完了します（本記事では細かい設定は省略）。
今回この時点ではiSCSI用のNICの設定はまだおこなっていません。

# クラスターの構築
New-Cluster -Name <Cluster Name> -Node <Node 1>,<Node 2>,<Node 3> -StaticAddress <Cluster IP> -NoStorage

# S2D有効化
Enable-ClusterStorageSpacesDirect -PoolFriendlyName "S2D on <Cluster Name>"

# S2D上のCSV作成 (3ノードのため3つ作成するのが推奨だが、ここでは省略して1つのみ作成)
## CSV名: Volume1, Size: 200GBで設定
New-Volume -FriendlyName "Volume1" -FileSystem CSVFS_ReFS -StoragePoolFriendlyName "S2D on <Cluster Name>" -Size 200GB

以下のようにStorage PoolとCSVが作成できました。
今回3ノードクラスターですので3-way mirrorで作成されていることが仮想ディスクのFootprintOnPoolから確認できます。

2. SANのセットアップ

次にSAN用のiSCSIターゲットの準備とクラスターノードでのiSCSIイニシエーターの設定、CSVの作成をおこなっていきます。

iSCSIターゲットの設定

今回Windows Server 2025の仮想マシンでローカルディスクをiSCSIターゲットとして設定していきます。

まずはiSCSIターゲットサーバーの役割をインストールしておきます。
続いてディスクをオンラインにしてボリュームを作成します。ここではFドライブに256GBのボリュームを作成しました。

次にiSCSI仮想ディスクを作成します。sandisk1という名前で256GBのvhdx (容量可変)で作成しています。
同じウィザード内でiSCSIターゲットの設定もおこないます。ターゲット名をtarget1と設定し、アクセスを許可するイニシエーターをIPアドレスで指定します (クラスターノードの3つのIPを指定)。今回は認証設定は省略しています。

iSCSIイニシエーターの設定

ターゲットの準備ができたらクラスターノードをiSCSIイニシエーターとして設定し、iSCSIの接続をおこないます。
接続はGUIからもできますが今回はPowerShellでの設定手順を紹介します。

まずはiSCSIのサービスを起動し、自動起動を有効化しておきます。

# 自動起動を有効化
Set-Service -Name MSiSCSI -StartupType Automatic

# 起動
Start-Service -Name MSiSCSI

# ステータス確認 (自動起動と現在の状態を確認)
Get-Service -Name MSiSCSI | select *

次にiSCSIターゲットサーバのIPアドレスを指定してiSCSIターゲットポータルを設定します。
この時点ではまだ接続はされていません。

# iSCSIターゲットポータルの設定
New-IscsiTargetPortal -TargetPortalAddress <iSCSIターゲットのIP>

# iSCSIターゲットポータルの確認
Get-IscsiTargetPortal

# iSCSIターゲットとの接続ステータス確認
Get-IscsiTarget
Get-IscsiConnection

最後にiSCSIの接続を確立します。
"IsPersistent"オプションを"$true"に指定することでサーバの再起動後も接続を維持してくれます。

# iSCSIターゲットとの接続を確立
$target = Get-IscsiTarget
Connect-IscsiTarget -NodeAddress $target.NodeAddress -IsPersistent $true

# iSCSIターゲットとの接続を確認
Get-IscsiTarget
Get-IscsiConnection

今回iSCSI用の通信は1枚のNICでおこなっていますが、複数NICで冗長化する場合はマルチパスIOの機能をクラスターノードにインストールして有効化します。

Install-WindowsFeature Multipath-IO

また、iSCSI用のNICはiSCSIの通信専用にするため、クラスターネットワークから除外しておきます。
デフォルトではクラスター用の設定になっており、これをおこなわないとS2D内のデータ同期の通信等でも利用されてしまいます。

# iSCSI用のNICが含まれるクラスターネットワークを特定
Get-ClusterNetworkInterface

# iSCSI用NICを含むクラスターネットワークのRoleを0 (クラスターネットワークに含めないよう)に設定
## Role: 0=None, 1=Cluster, 2=ClusterAndClient
(Get-ClusterNetwork -Name "<当該クラスターネットワーク名>").Role = 0

CSVの作成

すべてのノードでiSCSIの接続を確立したら、すべてのノードでiSCSIディスクをオンラインに変更します。

その後、1つのノードでiSCSIディスク上にボリュームを作成していきます。
このとき必ずファイルシステムはNTFSを選択します。

最後に上記のボリュームをクラスターディスク、CSVに追加しクラスターで利用可能にします。

# クラスターディスクに追加できる状態であることを確認
Get-ClusterAvailableDisk

# クラスターディスクに追加
Get-ClusterAvailableDisk | Add-ClusterDisk

# クラスターディスクを確認 (日本語OSの場合は使用可能記憶域グループのリソースとして表示される)
Get-ClusterResource

# CSVに追加
Get-ClusterResource -Name "<クラスターディスク名>" | Add-ClusterSharedVolume

# CSVに追加されたことを確認
Get-ClusterSharedVolume

3. クラスターの検証

最後に正しく構成できているかどうかをクラスターの検証機能で確認していきます。
SAN側のチェックをおこなうには先程作成したiSCSIディスクのCSVをオフラインにしておく必要があります。

CSVをオフラインにした後、コマンドやフェールオーバークラスターマネージャーでクラスターの検証を実行します。
検証結果で"Storage (記憶域)"や"Storage Spaces Direct (記憶域スペース ダイレクト)"の検証にパスしていればOKです。
※S2Dの方で警告が出ていますが検証環境の問題で無視可能なものでした。

日本語OSを利用している場合はTest-Clusterで指定する検証カテゴリ名も日本語で指定する必要があります。
Storageは"記憶域"ですが、Storage Spaces Directは"記憶域スペース ダイレクト"と、「記憶域スペース」と「ダイレクト」の間に半角スペースが入りますので注意。

ストレージライブマイグレーション

VMのディスクリソースをストレージライブマイグレーションでS2D上のCSVからSAN上のCSV、またその逆に移動をおこなってVMの切断が発生しないかを確認しました。
私の環境ではpingの欠けもおきずにマイグレーションできることが確認できました。

# PowerShellでおこなう際のコマンド、実行状況が%表示されて成功すると特にメッセージは表示されない
Move-VMStorage -ComputerName <VMの実行ノード> -Name <VM名> -DestinationStoragePath <移行先のCSV> -Verbose

最後にS2DとSANのディスクIOに注目し、いくつかのパターンで移動をおこなった際のネットワークアダプターのトラフィックを確認しました。
移動対象のVMの所有者ノード、S2D上のCSV、SAN上のCSVの所有者ノード、これらの違いによってどこで通信が発生しているのかを確認し、S2DとSANのディスクIO制御の違いを見ていきます。

先に仕様の要点を説明しますとSAN上のCSV (NTFS)はVMの所有者ノードが直接IOをおこない、S2D上のCSV (ReFS)はCSVのOwnerノードがIOを仲介する挙動を取ります。
これはGet-ClusterSharedVolumeStateコマンドで確認することができます。Volume1がS2D、Volume2がSANです。

仕様の詳細はこちらのドキュメントを参照ください。
MS Learn | クラスター共有ボリュームの概要

今回確認したパターンは以下の8パターンです。

パターン	VMの所有者	S2D CSVの所有者	SAN CSVの所有者	移動方向
1	Node 1	Node 1	Node 1	S2D→SAN
2	Node 1	Node 1	Node 1	SAN→S2D
3	Node 1	Node 2	Node 1	S2D→SAN
4	Node 1	Node 2	Node 1	SAN→S2D
5	Node 1	Node 1	Node 2	S2D→SAN
6	Node 1	Node 1	Node 2	SAN→S2D
7	Node 1	Node 2	Node 3	S2D→SAN
8	Node 1	Node 2	Node 3	SAN→S2D

パターン1: VM, S2D, SANすべて同じ所有者 (S2D→SAN)

ノード	所有リソース
Node 1	VM, S2D, SAN
Node 2
Node 3

移行中のトラフィックをパフォーマンスモニターで集計した結果です。

• Node 1のトラフィック
  

• Node 2のトラフィック
  

• Node 3のトラフィック
  

トラフィック増とその理由は以下のように考察できます。

• Node 1のSAN通信用のNICの送信トラフィックが高くなる：SANへの書き込み通信はVMの所有者ノードが直接担当するため
• 上記以外の送信・受信トラフィックに大きな変動がない：S2Dからの読み込みはS2Dの所有者ノードが直接担当するため

パターン2: VM, S2D, SANすべて同じ所有者 (SAN→S2D)

ノード	所有リソース
Node 1	VM, S2D, SAN
Node 2
Node 3

移行中のトラフィックをパフォーマンスモニターで集計した結果です。

• Node 1のトラフィック
  

• Node 2のトラフィック
  

• Node 3のトラフィック
  

トラフィック増とその理由は以下のように考察できます。
SAN用のNICを除く3つのノードがクラスターネットワークで利用されており、SMBマルチチャネルによって分散して使われているようです。

• Node 1のSAN通信用のNICの受信トラフィックが高くなる：SANからの読み込み通信はVMの所有者ノードが直接担当するため
• Node 1のクラスターネットワークのNICの送信トラフィックが高くなる：S2D側の所有者ノードとして、書き込みとレプリケーションを送信しているため
• Node 2のクラスターネットワークのNICの受信トラフィックが高くなる：S2D側の所有者ノードからの書き込みデータを受信しているため
• Node 3のクラスターネットワークのNICの受信トラフィックが高くなる：S2D側の所有者ノードからの書き込みデータを受信しているため

パターン3: VM, SANは同一所有者、S2Dのみ別所有者 (S2D→SAN)

ノード	所有リソース
Node 1	VM, SAN
Node 2	S2D
Node 3

移行中のトラフィックをパフォーマンスモニターで集計した結果です。

• Node 1のトラフィック
  

• Node 2のトラフィック
  

• Node 3のトラフィック
  

トラフィック増とその理由は以下のように考察できます。

• Node 1のSAN通信用のNICの送信トラフィックが高くなる：SANへの書き込み通信はVMの所有者ノードが直接担当するため
• Node 1のクラスターネットワークのNICの受信トラフィックが高くなる：S2D側の所有者ノードからの読み込みデータを受信しているため
• Node 2のクラスターネットワークのNICの送信トラフィックが高くなる：S2D側の所有者ノードからの読み込みデータをVMの所有者ノードに送信しているため

パターン4: VM, SANは同一所有者、S2Dのみ別所有者 (SAN→S2D)

ノード	所有リソース
Node 1	VM, SAN
Node 2	S2D
Node 3

移行中のトラフィックをパフォーマンスモニターで集計した結果です。

• Node 1のトラフィック
  

• Node 2のトラフィック
  

• Node 3のトラフィック
  

トラフィック増とその理由は以下のように考察できます。

• Node 1のSAN通信用のNICの受信トラフィックが高くなる：SANからの読み込み通信はVMの所有者ノードが直接担当するため
• Node 1のクラスターネットワークのNICの送信トラフィックが高くなる：S2D側の所有者ノードにSANから読み込んだデータを送信しているため
• Node 1のクラスターネットワークのNICの受信トラフィックが高くなる：S2D側の所有者ノードからの書き込みデータを受信しているため
• Node 2のクラスターネットワークのNICの送信トラフィックが高くなる：S2D側の所有者ノードを経由した書き込みとレプリケーションを送信しているため
• Node 2のクラスターネットワークのNICの受信トラフィックが高くなる：SANから読み込んだデータをVMの所有者ノードから受信しているため
• Node 3のクラスターネットワークのNICの受信トラフィックが高くなる：S2D側の所有者ノードからの書き込みデータを受信しているため

パターン5: VM, S2Dは同一所有者、SANのみ別所有者 (S2D→SAN)

ノード	所有リソース
Node 1	VM, S2D
Node 2	SAN
Node 3

移行中のトラフィックをパフォーマンスモニターで集計した結果です。

• Node 1のトラフィック
  

• Node 2のトラフィック
  

• Node 3のトラフィック
  

トラフィック増とその理由は以下のように考察できます。

• Node 1のSAN通信用のNICの送信トラフィックが高くなる：SANへの書き込み通信はVMの所有者ノードが直接担当するため
• 上記以外の送信・受信トラフィックに大きな変動がない：S2Dからの読み込みはS2Dの所有者ノードが直接担当するため

パターン6: VM, S2Dは同一所有者、SANのみ別所有者 (SAN→S2D)

ノード	所有リソース
Node 1	VM, S2D
Node 2	SAN
Node 3

移行中のトラフィックをパフォーマンスモニターで集計した結果です。

• Node 1のトラフィック
  

• Node 2のトラフィック
  

• Node 3のトラフィック
  

トラフィック増とその理由は以下のように考察できます。

• Node 1のSAN通信用のNICの受信トラフィックが高くなる：SANからの読み込み通信はVMの所有者ノードが直接担当するため
• Node 1のクラスターネットワークのNICの送信トラフィックが高くなる：S2D側の所有者ノードとして、書き込みとレプリケーションを送信しているため
• Node 2のクラスターネットワークのNICの受信トラフィックが高くなる：S2D側の所有者ノードからの書き込みデータを受信しているため
• Node 3のクラスターネットワークのNICの受信トラフィックが高くなる：S2D側の所有者ノードからの書き込みデータを受信しているため

パターン7: VM, S2D, SANがそれぞれ別の所有者 (S2D→SAN)

ノード	所有リソース
Node 1	VM
Node 2	S2D
Node 3	SAN

移行中のトラフィックをパフォーマンスモニターで集計した結果です。

• Node 1のトラフィック
  

• Node 2のトラフィック
  

• Node 3のトラフィック
  

トラフィック増とその理由は以下のように考察できます。

• Node 1のSAN通信用のNICの送信トラフィックが高くなる：SANへの書き込み通信はVMの所有者ノードが直接担当するため
• Node 1のクラスターネットワークのNICの受信トラフィックが高くなる：S2D側の所有者ノードからの読み込みデータを受信しているため
• Node 2のクラスターネットワークのNICの送信トラフィックが高くなる：S2D側の所有者ノードからの読み込みデータをVMの所有者ノードに送信しているため

パターン8: VM, S2D, SANがそれぞれ別の所有者 (SAN→S2D)

ノード	所有リソース
Node 1	VM
Node 2	S2D
Node 3	SAN

移行中のトラフィックをパフォーマンスモニターで集計した結果です。

• Node 1のトラフィック
  

• Node 2のトラフィック
  

• Node 3のトラフィック
  

トラフィック増とその理由は以下のように考察できます。

• Node 1のSAN通信用のNICの受信トラフィックが高くなる：SANからの読み込み通信はVMの所有者ノードが直接担当するため
• Node 1のクラスターネットワークのNICの送信トラフィックが高くなる：S2D側の所有者ノードにSANから読み込んだデータを送信しているため
• Node 1のクラスターネットワークのNICの受信トラフィックが高くなる：S2D側の所有者ノードからの書き込みデータを受信しているため
• Node 2のクラスターネットワークのNICの送信トラフィックが高くなる：S2D側の所有者ノードを経由した書き込みとレプリケーションを送信しているため
• Node 2のクラスターネットワークのNICの受信トラフィックが高くなる：SANから読み込んだデータをVMの所有者ノードから受信しているため
• Node 3のクラスターネットワークのNICの受信トラフィックが高くなる：S2D側の所有者ノードからの書き込みデータを受信しているため

全パターンを試してみての考察

最初に記載の通りSAN側の読み書きはVMの実行ノードがおこない、S2D側の読み書きはS2D側のCSVの所有者ノードを介しておこなわれることがキレイに確認できました。
この結果から改めて見えてくるのはVMとそのディスクの移行元もしくは移行先となるS2D側のCSVは同一ノードが所有しておくとトラフィック量を抑えられるということですね。

また、S2Dのストレージ通信用のNIC2つと管理用兼サービス用のvNICがクラスターネットワークのライブマイグレーション用にSMBマルチチャネルで使われている様子が見えましたが、いずれのケースでも管理用兼サービス用のvNICの利用割合は小さくなっていました。
ライブマイグレーションで利用する際の優先順位は一番下にしていたのですが、1番目と2番目のストレージ用NICは同程度利用されているのに対し、管理用兼サービス用vNICの利用量は抑えられていたのは疑問でした。

まとめ

S2DとSANを併用したWindows Serverフェールオーバークラスターの構成を検証しました。
構築は特に詰まるところなくS2Dの構築、SANの接続と進めることができました。
S2DとSAN間でのストレージライブマイグレーションもVMの実行に影響なく動作していて、新しい構成とはいえ既存の技術の組み合わせで安心して使えることが確認できたかと思います。

また、ストレージライブマイグレーション中のトラフィックを見ることでS2DとSANのディスクIOの挙動の違いも感じることができました。
超ざっくりな確認方法でしたがキレイにIOのトラフィック量を可視化できて満足しています。
iSCSI対応で気軽に検証できますので興味のある方はぜひ一度お試しください。