Storage Spaces Direct(S2D)の性能と安定性は、ディスクよりもネットワーク設計で決まります。RDMAの protocol選択、SETによるコンバージド化、そしてRoCEなら避けて通れないDCB/PFC/ETS。現場で本当にハマるポイントを、Microsoft Learnの一次情報とともに整理します。
S2Dの構築案件で最初に時間を割くべきは、ディスク構成でも回復性でもなく、ネットワークです。S2Dはノード間で常時ストレージバストラフィック(SBL)とCSVリダイレクトが飛び交う分散ストレージであり、その東西トラフィックがボトルネックになれば、どれだけ速いNVMeを積んでも性能は出ません。Microsoft Learnも「S2Dはクラスタ内サーバー間で高帯域・低遅延ネットワークを必要とする」と明言しています。本稿では、私たちがWindows Server 2025 DatacenterでS2Dを実構築した経験を土台に、ネットワーク設計の勘所をまとめます。
01ストレージトラフィックは「別物」として扱う
S2Dのネットワークトラフィックは、大きく3種類に分けて考えます。Microsoft Learnの分類に沿うと以下のとおりです。
- 管理(Management)：Windows Admin Center、AD、RDPなど、クラスタ外との通信。
- コンピュート(Compute)：VMが送受信するトラフィック。
- ストレージ(Storage)：
SMBを使うトラフィック。S2DのSBL/CSV、およびSMBベースのライブマイグレーションがこれに該当します。これはL2トラフィックであり、ルーティングされません。
設計上いちばん大事なのは、ストレージトラフィックが「ルーティングされないL2トラフィック」だという点です。ここを見落として管理と同じサブネットに相乗りさせると、SMB Multichannelの接続が意図せぬ経路を張り、ToRスイッチ間のインターリンク(MC-LAG)を無駄に往復して輻輳します。
192.168.1.0/24 (VLAN1)、右ポートを192.168.2.0/24 (VLAN2)のように分け、各系統をそれぞれのToRに閉じ込めるのが定石です。02RDMAはなぜ必須級なのか
RDMA(Remote Direct Memory Access)は、ネットワークスタックをNICにオフロードし、SMBストレージトラフィックがOSの処理をバイパスできるようにする技術です。これにより高スループット・低遅延を、CPUをほとんど食わずに実現します。空いたCPUはそのままVMやコンテナの実行に回せます。
S2Dの公式デプロイ手順でも「少なくとも10-GbEが必要で、RDMAを推奨する」とされています。実運用では、これは「推奨」というより実質必須と捉えてよいでしょう。RDMAなしでCSVリダイレクトやSBLの帯域を捌こうとすると、CPUがネットワーク処理に持っていかれ、肝心のワークロードが痩せます。
RDMAを実際にストレージ層で使う仕組みがSMB Directです。Windows Server 2012以降、SMB Directは既定で有効化されており、RDMA対応NICを検出すると自動的に使い始めます。RDMA対応の検出とマルチパス化を担うのがSMB Multichannelで、これを無効化するとSMB Directも道連れで無効になる点は覚えておいてください。
03iWARPかRoCEか — 設計判断の分岐点
RDMAには2つのプロトコル実装があり、ここが最初の大きな設計判断になります。iWARPとRoCEは混在できません。RDMA NICは同じプロトコルを実装する相手としか通信できないため、クラスタ全体で片方に統一します。
- iWARP：TCPを使います。PFC/ETSは任意(オプション)で付加できますが、必須ではありません。ToRスイッチの特別な設定なしでも動きます。
- RoCE(RoCE v2)：UDPを使います。信頼性を確保するためにPFCとETSが必須です。つまりDCB(Data Center Bridging)の設計・実装が前提になります。
Microsoft Learnの指針は明快です。「RDMAネットワークの運用経験がない」「ToRスイッチの管理に自信がない」「iWARPの既存展開がある」「どちらか迷う」ならiWARP。「データセンターに既にRoCEの展開がある」「DCBのネットワーク要件を管理できる」ならRoCE、と整理されています。公式デプロイ手順でも「どちらも使えるが、iWARPの方がセットアップは簡単」と述べています。
04SET(Switch Embedded Teaming)でコンバージドにまとめる
物理NICポートを増やさずに全トラフィックを流すための要がSET(Switch Embedded Teaming)です。Windows Server 2016で導入された、Hyper-V仮想スイッチに統合されたチーミング技術で、RDMAを使いながら同じ物理NICポートを全トラフィックで共用できます。
S2DにおいてLBFO(従来のNICチーミング)は非サポートで、SETが唯一の選択肢です。SETでなければRDMA対応NICのチーミング、Dynamic VMMQといったS2Dの主要機能が使えません。SETは1チームあたり最大8アダプタまでサポートします。
SETには厳しい前提が1つあります。チーム内のアダプタは対称(identical)でなければなりません。make(ベンダー)・model(バージョン)・speed(スループット)・configurationがすべて一致している必要があります。インターフェース記述が末尾の番号だけ違う、という状態が理想です。異機種を混ぜると、そもそもチームが正しく機能しません。ドライバやファームウェアまで揃えるのが安全です。
New-VMSwitchでSETを手動作成するのではなく、Network ATCにintentで宣言させる方式が推奨です。素のWindows Server上のS2Dでも、設計思想としてこの「宣言的に組む」考え方は踏襲する価値があります。05RoCEを選んだなら — DCB/PFC/ETSの3つのトラフィッククラス
RoCEを選んだ時点で、DCB(Data Center Bridging)の設計からは逃げられません。UDPベースのRoCEは、パケットロスを許容できない「ロスレス」なファブリックを、ホスト側とスイッチ側の両方で作り込む必要があります。ここがRoCEの技術的な山場です。
Microsoft Learnによれば、RoCEベースの実装では既定クラスを含めて3つのPFCトラフィッククラスを、ファブリックと全ホストにわたって構成します。
- システム(ハートビート)クラス：PFCなし。優先度7を推奨。帯域予約は10GbE以下で2%、25GbE以上で1%。
- RDMAクラス：PFC有効(ここが肝)。優先度3または4を推奨。帯域予約は50%。SMB Directによるロスレス通信のためのクラスです。
- 既定クラス：PFCなし。優先度0。VMトラフィックや管理トラフィックなど、他のすべてを載せます。
PFC(Priority Flow Control, 802.1Qbb)は、指定した優先度のトラフィックだけをポーズさせてロスをなくす仕組みです。ETS(Enhanced Transmission Selection, 802.1Qaz)は、クラスごとの帯域配分を保証します。RoCEではこの両方が必須です。
06よくある詰まり — PFC設定漏れで「速いはずが遅い」
RoCE案件でいちばん多い相談が「25/100GbEを積んだのにストレージ性能が出ない」というものです。原因の大半は、DCB/PFCの設定が片側にしか入っていないことです。Microsoft Learnも「DCBを実装するなら、PFCとETSの構成をネットワークスイッチを含む全ネットワークポートにわたって正しく実装しなければならない」と釘を刺しています。
- ホスト側だけPFCを設定し、ToRスイッチ側が未設定：ロスレスが成立せず、輻輳時にRoCEパケットがドロップし、再送で性能が崩壊します。
- 優先度(PCP)のマッピングがホストとスイッチで不一致：PFCのポーズが効くべき優先度に効かず、実質ロスレスになりません。
- ノード追加時にスイッチポート設定を入れ忘れる：既存ノードは正常なのに、増設ノードだけ性能が出ない、という切り分けにくい症状になります。
Get-NetAdapterRdmaやGet-SmbClientNetworkInterfaceでRDMAが実際に使われているかを見ます。SMB Directの実測は、RDMAをDisable-NetAdapterRdmaで切った状態と有効な状態で大容量コピーを比較するのが確実です。iWARPならこのDCBハマりどころが丸ごと消えるため、運用体制次第ではiWARPが賢明という判断も十分あり得ます。07帯域配分とライブマイグレーションの綱引き
コンバージド構成では、SBL/CSV・ライブマイグレーション・管理が同じ物理NICを共有します。ここで効いてくるのが帯域配分です。Microsoft Learnの例では、SMBにDCBで50%を割り当て、そのうちSBL/CSVが70%(最優先)、ライブマイグレーションが残りの29%を取る、という配分が示されています。
25GbE・2ポートSET(合計50Gbps)なら、SMB予約25Gbps・SBL/CSV約17.5Gbps・ライブマイグレーション上限約7.25Gbps・ハートビート約250Mbps、という具合です。
ライブマイグレーションで見落としがちなのが、移行トラフィックがRDMAクラスの帯域を食い尽くさないよう上限を設けることです。Microsoft Learnは以下を推奨しています。
- ライブマイグレーションの利用可能帯域が5Gbps以上でNICが対応するなら、
Set-VMHost -VirtualMachineMigrationPerformanceOption SMBでRDMA(SMB)を使う。 - 5Gbps未満なら、
-VirtualMachineMigrationPerformanceOption Compressionで圧縮を使い、ブラックアウト時間を短縮する。 - RDMAを使う場合は
Set-SMBBandwidthLimit -Category LiveMigration -BytesPerSecond 750MBのように上限を設定する(この例で750MBps=6Gbps。バイト/秒指定なので単位に注意)。
ライブマイグレーション設計そのものの詳細はHyper-Vライブマイグレーションの設計で、それを支えるAD側の準備はクラスタ・ライブマイグレーションのためのAD構築で扱っています。
08物理設計 — 25/100GbEとジャンボフレーム
帯域は「最低10GbE」がS2Dの出発点ですが、実案件では25GbEを下限に、集約度の高いHCIやオールNVMeでは100GbEを検討します。SBL/CSVはノード台数に比例して東西トラフィックが増えるため、ノードを増やすほどストレージネットワークの帯域が効いてきます。
ジャンボフレーム(MTU 9000系)は、SMB Directの大容量転送でオーバーヘッドを下げるために有効です。ただしエンドツーエンドで一致させることが絶対条件で、NIC・ToRスイッチ・インターリンクのMTUが1か所でも食い違うと、フラグメントやブラックホール化を招きます。設定したら必ず実測サイズでのpingや疎通で確認します。
スイッチレス(ノード間直結)構成も選択肢です。小規模クラスタではToRスイッチのDCB設定という難所を回避でき、全ノードが相互に直接接続される前提を満たせば有効です。ただしノード数が増えると配線が現実的でなくなるため、2〜3ノードの範囲が実用的です。
このあたりのノード数・回復性・障害ドメインの設計はWindows Server 2025 DatacenterでのS2D設計、クォーラムとCSVの考え方はフェールオーバークラスタのクォーラムとCSVで掘り下げています。
09Azure Localとの棲み分け、そしてAWSへの橋渡し
ここまでの設定を手作業で積み上げるのが、素のWindows Server上のS2Dです。一方でAzure Local(旧Azure Stack HCI)では、これらネットワーク構成をNetwork ATCが宣言的に自動構成します。SETもvSwitchもDCBの3クラスも、intentで宣言すればATCが面倒を見る、という思想です。「自前でフルコントロールするWindows Server S2D」か「運用を標準化するAzure Local」か、要件と運用体制で棲み分けるのが妥当です。仕様はバージョンで動くため、最新はMicrosoft Learnで確認してください。
そして、このRDMA・SMB・SET・DCBの深い理解は、そのままAWS移行の武器になります。オンプレHyper-V/S2Dのストレージネットワークをどう束ね、どう分離してきたかを分かっているからこそ、EC2/EBSやFSxへの移行で「何を残し、何をマネージドに寄せるか」を的確に設計できます。私たちEMWは、オンプレの実構築とAWS移行の両方に手を動かしてきた立場から、この橋渡しを支援しています。関連してRAIDからEBSへやオンプレサーバーのEC2サイジングも参考になるはずです。
—まとめ
S2Dのネットワーク設計は、次の順で詰めると迷いません。まずストレージトラフィックをL2の別物として専用VLAN・専用サブネットに分離する。次にiWARPかRoCEかをNICと運用体制から決める。RoCEならDCB/PFC/ETSの3クラスをホストとスイッチの両側で厳密に一致させる。SETは対称なNICでコンバージドに束ね、帯域配分とライブマイグレーションの上限で綱引きを制御する。最後に25/100GbEとジャンボフレームをエンドツーエンドで揃える。「速いはずが遅い」の大半はPFCの片側設定漏れです。実測で「本当にRDMAが効いているか」を確かめる癖をつければ、S2Dは設計どおりの性能を返してくれます。実際の構成レビューや移行のご相談は導入事例もあわせてご覧ください。