Configuring exclusive slots at the consumer level

An exclusive policy uses all free slots from a host. By default, this policy uses exclusive slots at the allocation level (that is, each host is assigned to only one allocation). Alternatively, you can configure 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). This process includes setting a parameter in the ego.conf file, and then using the cluster management console to select exclusive slot allocation for each resource group in your resource plan.

Before you begin

Exclusive consumers are supported on IBM® Spectrum Symphony Linux® 64-bit hosts.

Use exclusive consumers with slot-based hybrid scheduling polices only. Exclusive consumers are not supported on share policies, ownership model, standby services or global standby services, resource group preferences, or selective reclaim.

Note the following interactions between exclusive slot allocation policies and other IBM Spectrum Symphony features:

  • 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.

About this task

By default, an exclusive policy uses exclusive slots at the allocation level (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). This topic covers consumer-level exclusive slots. To use exclusive slots at the allocation level, refer to Enabling exclusive slots at the allocation level instead.

Procedure

  1. Enable exclusive slots at the consumer level:
    1. Open the $EGO_CONFDIR/ego.conf file for editing.
    2. Enable the EGO_ENABLE_CONSUMER_LEVEL_EXCLUSIVE parameter.
      For example, set the parameter to Y:
      EGO_ENABLE_CONSUMER_LEVEL_EXCLUSIVE=Y
    3. Optional: If you also want to prevent unwanted reclaim of owned slots, enable the EGO_DISABLE_RECLAIM_HYBRID_OWN parameter to Y:
      EGO_DISABLE_RECLAIM_HYBRID_OWN=Y
      When this parameter is set to Y:
      • For a leaf consumer that is an exclusive consumer, EGO will only reclaim the number of slots exceeding the consumer’s hybrid owned slots.
      • For a leaf consumer that is a non-exclusive consumer, the consumer is in the same group as all other leaf consumers that can share the same host with it. This parameter will take effect at the group level (that is, EGO will only reclaim the number of slots exceeding the group’s hybrid owned slots, which is the sum of hybrid owned slots of all leaf consumers in this group).
    4. Save your changes.
      Once saved, the cluster management console is updated:
      • The Consumer level option displays within the Resources > Resource Planning (Slot) > Resource Plan > Slot allocation policy > Exclusive view.
      • The Exclusive Consumer column displays, next to the consumer names, with check boxes you can select to mark as exclusive consumers.
  2. Configure the slot allocation to exclusive consumers on your preferred resource group:
    1. From the cluster management console Dashboard, select Resources > Resource Planning (Slot) > Resource Plan.
    2. Select the preferred resource group.
    3. Expand Slot allocation policy and select Hybrid policy.

      Use exclusive consumers with slot-based hybrid scheduling polices only. Exclusive consumers are not supported on share policies, ownership model, standby services or global standby services, resource group preferences, or selective reclaim.

    4. Click Exclusive > Consumer level.

      An information message displays to indicate that the policy will only affect future allocations.

    5. From the Exclusive Consumer column, select the exclusive consumers to define. Note the following information about these consumers:

      Once you flag a consumer as exclusive (that is, with a check mark), then all ancestor consumers for that exclusive consumer are also automatically flagged exclusive.

      Each exclusive consumer has a consumer group. A root consumer (/) has a consumer group. A leaf (child) consumer can fall under one of the following types of consumer groups:
      • A leaf consumer, with an exclusive flag, belongs to the consumer group of the same name.
      • A leaf consumer, without an exclusive flag can belong to one of the following consumer groups:
        • If the leaf consumer has one or more exclusive ancestor consumers, it belongs the consumer group owned by the closest exclusive ancestor consumer.
        • If the leaf consumer does not have exclusive ancestor consumers, it belongs to the consumer group owned by the root consumer (/).

      Each consumer group has an allocation group. An allocation for a leaf consumer belongs to the allocation group for this leaf consumer's consumer group.

      A host will only be shared by the allocations within the same allocation group; it will not be shared by allocations in different allocation groups.

      Tip: As a best practice, note the following guidelines:
      • Place sibling nodes in the same allocation group by checking their parent node with an exclusive flag, or place them in different groups by setting every node with an exclusive flag.
      • If some sibling nodes are in one allocation group, and others are in another group, and there is a reclaim between the sibling nodes, an under-used or satisfied allocation in the over-used group may be reclaimed.

        For example, take the scenario where there are three leaf nodes: a11, a12, and a13, with equal (one to one to one) share ratio. Leaf nodes a11 and a12 are in the same allocation group, whereas leaf node a13 is in another group. There are three hosts in the cluster.

        If leaf node a11 gets one slot from each host for a total of three slots, and a12 gets the remaining slots on the three hosts, that will leave no free slots. When there is a demand on leaf node a13, then a13 should get one host based on its share ratio. When leaf node a13 reclaims hosts, leaf node a11 will be reclaimed although it is not over-used, based on the share ratio.

    6. Click Apply to save your changes.