Once all workloads are shutdown to the pod you can commence with a demotion. A good way to confirm this is to check the performance statistics on the pod. It should all be zero:
Once confirmed, navigate in the FlashArray GUI to the pod you would like to demote. In this case it is a source pod. You would demote a source pod when you are about to failover the workload to the target site and this ensures that the data is fully synchronized to the target site and that the source becomes inaccessible on the source. This prevents the same workloads from running in production at once.
ActiveDR, however, does allow you to run the workload on both the source pod and the target pod at the same time--this is generally referred to as a test recovery and is discussed here: Promoting an ActiveDR Pod in a VMware environment
Go to Storage then Pods, then click on the pod.
In the upper right-hand corner, click on the vertical ellipsis and choose Demote. Choose Quiesce and click Demote.
DO NOT DEMOTE A POD if there are any volumes in that pod still connected to ESXi and the host personality of those FlashArray hosts is not set to ESXi. See here for more detail: Setting the ESXi Host Personality
|
1) Choose Demote from the pod management menu. |
2) Choose Quiesce and Demote to complete the process. |
|---|---|
|
|
|
Is there a time you wouldn't want to choose "Quiesce"? Possibly. If there was some type of transient failure on source site and you have already failed the workload over to the remote site and restarted the virtual machines. In this scenario production data has been written to the target site that is newer than what is on the original source. Therefore replicating any non-replicated changes from the original source to the original target site is not necessary.
During the demotion process, the state of the replica link will go to quiescing and then to quiesced when the synchronization is fully complete.
The overall pod state will be demoted.
The full state of the pod is preserved upon the demotion (volumes, data, snapshots, protection groups) and is stored in an "undo" pod for 24 hours.
This will provide an option to restore the environment exactly to the way it was if the new target site begins replicating over the original pod and it is deemed those changes are a mistake. To keep that point-in-time of the pod longer you can copy it to a new pod--though it should be noted the copied pod will provide new serial numbers to a volumes and snapshots, but the data will be identical to the original pod.
Once the demotion occurs the volumes will go NOT READY and not respond to reads or writes from a host. The volumes will only respond to VPD inquiries. So VMware will see the device, but will not know if there is a VMFS on them, and they will not be able to be re-attached. The pod hosting the volumes must be in the promoted state in order for it to be used by ESXi.
Note the below image shows demoted devices and the Attach button is grayed out.