Accounting

NOTE: This documents accounting features available in SLURM version 1.3, which are far more extensive than those available in previous releases.

SLURM can be configured to collect accounting information for every job and job step executed. Accounting records can be written to a simple file or a database. Information is available about both currently executing jobs and jobs which have already terminated and can be viewed using the sacct command. sacct can also report resource usage for individual tasks, which can be useful to detect load imbalance between the tasks. The sstat tool can be used to status a currently running job. The sreport can be used to generate reports based upon all jobs executed in a particular time interval.

There are three distinct plugin types associated with resource accounting. The SLURM configuration parameters (in slurm.conf) associated with these plugins include:

The use of sacct or sstat to view information about completed jobs is dependent upon both JobAcctGatherType and AccountingStorageType being configured to collect and store that information. The use of sreport is dependent upon some database being used to store that information.

Storing the accounting information into text files is very simple. Just configure the appropriate plugin (e.g. AccountingStorageType=accounting_storage/filetxt and/or JobCompType=jobcomp/filetxt) and then specify the pathname of the file (e.g. AccountingStorageLoc=/var/log/slurm/accounting and/or JobCompLoc=/var/log/slurm/job_completions). Use the logrotate or similar tool to prevent the log files from getting too large. Send a SIGHUP signal to the slurmctld daemon after moving the files, but before compressing them so that new log files will be created.

Storing the data directly into a database from SLURM may seem attractive, but requires the availability of user name and password data not only for the SLURM control daemon (slurmctld), but also user commands which need to access the data (sacct, sreport, and sacctmgr). Making possibly sensitive information available to all users makes database security more difficult to provide, sending the data through an intermediate daemon can provide better security and performance (through caching data). Gold and SlurmDBD are two such services. Our initial implementation relied upon Gold, but we found its performance to be inadequate for our needs and developed SlurmDBD. SlurmDBD (SLURM Database Daemon) is written in C, multi-threaded, secure, and considerably faster than Gold. The configuration required to use SlurmDBD will be described below. Direct database or Gold use would be similar.

Note that SlurmDBD relies upon existing SLURM plugins for authentication and database use, but the other SLURM commands and daemons are not required on the host where SlurmDBD is installed. Install the slurmdbd and slurm-plugins RPMs on the computer when SlurmDBD is to execute.

Infrastructure

With the SlurmDBD, we are able to collect data from multiple clusters in a single location. This does impose some constraints on the user naming and IDs. Accounting is maintained by user name (not user ID), but a given user name should refer to the same person across all of the computers. Authentication relies upon user ID numbers, so those must be uniform across all computers communicating with each SlurmDBD, at least for users requiring authentication. In particular, the configured SlurmUser must have the same name and ID across all clusters. If you plan to have administrators of user accounts, limits, etc. they must also have consistent names and IDs across all clusters. If you plan to restrict access to accounting records (e.g. only permit a user to view records of his jobs), then all users should have consistent names and IDs.

The best way to insure security of the data is by authenticating communications to the SlurmDBD and we recommend Munge for that purpose. If you have one cluster managed by SLURM and execute the SlurmDBD on that one cluster, the normal Munge configuration will suffice. Otherwise Munge should then be installed on all nodes of all SLURM managed clusters, plus the machine where SlurmDBD executes. You then have a choice of either having a single Munge key for all of these computers or maintaining a unique key for each of the clusters plus a second key for communications between the clusters for better security. Munge enhancements are planned to support two keys within a single configuration file, but presently two different daemons must be started with different configurations to support two different keys (create two key files and start the daemons with the --key-file option to locate the proper key plus the --socket option to specify distinct local domain sockets for each). The pathname of local domain socket will be needed in the SLURM and SlurmDBD configuration files (slurm.conf and slurmdbd.conf respectively, more details are provided below).

Whether you use any authentication module or not you will need to have a way for the SlurmDBD to get uid's for users and/or admin. If using Munge it is ideal for your users to have the same id on all your clusters. If this is the case you should have a combination of every clusters /etc/passwd file on the database server to allow the DBD to resolve names for authentication. If using Munge and a users name is not in the passwd file the action will fail. If not using Munge, you should add anyone you want to be an administrator or operator to the passwd file. If they plan on running sacctmgr or any of the accounting tools they should have the same uid, or they will not authentic correctly. An LDAP server could also server as a way to gather this information.

Slurm JobComp Configuration

Presently job completion is not supported with the SlurmDBD, but can be written directly to a database, script or flat file.If you are running with the accounting storage, you may not need to run this since it contains much of the same information.If you would like to configure this, some of the more important parameters include:

SLURM Accounting Configuration Before Build

While the SlurmDBD will work with a flat text file for recording job completions and such this configuration will not allow "associations" between a user and account. A database allows such a configuration.

MySQL is the preferred database, PostgreSQL is supported for job and step accounting only. The infrastructure for PostgresSQL for use with associations is not yet supported, meaning sacctmgr will not work correcting. If interested in adding this capabilty for PostgresSQL please email slurm-dev@lists.llnl.gov.

To enable this database support one only needs to have the development package for the database they wish to use on the system. The slurm configure script uses mysql_config and pg-config to find out the information it needs about installed libraries and headers. You can specify where your mysql_config script is with the --with-mysql_conf=/path/to/mysql_config option when configuring your slurm build. A similar option is available for PostgreSQL also. On a successful configure, output is something like this: 

