June 18, 2026
Rob Hindman and Parsan Saffaie from Microsoft, and their product team, took us for a deep dive into Storage Spaces Direct (S2D). They covered architecture, topologies, real‑world use cases, common challenges, and what’s coming next — including major improvements to repair workflows, scalability, and full‑stack NVMe performance. Onward to vNext.
TL/DR Overview
Storage Spaces Direct (S2D) is Microsoft’s software‑defined storage built into Windows Server and Azure Local. It pools local disks across cluster nodes to create a highly available, high‑performance storage layer for Hyper‑V VMs and stateful workloads.
- Architecture: Local NVMe/SSD/HDD across nodes → storage bus → pooled storage → virtual disks with mirroring/parity → REFS/NTFS → CSV + health service → workloads.
- Topologies: Hyper‑converged, disaggregated, standalone, SAN/NAS coexistence, campus clusters, and upcoming stretch clusters using Storage Replica.
- Resiliency: 2‑way, 3‑way, 4‑way mirror; parity; mirror‑accelerated parity. Mix per‑volume.
- Performance: Read‑optimized; RDMA strongly recommended for throughput and CPU savings.
- Use cases: HCI virtualization, modernization of enterprise storage, hybrid/edge deployments.
- Challenges: Complexity, repair jobs getting stuck, disk states hanging, pool expansion pain, performance drops during recovery.
- vNext focus: Simplifying management, improving repair/recovery workflows, better scaling guidance.
- Best practices: Validate RDMA first, let S2D auto‑assign cache, start with 3‑way mirror, monitor health service actions, avoid adding drives mid‑repair.
- Azure DR: Many customers use Azure Site Recovery or backup vendors (Veeam, Commvault, etc.) to fail over small 2‑node/edge clusters to Azure when hardware fails.
Summary
1/ What S2D Is & How It Evolved
Microsoft traced the evolution from RAID → SAN → Storage Spaces → S2D, emphasizing that S2D is software‑defined storage built into Windows Server and Azure Local. It pools locally attached drives across nodes into a single, highly available storage layer.
“S2D is software defined storage that’s built into Windows Server as well as Azure Local… it sees all of these drives across your nodes as a single pool of available storage.”
S2D supports both hyper‑converged and disaggregated topologies and has been widely adopted since Windows Server 2016.
2/ Architecture Deep Dive
Microsoft walked through the full S2D stack:
- Physical layer: NVMe, SSD, HDD
- Storage Bus Layer: every node can see every drive
- Storage Pool: aggregated capacity
- Virtual Disks: resiliency via mirroring or parity
- File System: REFS recommended for integrity & fast repair
- CSV + Health Service: shared access + continuous monitoring
- Workloads: Hyper‑V VMs, SQL, apps
“These sit on top of the file system and give every node… read‑write access to the same volumes… the cluster health service… triggers repair jobs when something goes wrong.”
3/ Supported Topologies
Microsoft highlighted S2D’s flexibility:
- Hyper‑converged clusters
- Standalone servers
- Disaggregated compute/storage
- SAN/NAS coexistence
- Campus clusters (rack‑aware)
- Upcoming stretch clusters using Storage Replica
“We will be supporting an S2D stretch cluster… a cheaper alternative to SAN replication.”
4/ Resiliency Options
S2D supports multiple resiliency types:
- 2‑way mirror
- 3‑way mirror
- 4‑way mirror (campus clusters)
- Single parity
- Mirror‑accelerated parity
Resiliency is chosen per volume, allowing mixed strategies in one pool.
“You can run multiple resiliency levels within a pool… specified at the volume level.”
5/ Performance Characteristics
S2D is read‑optimized, with writes focused on redundancy. RDMA is strongly recommended for performance and CPU offload.
“Reads are given a very high priority… RDMA networking… can save about 30% of your CPU cycles.”
6/ Recommended Configurations & Setup Tips
Key guidance included:
- Validate RDMA before enabling S2D
- Let S2D auto‑assign cache
- Start with 3‑way mirror for resiliency
- Monitor repair jobs closely
- Avoid adding drives during repair
“Look for those health service actions… don’t add drives as you’re mid‑repair.”
7/ Advantages & Limitations
Advantages:
- Flexible deployment
- Integrated into Windows Server & Azure Local
- Built‑in resiliency
- Scales up or out
- Works with SAN/NAS
Limitations / Common Issues:
- Complexity of architecture
- Repair jobs getting stuck
- Virtual disks stuck in maintenance
- Pool expansion challenges
- Performance tied heavily to network quality
“We’re aware that these are issues… disks going offline, things getting stuck in repair states… pool expansion can be difficult.”
8/ Roadmap & vNext Focus Areas
Microsoft emphasized major investments in:
- Manageability & ease of use
- Faster, more reliable rebuilds
- Better diagnostics & transparency
- Scalability improvements
- Full‑stack NVMe modernization (from drivers → VHDX → VM virtual NVMe controller)
“We’re modernizing the entire Windows storage stack to NVMe… radical improvements in IOPS, latency, CPU utilization.”
9/ Q&A Highlights
Topics included:
- CSV volume best practices: one per node, or multiples of node count
- ASR for DR: widely used with S2D clusters
- Switchless clusters: supported and cost‑effective for 3–4 node deployments
- Drive expansion: flexible, but add symmetrically per node
- Cluster‑aware updating: fully S2D‑aware, orchestrates safe rolling updates
“Cluster‑aware updating… will drain nodes, put storage into maintenance mode… patch the node… and work its way through the cluster.”