Accounting and Resource Limits

Slurm can be configured to collect accounting information for every job and job step executed. Accounting records can be written to a simple text file or a database. Information is available about both currently executing jobs and jobs which have already terminated. The sacct command can report resource usage for running or terminated jobs including individual tasks, which can be useful to detect load imbalance between the tasks. The sstat command can be used to status only currently running jobs. It also can give you valuable information about imbalance between tasks. 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:

  • AccountingStorageType controls how detailed job and job step information is recorded. You can store this information in a text file, MySQL or MariaDB database (using the InnoDB storage engine), optionally using SlurmDBD for added security.
  • JobAcctGatherType is operating system dependent and controls what mechanism is used to collect accounting information. Supported values are jobacct_gather/aix, jobacct_gather/linux and jobacct_gather/none (no information collected).
  • JobCompType controls how job completion information is recorded. This can be used to record basic job information such as job name, user name, allocated nodes, start time, completion time, exit status, etc. If the preservation of only basic job information is required, this plugin should satisfy your needs with minimal overhead. You can store this information in a text file, or MySQL or MariaDB database.

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

The use of sacct or sstat to view information about resource usage within jobs is dependent upon both JobAcctGatherType and AccountingStorageType being configured to collect and 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) and SlurmDBD provides such services. SlurmDBD (SLURM Database Daemon) is written in C, multi-threaded, secure and fast. The configuration required to use SlurmDBD will be described below. Storing information directly into database would be similar.

Note that SlurmDBD relies upon existing SLURM plugins for authentication and SLURM sql for database use, but the other SLURM commands and daemons are not required on the host where SlurmDBD is installed. Install the slurmdbd, slurm-plugins, and slurm-sql RPMs on the computer when SlurmDBD is to execute. If you want munge authentication, which is highly recommended, you will also need to install the slurm-munge RPM.

If SlurmDBD is configured for use but not responding then slurmctld will utilize an interal cache until SlurmDBD is returned to service. The cached data is written by slurmctld to local storage upon shutdown and recovered at startup. If SlurmDBD is not available when slurmctld starts, a cache of valid bank accounts, user limits, etc. based upon their state when the daemons were last communicating will be used. Note that SlurmDBD must be responding when slurmctld is first started since no cache of this critical data will be available. Job and step accounting records generated by slurmctld will be written to a cache as needed and transferred to SlurmDBD when returned to service.

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 plugin, use of the job completion plugin is probably redundant. If you would like to configure this, some of the more important parameters include:

  • JobCompHost: Only needed if using a database. The name or address of the host where the database server executes.
  • JobCompPass: Only needed if using a database. Password for the user connecting to the database. Since the password can not be security maintained, storing the information directly in a database is not recommended.
  • JobCompPort: Only needed if using a database. The network port that the database accepts communication on.
  • JobCompType: Type of jobcomp plugin set to "jobcomp/mysql" or "jobcomp/filetxt".
  • JobCompUser: Only needed if using a database. User name to connect to the database with.

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 or MariaDB is the preferred database. To enable this database support one only needs to have the development package for the database they wish to use on the system. Slurm uses the InnoDB storage engine in MySQL to make rollback possible. This must be available on your MySQL installation or rollback will not work.

The slurm configure script uses mysql_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. On a successful configure, output is something like this: 

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

