Exclusive slot allocation

IBM® Spectrum Symphony supports several slot allocation policies: stacked, balanced, and exclusive. Unlike stacked or balance policies, an exclusive policy uses all free slots from a host. By default, this policy uses exclusive slots at the allocation level to ensure host resources are fully used (that is, each host is assigned to only one allocation). Alternatively, you can enable exclusive slots at the consumer level (where free slots from the host can be shared and assigned to any number of allocations, but only amongst a select set of consumers within an exclusive consumer group). In both cases, you configure this allocation policy for each resource group in your resource plan, using the cluster management console.

An exclusive slot allocation policy is useful to resolve resource fragmentation issues. In a cluster made up of multi-core hosts, over time, a host's usage may become fragmented. This may occur when a single-thread task is allocated a multi-core host. In this case, the task occupies one core but the remaining cores are not used. This problem can extend to many hosts in the cluster to the point where there are a lot of free slots but none of the hosts are totally free.

For example, suppose we have two 8-core hosts and two applications: one with 1-core sessions and one with 4-core sessions. If there are five 1-core tasks from App1 occupying 5 of 8 slots on HostA and then a 4-core task is submitted by App2, then it may get the remaining 3 slots on HostA and another 1 slot on HostB. However, this configuration of slots is not usable by the 4-core task in App2.

Using exclusive slot allocation can help resolve this resource fragmentation problem:
  • All the slots of each host in the resource group are assigned to only one consumer at a time. If there is one slot on a host allocated to one consumer, the remaining slots on the same host are not allocated to other consumers; these slots will only be allocated to this consumer when it has demand. When a consumer reclaims resources from another consumer, EGO enforces the reclaiming of all slots on a host. Note that this behavior may cause a consumer to be allocated fewer slots than it deserves because a consumer can only be allocated slots on a host when it deserves the whole host. The same principle applies to a consumer that wants to reclaim slots.
  • If the number of slots on a host is increased, EGO does not allocate the extra slots to the application until existing allocations on the host are released.

Feature interactions

  • The exclusive slot allocation policy at both the allocation and consumer levels, is not compatible with MaxInstancesPerHost and MaxInstancesPerSlot configuration, which specifies the number of slots provided on each host. If MaxInstancesPerHost and MaxInstancesPerSlot is configured in the EGO service profile, the service cannot use a resource group configured for the exclusive slot policy. If you continue to use both configurations together, the EGO service will not start because of the conflicting combined configurations.
  • The exclusive slot allocation policy at both the allocation and consumer levels, is not compatible with the rusage feature, which limits the number of service instances applications can run on a host.