How to Configure Storage Spaces Direct (S2D) on Windows Server 2022

How to Configure Storage Spaces Direct (S2D) on Windows Server 2022

Storage Spaces Direct (S2D) is Microsoft’s software-defined storage technology built into Windows Server, enabling you to cluster servers with local storage — NVMe, SSDs, and HDDs — into a highly available, scalable storage pool without the need for a shared SAS fabric or SAN. In a hyper-converged infrastructure (HCI) deployment, S2D runs compute (Hyper-V) and storage workloads on the same physical nodes. In a disaggregated deployment, dedicated storage nodes serve as a Scale-Out File Server (SOFS) that compute nodes access over SMB 3.x. Windows Server 2022 brings improvements to S2D including faster rebuilds, compressed mirrors, and tighter integration with Windows Admin Center.

Hardware Requirements and Planning

S2D has strict hardware requirements. Every node in the cluster must be identical or near-identical in CPU generation, memory, and storage. Microsoft publishes an S2D Hardware Catalog; using certified hardware ensures predictable performance and support. Key hardware considerations include:

Storage tiers: S2D supports three device classes. NVMe drives act as cache by default when mixed with SSDs or HDDs. SSDs act as cache when mixed with HDDs. All-flash configurations (all NVMe or all SSD) use the fastest available media as capacity. You can use a three-tier configuration (NVMe cache, SSD capacity, HDD capacity) but the most common production deployments use NVMe cache with SSD capacity, or all-NVMe.

RDMA NICs: For production S2D you need at least two RDMA-capable NICs per node (25 GbE or 100 GbE recommended) supporting RoCE v2 or iWARP. RDMA is required for the high-throughput, low-latency storage bus traffic between nodes. Configure SET (Switch Embedded Teaming) on top of the RDMA NICs. The cluster network adapter must be able to reach all other nodes on a dedicated storage network (not the management network).

Minimum cluster size: Two nodes minimum for hyper-converged S2D (with only two-way mirroring available). Three nodes for three-way mirroring. Four nodes for erasure coding (parity). For production workloads with erasure coding, four to sixteen nodes is typical.

Memory: Each node needs sufficient RAM for the Hyper-V workloads plus the S2D cache. As a rule of thumb, allocate 1 GB of RAM per 1 TB of capacity drive storage for the S2D cache tier metadata.

Installing Required Features

S2D requires Failover Clustering and the Hyper-V role (for HCI). Install these on all cluster nodes:

Install-WindowsFeature -Name Failover-Clustering, Hyper-V, Hyper-V-PowerShell, RSAT-Clustering-PowerShell -IncludeManagementTools -Restart

After reboot, run cluster validation — S2D adds specific storage validation tests. Run this from a management machine targeting all future cluster nodes:

Test-Cluster -Node "node01","node02","node03","node04" -Include "Storage Spaces Direct","Inventory","Network","System Configuration"

Review the HTML report generated by Test-Cluster carefully. S2D validation will flag non-uniform storage (different drive models or capacities across nodes), missing RDMA configuration, or missing driver versions. Resolve all warnings before proceeding.

Creating the Failover Cluster

Create the cluster without adding any storage (the -NoStorage switch is critical — S2D manages storage itself, and you must not let the cluster wizard assign drives before enabling S2D):

New-Cluster -Name "s2d-cluster01" -Node "node01","node02","node03","node04" -NoStorage -StaticAddress "10.10.1.50"

If you are using a domain-based cluster with DNS dynamic registration, omit -StaticAddress. After creation, set the cluster quorum to a Cloud Witness or File Share Witness (an S2D cluster should not use a disk witness since all disks are managed by S2D):

Set-ClusterQuorum -Cluster "s2d-cluster01" -CloudWitness -AccountName "mystorageaccount" -AccessKey "BASE64ACCESSKEY=="

Enabling Storage Spaces Direct

Run Enable-ClusterStorageSpacesDirect on any one node of the cluster. This command discovers all eligible drives across all nodes, creates the storage pool, and configures the cache:

