vSphere Plugin User Guide: Replication Manager
Requirements
There are a few requirements that need to be met in order to utilize the new replication manager with vSphere Plugin 5.2.0 or higher.
- To utilize replication workflows between two vCenters they must be in Enhanced Linked Mode
- When using the replication workflows with two (or more) linked vCenters replication groups must not be shared between vCenters.
- This means that vCenters can not be registered to the same storage providers (Array VASA Provider). With the initial release of the replication manager will not support linked vCenters that are registered with the same array's VASA providers.
- The replication workflows will not be able to work between two unlinked vCenters to failover virtual machines between unlinked vCenters.
- The reason behind this is that the plugin must be able to communicate with both vCenters in order to be able to get a list of the virtual machines in the replication groups, perform virtual machine specific tasks and track tasks/requests.
- When using the replication workflows with one vCenter that vCenter must be connected to both arrays that are replicating and access to vVol Datastores on both arrays.
This KB will not be going into an in depth explanation of the vVols APIs that are leveraged by the replication manager.
For a more in depth review and expalantion of vVols Replication please see the vVols Replication Deep Dive
Replication Manager
There are two new views with the replication manager. There is the vVols Replication Manager Array View and then the vVols Replication Group Manager View. These two views are covered below.
Replication Manager View
From the main plugin page there is now a new button: Replication Manger (number 2 in the image below). First an array will need to be selected and then the replication manager button can be selected. Which leads to the Replication Manager Array View.
 vSphere Plugin Array List View - Select an Array (1) and then select Replication Manger (2) to navigate to the Replication Manager Array View |
 Replication Manager Array View |
After selecting an array and then clicking on Replication Manager this navigates to the Replication Manager Array View. This page is designed to give a high level overview of all the replication groups that are found from the selected arrays VASA provider.
- Name of the Array
- Sync Once (syncReplicationGroup) workflow button and replication group manage button
- Replication Group list
- The format for a replication group is the name of the array followed by the name of the array protection group: {array-name}:{pgroup-name}
- Which vCenter the replication group is found in
- The state of the replication group
- This would be Source, Target, InTest or FailedOver
- The Peer Array(s)
- Source or Target would refer to the relationship that the Peer array reports for the replication group. Clicking on the array hyperlink will lead to that arrays replication manager view.
- List of Virtual Machines using the replication group in the vCenter
- These are the Virtual Machines that are in this vCenter that are using a storage policy and have selected the specific replication group.
- Active Operation and status
By selecting one of the replication groups and then clicking on the manage button this will navigate to the Replication Group Management View.
Replication Group Management View
This is the page that will allow all of the operations for the replication group to be executed. In the top of the page the array and replication group will be displayed along with much more information for this specific replication group. There is plenty of information here that is displayed here is a breakdown.
 Replication Group Management View |
