Several Servers Usually Needed Access to the Same Disks
Keeping applications available after a server failure requires more than having another machine ready to take over. The replacement server also needs access to the data that the failed machine was using.
Traditional clusters often solved that problem with storage hardware shared between multiple servers. Rather than keeping important data only on disks installed inside one machine, the servers connected to a common storage system that could remain available as workloads moved between them.
This architecture worked, but it also separated storage into specialized infrastructure that had to be purchased, connected, configured, and maintained alongside the servers themselves.
The Servers Could Be Redundant While the Storage Remained Separate
A cluster might contain several compute nodes, yet their shared data could still depend on a dedicated storage enclosure or storage network outside those servers.
A Disk Inside a Server Was Not Automatically Cluster Storage
Internal storage has an obvious physical relationship with the computer containing it. A drive connected directly to one server can be seen and controlled by that server, but another machine in the cluster does not simply inherit direct access to the same hardware.
That distinction limited how ordinary locally attached disks could participate in traditional shared-storage designs.
Windows Server 2016 introduced Storage Spaces Direct to change that relationship. Instead of requiring all clustered storage devices to sit behind a conventional shared disk fabric, drives installed locally inside multiple servers could participate in a distributed storage system.
Local Storage Could Become Cluster Storage
The drives remained physically attached to individual servers, but software could combine their capacity into storage available across the cluster.
Servers Could Reach Drives Installed in Other Nodes
Storage Spaces Direct uses the connections between cluster nodes to make locally attached storage participate in a common architecture.
Each server contributes eligible drives installed inside that machine. Windows then combines storage resources across the nodes rather than requiring every server to attach directly to one external disk enclosure.
The physical disks remain distributed, but the storage presented to the cluster can operate as a unified software-defined system.
Shared Storage No Longer Had to Mean Shared Cabling to Every Disk
The network between servers could carry the storage communication required to turn individually attached drives into resources used by the cluster as a whole.
The Software Storage Bus Made Remote Disks Part of the Design
Storage Spaces Direct introduced a Software Storage Bus that allowed the cluster to establish a software-defined relationship among storage devices distributed across its servers.
Above that layer, familiar Windows storage technologies could organize the available capacity into pools and resilient virtual disks.
This meant the cluster did not have to pretend that every physical disk was connected to every machine. Windows understood that drives belonged to particular nodes while still building storage services across those boundaries.
Software Could Bridge a Physical Storage Boundary
Rather than changing where the drives were physically connected, Storage Spaces Direct changed how the cluster could use those distributed devices together.
Fast Devices Could Stay Directly Attached to the Server
Some modern storage devices achieve their performance precisely because they connect directly to a server rather than through a traditional shared disk enclosure.
NVMe drives are an important example. Their direct relationship with PCI Express makes them very different from storage designed around an external shared SAS fabric.
Storage Spaces Direct allowed Windows Server clusters to use locally attached device classes such as SATA SSDs and NVMe drives as part of the software-defined storage pool.
Direct Attachment Could Become an Advantage Instead of a Limitation
High-performance storage no longer had to become externally shared at the hardware level before it could contribute to a clustered Windows storage architecture.
Pooling Drives Was Only Part of the Job
Combining capacity from several servers would provide little resilience if important information existed only on a drive inside one node. Losing that server could make the data disappear with it.
Storage Spaces Direct therefore uses resilient storage layouts that can place data across different drives and servers. Depending on the configuration, mirroring or erasure coding can provide protection against hardware failures.
The cluster can continue presenting data even when individual storage devices or entire nodes become unavailable within the protection limits of the chosen layout.
Distributed Capacity Needed Distributed Resilience
A storage pool spanning several machines becomes highly available only when its data is arranged so the loss of one component does not remove the only usable copy of essential information.
The Pool Could Use Its Fastest Devices as Cache
A server may contain more than one class of storage device. Extremely fast drives can provide excellent performance, while larger or less expensive drives can provide substantial capacity.
Storage Spaces Direct could recognize the media available in the system and use fast devices as cache for the storage pool.
This allowed a design to combine different storage characteristics instead of requiring every drive to perform the same role.
The Fastest Drive Did Not Have to Store Everything
High-performance media could accelerate access while other devices supplied capacity, allowing the storage architecture to use different hardware for complementary purposes.
A Separate Storage Tier Was No Longer Mandatory
Once servers could combine their own internal drives into highly available storage, another architectural possibility emerged. The machines supplying the storage could also run the workloads consuming it.
In a hyperconverged configuration, Hyper-V and Storage Spaces Direct could operate on the same cluster nodes. Those servers provided computing resources for virtual machines while their internal drives supplied the shared storage underneath them.
This collapsed roles that had traditionally been divided between a compute cluster and a separate storage system.
The Storage Servers Could Also Be the Compute Servers
A hyperconverged cluster could use the same physical machines for virtual-machine processing and for the distributed storage holding those virtual machines.
The Technology Did Not Require One Architecture
Combining compute and storage can simplify some environments, but larger installations may need to scale those resources independently.
Storage Spaces Direct could also support a converged design in which one group of servers supplied the software-defined storage while another group ran workloads such as Hyper-V virtual machines.
A Scale-Out File Server could expose the storage to the compute tier over SMB, preserving a separation between the machines providing storage and those consuming it.
Software-Defined Storage Did Not Eliminate Architectural Choice
The same underlying technology could support tightly integrated hyperconverged systems or storage clusters serving a separate compute environment.
Scaling Out Could Bring New Drives Into the Pool
Traditional infrastructure often scales servers and storage through different processes. More processing capacity might require another server, while more storage might require expanding or replacing a separate array.
In a Storage Spaces Direct cluster, adding a properly configured node can contribute additional local drives to the software-defined storage pool.
For a hyperconverged deployment, the same new machine can also add processor and memory resources for workloads. Expansion can therefore increase multiple forms of capacity through the addition of another server.
Another Node Could Bring Its Storage With It
Scaling the cluster could increase available disk capacity and storage performance while also expanding compute resources in hyperconverged configurations.
Standard Servers Could Perform a Job Once Assigned to Specialized Hardware
Storage arrays traditionally concentrated disks, controllers, resilience features, and management inside dedicated equipment. Servers then connected to that storage as clients.
Storage Spaces Direct moved more of those responsibilities into Windows Server. Standard servers with appropriate local drives and high-speed networking could cooperate to provide pooled, resilient storage through software.
The physical disks did not become less important, but the intelligence coordinating them no longer had to reside entirely inside a separate storage appliance.
The cluster could build shared storage from drives that were never physically shared in the first place.
Storage Spaces Direct Turned Server Drives Into Distributed Infrastructure
Storage Spaces Direct changed what locally attached storage could mean in a Windows Server cluster. Drives installed inside separate machines could contribute to a common software-defined pool instead of remaining useful only to the server physically containing them.
Networking and the Software Storage Bus connected those distributed devices, resilient layouts protected data across hardware failures, and technologies such as NVMe could participate without first being placed behind a traditional shared storage enclosure.
The result was a different way to build clustered storage. Rather than starting with a shared disk system and connecting servers to it, Windows Server could start with the disks already inside multiple servers and turn them into shared infrastructure.
