I’ve configured a Protection Manager dataset with a Provisioning policy to create secondary (SnapMirror) storage when a primary storage volume is added to the Dataset. The dataset protection policy is just a single Mirror. The provisioning policy defines a resource group containing 4 aggregates at DR, and has the default options (ie just requires RAID-DP) .
The process is:
drfiler1:aggr00_sata = 69%
drfiler1:aggr01_sata = 74%
drfiler2:aggr02_sata = 33%
drfiler2:aggr03_sata = 40%
The question is about how the Provisioning Policy selects the aggregate to provision the SnapMirror destination volumes. I’ve tested this but strangely, it is selecting aggr00_sata for the mirror destination volumes. Based on usage, I would expect it to choose the one with the most free space (drlfiler2:aggr02_sata). Generally, the disk I/O and filer cpu is significantly lighter on drfiler2, so I don't think it can be selecting drfiler01 based on performance.
Does anyone know if there are any logs, etc which can be used to determine what the decision making process was?
The reason why aggr with 69% is selected could be because of Load Balancing.
The resource selection algorithm also uses a defined space margin with a default value of 75. The goal of the space margin is to ensure variability of the selected aggregate so that selection is not automatically limited to the one least-utilized or best-fit aggregate.
With the Least-Utilized algorithm, the space margin ensures that the aggregate with the largest free space will not always be selected, instead, it expands the suitable aggregates to those with free space of at least 75% of the largest aggregate.
After Space Balancing we have one more step called load balancing in order to actually select the one aggregate for the provisioning request. Load balancing would select the aggregate with the lower number of qtrees for a primary node or the lower number of relationships if these were a secondary node.
Hope this helps.
Soon we will have a videos explaining/Detailing the Provisioning Algorithms.