Administering Platform LSF - SAS

Chapter 15
Goal-Oriented SLA-Driven Scheduling
How service classes perform goal-oriented scheduling
Optimum number
of running jobs
Goal-oriented scheduling makes use of other, lower level LSF policies like
queues and host partitions to satisfy the service-level goal that the service class
expresses. The decisions of a service class are considered first before any
queue or host partition decisions. Limits are still enforced with respect to lower
level scheduling objects like queues, hosts, and users.
As jobs are submitted, LSF determines the optimum number of job slots (or
concurrently running jobs) needed for the service class to meet its service-level
goals. LSF schedules a number of jobs at least equal to the optimum number
of slots calculated for the service class.
LSF attempts to meet SLA goals in the most efficient way, using the optimum
number of job slots so that other service classes or other types of work in the
cluster can still progress. For example, in a service class that defines a deadline
goal, LSF spreads out the work over the entire time window for the goal, which
avoids blocking other work by not allocating as many slots as possible at the
beginning to finish earlier than the deadline.
Submitting jobs to a service class
Use the bsub -sla service_class_name to submit a job to a service class for
SLA-driven scheduling.
You submit jobs to a service class as you would to a queue, except that a
service class is a higher level scheduling policy that makes use of other, lower
level LSF policies like queues and host partitions to satisfy the service-level
goal that the service class expresses.
For example:
% bsub -W 15 -sla Kyuquot sleep 100
submits the UNIX command sleep together with its argument 100 as a job to
the service class named Kyuquot.
The service class name where the job is to run is configured in
lsb.serviceclasses. If the SLA does not exist or the user is not a member
of the service class, the job is rejected.
Outside of the configured time windows, the SLA is not active, and LSF
schedules jobs without enforcing any service-level goals. Jobs will flow
through queues following queue priorities even if they are submitted with
-sla.
Submit with run
limit
-sla and -g options
You should submit your jobs with a run time limit (-W option) or the queue should
specify a run time limit (RUNLIMIT in the queue definition in lsb.queues). If you do
not specify a run time limit, LSF automatically adjusts the optimum number of
running jobs according to the observed run time of finished jobs.
You cannot use the -g option with -sla. A job can either be attached to a job
group or a service class, but not both.
Administering Platform LSF 241