Understanding a Cluster Sharing Policy

1 minute read

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.