- Sync Once Workflow (syncReplicationGroup)
- Test Failover Workflow (testFailoverReplicationGroupStart)
- Cleanup Test Failover Workflow (testFailoverReplicationGroupStop)
- Failover Workflow (failoverReplicationGroup)
- Reprotect Workflow (reverseReplicationGroup)
- Replication Group State
- Replication Group Description
- Peer Array(s)
- Virtual Machine List
- These are the virtual machines that are in this vCenter using the replication group.
- Active Operation and Status
- Below this section each of the steps for the currently running or most recent workflow will be displayed.
Replication Workflows and Actions
There are a few different configuration that the replication workflows will work with.
Linked vCenter Servers
| vCenter Server | Registered Storage Providers | Virtual Machines | ReplicationGroup | vVol Datastore | FlashArray |
|---|---|---|---|---|---|
| vCenter-Server-A | FlashArray-A-ct0 FlashArray-A-ct1 |
Virtual-Machine-01 Virtual-Machine-02 |
RepGroup-A-01 (Source) |
FlashArray-A-vVol-DS | FlashArray-A |
| vCenter-Server-B | FlashArray-B-ct0 FlashArray-B-ct1 |
RepGroup-A-01 (Target) |
FlashArray-B-vVol-DS | FlashArray-B |
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.
Additionally the worfklows can work with a single vCenter Server as well.
Single vCenter Server
| vCenter Server | Registered Storage Providers | Virtual Machines | ReplicationGroup | vVol Datastore | FlashArray |
|---|---|---|---|---|---|
| vCenter-Server-A | FlashArray-A-ct0 FlashArray-A-ct1 |
Virtual-Machine-01 Virtual-Machine-02 |
RepGroup-A-01 (Source) |
FlashArray-A-vVol-DS | FlashArray-A |
| FlashArray-B-ct0 FlashArray-B-ct1 |
RepGroup-A-01 (Target) |
FlashArray-B-vVol-DS | FlashArray-B |
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 supported in Site Recovery Manger)
Single vCenter Server
| vCenter Server | Registered Storage Providers | Virtual Machines | ReplicationGroup | vVol Datastore | FlashArray |
|---|---|---|---|---|---|
| vCenter-Server-A | FlashArray-A-ct0 FlashArray-A-ct1 |
Virtual-Machine-01 Virtual-Machine-02 |
RepGroup-A-01 (Source) |
FlashArray-A-vVol-DS | FlashArray-A |
| FlashArray-B-ct0 FlashArray-B-ct1 |
RepGroup-A-01 (Target) |
FlashArray-B-vVol-DS | FlashArray-B | ||
| FlashArray-C-ct0 FlashArray-C-ct1 |
RepGroup-A-01 (Target) |
FlashArray-C-vVol-DS | FlashArray-C |
In this configuraiton 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. Meaning that workflows can be issued against the target replication group for either array.
However, if using linked vCenter Servers additional arrays, providers and vVol datastores can still only be leveraged in the single vCenter to be supported.
Linked vCenter Servers
| vCenter Server | Registered Storage Providers | Virtual Machines | ReplicationGroup | vVol Datastore | FlashArray |
|---|---|---|---|---|---|
| vCenter-Server-A | FlashArray-A-ct0 FlashArray-A-ct1 |
Virtual-Machine-01 Virtual-Machine-02 |
RepGroup-A-01 (Source) |
FlashArray-A-vVol-DS | FlashArray-A |
| FlashArray-C-ct0 FlashArray-C-ct1 |
Virtual-Machine-03 Virtual-Machine-04 |
RepGroup-A-01 (Target) RepGroup-C-01 (Source) |
FlashArray-C-vVol-DS | FlashArray-C | |
| vCenter-Server-B | FlashArray-B-ct0 FlashArray-B-ct1 |
RepGroup-A-01 (Target) |
FlashArray-B-vVol-DS | FlashArray-B | |
| FlashArray-D-ct0 FlashArray-D-ct1 |
RepGroup-C-01 (Target) |
FlashArray-D-vVol-DS | FlashArray-D |
This would still be a supported configuration. However, if one of the arrays on vCenter-A was registered and in use on vCenter-B, then any replication groups on that array would not be supported with the replication manager.
With this all covered here are some examples of what the workflows woudl look like.
Two vCenters in Enhanced Linked Mode Workflows
Here is the current environment for this example (the VM names and replication group names are a bit different)
| vCenter Server | Registered Storage Providers | Virtual Machines | ReplicationGroup | vVol Datastore | FlashArray |
|---|---|---|---|---|---|
| vCenter-Server-A | FlashArray-A-ct0 FlashArray-A-ct1 |
RepGroup-A-01 (Target) |
FlashArray-A-vVol-DS | FlashArray-A | |
| FlashArray-C-ct0 FlashArray-C-ct1 |
FlashArray-C-vVol-DS | FlashArray-C | |||
| vCenter-Server-B | FlashArray-B-ct0 FlashArray-B-ct1 |
Virtual-Machine-01 Virtual-Machine-02 |
RepGroup-A-01 (Source) |
FlashArray-B-vVol-DS | FlashArray-B |
Sync Replication Group
The sync once workflow will allow the user to select which target array will be issuing the protection group replicate 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.
 Sync Once Workflow View |
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.
 Test Failover Replication Group View - Target Selection |
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.
 Test Failover Replication Group View - Replica Selection |
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 but any standard scheduled pgroup snapshots will be listed without a replica name.
 Test Failover Replication Group View - Compute Resource Selection |
In the compute resouce selection view a host will need to be selected for the replication manager to register the recovered VMs in. At this time the replication manager only supports the selection of hosts and not clusters or resource pools.
 Test Failover Replication Group View - Network Selection |
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 Virtual Machines.
 Test Failover Replication Group View - Summary View |
In the summary view the test failover parameters are displayed to be reviewed before committing to.
 Test Failover Replication Group View - Registered VM View |
Once the test failover workflow has completed the test VMs will be regsitered and show up in the recovery vCenter. The VMs will be powered off so 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, will 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.
 Cleanup Test Failover Replication Group View - Replication Group View |
 Cleanup Test Failover Replication Group View - Cleanup Summary View |
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
The failover replication group workflow is very similar to the test failover workflow other than it will also be powering off the source VMs before executing the failover replication group workflow. The workflow wizard in the plugin will require the selection of the target, replica, compute resource to register the VM(s), a vm network to be used for all recovered VMs and whether to power on the recovered VMs after being reconfigured.
 Failover Replication Group Workflow - Click the Run button to initiator the workflow |
From the main replication group view the failover replication group workflow is initiated by selected the Run button.
 Failover Replication Group Wizard View - Run Failover - Target Selection View |
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.
 Failover Replication Group Wizard View - Run Failover - Select Replica View |
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 but any standard scheduled pgroup snapshots will be listed without a replica name.
 Failover Replication Group Wizard View - Run Failover - Select Compute Resource view |
In the compute resouce selection view a host will need to be selected for the replication manager to register the recovered VMs in. At this time the replication manager only supports the selection of hosts and not clusters or resource pools.
 Failover Replication Group Wizard View - Run Failover - Select Network View |
In the network selection view a network needs to be selected that all VMs will be reconfigured to use at the recovery vCenter. As this workflow is running the failover, the network should not be a test network but rather the network desired for the VMs and applications to be available.
 Failover Replication Group Wizard View - Run Failover - Options View |
In the Options view the ability to power on the VMs on recovery can be selected here.
 Failover Replication Group Wizard View - Run Failover - Summary View |
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.
 Failover Replication Group Workflow - Replication Group View after a Failover |
Once the failover workflow has completed the view for the source replication group will change. Note that that 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 nativated to by clicking on the peer array that is in the failed over state.
Reprotect
The "Reprotect" action will be activate 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.
 FAILEDOVER Replication Group View |
Here we see the replication group is in a "FAILEDOVER" state and the reprotect action is active to be chosen.
 Reprotect Workflow - Confirmation View |
There is a confirmation as part of the workflow as this action is not reversabile or can be "undone".
 Reprotect Workflow - Storage Policy and Replication Group Selection View |
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.