This chapter is from the book
This chapter is from the book
This chapter is from the book
VASA Vendor Provider
As part of the VSAN cluster creation step, each ESXi host has a VSAN storage provider registered with vCenter. This uses the vSphere APIs for Storage Awareness (VASA) to surface up the VSAN capabilities to the vCenter Server. The capabilities can then be used to create VM storage policies for the VMs deployed on the VSAN datastore. If you are familiar with VASA and have used it with traditional storage environments, you’ll find this functionality familiar; however, with traditional storage environments that leverage VASA, some configuration work needs to be done to add the storage provider for that particular storage. In the context of VSAN, a vSphere administrator does not need to worry about registering these; these are automatically registered when a VSAN cluster is created.
An Introduction to VASA
VASA allows storage vendors to publish the capabilities of their storage to vCenter Server, which in turn can display these capabilities in the vSphere Web Client. VASA may also provide information about storage health status, configuration info, capacity and thin provisioning info, and so on. VASA enables VMware to have an end-to-end story regarding storage. Traditionally, this enabled storage arrays to inform the VASA storage provider of capabilities, and then the storage provider informed vCenter Server, so now users can see storage array capabilities from vSphere Web Client. Through VM storage policies, these storage capabilities are used in the vSphere Web Client to assist administrators in choosing the right storage in terms of space, performance, and service-level agreement (SLA) requirements. This was true for both traditional storage arrays, and now it is true for VSAN also. Prior to the release of virtual volumes (VVols), there was a notable difference in workflow when using VASA and VM storage policies when comparing traditional storage to VSAN. With traditional storage, VASA historically surfaced information about the datastore capabilities, and a vSphere administrator had to choose the appropriate storage on which to place the VM. With VSAN, and now VVols, you define the capabilities you want to have for your VM storage in a VM storage policy. This policy information is then pushed down to the storage layer, basically informing it that these are the requirements you have for storage. VASA will then tell you whether the underlying storage (e.g., VSAN) can meet these requirements, effectively communicating compliance information on a per-storage object basis. The major difference is that this functionality is now working in a bidirectional mode. Previously, VASA would just surface up capabilities. Now it not only surfaces up capabilities but also verifies whether a VM’s storage requirements are being met based on the contents of the policy.
Storage Providers
Figure 4.6 illustrates an example of what the storage provider looks like. When a VSAN cluster is created, the VASA storage provider from every ESXi host in the cluster is registered to the vCenter Server. In a four-node VSAN cluster, the VASA VSAN storage provider configuration would look similar to this.
)
Figure 4.6 VSAN storage providers, added when the VSAN cluster is created
You can always check the status of the storage providers by navigating in the Web Client to the vCenter Server inventory item, selecting the Manage tab and then the Storage Providers view. One VSAN provider should always be online. The other storage providers should be in standby mode. This is all done automatically by VSAN. There is typically no management of the VASA providers required by administrators.
In VSAN clusters that have more than eight ESXi hosts, and thus more than eight VASA storage providers, the list of storage providers is shortened to eight in the user interface (UI) for display purposes. The number of standby storage providers is still displayed correctly; you simply won’t be able to interrogate them.