Note that at least the first time running the slurmdbd with MySQL you need to make sure your my.cnf file has innodb_buffer_pool_size equal to at least 64 megabytes. You can accomplish this by adding the line:
innodb_buffer_pool_size=64M
under the [mysqld] reference in the my.cnf file and restarting the mysqld. This is needed when converting large tables over to the new database schema.

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 security.

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 "AccountingStorage" then accounting information will not be referenced or recorded.

  • AccountingStorageEnforce: This option contains a comma separated list of options you may want to enforce. The valid options are any comma separated combination of
    • associations - This will prevent users from running jobs if their association is not in the database. This option will prevent users from accessing invalid accounts.
    • limits - This will enforce limits set to associations and if a qos is used and has limits those as well. By setting this option, the 'associations' option is automatically set. If a qos is used the limits will be enforced, but 'qos' described below is still needed if you want to enforce access to the qos.
    • nojobs - This will make it so no job information is stored in accounting. By setting this 'nosteps' is also set.
    • nosteps - This will make it so no step information is stored in accounting. Both nojobs and nosteps could be helpful in an environment where you want to use limits but don't really care about utilization.
    • qos - This will require all jobs to specify (either overtly or by default) a valid qos (Quality of Service). QOS values are defined for each association in the database. By setting this option, the 'associations' option is automatically set. If you want QOS limits to be enforced you need to use the 'limits' option.
    • safe - This will ensure a job will only be launched when using an association or qos that has a GrpCPUMins limit set if the job will be able to run to completion. Without this option set, jobs will be launched as long as their usage hasn't reached the cpu-minutes limit which can lead to jobs being launched but then killed when the limit is reached. By setting this option, both the 'associations' option and the 'limits' option are set automatically.
    • wckeys - This will prevent users from running jobs under a wckey that they don't have access to. By using this option, the 'associations' option is automatically set. The 'TrackWCKey' option is also set to true.
    (NOTE: The association is a combination of cluster, account, user names and optional partition name.)
    Without AccountingStorageEnforce being set (the default behavior) jobs will be executed based upon policies configured in SLURM on each cluster.
    It is advisable to run without the option 'limits' set when running a scheduler on top of SLURM like Moab that does not update in real time their limits per association.
  • AccountingStorageHost: The name or address of the host where SlurmDBD executes
  • AccountingStoragePass: If using SlurmDBD with a second MUNGE daemon, store the pathname of the named socket used by MUNGE to provide enterprise-wide authentication (i.e. /var/run/munge/moab.socket.2). Otherwise the default MUNGE daemon will be used.
  • AccountingStoragePort: The network port that SlurmDBD accepts communication on.
  • AccountingStorageType: Set to "accounting_storage/slurmdbd".
  • ClusterName: Set to a unique name for each Slurm-managed cluster so that accounting records from each can be identified.
  • TrackWCKey: Boolean. If you want to track wckeys (Workload Characterization Key) of users. A Wckey is an orthogonal way to do accounting against possibly unrelated accounts. When a job is run, use the --wckey option to specify a value and accounting records will be collected by this wckey.

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:

  • AuthInfo: If using SlurmDBD with a second MUNGE daemon, store the pathname of the named socket used by MUNGE to provide enterprise-wide. Otherwise the default MUNGE daemon will be used.
  • AuthType: Define the authentication method for communications between SLURM components. A value of "auth/munge" is recommended.
  • DbdHost: The name of the machine where the Slurm Database Daemon is executed. This should be a node name without the full domain name (e.g. "lx0001"). This defaults to localhost but should be supplied to avoid a warning message.
  • DbdPort: The port number that the Slurm Database Daemon (slurmdbd) listens to for work. The default value is SLURMDBD_PORT as established at system build time. If none is explicitly specified, it will be set to 6819. This value must be equal to the AccountingStoragePort parameter in the slurm.conf file.
  • LogFile: Fully qualified pathname of a file into which the Slurm Database Daemon's logs are written. The default value is none (performs logging via syslog).
  • PluginDir: Identifies the places in which to look for SLURM plugins. This is a colon-separated list of directories, like the PATH environment variable. The default value is the prefix given at configure time + "/lib/slurm".
  • SlurmUser: The name of the user that the slurmctld daemon executes as. This user must exist on the machine executing the Slurm Database Daemon and have the same user ID as the hosts on which slurmctld execute. For security purposes, a user other than "root" is recommended. The default value is "root". This name should also be the same SlurmUser on all clusters reporting to the SlurmDBD.
  • StorageHost: Define the name of the host the database is running where we are going to store the data. Ideally this should be the host on which SlurmDBD executes. But could be a different machine.
  • StorageLoc: Specifies the name of the database where accounting records are written, for databases the default database is slurm_acct_db. Note the name can not have a '/' in it or the default will be used.
  • StoragePass: Define the password used to gain access to the database to store the job accounting data.
  • StoragePort: Define the port on which the database is listening.
  • StorageType: Define the accounting storage mechanism is. The only acceptable value at present is "accounting_storage/mysql". The value "accounting_storage/mysql" indicates that accounting records should be written to a MySQL or MariaDB database specified by the StorageLoc parameter. This value must be specified.
  • StorageUser: Define the name of the user we are going to connect to the database with to store the job accounting data.

