There are three situations where you would want to promote a source pod (or a pod that was recently a source pod):
-
A source pod is promoted and the target is demoted. You then bring down all of the VMs and prepare the storage for demotion and finally proceed to demote the source. You then promote target pod. You proceed to resignature the datastores and power-on the virtual machines and you realize this was a mistake and need to bring the original source pod back online. More than 24 hours (or the configured eradication window) has elapsed since demotion.
Let's walk through these scenarios one by one.
Scenario #1
In this scenario the VMware environment has been brought down and the source pod has been demoted and the remote pod is also demoted:
Source pod is demoted
Remote pod is demoted
At this point it is decided that the environment does not need to be recovered on the remote pod but instead restored on the source pod (activeDRpodA in this example).
To do so, go to the source pods' FlashArray and identify the pod and click the vertical ellipsis on the top right-hand corner. Click Promote.
The following window will appear--since the data has not changed you do not need to select the option promote from undo pod if it appears.
Scenario #2
In this scenario the VMware environment has been brought down and the source pod has been demoted and the remote pod is has been promoted:
Original source pod is demoted
Original remote pod is promoted
At this point data might or might not have been changed on the newly promoted pod. Before you bring up the environment back on the original source pod, you will need to demote the original remote pod. Follow the instructions here to make sure all VMs using that pod are shutdown and removed.
Demoting an ActiveDR Pod in a VMware Environment
If new data has been written on the original remote pod and it should be used in the recovery, follow the normal steps to demote and promote ActiveDR pod pairs.
If you wish to discard any changes and reset to where the environment was at the point of demoting the original source pod, continue on.
Once you have verified the environment using the original remote pod (activeDRpodB in this case) is shutdown--go to the pod and click the vertical ellipsis and choose Demote.
Choose Skip Quiesce if you are 100% certain that any changes on the original remote pod (activeDRpodB in this case) are not needed.
This will demote the pod.
Note that the point-in-time upon demotion will be stored in an undo pod for the period of the configured eradication window (usually 24 hours). So if you decide that changed data is needed there is a restore point (if you chose Skip Quiesce though that point-in-time is NOT protected to the opposing array).
The next step is to promote the original source pod.
To do so, go to the source pods' FlashArray and identify the pod and click the vertical ellipsis on the top right-hand corner. Click Promote.
The following window will appear--select the undo pod to restore from. This will reset the original source pod to the state it was at when it was last demoted. If there is no undo pod it will not be an option and it will restore from the latest point-in-time it has access to.
Now connect the volumes to the host and host groups and rescan the ESXi cluster(s) as needed. Right-click the datacenter(s), cluster(s) or ESXi host(s) and then Storage > Rescan Storage. Click OK to rescan.
1) Right click inventory object
2) Choose Storage > Rescan Storage
3) Select all options and click OK.
Use the process to identify the storage you need to reconnect:
Identify Storage with the Everpure Plugin for the vSphere Client
For each volume ensure that they are attached. Click on an ESXi host, then Configure, then Storage Devices. For the NAA devices in the pod, select them and click the Attach button.
1) Choose an ESXi host
2) Go to Configure then Storage Devices
3) Select a device and attach it.
Now rescan again, but only the VMFS option is needed:
1) Datastore are not yet mounted
2) Choose rescan for storage
3) Rescan for new VMFS volumes
The datastores will now appear as inaccessible.
Right click on the datastores, one-by-one, and choose Mount.
1) Right-click a datastore and choose Mount
2) Choose the hosts to mount the datastore to and click OK
3) Repeat for each datastore
To register VMs and update RDMs. follow these sections:
The last step is to re-register and power-on the VMs. The full process to do this is beyond the scope of this document. An example:
1) Right-click the datastore and choose Register VM
2) Identify the target VM folder and choose the VMX file.
3) Specify a name and folder
4) Choose a host
The above process will register the virtual machine--repeat for each one you need to register.
Scenario #3
Scenario three means that there is no longer a restore point on the original site as the eradication window has passed and the undo pod has been permanently removed. If the data that has been written on the currently promoted side is to be kept the process to restore to the original site is identical to an intended failover. So you would follow the steps in demotion KB:
Demoting an ActiveDR Pod in a VMware Environment
and the current KB you are reading from the top.
If you would like to revert to a specific point-in-time on the formerly promoted site, you will need to follow the normal failover procedure and restore individual volumes from specific snapshots as necessary and then follow the normal recovery steps of those datastores (resignature, register VMs, power-on).