One of the most anticipated components of the 2015 release of VMware vSphere 6 was the long-awaited Virtual Volumes technology. Virtual Volumes (VVOLS) is not a product that is purchased, but rather a set of APIs that can leveraged by a storage array. VVOLS enabled policy-based, VM-level control over storage on any array that implements the technology.
In the 2016 State of Storage in Virtualization report conducted by ActualTech Media, survey respondents were asked about how they believe VVOLS can improve their storage environment. Respondents were allowed to select multiple answers. As seen in Figure 1, the most widely appreciated feature about VVOLS is the way it enables Storage Policy-Based Management (SPBM). Let’s take a look at all four of the ways survey respondents believe VVOLS will improve their storage environment.
Storage Policy-Based Management
SPBM is a key piece of the overall software-defined data center vision. At a basic level, SPBM is the ability to assign policies to virtual machines and have those policies dictate requirements for things like capacity, performance, availability, or replication. The policy engine will then leverage the capabilities of VVOLS to ensure that the virtual machine the policy is applied to has all the correct service level requirements met.
In a data center which is not software defined, the service levels which are applied to a given VM are applied by nature of being inherited from the datastore and volume the virtual machine is stored on. If the datastore volume is replicated, the VM is replicated. This causes a management headache as the environment grows because each unique combination of service level requirements needs a separate datastore. VVOLS and SPBM working together solve this problem by applying service level requirements at the VM-level rather than the datastore/volume level.
Storage Provisioning by VM Admins
The typical workflow of storage provisioning goes something like this: 1) Virtualization administrator requests storage of a certain capacity and performance from storage administrator, 2) Storage administrator and VM administrator argue over the exact needs, 3) Storage administrator provisions storage, 4) VM administrator finally consumes storage and provisions workload. This process is cumbersome, frustrating, and a well-known waster of time.
VVOLS changes the nature of storage provisioning. Rather than requesting new storage each time the virtualization administrator has a new service level or capacity requirement, VVOLS allows a large pool of storage resources (called a Storage Container) to be provisioned up front. The pool of storage is then carved up and provisioned at will by the virtualization administrator without the need to interact with the storage team. The Virtual Volume construct ensures that the storage being provisioned has all the correct capacity, performance, and data services characteristics.
While the previous benefit relieves stress for the virtualization administrator, this one improves the life of the storage administrator. By nature of the Virtual Volumes construct, the storage administrator can see storage metrics all the way down to the VM granularity. No longer must the storage admin team up with the VM admin to try to correlate storage performance data with ESXTOP data with vCenter performance data to try to find a VM causing performance problems. Right from the storage array, the operator can see which VM is hogging up the IOPS, for example. This alone could save countless hours of time, especially in larger environments.
The final VVOLS benefit to survey respondents was that of the scalability improvements VVOLS offers. A bit of background is required to understand this one. Prior to VVOLS, block storage was provisioned to the hypervisor (ESXi) as a Fibre Channel or iSCSI LUN. ESXi 6.0 support a maximum of 256 LUNs. In a large-scale environment (Service Provider, for instance) this can become a limitation of the platform. Rather than the traditional concept of LUNs, however, VVOLS uses the previously mentioned Storage Container construct along with a logic I/O proxy called a Protocol Enpoint. This architecture allows an ESXi 6.0 host to mount up to 64,000 Virtual Volumes – a staggering improvement in scale when compared to LUN-based management.
As you can see, Virtual Volumes technology has potential to make a large impact on your data center. It is especially crucial in efforts to adopt a software-defined approach to data center operations and management. As a reminder, VVOLS functionality is implemented by the storage vendor on the array. So in order to fully utilize the features that VVOLS offers, make sure any array you consider takes full advantages of the APIs made available by vSphere.