Way back in Windows Server 2012, Microsoft introduced its Storage Spaces feature. In Windows Server 2016, Microsoft released a similarly named feature called Storage Spaces Direct--or S2D, as it is sometimes called. Here's some hands-on evidence of how the two features differ, as well as advice on how to make the most of S2D.
Windows storage spaces is a Windows Server feature that lets you make better use of a server’s internal storage through software-defined storage. To put this into prospective, take a look at Figure 1, which shows the Windows Storage Spaces feature as it is exposed through Server Manager on a machine that is running Windows Server 2012 R2.
If you look at the upper portion of this figure, you can see that I have created a storage pool called MyPool. I then added four physical disks to the storage pool. You can see these disks listed in the lower-right portion of the figure. Each of these disks is 4.55TB in size, for a total pool size of 18.2TB. Windows allows you to add extra disks to the pool on an as-needed basis.
With the storage pool in place, you can create virtual disks on top of the pool. If you look at the Virtual Disks portion of the figure, you can see that I created a virtual disk called MyVirtualDisk. This is a fixed-length virtual disk that utilizes parity to protect against physical disk failures. The virtual disk’s total capacity is 13.6TB.
When you create a virtual disk within Storage Spaces, it is nearly indistinguishable from physical storage. If you look back at the previous figure, you can see that I have mapped the F: drive to my virtual disk. If you look at File Explorer in Figure 2, you can see that F: appears as a physical disk, even though it is actually a virtual disk.
Storage Spaces Direct
Storage Spaces Direct takes this Storage Spaces concept to the next level. While Windows Storage Spaces focused on a single server and its local storage, Storage Spaces Direct is able to pool storage across servers.
Storage Spaces Direct is based on the use of shared-nothing clustering. The first step in creating a Storage Spaces direct Architecture is to create a new cluster consisting of between two and 16 nodes. Unlike a typical Windows failover cluster, however, the cluster that acts as the basis for Storage Spaces Direct does not require the use of a cluster shared volume. Instead, each of the cluster’s nodes has its own internal storage. Once Storage Spaces Direct is enabled (which can be accomplished with the Enable-ClusterStorageSpacesDirect PowerShell cmdlet), all of the available storage is pooled together and becomes visible across each of the cluster’s nodes.
Once the storage has been pooled, you can create volumes on an as-needed basis, and this is where things get interesting. Normally, when you create a storage volume (without Storage Spaces Direct being involved), you have to configure the volume to use a file system such as NTFS or ReFS. In the case of Storage Spaces Direct, however, you have to set the file system to be either CSVFS_NTFS or CSVFS_ReFS. (This is specified through the New-Volume cmdlet’s -FileSystem parameter.) These file systems are necessary because they allow Windows to treat the volume as a cluster shared volume, meaning that it will be accessible from any node in the Storage Spaces Direct cluster. (Incidentally, Microsoft recommends using the CSVFS_ReFS file system.)
Storage Spaces Direct is not a mechanism for spanning a volume across servers. Instead, it allows you to make your storage volumes highly available.
Storage Spaces Direct uses cross-node redundancy to establish storage resiliency. The available resiliency options vary depending on the number of nodes that you are using. If your cluster only has two nodes, then any volumes that you create are mirrored across the two nodes. Similarly, if your cluster has three nodes, Storage Spaces Direct will use three-way mirroring to ensure that each node has its own copy of the volume.
If your Storage Spaces Direct cluster has four or more nodes, you get to choose the resiliency type. Windows Server 2016 allows you to use either mirroring or parity-based resiliency. Windows Server 2019 supports mirroring and parity, but also allows for nested resiliency, which adds extra protection to two node clusters.