ローカルディスクをプールしてSDSにするStorage Spaces Direct(S2D)。Windows Server 2025 Datacenterで組む際の構成設計を、ノード数・ディスク階層・フォールトドメイン・ネットワークの順に、現場でハマる勘所とともに整理します。Azure Local(旧Azure Stack HCI)との棲み分けも正確に押さえます。

Storage Spaces Direct(以下S2D)は、各サーバーの内蔵ディスクをEthernet経由でプール化し、共有ストレージ(SDS)として使うWindows Server / Azure Localの機能です。専用のSANファブリックもFibre Channelケーブルも要らず、業界標準サーバーだけでHCIやディスアグリゲート構成を組めます。本記事では、Windows Server 2025 Datacenterで実際にS2Dクラスターを設計するときの勘所を、アーキテクチャからネットワークまで順に押さえていきます。バージョン依存の値はMicrosoft Learnで最新をご確認ください。

01S2Dのアーキテクチャ — Software Storage Busが肝

S2Dは既存のWindows機能(Failover Clustering、Cluster Shared Volume(CSV)、SMB3、Storage Spaces)を土台にしつつ、Software Storage Busという新しい層を導入しています。これがクラスター全体をまたいで、各ノードのローカルディスクを「全ノードから見える」状態にする仕組みです。従来のFibre Channelや共有SASケーブルを、ソフトウェアで置き換えたものと考えると腹落ちします。

スタックを下から見ると、Software Storage Busの上にStorage Bus Layer(SBL)キャッシュが乗り、速いドライブ(SSD/NVMe)を遅いドライブ(HDD)に動的にバインドしてサーバーサイドの読み書きキャッシュを提供します。その上にストレージプール、Storage Spaces(ミラーやイレイジャーコーディングによる分散ソフトRAID)、ReFS、CSVが積み上がり、最終的にVMの.vhdxを置く仮想ディスクになります。

S2D ソフトウェアスタック Hyper-V VM(.vhdx をボリューム上に配置) Cluster Shared Volume(CSV)— 単一名前空間 ReFS — 仮想化向けファイルシステム Storage Spaces — ミラー / イレイジャーコーディング ストレージプール(1クラスター1プール推奨) SBLキャッシュ(速いドライブを遅いドライブに動的バインド) Software Storage Bus(全ノードが全ドライブを可視) ノード1 ローカルディスク ノード2 ローカルディスク ノードN ローカルディスク
図：S2Dのソフトウェアスタック。各ノードのローカルディスクがSoftware Storage Busで統合され、上位のプール・Spaces・CSVを経てVMのボリュームになります。

02対応ノード数と拡張 — 2から16、リニアに伸ばす

S2Dのクラスターは最小2ノード、最大16ノードです。容量を増やしたいときは、ドライブを足すか、サーバーを足すだけ。S2Dは新しいドライブを自動的にオンボードし、プールをリバランスします。スケールの上限は16ノード・400ドライブ超・1クラスターあたり最大4PB(=4,000TB)、1サーバーあたりの生容量はWindows Server 2019以降で400TBまでです。

現場のコツ：2ノードは組めますが、2ノードだと取り得るのは実質2wayミラーと、証人(Witness)によるクォーラム維持が前提になります。3ノード以上にすると3wayミラーが選べ、「1台落ちても、さらにもう1本のディスクが飛んでもデータが残る」耐性に届きます。予算が許すなら最初から3ノード以上を強く勧めます。

03ディスク構成と階層 — キャッシュとキャパシティを分けて考える

S2Dは直結のSATA / SAS / NVMe / 永続メモリ(PMem)に対応します。設計上いちばん大事なのは、「キャッシュ層」と「キャパシティ層」を分けて考えることです。速いメディアが混在していると、S2Dはそれを自動的にキャッシュデバイスとして使い、遅いメディアをキャパシティに回します。代表的な組み合わせと、Windows Serverでの最小ドライブ本数は次の通りです。

HDDでキャパシティを持つ構成では、Storage Bus Cachingが必須です。逆にオールフラッシュ構成ではプールキャッシュの効果は限定的で、Microsoftも必須とはしていません。キャッシュデバイスは32GB以上、書き込み耐性の高いもの(推奨で3 DWPD以上、または1日4TBW以上)を選びます。

