LSF Version 7.3 - Administering Platform LSF

Administering Platform LSF 361
Goal-Oriented SLA-Driven Scheduling
4 0 4 0 0 0
If the SLA is under reclaim, bsla displays the following keywords:
◆ NUM_RECALLED_HOSTS
◆ RECALLED_HOSTS_TIMEOUT
If a default system service class is configured with ENABLE_DEFAULT_EGO_SLA
in
lsb.params but no other service classes are explicity configured in
lsb.serviceclasses, bsla only displays information for the default SLA.
Changing existing configurations to use EGO-enabled SLA scheduling
When the EGO-enabled SLA is configured, you no longer need static hosts or host
groups, or host partitions.
Changing your configuration is not required for EGO-enabled SLA scheduling to
work. However, if you explicitly configure hosts or host groups in your batch
configuration there is no guarantee that EGO will allocate those hosts to your jobs.
If your business goals require guaranteed availability of resources, you should
change your configuration so that all hosts are allocated from EGO.
Static hosts, host
groups, and host
partitions
A typical LSF configuration divides hosts according to application requirements,
job resource requirements, project ownership, and fairshare. Administrators
usually configure host groups or host partitions to accomplish this.
Under EGO-enabled SLA scheduling, you should:
◆ Replace host groups with EGO resource groups by removing static host and
host group configurations from
lsb.hosts and lsb.queues.
TIP: You should remove any overlap among your host groups so that you have no host
overlap in the EGO resource groups.
◆ Replace host partitions with EGO consumers.
◆ Move resource requirement parameters from the queue to the EGO-enabled
service class.
◆ Submit jobs attached to an SLA so that the SLA consumer gets its host resources
from the EGO resource group.
SLA priority You may have both high priority and low priority jobs where you want to preempt
the low priority jobs when high priority jobs are pending. EGO-enabled SLA uses
EGO resource ownership to enable SLA priority. You can configure two SLAs with
two different EGO consumers and different SLA priorities. The consumer
associated with the higher priority SLA owns the resources and the consumer
assocuated with the lower priority SLA borrows resources from high priority
consumer. When a low priority job is running, and the high priority consumer has
pending jobs, EGO reclaims resources from the low priority SLA and assigns them
to the high priority SLA, allowing the pending job from the high priority SLA to
run.
EGO resource reclaim is not exactly the same as LSF preemption. Preempted jobs
in LSF are suspended, while jobs reclaimed from the EGO-enabled SLA are
requeued.