VMware released Virtual Volumes in 2015. Since then, and especially since Virtual Volumes 2.0, with its support for replication, the question has been “When will this integrate with SRM?” I’m thrilled to say, the answer to that question is “Now!” As of Site Recovery Manager 8.3, now there is support for doing everything that SRM offers from testing to recovery, with vVols. SRM support for vVols brings granular recovery of array-based replication, automated protection, and enhanced storage-policy based management to your recovery plans. Additionally, this functionality also enables automatic protection of VMs. Let’s take a closer look!
SRM and vVols
The integration of SRM with vVols was built on top of the replication capability that was introduced in vVols 2.0. This implementation introduced the concepts of replication groups and fault domains, which the SRM integration builds on. A fault domain roughly translates to a site or an array replication pair. A replication group, also known as a consistency group, is made up of one or more VMs that are replicated in a consistent state. A vVol protection group can consist of one or more replication groups. All of a replicated VMs disks must belong to the same replication group.
Creating a vVol Protection Group
One of the great things about vVols is that all of the workflows of SRM: Test, Cleanup, Planned Migration, Disaster Recovery, and Reprotect. All of them function just the same with vVols as they do with array-based replication or vSphere Replication. Also, vVol protection groups can be combined into the same recovery plan as array-based replication groups and vSphere Replication protection groups.
With the integration of vVols with SRM, we eliminated the need for an SRA (Storage Replication Adaptor). The VASA providers now handle all operations with the storage arrays. With vVols, replication configuration and management can be done directly from vSphere (not just the UI, through any tool used to manage vSphere – vRO, PowerCLI, etc.), and it integrates fully with VM provisioning and policy-based management. As part of the capability to manage this new integration through means other than the UI, new workflows to manage the SRM and vVols integration have been added to the SRM plugin for vRO. There are also vVol related enhancements to the vROps management pack for SRM.
Failover with vVols. Note that it is exactly the same as when using array-based replication or vSphere Replication
The preparation for protection before involving SRM is similar to that with standard array-based replication. Replication is configured between the arrays/fault domains, which includes defining replication groups and associated storage policies. With those in place, protection is as easy as associating a VM with a storage policy and placing it onto storage that complies with that policy.
There are a few guidelines to keep in mind when using vVols with SRM. Users familiar with SRM and array-based replication won’t be surprised by any of these.
- vVol replication integration with SRM requires SRM Enterprise licensing
- A protected VM must be contained entirely in a single Replication Group
- Each vVol Replication Group can only be a part of one SRM Protection Group
- The Replication Groups in a Fault Domain don’t all have to be part of the same Protection Group
- Each Protection Group can contain multiple Replication Groups
For details about what storage vendors are currently supporting the integration of vVols and SRM, check the compatibility guide.
Automatic Protection
The automatic protection of VMs in SRM 8.3 is quite simple. If you have an existing array-based protection group, when a VM is either deployed or migrated to a protected datastore, it will automatically be protected by SRM.
If you have an existing vVol protection group, when a VM is either deployed to a vVol associated with the replication group or the VMs policy is changed to the policy of that replication group. The VM will automatically be protected.
Automatic protection is flexible in that it supports VMs as well as templates. It is also intelligent in that it will not unprotect VMs. Not unprotecting VMs ensures that a VM being disassociated with a policy, or storage vMotioned accidentally, doesn’t remove it from protection.
There are a few requirements and limitations for using automatic protection. They are:
- Automatic protection requires a protection group to be configured
- SRM will not automatically unprotect VMs. It, therefore, doesn’t support moving a VM from one protection group to another. This capability may be included in a future release. Please let us know what you think about the idea of automated unprotection.
- If the user unprotects a VM and leaves it in the same replication group or array, SRM will not automatically protect it
vVols and vSAN are the future of storage at VMware. Now you have what you need to manage, protect, and recovery your workloads more efficiently. We’re looking forward to hearing about all the cool things you do with them.
