Learn more about Platform products at http://www.platform.com

[ Platform Documentation ] [ Title ] [ Contents ] [ Previous ] [ Next ] [ Index ]



lsb.serviceclasses


The lsb.serviceclasses file defines the service-level agreements (SLAs) in an LSF cluster as service classes, which define the properties of the SLA.

This file is optional.

You can configure as many service class sections as you need.

Use bsla to display the properties of service classes configured in lsb.serviceclasses and dynamic information about the state of each configured service class.

By default, lsb.serviceclasses is installed in LSB_CONFDIR/cluster_name/configdir.

Contents

[ Top ]


lsb.serviceclasses structure

Each service class definition begins with the line Begin ServiceClass and ends with the line End ServiceClass. A service class name, goals, and priority must be specified; all other parameters are optional.

CONTROL_ACTION

Syntax

CONTROL_ACTION = VIOLATION_PERIOD[minutes] CMD [action]

Description

Optional. Configures a control action to be run if the SLA goal is delayed for a specified number of minutes.

If the SLA goal is delayed for longer than VIOLATION_PERIOD, the action specified by CMD is invoked. The violation period is reset and if the SLA is still active when the violation period expires again, the action runs again. If the SLA has multiple active goals that are in violation, the action is run for each of them.

Example

CONTROL_ACTION = VIOLATION_PERIOD[10] CMD [echo `date`: SLA is 
in violation >> ! /tmp/sla_violation.log]

Default

None

DESCRIPTION

Syntax

DESCRIPTION = text

Description

Optional. Description of the service class. Use bsla to display the description text.

This description should clearly describe the features of the service class to help users select the proper service class for their jobs.

The text can include any characters, including white space. The text can be extended to multiple lines by ending the preceding line with a backslash (\). The maximum length for the text is 512 characters.

Default

None

GOALS

Syntax

GOALS = [throughput | velocity | deadline] [\
[
throughput | velocity | deadline] ...]

Description

Required. Defines the service-level goals for the service class. A service class can have more than one goal, each active at different times of the day and days of the week. Outside of the time window, the SLA is inactive and jobs are scheduled as if no service class is defined. LSF does not enforce any service- level goal for an inactive SLA.

The time windows of multiple service-level goals can overlap. In this case, the largest number of jobs is run.

An active SLA can have a status of On time if it is meeting the goal, and a status Delayed, if it is missing its goals.

The service-level goal defines:

Time window format

The time window of an SLA goal has the standard form:

[day:]hour[:minute]

with the following ranges:

Specify a time window one of the following ways:

You must specify at least the hour. Day of the week and minute are optional. Both the start time and end time values must use the same syntax. If you do not specify a minute, LSF assumes the first minute of the hour (:00). If you do not specify a day, LSF assumes every day of the week. If you do specify the day, you must also specify the minute.

You can specify multiple time windows, but they cannot overlap. For example:

timeWindow(8:00-14:00 18:00-22:00)

is correct, but

timeWindow(8:00-14:00 11:00-15:00)

is not valid.

Examples

GOALS = [THROUGHPUT 2]
GOALS = [THROUGHPUT 10 timeWindow (8:30-16:30)]
GOALS = [VELOCITY 5]
GOALS = [DEADLINE timeWindow (16:30-8:30)]\
      [VELOCITY 10 timeWindow (8:30-16:30)]

NAME

Syntax

NAME = string

Description

Required. Name of the service class.

Specify any ASCII string 60 characters or less. You can use letters, digits, underscores (_) or dashes (-). You cannot use blank spaces. The name you use cannot be the same as an existing host partition name.

Example

NAME = Tofino

Default

None. You must provide a unique name for the service class.

PRIORITY

Syntax

PRIORITY = integer

Description

Required. The service class priority. A higher value indicates a higher priority, relative to other service classes. Similar to queue priority, service classes access the cluster resources in priority order.

LSF schedules jobs from one service class at a time, starting with the highest- priority service class. If multiple service classes have the same priority, LSF run all the jobs from these service classes in first-come, first-served order.

Service class priority in LSF is completely independent of the UNIX scheduler's priority system for time-sharing processes. In LSF, the NICE parameter is used to set the UNIX time-sharing priority for batch jobs.

Default

1 (lowest possible priority)

USER_GROUP

Syntax

USER_GROUP = all | [user_name] [user_group] ...

Description

Optional. A space-separated list of user names or user groups who can submit jobs to the service class. Administrators, root, and all users or groups listed can use the service class.

Use the reserved word all to specify all LSF users. LSF cluster administrators are automatically included in the list of users, so LSF cluster administrators can submit jobs to any service class, or switch any user's jobs into this service class, even if they are not listed.

If user groups are specified in lsb.users, each user in the group can submit jobs to this service class. If a group contains a subgroup, the service class policy applies to each member in the subgroup recursively. If the group can define fairshare among its members, the SLA defined by the service class enforces the fairshare policy among the users of the SLA.

User names must be valid login names. User group names can be LSF user groups (in lsb.users) or UNIX and Windows user groups.

Example

USER_GROUP = user1 user2 ugroup1

Default

all (all users in the cluster can submit jobs to the service class)

Examples

SEE ALSO

bacct(1), bhist(1), bjobs(1), bkill(1), bmod(1), bsla(1), bsub(1), lsb.users(5)

[ Top ]


[ Platform Documentation ] [ Title ] [ Contents ] [ Previous ] [ Next ] [ Index ]


      Date Modified: February 24, 2004
Platform Computing: www.platform.com

Platform Support: support@platform.com
Platform Information Development: doc@platform.com

Copyright © 1994-2004 Platform Computing Corporation. All rights reserved.