A lot of the discussion around how to implement a software-defined storage architecture has focused on hypervisor vendors, and what they are doing to integrate the technology into their software stack.
That approach is appealing to IT managers in search of a configuration featuring a hypervisor with additional code that enables software-defined storage (SDS). But there is more to consider in this strategy, and one place that storage professionals should focus some energy in the coming year is in understanding the goal of a software-defined data center (SDDC).
The goal of a software-defined data center is to enable IT agility by supporting changing business requirements on the fly with available resources and applications. The core idea is to pool resources -- processors, networks, storage and perhaps middleware -- in such a way that you can develop atomic units of compute that can be readily allocated or de-allocated to business process requirements.
Need to stand up 50 more seats of a customer service application? An agile data center delivers the number and type of virtual servers, virtual networks and virtual storage resources required to make it happen. For agility to be delivered, you need portability in the resources. That is, the pooled and virtualized servers, networks and storage resources must be able to be patched together into whatever combination is desired to host a given application. But as storage pros know, this is not as simple as it sounds.
This is where we must look again at our hypervisor offerings. The SDS architectures of leading server hypervisor vendors are not, in my opinion, truly designed to be shared across hypervisor stacks, or between virtualized and non-virtualized servers.
Microsoft is a bit more flexible in this regard than VMware, since it uses Server Message Block to create shareable storage -- at least when it is fashioned into a scale-out file server with a Clustered Storage Spaces back end. Even without the file server "head," Microsoft's Clustered Storage Spaces will support both Hyper-V-hosted applications and applications running on bare metal without server virtualization.
The issue of sharing is important because of its impact on overall software-defined storage utility. Even with industry analyst predictions that 69% to 75% of x86 workloads will operate in a couple of years under the auspices of hypervisor software running on 21% of servers in the data center, that leaves the rest of the applications (approximately 25% of mostly mission-critical, revenue-generating apps that aren't virtualized at all) running on the other 79% of servers. Unless you think that having different kinds of storage to configure, administer and manage for different workloads contributes to agility, these mixed environments present differing needs that perhaps cannot be satisfied by software-defined storage that is done in the way that most major vendors accomplish it.
Another issue to consider is that many shops use more than one hypervisor. A survey done by TechTarget late last year found VMware to be dominant in the U.S. and Europe, but it also recorded dissatisfaction over hypervisor pricing models by 38% of the respondents, who said they would likely be changing their hypervisor this year. The bottom line is that the need to support applications instantiated on more than one hypervisor in the same shop also tends to balkanize storage, making its management and administration more challenging and agility harder to reach.
These considerations apply to larger shops. You could assume that smaller shops, with their smaller pool of IT resources and smaller budgets, would be a shoe-in for the one-size-fits-all hypervisor stack. But the cost of VMware's Virtual SAN is daunting, while Microsoft's hardware requirements place it beyond the budgets of more than a few small shops.
There are several broader considerations, related to agility, to keep in mind before adopting the virtual SANs of any one particular hypervisor vendor. It is certainly worth the time and effort to consider hardware- and hypervisor-agnostic virtual SANs, like those from StarWind Software Inc. or DataCore Software, to see what they can offer that your hypervisor vendor can't. One size fits most never fits anyone's needs very well.
Answers to frequently asked SDS questions
How software becomes storage in software-defined implementations