Furthermore, the protection provided by pods and ActiveCluster can be complemented with periodic replication over great distance. As of Purity 5.3.x, ActiveCluster supports arrays at a distance up to 11 ms RTT time--which may not be enough distance to put both FlashArrays out of the blast radius of a major disaster (typhoon, hurricane, etc.). Therefore, starting with Purity 5.2.x, it is possible to replicate the volumes in a pod (stretched or not) to a third FlashArray by creating an periodic replication-enabled protection group in the pod, and then putting desired volumes in that pod also in the protection group. This will replicate snapshots of those protected volumes to another array on a specified interval.
Periodic replication can protect either stretched pods or standalone pods.
For more information on ActiveCluster, please see the following page:
ActiveCluster with VMware User Guide
Your next question might be "Yeah, cool, but what does this have to do with array managers in SRM?". Good question, anonymous reader.
The characteristic that a pod is not tied to a specific physical array is something we did not want to break, or more accurately, it is a behavior that we didn't want to unnecessarily restrict within SRM. Traditionally, when FlashArray pairs were discovered in SRM array managers, the FlashArray SRA would return physical array pairs (e.g. FlashArray A replicates to FlashArray B). If the SRA returned volumes replicated from a pod under that physical array pair, it would require the containing pod to never be moved. If the pod was moved (unstretched then stretched) to a new array pair, SRM would not be able to understand the change (changing what array pairs owns a volume is not a workflow that SRM supports) and a reconfiguration of SRM would be required--likely breaking disaster recovery abilities until resolved. This is less than ideal.
The avoid this dissonance, the FlashArray SRA version 3.1 and later returns pods as potential replication sources for array pairs. So a pod is the source and a remote physical FlashArray is the target.
Note that currently (as of Purity 5.3.x) a pod cannot be a target for periodic replication--it can only be a source. Periodic replication (snapshot-based replication managed by a protection group) always replicates to the "root" of the array.
So in the below example, we have a pod named podSRM (seen near number label 2) currently residing on a FlashArray called flasharray-m50-1 (seen near number label 1) with a protection group in it called replicateto3rdSite (seen near number label 3) . This protection group replicates to a FlashArray called flasharray-m20-1 (seen near number label 4).
Since this pod has a replication relationship, the SRA will discover the pod as a source "array" and the target physical FlashArray as the target:
Near number label 1, the flasharray-m50-1 (a physical FlashArray) to flasharray-m20-1 (a physical FlashArray) replication pair can be seen.
Near number label 2 the podSRM (a pod) to flasharray-m20-1 (a physical FlashArray) relationship will be seen.
So volumes that are in asynchronous replication-enabled protection groups that are NOT in any pod will be in the "physical" array pair. Volumes that are in protection groups in the pod podSRM will be listed under the "pod to array" array pair.
Configuring the array managers for this is very similar to non-pod based periodic replication. In the local array, enter in the source array and for the peer add the array that is a failover target. How this is slightly different is for pods that are stretched across two arrays.
Let's walk through both scenarios.