Overview of resource planning

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. IBM® Spectrum Symphony supports two types of resource scheduling plans: slot-based and multidimensional scheduling.

Allocation types

Resources are allocated 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.

Dynamic resource allocation

Resources are allocated through lending and reclaiming. The following diagram illustrates this relationship:
EGO allocates resources to consumers and leaf consumers by lending and reclaiming
Resource lending and reclaiming work as follows:
Lending behaviour
A11's unused owned slots will be proportionally distributed to its immediate siblings (A12 and A13), based on the siblings' relative ownership. Refer to the green arrows in the relationship diagram.

If, however, A12 and A13 do not have enough workload to use up the rest of A11's ownership, then that unused ownership will propagate up one level in the consumer tree, and will be proportionally split amongst any of A's children (A2 and A3) that require additional resources. This is based on the relative ownership of A's children.

A's children then subdivide those resources to its own children based on their children's relative ownership. For example, A2 will subdivide resources to its own children based on its children's relative ownership. Similarly, A3 will subdivide in the same way. This occurs until it reaches leaf consumers. Refer to the pink arrows in the relationship diagram.

If, however, A's descendants do not have enough workload to use up the rest of the ownership, then the unused ownership will propagate up one level in the consumer tree and will be proportionally split amongst any of the root consumer's children that can still use additional resources, based on the relative ownership of the root consumer's children (B and C). The root consumer's children then subdivide those resources to its own children based on their children's relative ownership, and so on down the tree until it reaches leaf consumers. Refer to the orange arrows in the relationship diagram.

Reclaiming behaviour
If B or C's descendants are using A11's unused owned slots, then any demand from any descendants under A will trigger reclaim. If the entire ownership is not required back at this time (for example, there is not enough workload to trigger the entire reclaim of all resources), B and C will be reclaimed such that their allocations remain proportionally large compared to their relative ownership.

If A2 or A3's descendants are using A11's unused owned slots, then any demand from any descendants under A1 will trigger reclaim. Similarly, they will be reclaimed such that their allocations remain proportionally large compared to their relative ownership.

If A12 and A13 are using A11's unused owned slots, then any demand from A11 will trigger reclaim. Similarly, they will be reclaimed such that their allocations remain proportionally large compared to their relative ownership.

Resource update cycle

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.

Customizing the resource plan

A general order of events for customizing a resource plan might be as follows:

  1. If resource groups are necessary, create them first.
  2. Create consumers and edit the plan.
  3. Customize the resource plan for each consumer.
  4. Create a resource plan for each new resource group you add.

The plan can be modified by the cluster administrator and the consumer administrator. The consumer administrator has restricted permissions.

Out-of-box resource plan

EGO installs with two consumers at the first level: 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.
Important:

If you want to keep the default plan intact (to reset back to it at a later time), be sure to export and save it locally before making any changes. Import it when required.

Reserving management host slot to run services

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:

  • Disable borrowing and lending on the service slot.
  • Set the share ratio to 1.
  • Set the priority uniformly across all consumer parent or child levels for each service.