How does Pure Storage integrate with vSAN?

I get this question quite a bit–in fact I got this question just today while discussing ways to grow the Pure Storage/VMware business. To folks who are close to the VMware storage ecosystem it might seem like an odd question, but it’s a good question!

VMware puts a lot of energy and time into vSAN. Lots of technical information, lots of marketing, lots of webinars, lots of great people discussing its ins and outs at VMware. So if vSAN is such a big storage thing at VMware, how does Pure support vSAN? What do we do with it? How can use deploy vSAN to use Pure Storage FlashArray storage?

Well let’s first take a look at what VMware really is offering with storage. VMware, at the highest level of storage is offering Storage Policy Based Management (SPBM). In a strong and steady movement away from caring about specific datastores, it is much more about the features and protections you want to apply to your VMs, or more specifically their disks. I want it replicated, I want it encrypted, I want it fast. Etc.

VMware offers three ways of deploying storage policies:

1. External storage. This is “SAN” storage. Storage arrays. External storage appliances. Whatever you want to call it. You can create policies that interact with your SAN storage to make sure the storage you provision apply the features that you need.
2. Internal storage. This is direct-attached storage (DAS), internal disk, etc. Storage that comes inside of the servers you buy. You can create policies that interact with your internal storage to make sure the storage you provision apply the features that you need.
3. Tags. Any type of storage! Tag it, and create policies based on those tags. But let’s focus on the first two.

vSAN is the SPBM implementation for managing internal storage. The reason VMware puts so much effort into promoting it is because internal storage is fairly primitive–or at least vSAN assumes it likely is. It is just capacity. It is not necessarily durable or highly available, it is not necessarily efficient, it is not necessary performant, it is not necessarily encrypted, it cannot replicate itself, it cannot snapshot itself.

The storage you put in a server stores data. That’s what it does. 1’s and 0’s.

Drives with no coordinated features (features that do not extend beyond a single drive itself) does not make for storage to run your business on. Customers need the ability to restore, to protect, to failover, to secure their data. So yes, this can be done at the software layer you might say, but it ALWAYS is–maybe the application, maybe your storage array, or maybe something in between. There is always software on top of drives adding value in production environments (or well there should be). Software covers more than a single drive itself. This is what vSAN does–it assumes the storage is rudimentary and adds those features in a software layer above. RAID, erasure coding, encryption, snapshots, etc. VMware invests a lot in building these features, so of course they give it a lot of focus. Very similar to an array, it puts special sauce on top of raw capacity.

But why limit vSAN to internal storage? Why not extend it to external storage too? Well, because it would be wasteful. Most external storage arrays offer these features already. Their very existence is based upon them building software on top of raw capacity. They replicate, they snapshot, they QoS, they encrypt, etc. etc. So putting the vSAN layer on that just simply doesn’t make any sense.

So to resolve this disparity, VMware built a storage policy engine that does trust that the underlying storage has production-class features. This is called Virtual Volumes (vVols). vVols is the SPBM implementation for external storage. vVols offers no “native” features. It does not create snapshots, it does not encrypt, it does not replicate, it does none of these things. It trusts the storage arrays to do this. It just tells them when to do it.

What vVols provides is the ability for storage vendors to take the features they spend so much time, resources, and thought on, and integrates them directly into the vSphere provisioning and storage management plane. At the level of granularity that matters–the virtual disk. Create a snapshot? The array creates a snapshot. Assign replication? The array configures replication? Failover? The array fails the storage over and prepares it at the DR site.

Yes, VMware is initiating it, but the array is doing the work. This is why Pure Storage has invested so much in vVols–there is no better way to provide the features we put so much effort in, into the vSphere environment. VMware doesn’t even specify what those features should be–the vendors can surface up their differentiation because of vVols.

This is also why marketing and pushing vVols has been mostly a storage vendor task. VMware provided the mechanism–but we do the storage work. We know our features better than they. It is our job to talk about what we do in the VMware environment.

So in short, How does Pure Storage integrate with vSAN? Well we don’t. It is the wrong question. How does Pure Storage integrate with SPBM? vVols!

It is our job to just do it better than anyone else! And that is a fun challenge. And it has been, and continues to be, a blast to work with VMware on growing this program out.