VSAN Value and Paradigm Shifts

The VSAN story is out and doesn’t seem to be going away any time soon. It feels like everyone I talk to is asking about the product and the pricing model (see VSAN Pricing and Implications). More than once now, I’ve seen a wince or the written equivalent. I can certainly understand, as an extra $15K in licensing to a six CPU cluster is far from trivial. My goal here is to unpack the pricing a bit to examine the value that’s being delivered (the value is non-trivial as well).

Virtual Distributed Switch

Perhaps lost in the discussion of VSAN features is that the VSAN license includes the Virtual Distributed Switch (also known as the vSphere Distributed Switch) for the cluster (since every cluster member is licensed for VSAN). For anyone who’s maintained networking for a group of hosts, this is huge productivity gain, bringing centralized management, consistent naming, “network vMotion” (maintaining network state during a vMotion), Network IO Control (NIOC), and Single-Root IO Virtualization (SR-IOV). These are premium features, normally only available in Enterprise Plus licensing, which bring a lot of value to a VSAN cluster.

Here’s a great note from Punching Clouds on the deployment of 16 VSAN nodes in minutes. This is made possible in large part due to the vDS’s template creation and push deployment capability.

Paradigm Shift – Unbundling Storage Software from Hardware

I think the first time I came across this concept was in a presentation by Jon Toigo http://www.drunkendata.com/ entitled Why Storage Costs So Much and What You Can Do To Bend The Cost Curve.  It’s been almost five years, but I actually found the slide I remember.

Toigo’s thesis is that all storage appliances contain essentially the same commodity components under the hood; What makes a Tier 1 appliance more expensive is the Value-Added Software, the Channel, and Service/Support costs. I’d push back a little on this, pointing out that there’s definitely some custom silicon in some of those solutions, as well as engineering effort around and inside the chassis. Not all arrays are built on 3rd party platforms. The thesis of bundled software, however, remains intact. As much value might be in the chassis engineering, storage is drives, aggregation and management software, and connection/fabric.  Any premium charged to the customer over a generic white box storage appliance has to be justified. And some of those cost premiums are quite high.

But back to the bundling thesis. A major cost is having the storage management software bundled with the hardware appliance. Buy a Tier 1 appliance, pay service and support for upgraded software during the ownership cycle, and at the end, you can’t transfer that software to a new appliance. You buy it all over again. The disruptive model that VSAN brings is the ability to buy the storage smarts independently of the storage hardware and transfer the license to a new piece of hardware at any time in the lifecycle of the hardware. Remember the closed platform of the traditional appliance? VSAN uses commodity x86 CPU cycles to run its software, the same commodity x86 CPU cycles that receive the most development and performance attention due to the sales volume.

I’d also like to point out that VSAN isn’t the first software to take this approach. HP’s StoreVirtual (decended from the Lefthand VSA), Datacore, even the VMware VSA unbundled storage smarts from the array. So there’s even more to the value story, isn’t there?

From RAID to Policy Based Storage

The previous iteration of unbundled storage software and storage appliances relies on RAID hardware controllers to handle resiliency. RAID controllers offload the processing power of RAID-based resiliency from the general purpose CPU to specialized silicon. This was especially helpful with the popular use of parity RAID, before general purpose CPU core counts and processing power went up, and before drive space was expensive relative to processing power. Today, parity RAID is less usefu, per-GB storage costs have crashed, multiple copies of data is the gold standard for data protection. To accomplish this, VSAN uses general purpose CPU cycles to create N+1 copies of the data, determined by per-VM policy.

Ok, what does that mean? In effect, administrators can adjust the policies that affect VSAN striping and number of failures to tolerate on a per-VM basis. Perhaps you determine that one of your VMs needs an increased stripe width to help destage writes or increase the speed of read caches misses. You can make that change for the individual VM rather than for all the VMs on the storage. In addition, you can make that change after deployment.

So what do you think? Does this represent more VSAN Value than you’d originally thought?