vSphere Plugin: Replication Workflows and Actions

Topology Overview

Linked vCenter Servers

In this configuration, users will be able to failover VM-01 and VM-02 on FlashArray-A from vCenter-A to vCenter-B on FlashArray-B. Notice that vCenter-B does not have the storage providers for FlashArray-A registered nor is it using the vVol-DS from FlashArray-A.

The worfklows function with a single vCenter Server as well.

Single vCenter Server

In this configuration, vCenter-A has access to the vVol datastores on both FlashArray-A and FlashArray-B. Within the same vCenter Server, the replication manager can failover VM-01 and VM-02 from FlashArray-A to FlashArray-B. This would also work if there were multiple arrays connected to the same vCenter server or if replication groups had multiple target arrays (something not currently supported in Site Recovery Manger).

Single vCenter Server

In this configuration, vCenter-A has three array's storage providers registered, is mounted to a datastore on each array and the replication-group-A on FlashArray-A is replicating to both FlashArray-B and FlashArray-C. This means the workflows can be issued against the target replication group for either FlashArray-B or FlashArray-C.

Additional arrays, providers and vVol datastores can only be connected to a single vCenter if using linked vCenter Servers.

Linked vCenter Servers

This is a supported configuration with one caveat: if one of the arrays on vCenter-A was registered and in use on vCenter-B, any replication groups on that array would not be supported with the replication manager.

Two vCenters in Enhanced Linked Mode Workflows

The environment for this example:

Sync Replication Group

The sync once workflow will allow the user to select which target array will be issuing the protection group replication request. The replica name is a required field and should be used to help identify the specific PiT (point in time) replica for future use.

After clicking sync once, the protection group will take a pgroup snapshot and replicate it to the pgroups targets. The replication manager will monitor the tasks status and will update the task as complete when the replication job has completed.

Test Failover Replication Group

The test failover replication group workflow will allow the user create test VMs on the target array and in the target vCenter. This workflow will issue the API "testFailoverReplicationGroupStart" for the target replication group. The workflow wizard in the plugin will require the selection of the target, replica, compute resource to register the VM(s) and a vm network to be used for all recovered VMs.

In the target selection view, a target will need to be selected. This target will list out which array the target is and what vCenter the VMs will be recovered and registered in.

In the replica selection view, a replica will need to be selected for the replication manager to use. Any syncOnce workflows will have the replica name there; any standard scheduled pgroup snapshots will be listed without a replica name.

In the compute resource selection view, a host will need to be selected for the replication manager to register the recovered VMs in. The replication manager only supports the selection of hosts (not clusters or resource pools).

In the network selection view, a network needs to be selected that all VMs will be reconfigured to use at the recovery vCenter. With a test failover, this should be a private/contained test network that will not impact the source VMs.

In the summary view, the test failover parameters need to be confirmed.

Once the test failover workflow has completed, the test VMs will be registered and show up in the recovery vCenter. The VMs will be powered off and will need to be powered on if so desired.

Cleanup Test Failover Replication Group

The cleanup test failover workflow will power off any virtual machines recovered/registered with the workflow, delete them and then issue the API "testFailoverReplicationGroupStop". This will let the target array clean up the test objects and the VASA providers will be able to transition the target replication group from an INTEST state back to a TARGET state.

There is only a single view for the cleanup workflow. This summary view will confirm which array and vCenter the target replication group will be cleaned up from and then after confirming the workflow is executed.

Failover Replication Group

From the main replication group view, the failover replication group workflow is initiated by selected the Run button.

In the target selection view, a target will need to be selected. This target will list out which array the target is and what vCenter the VMs will be recovered and registered in.

In the replica selection view, a replica will need to be chosen for the replication manager to use. Any syncOnce workflows will have the replica name there; any standard scheduled pgroup snapshots will be listed without a replica name.

In the compute resource selection view, a host will need to be selected for the replication manager to register the recovered VMs in. The replication manager only supports the selection of hosts (not clusters or resource pools).

In the network selection view, a network needs to be selected that all VMs will be reconfigured to use at the recovery vCenter. Because this workflow is running the failover, the network should not be a test network; the network should be the desired network for the VMs and applications to be available.

In the Options view, the ability to power on the VMs on recovery can be selected.

In the Summary view, the failover parameters are displayed to be reviewed before committing to. Keep in mind that all VMs in this replication group on the source site will be powered off and removed from the vCenter.

Once the failover workflow has completed, the view for the source replication group will change. Note that the reprotect option is not here. This reprotect workflow will need to be ran against the replication group in the failed over state. This can be navigated to by clicking on the peer array that is in the failed over state.

Reprotect

The Reprotect action will be active when the replication group selected is in a Failed Over state. Keep in mind that the reprotect workflow will reverse the replication group states. The wizard will allow the user to select which Storage Policy on the recovery vCenter to be used as well as the replication group that will be used from that policy.

Here we see the replication group is in a "FAILEDOVER" state and the reprotect action is able to be selected.

There is a confirmation as part of the workflow as this action is not reversible cannot be undone.

After confirming that the reprotect action can be executed, the next view requires that a Storage Policy and replication group (if applicable) is chosen.

Once the reprotect has completed, the screen will redirect to the array's replication groups view. From there the replication group that was selected from the reprotect workflow wizard should now have the VMs listed there. Here the previously used and mapped protection group was selected during the reprotect and the most recent operation is shown as reprotect.