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
-
Enable exclusive slots at the consumer level:
-
Open the $EGO_CONFDIR/ego.conf file for editing.
-
Enable the EGO_ENABLE_CONSUMER_LEVEL_EXCLUSIVE parameter.
For example, set the parameter to
Y:
EGO_ENABLE_CONSUMER_LEVEL_EXCLUSIVE=Y
- 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).
-
Save your changes.
Once saved, the
cluster management console is updated:
- The Consumer level option displays within the view.
- The Exclusive Consumer column displays, next to the consumer names, with
check boxes you can select to mark as exclusive consumers.
-
Configure the slot allocation to exclusive consumers on your preferred resource group:
-
From the cluster management console
Dashboard, select .
-
Select the preferred resource group.
-
Expand Slot allocation policy and select .
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.
-
Click .
An information message displays to indicate that the policy will only affect future allocations.
-
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.
-
Click Apply to save your changes.