The resource plan defines how cluster resources are allocated among consumers. The plan takes into account the differences between consumers and their needs, resource properties, and various other policies concerning consumer rank and the allocation of resources.
In general, the cluster administrator uses the SDK to first define consumer conditions that trigger a request to EGO for additional resources (for example, if an application response time or a queue depth exceeds some predetermined threshold). When a request from a consumer comes in for additional resources, EGO uses the resource plan to determine whether or not to allocate resources to that consumer. The resource plan also controls the quantity of resources that EGO allocates to the consumer at any time.
A resource plan supports a number of rules used to set policies for how, when, and where resources get allocated. This includes policies concerning resource allocation and ownership, borrowing and lending, sharing, and the reclaiming of borrowed resources. In all cases, resource plans must be set at the leaf level (consumers with no descendents).
EGO allocates resources to a consumer through ownership, borrowing, or sharing. A consumer can use one or a combination of these methods to secure resources. All are a form of allocation.
Ownership refers to the guaranteed allocation of a minimum number of resources to a consumer.
Borrowing refers to the temporary allocation of owned resources from a lending consumer to a consumer with an unsatisfied demand.
Sharing refers to the temporary allocation of unowned resources from a “share pool” to a consumer with an unsatisfied demand.
For dynamically allocated resources, client demand is fundamental to the allocation. If there is competition from other consumers, or limits configured for the consumer, the allocation could be less than what is needed. This is considered a shortfall.
The priority for allocation is to satisfy each consumer's reserved ownership, then allocate remaining resources to consumers that have demand. By default, resources are systematically allocated in the following order:
EGO always allocates owned resources first to consumers according to the resource plan.
Then, when there are no owned resources left to borrow from consumers who are willing to lend them, EGO allocates unowned resources from the share pool to consumers with unsatisfied demand.
Share pool resources first come from the “family” pool (any unowned resources within a particular branch in the consumer tree).
Once the family pool is exhausted, then EGO distributes resources from other branches in the consumer tree, eventually moving up the tree to distribute any unowned resources from the cluster level.
Share pool resources are distributed to competing leaf consumers according to their allowed share ratio. If the share ratio for two competing consumers is 1:1, resources are allocated evenly. If the share ratio is 1:2, then the second competing consumer gets twice as many available resources from the share pool.
Finally, when there is demand, consumers lend and borrow resources from each other.
If a consumer has previously lent out resources to another consumer, the lending consumer recalls the owned resources necessary to meet its current unsatisfied demands once other allocation options have been exhausted, regardless of the borrowing consumer’s priority. This default behavior can be changed so that owned resources are instead recalled first before borrowing from other consumers.
By default, EGO updates the resource information used for scheduling every 60 seconds. The frequency of the update cycle is determined by EGO_RESOURCE_UPDATE_INTERVAL in ego.conf.
The update cycle determines how quickly EGO detects a new resource or unavailable resource in the cluster. It also determines how often EGO detects changes in load indices that might be used to allocate resources to jobs.
A general order of events for customizing a resource plan might be as follows:
The plan can be modified by the cluster administrator and the consumer administrator. The consumer administrator has restricted permissions.
EGO installs with two top-level consumers: ManagementServices and SampleApplications. Do not remove the ManagementServices branch: it contains required system services.
The default resource plan can be modified as required (except for removing the ManagementServices branch). You need to create a consumer for each new application.
The provided sample consumer, EclipseSamples, allows you to begin using EGO right away. This consumer comes with registered applications that are ready to run. You must have the EGO SDK installed.
By default, there are 12 slots per management host. Although this number is configurable, be aware that each service requires at least 1 slot to run. For example, if you configure the EGO Services leaf consumer with 0 owned slots, the cluster does not run. Note that slot ownership must filter down through the consumer tree until a service inherits a slot directly from a parent. To avoid service interruption and to protect a service’s owned resource, ensure the following: