Let’s start with the VASA provider. This is the component that sits between the array and vCenter server/ESXi hosts. It provides the out-of-band communication path between the ESXi host and the storage array for VM/VVol tasks, as well as surfacing up the array capabilities to the vCenter Server. These capabilities allow administrator to create VM storage policies, which are then selected during the virtual machine provisioning process.
The VASA provider can take different forms; some array vendors have it embedded in the storage controller while others run it in a virtual appliance. In the context of VVols, the VASA provider should ideally be stateless. In other words, if it goes away for some reason, this should have no impact on your VM I/O. Yes, it will impact the ability to do certain operations (such as the creation of new VMs, creation of snapshots, etc) since the communication path between the ESXi hosts and the array has been impacted, but losing the VASA provider should not impact the current running VMs.
One option is to configure the VASA provider in a HA mode, so that one VASA provider acts as the primary and the other(s) act as backups. This is what we have done with VSAN which also uses a VASA provider. This would be a good question to ask your storage vendor; can your VASA provider be setup in a HA configuration? If not, then you would need to deploy out a new VASA provider should you lose the existing one.
Now, earlier in this post I said that “ideally” the VASA provider should be stateless. There should be no need to store anything on the VASA provider. However that is not to say that some storage array partners have not put something stateful into their VASA provider that would no longer make them stateless. To be the best of my knowledge, VMware has not provided strict guidelines on how the VASA provider should be implemented; we have left this up to the storage array partners. This is yet another VVol question to ask your storage vendor; “If I lose my VASA provider, will it impact my existing VVols?”.
The other query that I have been getting a lot is in relation to vCenter Server availability. The VVol information that is stored by vCenter server relates to the VM storage policies that the VMs are using. Remember these are the policies created by the administrator based on the capabilities surfaced up by the array. Again, if vCenter goes away, this has no impact on the running VMs. The policy information associated with the VM continues to be used by the VMs. The issue is that if you do not have a vCenter server backup and you deploy a new vCenter, then it will not have the policy information for your running VMs. So these policies will need to be recreated, which is possible, though it might be a little tedious/manual. Again, we have ways of doing this for VSAN, and I suspect it is the same for VVols (though I admit I have not tried this scenario). This is why it is a good idea to back up your vCenter Server.
Note that failures in either of these components should not lead to data loss in VVols. I/O to VVols does not depend on vCenter or the VASA Provider. These are components needed for configuration and management, but should not lead to any sort of data loss issues if they are not present. The paradigm with the VVol architecture is that the storage is the source of truth, whilst the VASA providers is your guide. We would hope that the storage vendors follow this paradigm with their respective implementations, but just like the VAAI implementations of the past, that will probably vary from vendor to vendor.
I was involved in an interesting discussion with customers (on the Veeam forums) who have done some testing of this scenario with VVols. They have reported back the following. One customer, using a DELL EQL 6110S array (FW 8.1.0), installed a vCenter server, the DELL VASA provider, created some containers/VVol datastores, and deployed some VMs/VVols. He then deleted the vCenter server AND the VASA provider. Next, he installed a brand new vCenter Server and VASA provider, added the ESXi hosts (which had the containers/VVol datastores) to the new vCenter, and finally connected the VASA provider to the vCenter server. As per the customer, he then rebooted vCenter server once more and the ESXi hosts could see all the previously created VVols, and vCenter could see and manage all of the VMs. Obviously the policies would need to be created in this scenario.
I also read about a customer who was using the beta version of vCenter server 6.0 to test VVols on his HP 3PAR array. When the GA version of vCenter server 6.0 became available, he deployed the brand new version of vCenter server 6.0, and was able to see all of the VVols and VMs.
I am aware of a warning provided by NetApp. They are recommending that the vCenter and VASA provider needs to be updated regularly. They go on to state that “If the vCenter Server or VASA Provider server goes down, you risk losing the entire VVOLs environment.” This suggests that there is something stateful being stored in either the vCenter Server, the VASA provider, or both. I would recommend discussing this in detail with your NetApp reps if you are planning on using VVols with NetApp.
If you are doing any testing with other storage in this area, I’d really like to hear about your experiences in the comments section of this post.