VVOLs, VASA - And Why It All Matters

Just about everyone involved with either storage or virtualization has heard the terms.  Maybe you have an idea of what the concepts are about. 

But not many people have a good understanding as to why these VMware technologies under development can be a really big deal for storage users — and their vendors.

 

I admit — my initial understanding was a bit thin in a few places.  But during my time here at VMware, I’ve come to have a much deeper appreciation of what’s going on in this space, and why it’s important.

 

If you already deeply  grok all of this stuff, feel free skip this post.  The rest of us might want to read on …

 

The Problem Statement

To keep things simple, let’s imagine a typical IT environment.

 

We have three components that are relevant.

 

First, there are any number of arrays — potentially from different vendors, each with potentially different capabilities.

 

Second, we’ve got an arbitrary set of applications, each potentially demanding different capabilities that — in theory — could be provided by the storage arrays.

 

And, finally, we’ve got a future-state vSphere environment that sits as an arbiter between what the applications need, and what the arrays can potentially provide.

 

The problem —  how do you match consumers to providers in a simple, easy and natural way?  Sounds easy, but getting there has proven to be very difficult indeed.

 

The First Model

 

The first approach — still in use today — was simply establishing different classes of arrays (high-end, mid-tier, NAS, etc.) and statically binding a given application’s VM to a specific array.  

E.g. all the important VMs go on this high-end array, all the not-so-important VMs go on this mid-tier array, and all the noncritical stuff goes on this really cheap array.

 

It’s a solution, but certainly not an ideal one.

 

For starters, it presumes that a given array can deliver only one level of service, which is not usually the case today.

 

Today’s modern arrays allow wide flexibility to deliver different levels of performance, data protection, tiering, replication, etc.  A given data store sitting on a modern array can vary widely in its policy characteristics, and can even dynamically change them in some instances.

 

Second, it sort of forced you to be really smart about what kinds of arrays you bought, how many, and when.  Storage arrays can be expensive beasts, they take significant effort to bring in and migrate data to and from, and you certainly don’t want to waste any capacity you’ve purchased.

 

So, in practice, this resulted in a fair amount of misalignment between what the array provided, and what the application actually required.  Since it’s always better to err on the side of safety, you saw a lot of higher-end arrays supporting less-than-critical applications.  

Certainly not as efficient and optimized as what we see in today's virtualized compute environments.

 

The Second Model

 

Once people starting taking advantage of the fact that a given array could potentially deliver multiple levels of service, things evolved to a better state.  Still not ideal, but better.

 

Storage administrators would create different classes of service within a given storage array — the quintessential Gold, Silver and Bronze approach.   Existing and new workloads would be assigned to a static level of service — established in advance by the storage administrator.

 

If service level requirements changed up or down, it involved was moving a given application’s data store to the appropriate pool within a storage array.  Yes, some effort was involved, but it’s less daunting than the alternatives.

 

Things are better in this model, as the resources are now pooled to a greater degree, and there’s less need for advanced planning.

 

But we’re still not in an ideal state for several reasons.

 

First, the storage administrator still has to go through a  have-a-hunch-provision-a-bunch planning exercise when any new array comes into service.   Re-carving your array resources into a different set of service pools isn’t exactly a simple task.

 

Second, we’re still not respecting individual application requirements — we’re simply shoving them into convenient, standardized and pre-defined buckets.  And that’s true for everything a storage array does: performance, protection, remote replication, encryption, etc.

 

Ideally, we’d have a per-VM (and per-application) storage profile for each and every application if desired.  No need to pre-allocate standardized buckets.  No need to specifically map a given application to a specific array.  The ability to adjust things up or down  — again, with that per-VM granularity that’s ideal.

 

And that’s what VASA and VVOLs aspire to do.

 

The Third Model

 

Let’s go back to our consumer/provider model, as before.

 

Ideally, each array could expose a manifest of capabilities it could potentially invoke.  

 

