All builds continually adjust the number of agents they can use. Cluster sharing requires constant cooperation between `eMake ` and the Cluster Manager. Each `eMake ` machine sends a message to the Cluster Manager whenever it wants more agents.
Cluster sharing allows more than one build to run on a cluster by dynamically reallocating agents based on the cluster sharing policy set up in Cluster Manager. The policy is based on an CloudBees Build Acceleration fair-sharing algorithm.
When you create a cluster sharing policy, in addition to the total number of agents in the cluster, you should consider the following information:
-
Same priority builds with the same boost share the cluster equally.
-
Higher priority class builds can take agents away from lower priority class builds.
-
A build cannot lose an agent if losing an agent will cause the build to go below its minimum, unless preemption is set to priority. Builds that cannot get a minimum number of agents must wait, where minimum is the lower of these values: the build class’s MinAgents and the build’s current MaxAgents.
The cluster sharing algorithm assigns agents to builds by reading the values for:
-
Maximum number of agents the build is capable of using, as specified by `eMake ` the last time it made an agent allocation request.
-
BuildID —Unique identifier for each build that sorts builds by age within each priority.
-
Priority —High, normal, or low.
-
Boost within each priority.
Any leftover or unused agents are distributed evenly based on priority and needed agents determination of running builds.