checking for mysql_config... /usr/bin/mysql_config
MySQL test program built properly.

SLURM Accounting Configuration After Build

For simplicity sake we are going to reference everything as if you are running with the SlurmDBD. You can communicate with a storage plugin directly, but that offers minimal authentication.

Several SLURM configuration parameters must be set to support archiving information in SlurmDBD. SlurmDBD has a separate configuration file which is documented in a separate section. Note that you can write accounting information to SlurmDBD while job completion records are written to a text file or not maintained at all. If you don't set the configuration parameters that begin with "JobComp" then job completion records will not be recorded.

SlurmDBD Configuration

SlurmDBD requires its own configuration file called "slurmdbd.conf". This file should be only on the computer where SlurmDBD executes and should only be readable by the user which executes SlurmDBD (e.g. "slurm"). This file should be protected from unauthorized access since it contains a database login name and password. See "man slurmdbd.conf" for a more complete description of the configuration parameters. Some of the more important parameters include:

MySQL Configuration

While SLURM will create the database automatically you will need to make sure the StorageUser is given permissions in MySQL to do so. As the mysql user grant privileges to that user using a command such as 

GRANT ALL ON StorageLoc.* TO 'StorageUser'@'StorageHost';
(The ticks are needed)

live example:

mysql@snowflake:~$ mysql
Welcome to the MySQL monitor.Commands end with ; or \g.
Your MySQL connection id is 538
Server version: 5.0.51a-3ubuntu5.1 (Ubuntu)

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> grant all on slurm_acct_db.* TO 'slurm'@'localhost';
Query OK, 0 rows affected (0.00 sec)

or with a password...

mysql> grant all on slurm_acct_db.* TO 'slurm'@'localhost' 
    -> identified by 'some_pass' with grant option;
Query OK, 0 rows affected (0.00 sec)

This will grant user 'slurm' access to do what he needs to do on the local host. This should be done before the SlurmDBD will work properly.

Tools

There are a few tools available to work with accounting data, sacct, sacctmgr, and sreport. These tools all get or set data through the SlurmDBD daemon.

See the man pages for each command for more information.

Web interfaces with graphical output is currently under development and should be available in the Fall of 2008. A tool to report node state information is also under development.

Database Configuration

Accounting records are maintained based upon what we refer to as an Association, which consists of four elements: cluster, account, user names and an optional partition name. Use the sacctmgr command to create and manage these records. There is an order to set up accounting associations. You must define clusters before you add accounts and you must add accounts before you can add users.

For example, to add a cluster named "snowflake" to the database execute this line:

sacctmgr add cluster snowflake

Add accounts "none" and "test" to cluster "snowflake" with an execute line of this sort:

sacctmgr add account none,test Cluster=snowflake \
  Description="none" Organization="none"

If you have more clusters you want to add these accounts, to you can either not specify a cluster, which will add the accounts to all clusters in the system, or comma separate the cluster names you want to add to in the cluster option. Note that multiple accounts can be added at the same time by comma separating the names. Some description of the account and the organization which it belongs must be specified. These terms can be used later to generated accounting reports. Accounts may be arranged in a hierarchical fashion, for example accounts chemistry and physics may be children of the account science. The hierarchy may have an arbitrary depth. Just specify the parent='' option in the add account line to construct the hierarchy. For the example above execute

sacctmgr add account science \
 Description="science accounts" Organization=science
sacctmgr add account chemistry,physics parent=science \
 Description="physical sciences" Organization=science

Add users to accounts using similar syntax. For example, to permit user da to execute jobs on all clusters with a default account of test execute:

sacctmgr add user da default=test

If AccountingStorageEnforce=1 is configured in the slurm.conf of the cluster snowflake then user da would be allowed to run in account test and any other accounts added in the future. Any attempt to use other accounts will result in the job being aborted. Account test will be the default if he doesn't specify one in the job submission command.

Partition names can also be added to an "add user" command with the Partition='partitionname' option to specify an association specific to a slurm partition.

Account Options

When either adding or modifying an account, the following sacctmgr options are available:

User Options

When either adding or modifying a user, the following sacctmgr options are available:

Modifying Entities

When modifying entities, you can specify many different options in SQL-like fashion, using key words like where and set. A typical execute line has the following form: 

sacctmgr modify <entity> set <options> where <options>

For example:

sacctmgr modify user set default=none where default=test

will change all users with a default account of "test" to account "none". Once an entity has been added, modified or removed, the change is sent to the appropriate SLURM daemons and will be available for use instantly.

Removing Entities

Removing entities using an execute line similar to the modify example above, but without the set options. For example, remove all users with a default account "test" using the following execute line:

sacctmgr remove user where default=test

Note: In most cases, removed entities are preserved, but flagged as deleted. If an entity has existed for less than 1 day, the entity will be removed completely. This is meant to clean up after typographic errors.

Last modified 27 June 2008

Lawrence Livermore National Laboratory
7000 East Avenue • Livermore, CA 94550
Operated by Lawrence Livermore National Security, LLC, for the Department of Energy's
National Nuclear Security Administration
NNSA logo links to the NNSA Web site Department of Energy logo links to the DOE Web site