Platform LSF Administration Guide Version 6.2
What’s New in Platform LSF Version 6.0
Administering Platform LSF
32
What’s New in Platform LSF Version 6.0
Platform LSF Version 6.0 introduces the following new features:
◆
“Policy management” on page 32
❖
“Goal-oriented SLA-driven scheduling” on page 32
❖
“Platform LSF License Scheduler” on page 33
❖
“Job-level exception management” on page 33
❖
“Queue-based fairshare” on page 34
❖
“User fairshare by queue priority” on page 34
◆
“Job group support” on page 34
◆
“High Performance Computing” on page 34
❖
“Dynamic ptile enforcement” on page 34
❖
“Resource requirement specification for advance reservation” on page 35
◆
“Administration and diagnosis” on page 35
❖
“Scheduler dynamic debug” on page 35
❖
“Administrator action messages” on page 35
❖
“Platform LSF Reports” on page 36
◆
“Run-time enhancements” on page 36
❖
“Thread limit enforcement” on page 36
❖
“Non-normalized job run time limit” on page 37
❖
“Resource allocation limit display (blimits command)” on page 37
Policy management
Goal-oriented SLA-
driven scheduling
Goal-oriented SLA-driven scheduling policies help you configure your workload so that
your jobs are completed on time and reduce the risk of missed deadlines:
◆
They enable you to focus on the “what and when” of your projects, not the low-
level details of “how” resources need to be allocated to satisfy various workloads.
◆
They define a “just-in-time” service-level agreement between LSF administrators
and LSF users.
You implement your SLA scheduling policies in service classes associated with your
projects and users. Each service class defines how many jobs should be run to meet
different kinds of goals:
◆
Deadline goals—A specified number of jobs should be completed within a
specified time window. For example, run all jobs submitted over a weekend.
◆
Velocity goals—Expressed as concurrently running jobs. For example: maintain 10
running jobs between 9:00 a.m. and 5:00 p.m. Velocity goals are well suited for short
jobs (run time less than one hour). Such jobs leave the system quickly, and
configuring a velocity goal ensures a steady flow of jobs through the system.
◆
Throughput goals—Expressed as number of finished jobs per hour. For example:
finish 15 jobs per hour between the hours of 6:00 p.m. and 7:00 a.m. Throughput
goals are suitable for medium to long running jobs. These jobs stay longer in the
system, so you typically want to control their rate of completion rather than their
flow.