When the target pod is promoted during a test, the pod is now available for provisioning. While it is possible to do so, it is not recommended to provision from a pod that is promoted for the use of a test as upon demotion those volumes will be destroyed as the pod will sync back up with the source pod which does not have the volume that was created in the temporarily promoted target pod.
In this case there are two pods linked for ActiveDR, a source pod called srm-podA and a target pod srm-podB. During an SRM test, someone added a volume to srm-podB called volcreatedintarget:
This volume is not in the source pod:
The SRM protection group is not aware of it either:
A cleanup will fail because that volume is unknown and therefore not tagged as being in test. The SRA does not want to continue on and demote the pod because that volume could be serving up production data--someone might have accidentally provisioned it to the target pod when it was promoted. While doing so is a mistake--accidents happen and the SRA does not want to make it worse. Therefore, the cleanup will fail:
Failed to delete snapshots of replica devices. SRA command 'testFailoverStop' failed. More than one type of devices found in the pod. Please verify that all the volumes are either untagged or tagged with same value in the "puresra" namespace.
The options are:
- Move the data off of the volume to a new FlashArray volume in a different pod via some host-based tool and then delete the original volume.
- Terminate the pod replica link, move the volume out of the pod, and then relink the pods (note this will cause replication to stop for the duration of the process!).
You may either do this, then re-run test recovery cleanup or run test recovery cleanup with the force cleanup option selected to have the SRA skip the demotion step. The force option will require manual intervention to demote the pod.