VMware introduced a new feature in Sphere 6.0 called Virtual Volumes or VVols in short. VVols allows a granular storage management of virtual machines. Storage related policies can be applied to virtual machines instead of to LUN’s.
If you are planning to use VVols it is important to understand the components and dependance of Vvol components.
From what I understand currently not many customers are using VVols in a production environment.
One of the components required to use VVols is the VASA Provider. The VASA provider is software which sits between vCenter Server and the storage array. The VASA provider is required for certain actions like creation of a VM, start a VM, migrate (manual or automated by DRS), edit settings or create snapshot. The actual IO stream of the VM does not depend on the availability of the VASA Provider.
Storage vendors are free in how to implement the VASA Provider. Some implement it as firmware in the controller, some as a virtual appliance.
HP has VASA Provider software built into the 3PAR StorServe array. Also Nimble Storage and Solidfire implemented the VASA Provider in the array.
NetApp decided to build the VASA Provider as a virtual appliance. Other vendors which are using a virtual appliance are Hitachi, IBM. EMC (VMAX) and Dell EqualLogic.
NetApp FAS running Clustered Data ONTAP 8.3 support VVol’s.
The VASA Provider should be stateless. That means no important data required for a proper operation is stored on the appliance. However NetApp does store data important for VVol operations on the VASA Provider appliance.
NetApp writes in this post
When you work with VVOLs, you must back up the vCenter Server and VASA Provider for clustered Data ONTAP on a regular basis. The vCenter Server and VASA Provider maintain information about the VVOL datastores. If the vCenter Server or VASA Provider server goes down, you risk losing the entire VVOLs environment.
<update> This writing seems to be incorrect. NetApp warning about the loss of vCenter is related to the loss of storage policy configuration information specifically
So let this be a warning! When using VASA Provider as virtual appliance make sure:
- the VASA Provider appliance is not installed on a VVOL
- backup on a regular base the VASA Provider and vCenter Server
- know how to restore the appliance. Recovery of a Netapp VASA Provider could be complex. See comment in this post.
- Ask NetApp how to make the VASA Provider appliance high available
VMware has a special VASA Provider High Availability (VPHA) category in the compatibility matrix.
Some VASA Providers can be deployed in an active-active configuration, some in active-passive.
VASA Providers in active-active are:
- NexGen VASA Provider 1.0
- SANBlaze VASA Provider 7.3
VASA Providers in active-passive are:
- IBM Storage Provider for VMware VASA version 2.0.0
The text below was copied from the VASA 2.0 Programming Guide.
VASA 2.0 allows multiple providers to manage the same array, and introduces the activateProviderEx call to designate the primary provider. Providers can be implemented as active/active or active/passive. In active/active mode, all providers can manage a storage array, so they must share state and coordinate underlying resources. In active/passive mode, one provider acts as primary and the other acts as standby for transfer of responsibility if the primary provider becomes unreachable.
Figure 2-2. VASA Providers active/active and active/passive Figure 2‐2 shows a setup where SMS on vCenter or vvold on ESXi treats VASA Providers A and B as both active for storage array BA, and VASA Providers X and Y as active/passive for storage array YX. For active/passive mode, the VasaProviderInfo data object’s needsExplicitActivation property must be set to true. For active/active mode, it must be set false, so SMS does not call activateProviderEx unnecessarily. When it detects loss of connectivity for an active/passive provider, the VASA client can call activateProviderEx, specifying the standby provider to designate as the new primary, and the non‐responding provider to be replaced. It is the responsibility of the standby VASA Provider to coordinate the handoff. For an active/active pair of providers, the activateProviderEx call might be unnecessary, but currently occurs anyway.
Cormac Hogan has a great blogpost about the availability of vCenter and the VASA Provider here.
This Veeam forum thread also has info.