Efficiency, automation and flexibility are becoming higher priorities for the corporate data center. It's not enough...
for IT administrators to manually overallocate resources to support some VM. Resources are now expected to match the needs of each workload for optimum utilization and performance.
These priorities are affecting business storage technology. Storage is moving beyond a traditional logical unit number-based allocation in favor of more granular, policy-driven storage virtualization. VMware calls these Virtual Volumes (VVOLs) and provides support for them with vSphere 6. But virtualization pros need to understand the objectives, nuances, requirements and limitations of VVOL technology before deploying the technology in production.
Storage was the first computing resource to benefit from virtualization. Just consider the venerable disk partition. A partition is simply a construct that abstracts a magnetic disk's physical platters, tracks and sectors into logical instances that can store files -- such as a C drive or other logical unit number (LUN). This also works when provisioning logical instances from the flash memory cells and modules of a solid-state disk (SSD). By using partitions to create logical disk instances, storage users don't know -- or care -- where data is physically placed on a hard disk drive or SSD.
Yet storage didn't progress beyond that in the virtualization realm. Virtualization platforms such as vSphere 6 can easily provision, adjust -- grow or shrink -- and migrate virtualized processors and memory, but admins still create, assign and protect static LUNs for VMs and other workloads in much the same way they have for decades.
There are several problems with this legacy storage paradigm. For example, once a LUN is created, it typically cannot be changed or moved; it can only be backed up or replicated. A single LUN might also serve multiple workloads, each demanding a share of storage I/O to that LUN and potentially hurting the storage performance of other applications. In addition, significant storage changes such as adding storage capacity to a LUN or moving a LUN to a different tier of storage performance would require creating a new logical unit number, replicating data to it and redirecting applications to use it. This further disrupts multiple applications that might use the single LUN. So traditional storage provisioning lacks the flexibility and scalability that businesses expect from software-defined technologies, such as software-defined storage.
VMware addresses these storage issues with VVOLs. VVOLs use an expanded hypervisor layer to provide a new means of provisioning and managing storage that meets the needs of software-defined storage and is more consistent with other virtualized resources, such as processors and memory. To facilitate software-defined storage with VVOLs, VMware has added both a virtual data layer and a policy layer to vSphere.
The virtual data layer virtualized both storage area network and network-attached storage devices, creating virtual data stores in vSphere and allowing storage instances to be provisioned and managed on a per-VM basis. This means multiple workloads don't have to share the same LUN. This virtual data layer also identifies the features and capabilities of the storage subsystem, and can offer those as services to any per-VM storage instance, allowing a granular level of storage configuration and control. For example, one storage instance can be configured to use the storage array's replication, caching and deduplication capabilities, while another storage instance can use the array's snapshot and disaster recovery features.
The vSphere policy layer connects, monitors and manages the relationships established between these virtualized storage instances and the various features across multiple heterogeneous storage subsystems. This is accomplished through storage policy-based management (SPBM) using rules to translate storage service requirements into storage instances. For example, deploying an important VM might trigger the creation of a storage instance on high-performance storage and apply deduplication to reduce expensive physical storage capacity demands. The policy layer also integrates with self-service and cloud-type automation tools such as vRealize Automation and OpenStack.
The scenarios that are crucial for VVOLs remaining prominent include standard, but critical, tasks in a virtual IT environment such as replicating a crucial database volume in production or monitoring and maintaining strict performance service-level agreements. These kinds of scenarios are the ones that are pushing businesses to move their applications to virtual environments.
Getting VVOL compatible
Implementing VVOLs in a data center will take some consideration of the software and hardware infrastructure. For example, a data center will require the latest release of vSphere 6.0. If an upgrade is required, the IT staff will need to handle the implications of evaluation, budgeting, licensing and migration -- and address any workload disruptions that may occur.
In addition, the storage hardware or virtual storage appliance must also be compatible with VVOLs. Even storage subsystems that are intended to support VVOLs require vSphere APIs for Storage Awareness (VASA) software and perhaps even a firmware upgrade to ensure full compatibility with vSphere VVOLs. This requires a careful review of hardware compatibility -- often a detailed conversation with the storage vendors -- along with an evaluation of VVOL functionality, before using VVOLs with the arrays in a production environment.
Pay close attention to the services and features integrated into the storage array, as not all arrays will be created equal. Some vendors have certified storage products such as Hewlett Packard Enterprise's 3PAR StoreServ, Tintri's VMstore T5000 All-Flash series or NEC's iStorage M series. Other vendors support vSphere's vStorage APIs for Array Integration, which can coexist alongside VASA and VVOLs, and moves some features such as cloning and migration to the array.
But using VVOLs effectively takes more than just the right virtualization software and storage hardware. IT administrators will need to revisit the way storage is provisioned to applications and rethink the ways storage characteristics impact application performance and reliability. VVOLs won't magically cure bad provisioning practices or fix poor capacity planning strategies. If your incumbent array has IOPs limitations that don't allow an app to migrate, VVOLs won't be of any help. However, VVOLs guarantee that your application remains in an appropriate performance tier.
In spite of the promise that VVOLs offer, the technology is hardly ubiquitous, and there are several limitations that potential adopters should consider when evaluating or testing VVOL capabilities. For example, Storage DRS and SCSI-2 reservations are not yet supported with VVOLs, so administrators can't aggregate storage cluster resources or substitute pass-through raw device mappings with VVOL technology. In addition, a single VVOL's storage instance cannot yet span different physical storage arrays.
Integration is key
Virtual Volumes have the potential to drive serious improvements in storage management, pushing the boundaries of software-defined storage, SPBM and the broader concept of a software-defined data center. But the ultimate success or failure of VVOL technology will depend largely on storage vendors, not VMware. VVOL technology amounts to a new API, and it's up to individual storage vendors to use that API and develop storage arrays that can offer meaningful storage services -- such as data deduplication, data compression, snapshots, cloning, replication and more -- to VVOLs. Only then will we see if storage systems can deliver on the promise of VVOLs.
Everything you need to know about Virtual Volumes
A beginner's guide to VMware Virtual Volumes
A closer look at VMware products changing the storage game