現場のコツ：コンシューマ向けSSDは避けてください。S2Dではソリッドステートドライブに電源断保護(power-loss protection)が必須です。ここをケチると、停電時にキャッシュ上の書き込みが飛んでプールが不整合になります。加えて、キャッシュ容量1TBあたり4GBのRAMをメタデータ用に各ノードで確保する点も、メモリサイジングで見落としがちです。

04やってはいけない接続 — RAIDカードとSANはNG

S2Dは各ドライブが「1台のサーバーだけに物理接続されている」ことを前提にした設計です。ここを踏み外すと構築が根本から成立しません。ハマりどころを列挙します。

  • SAN(Fibre Channel / iSCSI / FCoE)は非対応。S2Dは内蔵ディスク前提です。
  • パススルーできないRAIDコントローラは非対応。HBAは単純なパススルー(simple pass-through)モードで動く必要があります。SASデバイスを直接パススルーできるRAIDカードのみ許容されます。
  • 複数サーバーから共有されるSASエンクロージャや、MPIO(マルチパスIO)は非対応。ドライブが複数経路から見えてはいけません。
  • 外付けJBODは「1台のサーバーにだけ」接続する形なら可。SES(SCSI Enclosure Services)とユニークIDが必要です。

また全ノードでドライブの本数と種類を揃える(ドライブ対称性)のが原則です。片ノードだけディスク構成が違うと、プールの効率やリバランスに悪影響が出ます。SET(Switch Embedded Teaming)を使う場合は、NIC・ドライバ・ファームウェアまで各ノードで完全一致させる必要がある点も要注意です。

05フォールトドメイン — 有効化する「前」に定義する

S2DはStorage Spacesの耐性(分散ソフトRAID)を、フォールトドメイン(FD)単位でデータのコピーを分散させることで実現します。FDにはSite > Rack > Chassis > Node の4階層があり、ノードは自動検出、それ以外は任意で定義します。ブレードを使わないならChassisは省略しても構いません。

設計上、決定的に重要なのはS2Dを有効化する前にFDを定義しておくことです。FDを先に切っておくと、自動構成がプール・階層・列数(column count)・耐性をChassis/Rack耐性に合わせて用意してくれます。プールとボリュームを作った後にFDトポロジを変えても、データは遡って再配置されません。定義はPowerShellで行います。

  • Get-ClusterFaultDomain：現在のFDトポロジを確認
  • New-ClusterFaultDomain -Type Rack -Name "Rack A"：Chassis/Rack/Siteを作成
  • Set-ClusterFaultDomain -Name "node01" -Parent "Rack A"：親子関係(ネスト)を設定
  • XMLでGet-ClusterFaultDomainXML / Set-ClusterFaultDomainXMLを使った一括定義も可能
現場のコツ：Windowsは、あなたが定義したFDが物理世界と一致しているかを検証しません。実際には1ラックに全ノードが載っているのに、ソフト上で2つのRack FDを作っても、ラック障害には耐えられません。図面と現物のラック割りを突き合わせ、-Locationメタデータに「Building 34, Room 4010」のような実在情報を入れておくと、Health Serviceのアラートで障害箇所の特定が速くなります。

フォールトドメイン階層(Site > Rack > Chassis > Node) Site: Sapporo Rack A Chassis 01 Node 1 Node 2 Chassis 02 Node 3 Node 4 Rack B Chassis 03 Node 5 Node 6 データコピーを別Rackに分散
図：Site > Rack > Chassis > Node のネスト。コピーを別FDに分散させることで、ラックやシャーシ単位の障害にも耐えられます。

06必要なネットワーク — RDMAとスイッチレスの判断

S2DはノードをSMB3(SMB Direct / SMB Multichannel)でつなぎ、そこにストレージトラフィックが流れます。ここが遅いと全体が遅くなるので、ネットワークは「本業」として設計します。Microsoftの最小要件の目安は次の通りです。

  • 小規模(2〜3ノード)：10Gbps NIC以上、冗長のため各ノード2本以上を推奨
  • 4ノード以上/高性能/スケール構成：RDMA対応NIC(iWARP推奨、またはRoCE)、25Gbps NIC以上、各ノード2本以上
  • スイッチレス:全ノードが互いに直結する必要あり(フルメッシュ)。小規模なら有効な選択肢
現場のコツ：RDMAはiWARPとRoCEで運用難易度が大きく違います。RoCEはスイッチ側でPFC/ETS(ロスレスEthernet)の設定が正しく通っていないと、負荷時に一気に不安定化します。スイッチ設定まで自前で握れないならiWARPが無難です。設計を単純化したい2〜3ノードでは、スイッチレスのフルメッシュにして高価な25GbEスイッチを省く判断も現実的です。RDMAやSET/Network ATCの具体設計は別記事(S2Dのネットワーク設計)で掘り下げます。

