VMware's Virtual and Physical SAN Misdirection

I almost fell off my chair laughing as I read this post by Chuck Hollis that talks about using vSphere VSAN (Virtual SAN) with external storage arrays. Is it the rantings of someone clinging onto the vestiges of a former life, or perhaps it’s a veiled way for VMware to start unravelling their failed VVOL strategy?

Let’s do some scene setting. VSAN or Virtual SAN is VMware’s attempt to counter the hyper-converged players who have carved out a niche in the market by physically merging the storage and hypervisor hardware and software into one single unit. VSAN allows customers to cluster three or more ESXi hypervisors together and use local storage, supplemented with flash, to act as a single virtual datastore repository. Data is spread across the cluster and can be made resilient to tolerate node and/or disk failure.

VMware have made a massive push on VSAN with their corporate bloggers writing dozens of posts over recent months (Duncan Epping 38 posts, Cormac Hogan 25 posts, William Lam 14 posts to name but a few) and speakers at every VMUG around the world. The company clearly wants to do something to grab a share of the revenue that Nutanix, SimpliVity, Maxta, Atlantis and others are managing to generate by simplifying or in some cases removing external storage from virtual server and desktop implementations.

VVOLs are VMware’s attempt to encapsulate the virtual machine into a logical object on disk that can then have policies (performance, resiliency etc) applied to it, rather then today’s somewhat messy collection of files that comprise a vSphere virtual machine. Startup vendors such as Tintri have been managing VMs at the object level for some time (founded in 2008, shipped product since 2011) by storing the VM on NFS, which is much easier to manage than block storage. Technical previews of VVOL have been around for 18 months or more, yet the feature still hasn’t materialised.

Virtual on Physical

So let’s talk about VSAN and its applicability to shared storage. The whole focus of VSAN was to move customers away from needing shared physical storage. In fact this has been one of the marketing messages since the technology was first conceived. VSAN removes the issues of dealing with those pesky storage teams, those expensive and complex storage arrays and takes us to a new world of simplification and ease of use where all of our resources live happily in the server.

However, as I have discussed many times, the external storage market has brought us resilient, highly available and feature rich products that deliver consistent and predictable performance, especially as we move into the widespread deployment of solid state. Shared arrays offload “heavy lifting tasks” through VAAI. They support efficient replication, compression, de-duplication, deliver quality of service, proactive device sparing, data scrubbing, integrity checking and multi-tenancy, plus a whole lot more.

Of course many of these features are not available in VSAN 1.0. The initial release doesn’t support even support vSphere features such as Fault Tolerance, Storage DRS, SIOC or Distributed Power Management. Some of these are features which work well with shared storage and as a result would be lost in a VSAN/PSAN (physical SAN) model.

But could VSAN with PSAN offer anything? Screen shot snippets from Chuck’s blog highlight soft benefits such as “simpler, automated provisioning”, “application storage resource managed by VM teams” “Leverage strong vSphere integration” and “Frees storage team from day-to-day requests”. Frankly these statements are nothing more than hogwash or marketing fluff at its best.

VVOL becomes VSAN

But what about VVOL? The implementation of VVOL is hampered by two things; the first is the Fibre Channel protocol itself, the second is the effort required for storage vendors to re-design their products to support VVOL at the scale VMware are looking to achieve. No vendor today, for example would be comfortable or even capable of supporting arrays with hundreds of thousands or millions of VVOL objects. See my previous comments here and here for more details.

If VMware can’t deliver VVOLs, then why not create another layer of abstraction between the storage and the hypervisor and use VSAN as the datastore “container” for virtual volumes? Now I get to apply my policies of resilience and performance at the VM level, rather than having it within the storage and VSAN acts as the arbitration layer, determining the best physical storage to use for the deployment of my VM and to deliver the policy features I require. In some ways it almost makes sense although we have to be careful we’re not approaching Frankenstorage again.

The Architect’s View™

Hyper-converged solutions are a great idea but there are better implementations out there than VSAN (more soon on this). External block storage is still an issue with vSphere. VMware even killed off their Virsto acquisition, which could have bridged between the two. VVOLs have gone no further than technical previews. VMware is owned by the biggest storage company in the world. It’s not difficult to see the win-win scenario where VMware takes away the pain of VVOLs and the embarrassment of being owned by a storage company through the model of VSAN & PSAN. This may be a good thing.

Frankly, however with posts like this latest one from Chuck, customers will be wondering exactly what VMware’s strategy for storage actually is. Some may even think that VMware has no strategy at all.

Note: in follow up posts I’ll discuss why technology like Atlantis Computing’s USX could be a much better solution for using VSAN.