(Click to open topic with navigation)
Peer-to-Peer Resource Affinity Overview
The concept of resource affinity stems from a number of facts:
Regardless of the reason, Moab servers allow the use of peer resource affinity to guide jobs to the clusters that make the best fit according to a number of criteria.
At a high level, this is accomplished by creating a number of job templates and associating the profiles with different peers with varying impacts on estimated execution time and peer affinity.
A direct way to assign a peer allocation algorithm is with the PARALLOCATIONPOLICY parameter. Legal values are listed in the following table:
Value | Description |
---|---|
FirstStart | Allocates resources from the eligible peer that can start the job the soonest. |
LoadBalance | Allocates resources from the eligible peer with the most available resources; measured in tasks (balances workload distribution across potential peers). |
LoadBalanceP | Allocates resources from the eligible peer with the most available resources; measured in percent of configured resources (balances workload distribution across potential peers). |
Random | Allocates partitions in a random order each iteration. In general, all the jobs scheduled within the same iteration receive the same randomized list of partitions. This means the randomization happens between iterations and not within the same iteration. One iteration Moab might start with partition X and the next it might start with partition Y. |
RoundRobin | Allocates resources from the eligible peer that has been least recently allocated. |
The mdiag -t -v command can be used to view current calculated partition priority values.
Per-partition scheduling can be enabled by adding the following lines to moab.cfg:
PERPARTITIONSCHEDULING TRUE JOBMIGRATEPOLICY JUSTINTIME
To use per-partition scheduling, you must configure fairshare trees where particular users have higher priorities on one partition, and other users have higher priorities on a different partition.
Do not set the USEANYPARTITIONPRIO parameter if you use per-partition scheduling. Doing so causes Moab to schedule jobs to the first partition listed, even if nodes from another partition will be available sooner.