07ハイパーコンバージド vs 分離(ディスアグリゲート)

S2Dのデプロイには2種類あります。用途で明確に分かれます。

  • ハイパーコンバージド(HCI)：1つのクラスターで計算とストレージを兼ねる。同じサーバー上でHyper-Vを有効化し、VMをローカルボリュームに直接置く。SoFSやファイル共有の権限設計が不要で、中小規模・拠点/ブランチオフィス向け。
  • 分離(Converged / Disaggregated):ストレージ用クラスターと計算用クラスターを分ける。S2Dの上にScale-Out File Server(SoFS)を載せ、SMB3のファイル共有としてストレージを提供する。計算とストレージを独立にスケールでき、サービスプロバイダーや大規模なHyper-V IaaS向け。

SoFSの層は分離構成でのみ必要です。HCIではVMがストレージと同居するので不要です。どちらを選ぶかは「計算とストレージを別々に伸ばしたいか」で判断すると迷いません。多くのエンタープライズ案件では、まずHCIで始めて要件が固まってから分離を検討する、という順序が現実的です。

08Windows Server 2025 DatacenterとAzure Localの棲み分け

S2DはWindows ServerのDatacenterエディションの機能で、Windows Server 2025 Datacenterでも利用できます(Microsoft Learnの機能比較表でもWindows Server 2025のS2D対応は「Yes」)。一方、Azure Local(旧Azure Stack HCI)はHCI専用のOSで、同じS2Dを土台にしつつ立ち位置が異なります。混同すると製品選定を誤るので、要点を整理します。

  • クラウド接続：Azure Localは必須(少なくとも30日ごとに接続)。Windows Serverは任意(Arcやペイアズユーゴー利用時のみ必要)。
  • デプロイ形態:Azure LocalはHCI(ハイパーコンバージド)のみ。分離構成やSoFS単体は組めません。ワークロードはVM/コンテナ内で動かす前提(ホストに直接役割を載せられない)。
  • 柔軟性:Windows Server 2025はSAN/レガシーハードウェア/多様なドライバまで幅広く対応し、ベアメタルSQL Serverやファイルサーバーなど「サーバーとしての役割」も直接担えます。CALでのクライアント直接接続も可能。
  • ハードウェア:Azure Localは検証済みソリューション(Azure Local Catalog)前提。Windows Serverは「Certified for Windows Server」ロゴのハードウェアで動く。
現場のコツ：ざっくり言えば、「Azureと常時つなぎ、HCIに寄せて運用を一元化したい」ならAzure Local、「オンプレ単独で、SANや従来型サーバー役割との併用も含めて自前で柔軟に設計したい」ならWindows Server 2025 Datacenterです。閉域・非接続が要件の案件ではAzure Localの30日接続要件が効いてくるので、ここは初期の要件定義で必ず確認します。エディションやバージョン依存の対応可否はMicrosoft Learnの比較表で最新を確認してください。

—まとめ

S2Dの構成設計は、(1)2〜16ノードの規模と耐性、(2)キャッシュ/キャパシティの階層とドライブ対称性、(3)RAID/SANを避ける接続要件、(4)有効化前のフォールトドメイン定義、(5)RDMAとスイッチ有無を含むネットワーク、という順で詰めると漏れがありません。そしてHCIか分離か、Windows Server 2025 DatacenterかAzure Localか、を最初に決め切ることが、後戻りを防ぐ鍵です。

EMWは、S2D(Windows Server 2025 Datacenter)の構築、Hyper-Vライブマイグレーションによる移行、そのためのAD構築まで、実際に手を動かして手掛けてきました。こうしたオンプレHyper-V/Windows基盤の深い理解は、そのままAWSへの移行設計にも効きます。ローカルディスクをどうプールし、どう冗長化しているかを把握しているからこそ、RAID構成からEBSへの置き換えやWindows Serverの移行落とし穴を的確に見通せます。設計・構築から、その先のクラウド移行まで、まとめてご相談いただけます。

—参考(一次情報)

S2DやHyper-V基盤の設計・構築、あるいはその先のAWS移行まで、手を動かせるEMWにご相談ください。お問い合わせ

相談する
← ブログ一覧へ戻る