VVols simplifies the process of setting up and managing storage to support VMs by enabling VMware administrators and users to create specific storage policies. But under the covers VMware leaves the implementation of VVols to the storage array vendor. In this article we will compare different ways that storage vendors can implement VVols, different levels of VVols integration, and what they mean for a typical VMware environment.
A storage container is a logical storage volume that is created from the back-end storage to support specific policies. VVols allows for the creation of large numbers of storage containers, as many as required to provide the combination of storage characteristics needed by the VMs in the environment. This allows for the VM-level storage management that’s part of the appeal of VVols. This implementation, which is done through vSphere Storage API for Storage Awareness (VASA), involves a translation from user-oriented policy rules like availability or performance, to storage-specific characteristics, like media type or number of drives.
VVols Depend on Back-end Storage
How a particular array performs that translation of policies into storage characteristics is completely up to the array vendor (within the structure of VASA) but is dependent upon the array architecture. For example, a storage system with flash drives could support a ‘high performance’ container by simply creating it out of any available space, since flash performance is essentially homogeneous. A disk-based array would most likely put that same container into a high spindle-count, RAID10 volume.
This fact, that storage characteristics are functions of the back-end storage itself, means that changing the policies associated with a particular VVol requires migrating that VVol into another container. For example, if a VVol needed more performance that could mean moving it from a disk-based container to a flash container, something VMware can do with Storage vMotion. And although this process can be automated with VASA APIs, it still requires that the VM be “stunned” and data be moved.
This requirement to migrate VVols between containers, and specifically, between the physical storage behind them, can impact VM performance, since the array controllers and the host processors must handle this overhead. The act of stunning or quiesing the VM will impact performance as well. And when migrated between separate storage systems, network latency must also be taken into account. How they handle this migration is one of the things that differentiates the way storage systems support VVols.
For this comparison of VVols implementation, we’ll use the following overly simplistic scenario. A VMware Administrator using VVols has created two policies, Gold and Silver, to support VMs with different performance requirements. The Gold policy maps to a container that’s comprised of only flash drives and the Silver policy maps to a container comprised of only disk drives.
How Storage Systems Implement VVols
At the most basic level of VVols compatibility the VMware environment above could use two storage systems. Array 1, an all disk array, would support the Silver container with a disk-drive storage pool and Array 2, with all-flash drives, would support the Gold container.
The VMware administrator only has to create policies for each tier that describe the specific performance they need (Gold or Silver) and then choose which one they want to assign to each VVol. But the storage system still needs to put those VVols into the right physical storage pools (that support each container), and if they want to change policies, the system has to move those VVols to other pools. In this case, if a VVol’s policy is changed from Gold to Silver, then data is migrated from Array 2 to Array 1.
At a higher level of VVol integration both containers could be housed in the same storage system, assuming the array had the ability to create both the flash and disk storage pools. This could be a traditional enterprise array or a hybrid storage array that has flash and disk-drive tiers. In this scenario, Gold would be carved out of an all-flash tier and Silver would be a disk-drive-only tier.
Users can change storage policies for VMs without moving its VVols between arrays, but data must still be migrated between containers (and tiers) on a single array. This eliminates network latency and the processing by two different storage controllers, but still involves migrating data.
No VVol Migration
Hybrid storage arrays that leverage caching and automated data placement can support a higher level of VVols integration. These systems are continually updating that placement of data to reflect current usage. When a file is left idle, the system is moving it to a lower performing tier automatically and to a higher tier when it’s active again. This takes the inherent capabilities of hybrid arrays, the ability to continuously update data placement based on current policies, and applies them at the VM level, instead of at the LUN level.
This level of integration also eliminates the need to change performance policies, since the system accommodates fluctuating performance demand automatically. The result is a storage system that’s ideal for VVols. These systems also simplify the creation of storage containers, since they essentially use a single container to support all performance policies. However, they also assume adequate resources will be available to support all VVols.
The I/O Blender and Overprovisioning
When the environment is running under ‘normal’ conditions these basic data placement algorithms typically work fine. But as VMware administrators know, things can change quickly in a virtualized environment. When activity peaks the “I/O Blender” effect can kick in causing storage resource contention. This can result in performance issues or the need to overprovision in order to cover these peak demands for all VMs, since the system can’t tell which VMs are the most critical.
Some hybrid storage systems are providing a software-defined Quality of Service (QoS) capability that can actually prioritize VVols when there is contention for performance on the system. This eliminates the need to overprovision in order to accommodate all VMs and guarantees that the most critical VMs get the resources they need first.
VVols have the potential to improve management and increase the efficiency of storage systems supporting virtual environments. But the implementation of VVols varies between vendors creating very different experiences for both users and storage administrators, especially when storage policies are changed.
At a basic level, most VVol implementations will provide VM-level, policy-based storage management. But they can still require VVol migration when policies change, leaving the ‘heavy lifting’ to the storage system. This can be a big problem as users, removed from the actual data handing in the underlying storage, may be unaware of the performance impact that VVols are putting on the system.
Hybrid storage arrays improve on this basic implementation and address the problem of data migration. By leveraging their ability to automatically move data blocks between storage tiers they can eliminate VVol migration and consolidate storage containers, but may still have trouble when storage demand spikes.
Some hybrid storage systems have added a software-defined QoS capability to resolve these issues with storage contention. By prioritizing VVols they can ensure that the most critical VMs get the resources they need first, even during peak demand periods. This implementation of VVols looks to provide the power and simplicity of VM-level management while maintaining storage performance and efficiency, even under the unpredictable conditions common in virtual environments.
Sponsored by NexGen Storage
About NexGen Storage
NexGen builds hybrid flash arrays with data management capabilities that enable their customers to prioritize data and application performance based on business value. The goal is to avoid the high cost of all-flash arrays that treat all data as high-value data. Their integration with VVols allows for even more intelligent data prioritization without the penalty of having to move data between different physical storage systems or between storage containers on the same system.