MySQL Configuration

While SLURM will create the database tables automatically you will need to make sure the StorageUser is given permissions in the MySQL or MariaDB database 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)

(You need to be root to do this. Also in the info for password usage there is a line that starts with '->'. This a continuation prompt since the previous mysql statement did not end with a ';'. It assumes that you wish to input more info.)

If you want Slurm to create the database itself, and any future databases, you can change your grant line to be *.* instead of StorageLoc.*

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)

You may also need to do the same with the system name in order for mysql to work correctly:

mysql> grant all on slurm_acct_db.* TO 'slurm'@'system0';
Query OK, 0 rows affected (0.00 sec)
where 'system0' is the localhost or database storage host.

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)

The same is true in the case, you made to do the same with the system name:

mysql> grant all on slurm_acct_db.* TO 'slurm'@'system0'
    -> identified by 'some_pass' with grant option;
where 'system0' is the localhost or database storage host.

Verify you have InnoDB support

mysql> SHOW VARIABLES LIKE 'have_innodb';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| have_innodb   | YES   |
+---------------+-------+

Then create the database:

mysql> create database slurm_acct_db;

This will grant user 'slurm' access to do what it needs to do on the local host or the storage host system. This must be done before the SlurmDBD will work properly. After you grant permission to the user 'slurm' in mysql then you can start SlurmDBD and the other SLURM daemons. You start SlurmDBD by typing its pathname '/usr/sbin/slurmdbd' or '/etc/init.d/slurmdbd start'. You can verify that SlurmDBD is running by typing 'ps aux | grep slurmdbd'.

If the SlurmDBD is not running you can use the -v option when you start SlurmDBD to get more detailed information. Starting the SlurmDBD in daemon mode with the '-D' option can also help in debugging so you don't have to go to the log to find the problem.

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.

  • sacct is used to generate accounting report for both running and completed jobs.
  • sacctmgr is used to manage associations in the database: add or remove clusters, add or remove users, etc.
  • sreport is used to generate various reports on usage collected over a given time period.

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 2009. 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.

NOTE: 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 DefaultAccount=test

If AccountingStorageEnforce=associations 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.

Cluster Options

When either adding or modifying a cluster, these are the options available with sacctmgr:

  • Name= Cluster name

Account Options

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

  • Cluster= Only add this account to these clusters. The account is added to all defined clusters by default.
  • Description= Description of the account. (Default is account name)
  • Name= Name of account. Note the name must be unique and can not represent different bank accounts at different points in the account hierarchy
  • Organization=Organization of the account. (Default is parent account unless parent account is root then organization is set to the account name.)
  • Parent= Make this account a child of this other account (already added).