Enable-ClusterStorageSpacesDirect -CacheState Enabled -AutoConfig $true -SkipEligibilityChecks $false

The -AutoConfig $true flag lets S2D automatically configure cache and capacity tiers based on the drive types it discovers. To manually control which drives are cache versus capacity, use -CacheDeviceModel to specify the model string of the cache drives, then run Enable-ClusterStorageSpacesDirect without AutoConfig.

After S2D is enabled, a storage pool named “S2D on s2d-cluster01” is created automatically. Verify it:

Get-StoragePool -IsPrimordial $false | Select FriendlyName, OperationalStatus, HealthStatus, Size, AllocatedSize

Cache and Capacity Tier Architecture

In a mixed-media deployment, S2D uses the faster drives as a write-back read cache. Write I/O lands in cache first (on every node that owns a copy of the data) and is destaged asynchronously to capacity drives. Read I/O is served from cache if the data is hot. The cache is a persistent, block-level cache — it survives reboots. The cache devices are consumed entirely by S2D and do not appear as usable storage capacity.

In an all-flash or all-NVMe deployment, you can disable the cache for lower latency:

Enable-ClusterStorageSpacesDirect -CacheState Disabled

For all-NVMe where you want cache enabled anyway (for write coalescing), S2D will use a portion of NVMe drives as cache depending on the ratio configured in the storage pool.

Creating Virtual Disks and Volumes

With S2D enabled, create virtual disks (storage spaces) from the pool. Always specify the resiliency setting (mirror or parity) and optionally the storage tier. Two-way mirror requires 2+ nodes. Three-way mirror requires 3+ nodes. Parity (erasure coding) requires 4+ nodes:

# Three-way mirror virtual disk — 2 TB
New-Volume -FriendlyName "VM_Volume_01" -FileSystem CSVFS_ReFS -StoragePoolFriendlyName "S2D on s2d-cluster01" -ResiliencySettingName Mirror -Size 2TB

# Parity virtual disk — 10 TB (requires 4+ nodes)
New-Volume -FriendlyName "Backup_Volume_01" -FileSystem CSVFS_ReFS -StoragePoolFriendlyName "S2D on s2d-cluster01" -ResiliencySettingName Parity -Size 10TB

# Mirror-accelerated parity (tiered) — performance tier for hot data, parity for cold
New-Volume -FriendlyName "MAP_Volume_01" -FileSystem CSVFS_ReFS -StoragePoolFriendlyName "S2D on s2d-cluster01" -StorageTierFriendlyNames "Performance","Capacity" -StorageTierSizes 500GB,5TB

New-Volume automatically creates the virtual disk, partition, formats it as ReFS, and registers it as a Cluster Shared Volume (CSV). The volume appears at C:ClusterStorageVolume1 (and subsequent numbers) on all cluster nodes simultaneously.

Cluster Shared Volumes (CSV)

CSV allows all cluster nodes to simultaneously access the same NTFS or ReFS volume through a unified namespace. With S2D, all volumes should be CSVs. Check CSV status:

Get-ClusterSharedVolume | Select Name, State, OwnerNode | Format-Table -AutoSize

# Get detailed CSV state including filesystem path
Get-ClusterSharedVolumeState | Format-Table -AutoSize

Each CSV has an owner node that handles metadata operations, but all nodes can read and write data directly. If the owner node fails, ownership transfers automatically. To manually move a CSV to a different node:

Move-ClusterSharedVolume -Name "Cluster Virtual Disk (VM_Volume_01)" -Node "node02"

Deploying Hyper-V VMs on S2D

Store VM configuration files and VHDs in the CSV path. For Hyper-V, create the VM with the path pointing to the ClusterStorage directory:

New-VM -Name "TestVM01" -MemoryStartupBytes 4GB -Generation 2 -Path "C:ClusterStorageVM_Volume_01VMs" -NewVHDPath "C:ClusterStorageVM_Volume_01VMsTestVM01TestVM01.vhdx" -NewVHDSizeBytes 100GB -Switch "Hyper-V vSwitch"

