IBM LoadLeveler for AIX 5L: Using and Administering

Step 3: Define LoadLeveler machine characteristics

You can use the following keywords to define the characteristics of machines in the LoadLeveler cluster:

• ARCH
• CLASS
• Feature
• START_DAEMONS
• SCHEDD_RUNS_HERE
• SCHEDD_SUBMIT_AFFINITY
• STARTD_RUNS_HERE
• X_RUNS_HERE

ARCH = string (required)

Indicates the standard architecture of the system. The architecture you specify here must be specified in the same format in the requirements and preferences statements in job command files. The administrator defines the character string for each architecture.

For example, to define a machine as a RS/6000, the keyword would look like:

  ARCH = R6000

CLASS = { "class_name" ... } | { "No_Class" } | class_name (count) ...

This keyword determines whether a machine will accept jobs of a certain job class. For parallel jobs, you must define a class instance for each task you want to run on a node using one of two formats:

• The format, CLASS = class_name (count), defines the CLASS names using a statement that names the classes and sets the number of tasks for each class in parenthesis.

  With this format, the following rules apply:

  • Each class can have only one entry
  • If a class has more than one entry or there is a syntax error, the entire CLASS statement will be ignored
  • If the CLASS statement has a blank value, it will be set to No_Class (1)
  • The number of instances for a class specified inside the parenthesis ( ) must be an unsigned integer. If the number specified is 0, it is correct syntactically, but the class will not be defined in LoadLeveler
  • If the number of instances for all classes in the CLASS statement are 0, the default No_Class(1) will be used
• The format, CLASS = { "class1" "class2" "class2" "class2"}, defines the CLASS names using a statement that names each class and sets the number of tasks for each class based on the number of times that the class name is used inside the {} operands.

Note:

With both formats, the class names list is blank delimited.

You can specify a default_class in the default user stanza of the administration file to set a default class. If you don't, jobs will default to the class called No_Class.

In order for a LoadLeveler job to run on a machine, the machine must have a vacancy for the class of that job. If the machine is configured for only one No_Class job and a LoadLeveler job is already running there, then no further LoadLeveler jobs are started on that machine until the current job completes.

You can have a maximum of 1024 characters in the class statement. You cannot use allclasses as a class name, since this is a reserved LoadLeveler keyword.

You can assign multiple classes to the same machine by specifying the classes in the LoadLeveler configuration file (called LoadL_config) or in the local configuration file (called LoadL_config.local). The classes, themselves, should be defined in the administration file. See Setting up a single machine to have multiple job classes and Step 3: Specify class stanzas for more information on classes.

Defining classes - examples

Example 1

This example defines the default class:

Class = No_Class(1)

or

Class = { "No_Class" }

This is the default. The machine will only run one LoadLeveler job at a time that has either defaulted to, or explicitly requested class No_Class. A LoadLeveler job with class CPU_bound, for example, would not be eligible to run here. Only one LoadLeveler job at a time will run on the machine.

Example 2

This example specifies multiple classes:

Class = No_Class(2)

or

Class = { "No_Class" "No_Class" }

The machine will only run jobs that have either defaulted to or explicitly requested class No_Class. A maximum of two LoadLeveler jobs are permitted to run simultaneously on the machine if the MAX_STARTERS keyword is not specified. See Step 5: Specify how many jobs a machine can run for more information on MAX_STARTERS.

Example 3

This example specifies multiple classes:

Class = No_Class(1) Small(1) Medium(1) Large(1)

or

Class = { "No_Class" "Small" "Medium" "Large" }

The machine will only run a maximum of four LoadLeveler jobs that have either defaulted to, or explicitly requested No_Class, Small, Medium, or Large class. A LoadLeveler job with class IO_bound, for example, would not be eligible to run here.

Example 4

This example specifies multiple classes:

Class = B(2) D(1)

or

Class = { "B" "B" "D" }

The machine will run only LoadLeveler jobs that have explicitly requested class B or D. Up to three LoadLeveler jobs may run simultaneously: two of class B and one of class D. A LoadLeveler job with class No_Class, for example, would not be eligible to run here.

Feature = {"string" ...}

Where string is the (optional) characteristic to use to match jobs with machines.

You can specify unique characteristics for any machine using this keyword. When evaluating job submissions, LoadLeveler compares any required features specified in the job command file to those specified using this keyword. You can have a maximum of 1024 characters in the feature statement.

For example, if a machine has licenses for installed products ABC and XYZ, in the local configuration file you can enter the following:

Feature = {"abc" "xyz"}

When submitting a job that requires both of these products, you should enter the following in your job command file:

requirements = (Feature == "abc") && (Feature == "xyz")

START_DAEMONS = true | false

Specifies whether to start the LoadLeveler daemons on the node. When true, the daemons are started.

In most cases, you will probably want to set this keyword to true. An example of why this keyword would be set to false is if you want to run the daemons on most of the machines in the cluster but some individual users with their own local configuration files do not want their machines to run the daemons. The individual users would modify their local configuration files and set this keyword to false. Because the global configuration file has the keyword set to true, their individual machines would still be able to participate in the LoadLeveler cluster.

Also, to define the machine as strictly a submit-only machine, set this keyword to false. For more information, see the submit-only keyword.

SCHEDD_RUNS_HERE = true | false

Specifies whether the schedd daemon runs on the host. If you do not want to run the schedd daemon, specify false.

To define the machine as an executing machine only, set this keyword to false. For more information, see the submit-only keyword.

SCHEDD_SUBMIT_AFFINITY = true | false

Specifies that the llsubmit command submits a job to the machine where the command was invoked, provided that the schedd daemon is running on that machine (this is called schedd affinity). Installations with a large number of nodes should consider setting this keyword to false. For more information, see Scaling considerations.

STARTD_RUNS_HERE = true | false

Specifies whether the startd daemon runs on the host. If you do not want to run the startd daemon, specify false.

X_RUNS_HERE = true | false

Set X_RUNS_HERE to true if you want to start the keyboard daemon.