ViPR VASA Provider

VASA stands for “vSphere Storage APIs for Storage Awareness”. It’s an initiative taken by VMware to better integrate storage arrays with the vCenter Server. Most mainstream arrays support VASA, including EMC’s VMAX, VNX, VPLEX and Isilon.

A VASA Provider is a web service that can run on a stand-alone server, or on the storage array. VASA defines a set of APIs that the vCenter Server makes to the VASA Provider. The goal of these APIs is that the vCenter administrator should be able to view the capabilities of underlying volumes, file systems, and corresponding Datastores. Knowing the storage capability of any datastore helps the administrator to choose the right storage for any given application.

When we released EMC ViPR software-defined storage, we simultaneously released a VASA Provider for ViPR. The VASA Provider for EMC ViPR conforms to the VASA specification, but is unique in many ways. Ours was probably the first implementation of a VASA Provider for ‘software-defined’ storage. In this blog post I will cover some of its unique features. For more specific details on VASA, please refer to VMware documentation for VASA.

Managing Data Center Growth
The VASA Provider is a service that is bundled and deployed along with ViPR. Therefore, by default, the VASA Provider is available as a service when ViPR is deployed. To ensure high availability, this service runs on every control node in a multi-node ViPR deployment.

The VASA Provider exposes ViPR as a single giant virtual array. The entire data center can be thought of as an array in this case. Beneath this there can be a large number of physical arrays. The advantage of this approach is that as more arrays are brought under the control of ViPR, the vCenter server is not affected. It doesn’t have to rebuild its inventory of arrays and storage processors when the infrastructure changes. The administrator doesn’t need to add a new VASA Provider every time a new array is added to the data center. This is a big advantage in a large and growing data center.
Managing Storage Capabilities
The concept of ‘storage capabilities’ is central to VASA. Storage capabilities can be thought of as ‘classes of service’ that a storage array can support. By knowing the list of such capabilities, the vCenter administrator can define his own ‘policies’ or rules for deploying a virtual machine to match the storage capabilities.

In ViPR terminology, classes of service are called ‘virtual storage pools’ (vPool). The vPools in ViPR are not hard-coded; they can be defined and expanded by the storage administrator dynamically. The VASA Provider exposes the vPools in ViPR as storage capabilities in the vCenter UI. Thus even a heterogeneous data center can show a consistent set of storage capabilities (think PLATINUM/GOLD/SILVER or any other names that you wish to use). This is much better to understand and manage than a complex mix of names which get exposed when using VASA Providers from multiple array vendors.

The dynamic nature of this scheme means that as you define a new vPool in ViPR (say, because you just added a completely different type of storage to your data center), this capability just shows up in your vCenter UI automatically. You can then start using it for your VMs.

Security and Isolation
The vCenter admin adds the VASA Provider to his virtual infrastructure by providing his credentials. The VASA Provider uses those same credentials to access the REST API. Thus only those volumes, file systems and storage capabilities accessible to that account get reported to that user.

Further, the volumes and file systems are pruned based on the physical FC and iSCSI adapters being managed by the vCenter. In a large deployment, we expect multiple vCenter servers to share a single ViPR installation, but each vCenter server sees only the resources relevant to it.

In the future, one can imagine a large cloud provider supporting multiple tenants, with each tenant having access to only its own resources. The VASA Provider is designed to help maintain the security and isolation required in such a scenario.

Monitoring Events and Alarms
The VASA Provider for ViPR reports events and alarms relevant to the exposed datastores to the vCenter. Thus, if a thinly provisioned LUN is running out of capacity, the vCenter admin will get to know this well in advance. He can then take appropriate action (move the VM to another datastore, delete some unwanted data, or expand the underlying physical storage).

For more information on this topic, watch a small demo of the ViPR VASA Provider here, and refer to the set of documentation here. Lastly, if you plan to use ViPR in your data center, I strongly encourage you to use the ViPR VASA Provider.

About the Author: Anil Degwekar