IHAC running OnCommand 5.1 for 7-mode who is using Protection Manager. They have a large Resource Group used for SnapMirror secondaries which contains two controllers (HA Pair) each having two aggregates. Their dataset and Mirror policy lets Protection Manager auto-provision the secondary volume from the resource pool. For some reason, Protection Manager only chose to use one of the controllers and its aggregates and did not provision any mirrors on the second controller. So their mirror configuration is now very lopsided and all going to node #1 of the HA pair. Both aggregates in node #1 are around 75% full.
Based on what I've looked at, there is no reason why Protection Manager shouldn't have chosen the second node to provision Mirror volumes on:
Both controllers have SnapMirror licensed and enabled
The Mirror node of the dataset doesn't use a provisioning policy and therefore doesn't use resource pool labels. Any controller & aggregate in the resource pool will work.
The second node's aggregates are completely empty.
There is virtually no I/O going to node #2, so it should not have been filtered-out based on performance characteristics.
What can I look at to determine why Protection Manager chose to use node #1 and its two aggregates, but not node #2?
There is Getting Started course in pipe line that would explain you how resource selection is done. But for now I suggest you raise a case with NGS and enable some extra logging to find why the other filer is being ignored.
At a high level for Volume SnapMirror following are done.
The ONTAP version of the source filer and the root volume language of the source filer (language of the mirror source, if there is no language for the root volume).
The order in which these aggregates are considered is as follows (lower the number, higher the precedence):
Thanks Adai. I understand the basic resource selection process. In this case, both controllers in the resouce pool were at the exact same ONTAP release and same language. They were two nodes of an HA pair, so they're basically identical. So, that's why I found it odd that PM only chose to use one of the nodes for all its provisioning.