vStorage APIs for Storage Awareness (VASA)

I am currently in Beijing halfway through a five city roadshow to present and listen to EMC’s technical pre-sales team. One of my roles in this traveling show is to talk about vSphere 5, and all of the great things EMC is doing to make it even better for customers. A big part of my talk is centered around the new vStorage API for Storage Awareness, or VASA. I think this new API is going to provide value far beyond what most people realize.

This new API allows VASA-enabled arrays (such as EMC’s VMAX and VNX) to expose storage architecture details to vSphere. Instead of only seeing a block or file device with some amount of capacity, VASA allows vCenter to know about replication, RAID, compression, deduplication, and other storage features. With this new information VMware administrators can create storage profiles that map to volumes. Virtual machines can then be assigned storage by policy, and not just the availability of space.

This is a subtle change in the way applications are mapped to storage with a potentially very large impact to the efficiency of virtual environments. If you think about it, until the creation of VASA, administrators were forced to manually enforce the mapping between applications and storage. Mistakes in this mapping could result in critical applications residing on unprotected storage. The other mistake is when low priority applications find themselves hosted on very expensive storage backed by high performance media, replicated, and on the nicest arrays in the environment. The first mistake can mean data is lost in a failure. The second mistake means much more is being spent on storage than needed.

The promise of VASA is that applications will always be properly mapped to their ideal storage. This introduce a new mechanism for application deployment, where applications are deployed to storage based on policy which is enforced by vSphere. Policy-based deployment will be more efficient and suffer fewer mistakes. The potential value to customers is very large.

My expectation is that VASA will not immediately resonate among storage companies’ pre-sales teams the way VAAI did. And without storage companies pushing it, customers may not realize the incredible power of this new API. VAAI is simple and sexy and its value can be seen in a five minute demonstration, as Chad showed when vSphere 4.1 launched.

But VASA is subtle. How do you demonstrate the value of guaranteeing a print server does not end up on solid state disks? How do you quantify the cost of lost data from a mission critical application that was placed on unprotected storage? Because these questions are not easy to answer, I fear the world will not realize the might of VASA. But, day-by-day VASA will uncover mistakes and the word will spread of fortunes saved because of policy-based storage deployment. Some day VASA will be recognized as one of the great additions by vSphere 5.

6 comments on this post.
  1. Johnny:

    Scott, great post. I think a lot of places generally name their datastores in a way that would tell you the underlying setup (EFD_datastore0, SATA_datastore5, etc). That is one way to prevent a VM from winding up on the wrong datastore. I can see VASA helping SDRS from making a wrong choice. I’m assuming VASA and SDRS will work hand in hand. Is that correct?

    -Johnny (@sd0a)

  2. drummonds:

    Johnny,

    You’re absolutely right. Smart admins have carried the time-tested programming practice of self-documentation into the infrastructure for many years. If I can extend that programming analogy further, self-documenting variables in C is good but does not avoid mistakes. Strongly typed programming languages (like Java) do. Having a language (or a management tool like vCenter) enforce policy is always better than asking developers (or admins) to do it.

    VASA and SDRS are what I will call “concurrent” technologies. They each provide supporting functionality along a similar direction. But they neither conflict nor require each other. Storage profiles can be defined with or without SDRS. SDRS can be run against clusters of storage without having VASA information to confirm the volumes similarity.

    But together they are awesome.

    Scott

  3. ChanEK:

    I’d be more interested to see the full technical details. Just creating a policy set alone (as highlighted in this article) so that vms can ve mapped to correct storage means nothing as this has always been the job of a sensible vmware admin. (it’s not like I’d create an sal vm and put it on a Sata datastore now is coz that would be stupid). Besides if you are sensible you’d incorporate some sensible datastore naming concept so that looking at the datastore you know it’s (default) owning controller, raid characteristics, and deduce level and the Lun ID (at least) so to me this mapping alone means nothing (but typical emc glorification of simple things. in my opinion, something like this will only cone handy if you incorporate svmotion in to drs. (perhaps this is the build up??)

    Anyways, like I said I’d like to see the full technical whitepaper to see what else it can do.

    However I woul like to see

  4. ChanEK:

    And never comment on a blog using an iPhone… Cox if you do, you end up with the kind odd of gibberish like above :-) sorry folks….!!

  5. Welcome to vSphere-land! » vSphere 5 Links:

    [...] 5 Video – Storage DRS (NTPro.nl) vSphere 5 What’s New – Storage Appliance (VSA) (NTPro.nl) vStorage APIs for Storage Awareness (VASA) (Pivot Point) Storage Changes in VMware vSphere 5 (Stephen Foskett) VMware Virtual Storage [...]

  6. VM Fan:

    cox if you do lol