With the release of vSphere 6.5, I have noticed a renewed interest in the adoption of Virtual Volumes. One of the top topics of discussion with customers has been the VASA Provider and the way in which storage vendors are providing it as part of their Virtual Volumes implementation. Well, I think it’s time for me to shine some light on the topic and what I have been discussing with customers and partners recently.
Just in case anyone reading this article is new to Virtual Volumes, let me provide an abbreviated description of what the VASA Provider is and its importance for the use of Virtual Volumes just to set the context for the discussion.
The VASA Provider is a critical software component of the Virtual Volumes architecture framework. While VMware develops the Virtual Volumes framework, the VASA Provider is designed and implemented by the storage vendors to support their storage solutions. The VASA Provider is responsible for some for the most critical functions of the 
framework including some of the communication aspects between vSphere and storage arrays. Below, I have listed some of the essential functions the VASA Provider is responsible for:
- Provides storage awareness services
- Centralized connectivity for ESXi and vCenter Servers
- Responsible for creating Virtual Volumes (vVols)
- Provide support for VASA APIs used for ESXi
- Responsible for defining binding operations
- Offloading VM related operations directly to array
As you can see, these are also the most critical functions for Virtual Volumes. In reality, it’s fair to say that the VASA Provider is kind of the brain of the framework and without it, Virtual Volumes will not work as intended. It’s kinda of a big deal. BOOM!
This brings me to point out the importance of the adequate design, availability, and implementation of the VASA Provider. It is important to note that the development of the VASA Provider, along with all of the vendor’s specific characteristics is completely up to the storage vendors. They are to achieve that based on the standards that have been provided and developed by VMware.
When customers are looking into the adoption of Virtual Volumes, they are interested in knowing the details of the VASA Providers implementation and its characteristics before making the actual decision of adopting Virtual Volumes and what particular vendor to choose.
Know that the implementation of the VASA Provider is supported in one of two ways:
- Designed and built into storage arrays management service or controller firmware
- Designed and constructed in the form of an out-of-band Virtual Appliance
For the initial release of Virtual Volumes (vVols 1.0), most storage design partners selected the Virtual Appliance model for their implementation of the VASA Provider. Considerations for
taking the Virtual Appliance implementation approach may have been due to engineering resources and the amount of time and effort required to modify their current storage architectures and concepts, to implement the new storage architecture, concepts, and technologies being introduced by the Virtual Volumes framework. This was one of the reasons for that initial VASA Provider implementation approach, but there were others which I’m not at liberty to discuss.
Regardless of what those facts were, this was the direction taken by some of the early design partners and well-established storage vendors in the industry that represented the largest storage footprint in the data center. (Hitachi, NetApp, Dell, EMC (Now DellEMC).
On the other hand, the new and up and coming storage vendors, who have a more modern and adaptable architecture, such as SolidFire, Nimble Storage, NexGen Storage, etc. did not necessarily face the same challenges and constraints as the other larger storage vendors. This allowed them to adopt and implement the new storage architecture, concepts, and technologies that were being introduced by the Virtual Volumes framework into their products. Some vendors were able to implement their VASA Provider as part of their management service and embed into the storage controller.
Over time, I’ve paid close attention to these types of discussions, and I’ve noticed customers and vendors positioning the controller embedded implementation as the preferred approach. As a result of these assumptions, the controller integrated implementation has become the preferred method for the VASA Provider.
I can understand how customers and vendors may have initially arrived at this conclusion when the focus is around operational efficiencies. But, I can raise the same arguments for the very same reasons and position them for the Virtual Appliance implementation.
I often see these types of comparisons being drawn between storage vendors. In reality, that should not be the case and here are some of my points as to why.
Caveat: keep in mind that the points and observations that I will be highlighting are not meant to be taken as a competitive comparison in any way, shape, or form.
The purpose of my observations is to introduce a different perspective, so that when conducting an evaluation of the pros and cons of both types of VASA Provider implementations you may have a few more insights to draw upon.
My points of discussion focus on operational efficiency, infrastructure manageability, and risk mitigation considerations. They are not based on the storage features, capabilities and other data service related technologies of any particular vendor.
VASA Provider: Controller Embedded vs. Virtual Appliance
Below, are a few of the enterprise infrastructure characteristics on which my observations are based on.
- Manageability
- Availability
- Failures
- Risks
- Cost
Unless you are at a point of procuring new hardware, the requirement to have the VASA Provider embedded in the storage controller should not be a deciding factor. To my knowledge, storage vendors do not offer customers the option to purchase newer storage controllers that may include the VASA Provider for Virtual Volumes and allow them to swap out the older storage controllers.
From a manageability perspective, I can see the value of having the VASA Provider embedded in the storage controllers in large enterprise infrastructures composed of a multitude of storage solutions. In these types of environments, this immediately becomes attractive due to the increased manageability, availability, and ease of operational infrastructure.
Not having to worry about the management of virtual appliances, not having to deal with their potential failures and availability concerns, reduces the risks of potentially having a significant storage domain (Virtual Volumes) failure.
Consider the following:
What if your preferred storage vendor doesn’t have or support the controller embedded VASA Provider for their Virtual Volumes solution?
Would you completely write off all of the benefits (cost, features, operations, etc.) provided by that vendor’s solutions for your infrastructure and business? All because you may have been lead to believe that the alternative implementation of the VASA Provider is not optimal?
Are you willing and able to procure an entirely new storage solution from a newer storage vendor to overcome the limiting issues? But, then does the solution satisfy the rest of the infrastructure and business requirements around costs, technologies, and functional requirements? It may or it may not.
For example, new vendors can implement unique ways to overcome any potential limitation and concerns about the embedded VASA Provider. One of those vendors is SolidFire. They have introduce a unique distributed architecture
for their VASA Provider design and implementation as part of their storage platform service. But, does their solution satisfy the rest of the infrastructure costs, technologies, and functional requirements you infrastructure needs? It may or it may not.
Now from an operation efficiency and risk assessment perspective consider the following when the storage solution has the controller embedded VASA Provider:
Typically, enterprise infrastructure are composed of a vast number of storage arrays which include models, vendors, etc., what happens when firmware upgrades are needed or required?
How many storage frames need to be upgraded? What are the potential risks of upgrading? Accessibility and availability are questioned here. What is the impact to the manageability of the infrastructure from an operational efficiency perspective at that point?
All of this because the Virtual Appliance VASA Provider model has been deemed as not optimal for various reasons, one being the inability to provide an adequate level of availability, equivalent to the levels offered by storage controllers.
I tend to take a pragmatic approach when observing these scenarios so that I can understand the full spectrum of what is going on and what is at stake. It’s is pretty safe to say that you are only going to have the option to get the VASA Provider embedded into storage controllers if you are going to purchase new storage arrays which may or may not provide that option. May want to consider this, by the way.
The Virtual Appliance VASA Provider just like the controller embedded VASA Provider has its set of pros and cons which need to be considered and evaluated in a similar fashion to what I have presented above for the controller embedded VASA Provider.
There are some pretty significant valuable capabilities that the Virtual Appliance VASA Provider delivers from a risk mitigation and operational perspective. Here are some examples:
In enterprise infrastructures, which are composed of a vast number of storage solutions and arrays, performing upgrades are risky and daunting tasks for any storage infrastructure.
This is number one, because of the sensitivity of performing array-based firmware and controller upgrades.
Number two, the frequency of required upgrades has to be considered. With the controller embedded VASA Provider, these are facts to consider from that perspective. Where with a Virtual Appliance VASA Provider, this could be achieved in a much more efficient manner (upgrading one or a couple of appliances) with a much lower exposure to risks of bringing down the storage system.
From an availability standpoint, the question could come down to the availability of your infrastructure for that matter, but beyond that why would anyone feel that the Virtual Appliance VASA Provider is inferior to the Controller Embedded VASA Provider? They are the same and are based on the same framework. Here are some facts, if you are under the assumption that the Virtual Appliance VASA Provider is a single point of failure to your storage domain or it can expose you to limited functionality outages if the Virtual Appliance was to fail.
The VASA Provider framework is designed to provide its high availability service, and it is based on two functional behaviors active/passive or active/active. You can deploy multiple Virtual Appliances for high availability. They are low-maintenance appliances that required minimal administration.
You don’t have to depend on vSphere to provide availability for the Virtual Appliance, but this is something that comes as an additional value for running the Virtual Appliance VASA Provider.
A question posed to your storage vendor should be whether or not their VASA Provider implementation uses the high-availability feature within the VASA Provider framework – because it is up to them to decide whether to use it or not.
Here is another question to ask – how much faster can you recover from a Virtual Appliance failure vs. a storage controller failure?
Hopefully, folks may now be able to clearly quantify and evaluate the pros and cons and possible misguided perception of the Virtual Appliance VASA Provider which may have deterred anyone from choosing a particular vendor’s Virtual Volumes solution because of the VASA Provider’s implementation details.
Understand that I’m not choosing one implementation over the other, but just presenting some additional facts to consider. The framework provides the tools and functions business need to feel confident with their adoption of Virtual Volumes if they wish to. The implementation details of the VASA Provider should not keep anyone from adopting Virtual Volumes for your enterprise.
Now that I feel we can move past the VASA Providers concerns, and focus on what matters. Ask the vendors whose solution you may be considering for Virtual Volumes about the following:
- Scalability – Total of Virtual Volumes supported per array or frame
- Storage Containers – how many are supported
- Protocol Endpoints – how many supported, how many supported per storage containers.
- Space Reclaim – Do they leverage the space reclaim APIs
- Storage Policy-Based Management – Is the solution integrated with SPBM
- Array-Based Replication – is it supported? This is a new feature part of vSphere 6.5 and Virtual Volumes 2.0
The wrong answers for any of the items listed above should and could become blockers to the adoption of Virtual Volumes based on infrastructure and business requirements. These limitations are vendor specific and not limitations relating to VMware software.
I hope this will be found useful. If it sounds too complicated, I would highly recommend taking a look at my all time favorite Virtual SAN (vSAN).
That last line was for you Keith Norbie. I know you’ll appreciate it. See you on the wild side buddy Boom!!! Get Some!!!
-Enjoy
For future updates on Virtual SAN (VSAN), vSphere Virtual Volumes (vVols) and other Storage and Availability technologies, as well as vSphere Integrated OpenStack (VIO), and Cloud-Native Applications (CNA) be sure to follow me on Twitter: @PunchingClouds.
