Platform LSF Administration Guide Version 6.2

Chapter 17
Goal-Oriented SLA-Driven Scheduling
Administering Platform LSF
313
How service classes perform goal-oriented scheduling
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.
Optimum number
of running jobs
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
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.
-sla and -g options
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.