In vSphere 5, visibility into the storage arrays that support a VMware virtualized server environment got a whole lot better with the addition of a new set of vStorage APIs, the vStorage APIs for Storage Awareness (VASA).
These APIs provide a way of extracting information about the storage arrays that support a virtualized server environment so that the virtualization layers can make better decisions about where to place data.
This functionality is important to virtualization and storage administrators because it enables hypervisor management tools to access information about the capabilities of a storage array, such as native thin provisioning, deduplication, spindle speed, interconnect speeds, etc. This information can then be used in tasks such as capacity planning, automation and orchestration.
The APIs also help an administrator or tool to build a profile about the underlying storage subsystems. These profiles can then be used by virtualization administrators to better manage the storage.
To illustrate how this works, let’s examine two use cases, one with the vStorage APIs for Storage Awareness and one without.
Case 1, without VASA: A heavily used Microsoft SQL Server database with heavy I/O load in utilization and IOPS is on an array that needs to be updated. To address the problem, the administrator finds free space somewhere else and puts the database there, but the new location has half the performance of the original storage location. This migration has a dramatic negative effect on a business-critical application.
Case 2, with VASA: A heavily used Microsoft SQL Server with a heavy I/O load in utilization and IOPS is on an array that needs to be updated. To address the problem, using information from VASA, the virtualization administrator searches for a storage location that has similar performance characteristics of the original storage location, and moves the database to the new location.
With the vStorage APIs for Storage Awareness, the virtualization administrator can make an intelligent decision, rather than simply find free space, and he can also prepare users for a possible pending slowdown.
Case 2 is a perfect scenario for automation and orchestration within the virtual environment, which have been enabled by vSphere 5’s Storage Distributed Resource Scheduling (DRS) feature. Using information from the prebuilt VASA profile within VMware vCenter, Storage DRS automates the placement of storage workloads based on contention to similar storage locations.
Granted, at the moment, among hypervisor vendors, VASA is used by only VMware, but other hypervisor vendors could use SNIA’s Storage Management Interface Specification (SMI-S) APIs to get similar data and thereby allow non-VMware virtualization administrators to take control of their storage without running to a storage administrator for information every time they want to migrate a VM between data stores.
As more capabilities are available to VASA, storage profiles and automation will improve. For instance, it will be possible in the future to specify that a particular VM will always reside on an array that has deduplication, replication, thin provisioning and high IOPS.
Unfortunately, in virtual server environments with arrays that don’t support VASA, virtualization administrators will have to build such profiles by hand, in their heads or on a spreadsheet -- until their arrays do support VASA. And they’ll need to solicit input from the storage administrators, whose time could be better spent elsewhere.