I am an array.  Here is how much capacity I have.  Here are my capabilities to use flash — either as a cache or a persistent store.  Here are the different provisioning modes: thin, thick, reserved, etc.  Here are my storage protection modes: RAID options, etc.  Here are my remote replication options: sync, async, etc.  Here is my ability to understand consistency groups.  Here is my ability to encrypt data at rest, and do dedupe, and all the rest of it.

 

All published in a machine-readable format, to be consumed later.

 

Now let’s look at it from a consumer side.

 

Here is an application being provisioned, ostensibly in a VM.  Here is what I think I need in terms of capacity, performance, preferred provisioning, protection model, replication, encryption, etc. etc. 

Maybe that’s been simplified into a standardized profile, but the required capabilities can be expressed on a granular per-VM basis if needed.

 

Imagine that request being passed down to a pool of storage arrays — potentially from multiple vendors — and the answer(s) come back: here are your choices.  Including the potential option of “your request can’t be satisfied — what would you like to do?”

 

Presuming the request can be satisfied, a data container is provisioned with the requested attributes (and no more!) for just what the application’s data store needs.  Should needs evolve (more/less capacity, performance, protection, etc.) that too could be expressed and satisfied dynamically.

 

Storage administration functions basically collapse into making sure enough resources are available (in aggregate) to satisfy consumer requests, and maintaining the general health of the storage infrastructure.

 

Conversely, storage provisioning now becomes an integral part of application provisioning: done at the same time and in the same way as other provisioning aspects: CPU, memory, etc.

 

It’s hard to imagine a slicker model :)

 

That’s What VASA and VVOLs Are All About

 

VASA (the vSphere APIs for Storage Awareness) is the standardized dialog between storage providers and storage consumers. 

VASA 1.0 is in use today, VASA 2.0 will expand the richness of the potential dialog between producers and consumers.

 

A VVOL, then, is the storage container provisioned using VASA.  It aligns precisely to VM boundaries.  It contains the data store, a set of data services expected, as well as maintains the metadata of the requested policy.  This latter point can be important as one considers policies that encompass regulatory compliance, for example.

 

Warning: Obstacles Ahead

 

While this all might seem ideal in theory, there are more than a few pragmatic challenges getting there.

 

First, we’ll need to wait for a future release of vSphere to get the required VASA 2.0 and VVOL support — but that is coming.

 

Second, VMware’s storage array partners have some heavy lifting to do.  Many arrays aren’t designed to expose capabilities and have them dynamically consumed — let alone do so aligned to VM boundaries.  

 

We’ll need to see things like rich VASA providers that expose much of the functionality that once was restricted solely to proprietary interfaces.  Implementing VVOLs (storage and services aligned to VM boundaries) presents additional challenges.

 

But perhaps the most challenging obstacle is that enterprise IT shops will have to evolve their storage model in multiple dimensions.  Simply carving out pools of LUNs (or file systems) won’t cut it any more — that will be done dynamically between consumer and provider.  Storage provisioning completely changes as a result.  Capacity planning changes, as does performance management.

 

It’s a big shift, especially in larger shops.

 

That being said, I think that once decent-sized VMware shops fully understand the implications of the new model, there will be strong enthusiasm to get there sooner than later.  And once that manifests itself, I’m sure we’ll see the highly competitive storage array crowd arguing who has the better implementation of VASA and VVOLs before long.  Things should move along quickly as a result.

 

The Road Ahead?

 

Embedded in the VASA and VVOL discussion is a real-deal, game-changing  Big Idea: that administrators can encapsulate a wide range of business policies — from simple things like performance and availability, to more nuanced topics like HIPPA compliance.

Best of all, this can be done at application provisioning time, binding those requirements to the VM itself, and then exposing those requirements in a consistent fashion to the supporting infrastructure in a consistent fashion.

It’s a radical thought, but an obvious one once you fully consider it.  It certainly changes the way we think about storage provisioning and operational models.

 

Ys, it’s a big, bold leap — but it needs to be done.

- See more at: http://chucksblog.emc.com/chucks_blog/2013/11/vvols-vasa-and-why-it-all-matters.html#sthash.8SdIOkqi.dpuf