The Cluster Often Reached Disks Outside the Servers
Highly available server clusters traditionally depended on storage that multiple machines could reach. That storage might live in a dedicated array, shared disk enclosure, or another system separate from the servers performing the actual computing.
This created a clear division. The servers supplied processing and memory while the storage platform supplied shared capacity that remained available to the cluster.
Storage Spaces Direct introduced another approach. Drives physically installed inside individual servers could become part of a larger software-defined storage system spanning the cluster.
The Server Was No Longer the Boundary of the Storage Pool
A drive could remain physically attached to one machine while its capacity participated in storage designed for the clustered environment as a whole.
Storage From Several Servers Could Be Combined
Ordinary Storage Spaces could aggregate physical disks into pools and create virtual disks from that capacity. Storage Spaces Direct extended the concept across multiple clustered servers.
Each server could contribute locally attached drives. Software then coordinated those devices into shared storage rather than requiring every disk to sit behind one server or inside a common external enclosure.
The result changed the role of internal server storage. Those disks no longer had to remain isolated resources belonging only to the machine containing them.
Local Hardware Could Become Distributed Storage
The physical location of a drive and the logical storage presented to the cluster became two different things.
Servers Had to Exchange Storage Data With Each Other
Combining drives across separate machines required the cluster nodes to communicate continuously.
Storage Spaces Direct used Ethernet networking and SMB technologies to move storage traffic between servers. This made the network an important part of the storage architecture rather than merely a path for users and applications to reach the machines.
Fast, low-latency communication between nodes became especially important because data might need to be written to or retrieved from storage physically located in another server.
The Storage Fabric Could Be the Server Network
A specialized external storage fabric was no longer the only way to connect machines to resilient shared capacity. The clustered servers could coordinate their internal drives across high-speed Ethernet.
Resiliency Had to Extend Across Drives and Servers
A distributed storage pool would be fragile if important data existed on only one physical device.
Storage Spaces Direct could use mirroring and parity-based resiliency so data remained protected across the available hardware. The design could account not only for individual drive failures but also for a server becoming unavailable.
This made placement important. Protected data had to be arranged so that losing one component did not automatically remove every usable copy of the information with it.
Pooling Capacity Is Not the Same as Protecting Data
Combining disks creates usable capacity, but resiliency determines what happens when hardware disappears. A distributed storage system must plan for failures as part of its architecture.
Software Hid Much of the Physical Layout
Applications do not necessarily need to understand which server contains each physical disk involved in storing their data.
Storage Spaces Direct creates storage pools and volumes above the underlying hardware. Cluster Shared Volumes can then make those volumes available across the cluster while the storage system handles the relationship between logical data and physical devices.
This abstraction is one of the central ideas behind software-defined storage. Hardware still matters, but applications can work with logical storage rather than managing individual disks directly.
Logical Storage Could Outgrow a Single Machine
A volume presented to workloads could represent capacity and resiliency assembled from hardware distributed across several servers.
The Storage Pool Did Not Have to Treat Every Device the Same Way
Server storage can contain devices with very different performance characteristics. Solid-state storage provides low latency and high throughput, while hard drives can provide large amounts of capacity economically.
A software-defined design can use those characteristics when organizing the storage system. Faster media can help accelerate access while larger capacity devices hold more of the underlying data.
The important shift is that the behavior of the storage system is determined by more than the specifications of one physical drive. Caching, resiliency, data placement, networking, and the combined hardware of the cluster all influence the result.
A Drive Became One Component of a Larger Storage Stack
The performance and reliability experienced by a workload could depend on several layers working together rather than on one disk operating by itself.
The Same Servers Could Provide Compute and Storage
Storage Spaces Direct made a hyperconverged arrangement possible in which Hyper-V and the storage system operated on the same cluster nodes.
The servers could run virtual machines while their internal drives simultaneously contributed to the storage holding those workloads. This reduced the need to maintain a completely separate storage platform simply to provide shared capacity to the virtualization cluster.
Expanding such an environment could also become conceptually different. Adding another server could contribute processing resources, memory, networking, and additional storage capacity at the same time.
One Server Could Expand Several Parts of the Infrastructure
In a hyperconverged design, scaling the cluster could increase both the resources available to virtual machines and the storage available beneath them.
A Dedicated Storage Cluster Was Still Possible
Hyperconvergence was not the only way to use the technology.
A separate cluster could concentrate on providing storage while another group of servers handled compute workloads. This converged approach preserved a degree of separation while still using software-defined storage built from drives attached directly to the storage nodes.
The choice depended on how an environment needed to scale. Some organizations could benefit from adding compute and storage together, while others might need those resources to grow independently.
Software Defined Did Not Mean One Fixed Architecture
The same underlying storage concept could support servers that combined compute and storage roles or dedicated nodes whose primary purpose was supplying storage to other systems.
Capacity Could Grow With Drives or Additional Servers
Traditional storage expansion often centered on the limits and configuration of a particular enclosure or array.
Distributed storage introduced another scaling model. Additional drives could increase capacity within existing nodes, while additional servers could bring more storage resources into the cluster.
This allowed the storage system to grow horizontally as infrastructure requirements increased.
Scale Out Became Part of the Storage Model
Growth did not have to mean replacing one storage system with a larger one. Capacity and performance could also increase by extending the clustered collection of resources.
Software Defined Storage Did Not Make Physical Design Irrelevant
Moving more storage intelligence into software did not eliminate the importance of the underlying equipment.
Drive performance, server configuration, network bandwidth, latency, redundancy, and failure domains all influenced how reliably and efficiently the storage system operated.
The difference was where coordination occurred. Instead of depending entirely on a dedicated external storage appliance to provide the intelligence and shared capacity, much of that work could be performed across the Windows Server cluster.
The disks remained inside individual servers, but the storage they created no longer had to belong to only one server.
Storage Spaces Direct Moved Shared Storage Into the Server Cluster
Storage Spaces Direct changed the relationship between local disks and clustered infrastructure. Internal drives that once appeared to belong exclusively to individual machines could participate in a resilient storage pool spanning multiple servers.
Networking connected the nodes, software coordinated the disks, and resiliency protected data across the available hardware. Workloads could then consume logical storage without needing to manage the physical location of every drive involved.
The larger change was architectural. Shared storage no longer had to begin with a separate storage system outside the servers. The servers themselves could become the building blocks from which the shared storage platform was assembled.