User Options

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

  • Account= Account(s) to add user to
  • AdminLevel= This field is used to allow a user to add accounting privileges to this user. Valid options are
    • None
    • Operator: can add, modify, and remove any database object (user, account, etc), and add other operators
      On a SlurmDBD served slurmctld these users can
      • View information that is blocked to regular uses by a PrivateData flag
      • Create/Alter/Delete Reservations
    • Admin: These users have the same level of privileges as an operator in the database. They can also alter anything on a served slurmctld as if they were the slurm user or root.
  • Cluster= Only add to accounts on these clusters (default is all clusters)
  • DefaultAccount= Default account for the user, used when no account is specified when a job is submitted. (Required on creation)
  • DefaultWCKey= Default wckey for the user, used when no wckey is specified when a job is submitted. (Only used when tracking wckeys.)
  • Name= User name
  • Partition= Name of SLURM partition this association applies to

Limit Enforcement

When limits are developed they will work in this order. If a user has a limit set Slurm will read in those, if not we will refer to the account associated with the job. If the account doesn't have the limit set we will refer to the cluster's limits. If the cluster doesn't have the limit set no limit will be enforced.

All of the above entities can include limits as described below and in the Resource Limits document. In enable any limit enforcement you must at least have AccountingStorageEnforce=limits in your slurm.conf, otherwise even if you have limits set they will not be enforced. Other options for AccountingStorageEnforce and the explanation for each are found on the Resource Limits document.

  • Fairshare= Integer value used for determining priority. Essentially this is the amount of claim this association and it's children have to the above system. Can also be the string "parent", this means that the parent association is used for fairshare.
  • GrpCPUMins= The total number of cpu minutes that can possibly be used by past, present and future jobs running from this association and its children. If this limit is reached all jobs running in this group will be killed, and no new jobs will be allowed to run. This usage is decayed (at a rate of PriorityDecayHalfLife). It can also be reset (according to PriorityUsageResetPeriod) in order to allow jobs to run against the association tree again.
  • GrpCPURunMins= Used to limit the combined total number of CPU minutes used by all jobs running with this association and its children. This takes into consideration time limit of running jobs and consumes it, if the limit is reached no new jobs are started until other jobs finish to allow time to free up.
  • GrpCPUs= The total count of cpus able to be used at any given time from jobs running from this association and its children. If this limit is reached new jobs will be queued but only allowed to run after resources have been relinquished from this group.
  • GrpJobs= The total number of jobs able to run at any given time from this association and its children. If this limit is reached new jobs will be queued but only allowed to run after previous jobs complete from this group.
  • GrpMemory= The total amount of memory (MB) able to be used at any given time from jobs running from this association and its children. If this limit is reached new jobs will be queued but only allowed to run after resources have been relinquished from this group.
  • GrpNodes= The total count of nodes able to be used at any given time from jobs running from this association and its children. If this limit is reached new jobs will be queued but only allowed to run after resources have been relinquished from this group. Each job's node allocation is counted separately (i.e. if a single node has resources allocated to two jobs, this is counted as two allocated nodes).
  • GrpSubmitJobs= The total number of jobs able to be submitted to the system at any given time from this association and its children. If this limit is reached new submission requests will be denied until previous jobs complete from this group.
  • GrpWall= The maximum wall clock time any job submitted to this group can run for. If this limit is reached submission requests will be denied.
  • MaxCPUMinsPerJob= A limit of cpu minutes to be used by jobs running from this association. If this limit is reached the job will be killed.
  • MaxCPUsPerJob= The maximum size in cpus any given job can have from this association. If this limit is reached the job will be denied at submission.
  • MaxJobs= The total number of jobs able to run at any given time from this association. If this limit is reached new jobs will be queued but only allowed to run after previous jobs complete from this association.
  • MaxNodesPerJob= The maximum size in nodes any given job can have from this association. If this limit is reached the job will be denied at submission.
  • MaxSubmitJobs= The maximum number of jobs able to be submitted to the system at any given time from this association. If this limit is reached new submission requests will be denied until previous jobs complete from this association.
  • MaxWallDurationPerJob= The maximum wall clock time any job submitted to this association can run for. If this limit is reached the job will be denied at submission.
  • QOS= comma separated list of QOS's this association is able to run.

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 30 April 2014