With the release of vSphere 6.0 back in March 2015, VMware delivered the long anticipated Virtual Volumes feature (a.k.a. vVols). Over the past year and a half the vVols momentum has been quietly building with more and more customer interest and partner activity. The adoption of vVols has steadily increased as more and more customers move to vSphere 6, but one of the key inhibitors to widespread adoption had been its lack of support for array-based replication (ABR). Enter vSphere 6.5.
Announced this week, the release of vSphere 6.5 introduces enhancements to several of VMware’s storage management capabilities, including enhancements to Storage Policy-Based Management (SPBM), Storage IO Control (SIOC), virtual disk management, and of course the highly anticipated 2.0 version of vSphere Virtual Volumes. In this post I will walk through what’s new in vVols 2.0 and VASA 3.0. Any guesses what feature made the top of the list?
Array-Based Replication Support
You guessed it! The vSphere 6.5 release introduces vVols support of array-based replication, but unlike legacy array-based replication that required explicit placement on specific datastores to ensure a VM was replicated, vVols replication provides fine grained control over VM replication. This means you have the flexibility to replicate a group of virtual machines (Replication Group) or you can replicate at an individual VM level.
Replication Group
A Replication Group is a group of replicated storage devices as defined by a storage administrator (perhaps acting on behalf of an application owner) to provide atomic failover for an application. In other words, a Replication Group is the minimum unit of failover. In vSphere 6.5, Replication Groups are created and managed by a storage administrator using the storage vendor’s tools.
Let’s take a closer look at how this works:
- Vendor-specific replication capabilities are communicated up to vSphere via VASA (vSphere APIs for Storage Awareness)
- VI administrators create granular VM storage policies containing the desired replication capabilities available from the underlying storage system
- When VMs are being provisioned the user:
- Selects a policy containing the replication capabilities
- Chooses the compatible datastore
- Chooses a replication group in which to place the VM (to support multi-VM consistency)
- Completes the provisioning
The replication group that the user selects allows them to place multiple VMs intentionally in the same consistency group. The replication groups are advertised by the VASA provider. The storage system can also advertise a special “Automatic” replication group that will place the VM into an empty replication group by itself to support per-VM replication.
Virtual Volumes replication also supports multiple replication targets. In the example below, the source in Manchester UK (Repl. Group A) is replicating to London (Repl. Group A1) and Berlin (Repl. Group A2)
Automating Disaster Recovery
vSphere 6.5 also offers public APIs for triggering DR operations as well PowerCLI cmdlets for administrator-level orchestration and automation.
Replication Workflows
- Replication Discovery – vVols disaster recovery discovers the current replication relationships between two fault domains.
- Sync Replication Group – Synchronizes the data between source and replica.
- Disaster Recovery and Planned Migration – For planned migration, on-demand sync can be initiated at the recovery site.
- Setting up protection after a DR event – After the recovery on a peer site, administrators can set protection in the reverse direction.
Line of Service
VASA 3.0 introduces a new concept called “line of service.” A line of service is a group of related capabilities with a specific purpose, such as inspection, compression, encryption, replication, caching, or persistence (storage). Now in addition to configuring replication at the individual SPBM policy level, I can create a line of service for replication and assign it to multiple policies. As an example, imagine I have 3 storage policies: Gold, Silver and Bronze. While these three categories have very different storage capabilities assigned, I can manage the replication once with a replication line of service instead of 3 times by configuring replication at the VM Storage policy level.
Virtual Volumes Support for Oracle RAC
In addition to all the array-based replication functionality, vVols 2.0 is also now validated to support Oracle RAC workloads (similar to validation for VMFS) delivering policy-based, VM-centric storage for Business Critical Applications like Oracle RAC.
Are you ready?
As I mentioned earlier, the lack of support for array-based replication was a significant inhibitor for mass adoption of vVols. Now with vSphere 6.5, customers can protect their vVols environment with array-based replication while experiencing how vVols can greatly simplify storage management and provide greater granularity over the existing operational model. There’s no need to wait anymore, so get ready for the vVols revolution!
More resources
For the latest information on vSphere Virtual Volumes be sure to check the following locations