# Register VM as a clustered role
Add-ClusterVirtualMachineRole -VMName "TestVM01"

Monitoring S2D Health

S2D provides a rich health model accessible through PowerShell. The storage subsystem, pools, virtual disks, and physical disks all report health and operational status:

# Overall storage subsystem health
Get-StorageSubSystem -FriendlyName "Clustered Windows Storage on s2d-cluster01" | Select HealthStatus, OperationalStatus

# All virtual disks
Get-VirtualDisk | Select FriendlyName, HealthStatus, OperationalStatus, ResiliencySettingName, Size, FootprintOnPool | Format-Table -AutoSize

# Physical disk health — look for disks with non-Healthy status
Get-PhysicalDisk | Select FriendlyName, MediaType, OperationalStatus, HealthStatus, Usage, Size | Sort HealthStatus | Format-Table -AutoSize

# S2D-specific storage job progress (rebuild, repair)
Get-StorageJob | Select Name, ElapsedTime, JobState, PercentComplete, IsBackgroundTask | Format-Table -AutoSize

When a drive fails, S2D automatically begins a rebuild job. The rebuild reads data from surviving copies (mirror or parity) and writes it to a spare drive or distributes it across remaining drives. Monitor rebuild progress:

while ($true) {
    $jobs = Get-StorageJob
    if ($jobs) { $jobs | Select Name, PercentComplete, JobState | Format-Table -AutoSize }
    Start-Sleep -Seconds 30
}

S2D Deduplication and Compression

S2D volumes formatted as ReFS support inline deduplication and compression on Windows Server 2022 (requires Datacenter Edition). This significantly reduces storage footprint for VM workloads with similar guest OS images. Enable it on a CSV volume:

# Install the Deduplication feature on all nodes
Invoke-Command -ComputerName "node01","node02","node03","node04" -ScriptBlock {
    Install-WindowsFeature -Name FS-Data-Deduplication
}

# Enable ReFS deduplication on the CSV volume (run on owner node)
Enable-DedupVolume -Volume "C:ClusterStorageVM_Volume_01" -UsageType HyperV

# Check deduplication status
Get-DedupStatus -Volume "C:ClusterStorageVM_Volume_01" | Select Volume, SavingsRate, SavedSpace, OptimizedFilesCount

Fault Tolerance Summary

S2D fault domains are nodes by default. In a rack-aware deployment, you can define chassis or rack fault domains so that S2D keeps mirror copies in separate racks. For a standard 4-node cluster:

Two-way mirror: tolerates 1 node/drive failure. Efficiency ~50%. Three-way mirror: tolerates 2 simultaneous node failures. Efficiency ~33%. Dual parity (RAID-6 equivalent): tolerates 2 drive failures per erasure set. Efficiency ~50% for 4 nodes, improving with more nodes. Mirror-accelerated parity: hot data in mirror tier, cold data in parity tier — balances performance and efficiency.

Windows Admin Center Integration

Windows Admin Center (WAC) provides a graphical interface for S2D management. After connecting WAC to your S2D cluster, the Cluster Manager extension shows real-time health of nodes, drives, volumes, and virtual machines. The Storage dashboard displays drive inventory with health indicators, rebuild status, cache hit ratios, and IOPS/latency per volume. WAC also surfaces S2D alerts and lets you add, remove, or replace drives without PowerShell. Install WAC on a management server (not on a cluster node) from the Microsoft download center and add your cluster connection using the cluster name.

# Verify S2D cluster is accessible from WAC management node
Get-Cluster -Name "s2d-cluster01" | Select Name, S2DEnabled

# Check S2D is enabled (S2DEnabled should be 1)
(Get-Cluster -Name "s2d-cluster01").S2DEnabled

Storage Spaces Direct on Windows Server 2022 provides enterprise-grade, software-defined storage suitable for both small edge deployments and large-scale data center HCI clusters. Proper hardware selection, network configuration, and ongoing health monitoring are the keys to a reliable S2D environment.