FlashArray Replication, vVols and SRM 8.3 – Test Failover

VMware vSphere Virtual Volumes (vVols) and FlashArray based replication will now be supported with Site Recovery Manager (SRM) 8.3! Along with the ability to leverage the API calls for SPBM Failover and Reverse operations for vVols with PowerCLI or vRO, SRM will now support the SRM recovery workflows with vVols and array based replication.

The cool part with vVols and SRM working together is that there isn’t a need for an SRA in order to leverage Array Based replication. The key part here is that SRM is able to leverage communication to VASA and execute Recovery Plan workflows through the existing SPBM Failover API. Cody Hosterman and I did a vVols Replication deep dive about a year ago that dives into each of the APIs in detail. That can be found here.

In this post, I’ll just be going through how the initial setup looks, storage policy mappings and then run through a test failover and cleanup. In a future post I’ll cover running through the failover and re-protect.

Setup and Storage Policy Mappings

Here is the setup that I’ll be using and how the mappings look. I have already configured the mappings with the exception of the storage policy mapping. Additionally notice that there is no SRA and no Array Managers.

(Click on the Images in this post for them to be easier to see)

I am going to be setting up SRM protection groups, which will be configured on the replication groups associated with the storage policies I have created. Those storage policies will be following a set of rules that should be associated with a FlashArray protection group. Such as replicating every 2 hours and retaining all snapshots for 12 hours.

From each vCenter I have a storage policy with the same ruleset that I’ll be mapping together. There is also a protection group on the protected FlashArray that has the required ruleset. There are VMs using the storage policy on the protected vCenter/FlashArray and the two replication groups.

Then when creating the mappings for the storage polices, I just map the ones that have the same rulesets and make sure that the reverse mapping is created as well.

Creating the Protection Group and Recovery Plan with vVols

I’ll be creating the SRM Protection Group and Recovery Plan for the vVol based VMs next. When creating the SRM protection group there is going to be a new option when selecting the type of protection group, Virtual Volumes (vVols Replication).

When selecting vVols Replication I can see the list of Fault Domains (essentially the FlashArray) that vCenter is using vVols. After selecting the fault domain I can see the replication groups associated with the fault domain for this vCenter Server. I can select one or more replication groups and then I can add the new protection group to an existing recovery plan or create a new one.

As I have two replication groups for the storage policy I’m using, I went ahead and created an additional SRM protection group for the other replication group and added it to the same recovery plan.

I can then check the VMs protection state on the protection group and the recovery plan. If needed, the protection configuration can be updated and the startup priority can be tweaked. When looking in vCenter you can see that the placeholder VMs created on the recovery vCenter as well.

SRM Test Failover and Cleanup

Here is an example of running through a Test Failover. The option to replicate the most recent data will initiate a syncReplicationGroup to start the testFailoverReplicationGroup. Checking the protection group on the FlashArray will show that a snapshot was replicated over for both protection groups on the target FlashArray.

Once the syncReplicationGroup has completed the testFailover will continue. Part of the test failover process will create new protection groups on the target site with the source rule set. If a previous test or failover was ran, VASA will reuse the old protection groups instead of creating a new one. As long as no volumes, hosts or host groups were manually added to the pgroup on the FlashArray.

Once the test failover has completed, I would want to check the test VMs to make sure they are up and running. In vCenter I can see the protected VMs are still up and running and the test VMs are all powered on as well.

In a future post I want to dig into some interesting workflows that can be done with the test VM, but for now I can see that the test is complete. Next step is to go ahead and clean up the test Failover. You’ll see in the example below that part of this process is to clean up the volumes and volumes groups on the target array that were created for the test.

You will also notice that the FlashArray protection groups are not destroyed. The primary reason behind this is that Pure’s VASA wants to be able to reuse those pgroups when the next test failover or failover is ran. The FlashArray pgroups can be renamed, but if the replication schedule is changed or if volumes are added to it, then VASA will create a new pgroup on the next test failover or failover.

What’s Next?

What is there to look forward to before the release of vSphere 7.0 and SRM 8.3? The first part is that I’ll be doing an additional post about running a Failover and Reprotect. After that I’ll be digging into some different setups and workflows. With regards to vSphere 7.0, jhop has also posted about configuring NVMe-oF with VMware and Pure Storage. Cody posted a quick breakdown about what’s new in vSphere 7.0 as well. There will be some additional posts that we’ll be making leading up to the release of vSphere 7.0.