If an array manager fails to discover arrays with a similar error to below:
And the listing for Last Array Manager Ping is in a failed state:
The likely cause is one of the following issues:
- A pod was renamed that was part of an enabled array pair (renaming protected pods is not support in the 3.1 SRA release)
- A pod was destroyed that was part of an enabled array pair
- The pod that was part of an enabled array pair was moved to a new FlashArray and that new FlashArray is not included in any array manager.
Check if the Pod was Renamed
In the case of a rename, if the array pair is not needed in SRM, you can simply disable the pair and array discovery will work again.
In the 3.1 release of the SRA, renaming pods without reconfiguring SRM protection is not supported. In a future SRA release, the ability to rename pods without having to reconfigure protection in SRM will be added.
If the array pair that included the renamed pod is still needed, you will need to rename it back to the original name. Identify the FlashArray(s) that hosted the original pod and go to either one of the web interfaces of FlashArrays (if of course it was on two) that hosted the pod and go to Settings > Users > Audit Trail.
Search for the command purepod and the subcommand rename. This will show any pod renames that occurred on the array. If no results show up for the original pod, try the other array (if it was stretched).
Once you find what the pod was renamed to, rename it back to the original name.
Renaming it back to the original name will fix array discovery.
Check if the Pod was Destroyed
It is also possible that the pod itself was destroyed on the FlashArray. Before deciding upon the right course of action, it is important to verify that this is indeed what happened. Login to the FlashArray web interface of the array that hosted the pod originally and go to Settings > Users > Audit Trail.
Search for the command purepod and the subcommand destroy. This will show any pod destroy operations that occurred on the array. If no results show up for the original pod, try the other array (if it was stretched).
Once you confirm that the pod was indeed destroyed, you have a few options:
-
If there are protected volumes in it, verify the volumes are still in-use and were moved out of the pod prior to the pod destruction. If they are still in-use:
-
If it has been less than 24 hours, restore the pod from the Destroyed Pods box and move the volumes back in it
- If it has been more than 24 hours, or the pod was manually eradicated (permanently deleted), you can create a new pod with the same name and move the affected volumes into it. Then re-run array discovery.
- Move the volumes into a new pod (or into a non-pod protection group) and re-create (or remove and re-add it to) their protection group entirely in SRM. In this case, you will need to remove any affected devices from their SRM protection groups and re-add them under a new array pair.
Check if the Pod was Moved
In the case of the pod being moved to a different array (or arrays), it is necessary to find where the pod was moved from and then update the array managers with the new FlashArray addresses.
Login to the FlashArray web interface of the array that hosted the pod originally and go to Settings > Users > Audit Trail.
Search for the command purepod and the subcommand remove. This will show any pod unstretches from that array. If there is a remove operation it means it was removed from that array.
Now search for the command purepod and the subcommand add. This will show any pod stretches from that array. If there is a add operation it means it was added to that array.
Now that you know where the pod is, follow the steps in the section, Moving a Pod to a different FlashArray
-
If it has been less than 24 hours, restore the pod from the Destroyed Pods box and move the volumes back in it