Slurm installation and upgrading

Jump to our Slurm top-level page.

To get started with Slurm see the Slurm_Quick_Start Administrator Guide. See also CECI Slurm Quick Start Tutorial.

Hardware optimization for the slurmctld master server

SchedMD recommends that the slurmctld server should have only a few, but very fast CPU cores, in order to ensure the best responsiveness.

The file system for /var/spool/slurmctld/ should be mounted on the fastest possible disks (SSD or NVMe if possible).

Create global user accounts

There must be a uniform user and group name space (including UIDs and GIDs) across the cluster. It is not necessary to permit user logins to the control hosts (ControlMachine or BackupController), but the users and groups must be configured on those hosts. To restrict user login by SSH, use the AllowUsers parameter in /etc/ssh/sshd_config.

Slurm and MUNGE require consistent UID and GID across all servers and nodes in the cluster. It is very important to avoid UID and GID below 1000, as defined in the standard configuration file /etc/login.defs by the parameters UID_MIN, UID_MAX, GID_MIN, GID_MAX, see also https://en.wikipedia.org/wiki/User_identifier.

Create the users/groups for slurm and munge, for example:

export MUNGEUSER=1001
groupadd -g $MUNGEUSER munge
useradd  -m -c "MUNGE Uid 'N' Gid Emporium" -d /var/lib/munge -u $MUNGEUSER -g munge  -s /sbin/nologin munge
export SlurmUSER=1002
groupadd -g $SlurmUSER slurm
useradd  -m -c "Slurm workload manager" -d /var/lib/slurm -u $SlurmUSER -g slurm  -s /bin/bash slurm

and make sure that these same users are created identically on all nodes. This must be done prior to installing RPMs (which would create random UID/GID pairs if these users don't exist).

Please note that UIDs and GIDs up to 1000 are currently reserved for the CentOS system users, see this article and the file /etc/login.defs.

MUNGE authentication service

The MUNGE authentication plugins identifies the user originating a message. You should read the Munge_installation guide and the Munge_wiki.

The MUNGE RPM for RHEL7 is in the EPEL repository, where you install the newest version of epel-release RPM for EL7, for example:

CentOS: yum install epel-release
RHEL7:  yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

Install the MUNGE RPM packages from the EPEL repository:

yum install munge munge-libs munge-devel

To download packages directly (using statically in compute nodes):

MUNGE configuration and testing

By default MUNGE uses an AES AES-128 cipher and SHA-256 HMAC (Hash-based Message Authentication Code). Display these encryption options by:

munge -C
munge -M

On the Head/Master node (only) create a secret key to be used globally on every node (see the Munge_installation guide):

dd if=/dev/urandom bs=1 count=1024 > /etc/munge/munge.key
chown munge: /etc/munge/munge.key
chmod 400 /etc/munge/munge.key

Alternatively use this command (slow):

/usr/sbin/create-munge-key -r

NOTE: For a discussion of using /dev/random in stead of /dev/urandom (pseudo-random) as recommended in the Munge_installation guide, see Myths about /dev/urandom.

Securely propagate /etc/munge/munge.key (e.g., via SSH) to all other hosts within the same security realm:

scp -p /etc/munge/munge.key hostXXX:/etc/munge/munge.key

Make sure to set the correct ownership and mode on all nodes:

chown -R munge: /etc/munge/ /var/log/munge/
chmod 0700 /etc/munge/ /var/log/munge/

Then enable and start the MUNGE service on all nodes:

systemctl enable munge
systemctl start  munge

Run some tests as described in the Munge_installation guide:

munge -n
munge -n | unmunge          # Displays information about the MUNGE key
munge -n | ssh somehost unmunge
remunge

Build Slurm RPMs

See the Slurm_Quick_Start Administrator Guide, especially the section below this text:

Optional Slurm plugins will be built automatically when the configure script detects that the required build requirements are present.
Build dependencies for various plugins and commands are denoted below:

You must decide which Slurm plugins to activate in the RPM packages which you build, especially items such as:

  • MySQL for accounting support
  • cgroup Task Affinity
  • MUNGE support
  • Lua Support
  • PAM support
  • NUMA Affinity

Install prerequisites

Install Slurm prerequisites as well as several optional packages that enable Slurm plugins as described in the Slurm_Quick_Start guide:

yum install rpm-build gcc openssl openssl-devel libssh2-devel pam-devel numactl numactl-devel hwloc hwloc-devel lua lua-devel readline-devel rrdtool-devel ncurses-devel gtk2-devel libssh2-devel libibmad libibumad perl-Switch perl-ExtUtils-MakeMaker

Enable the EPEL repository and install the following packages:

yum install epel-release
yum install man2html
yum install munge munge-libs munge-devel

If you want to build the Slurm REST API daemon named slurmrestd (from Slurm 20.02 and newer) you must install these prerequisites:

yum install http-parser-devel json-c-devel

Install MariaDB database

Important: If you want to enable accounting, you must install the MariaDB (a replacement for MySQL) version 5.5 from CentOS/RHEL 7 packages before you build Slurm RPMs:

yum install mariadb-server mariadb-devel

Optional: Install the latest MariaDB version. This is not required, and installation is somewhat involved.

For best results with RPM and DEB packages, use the Repository Configuration Tool. Configure the Yum repository as instructed and read the MariaDB Yum page.

For building Slurm you need to install these MariaDB 10.4 (or later) packages:

yum install MariaDB-client MariaDB-shared MariaDB-devel

The MariaDB-shared package contains the required shared libraries for Slurm. The slurmdbd server host will need to install also:

yum install MariaDB-server MariaDB-backup

Do not forget to configure the database as described in the Slurm_database page!

Build Slurm packages

Get the Slurm source code from the Slurm_download page. At this point you must decide whether to build in Slurm plugins, for example, mysql for accounting (see above).

Set the version (for example, 20.02.3-1) and build Slurm RPM packages by:

export VER=20.02.3-1
rpmbuild -ta slurm-$VER.tar.bz2 --with mysql      # Includes accounting support with the slurm-slurmdbd package
rpmbuild -ta slurm-$VER.tar.bz2 --without mysql   # No slurm-slurmdbd accounting support

The --with mysql option is not strictly necessary because the slurm-slurmdbd package will be built by default, but using this option will catch the scenario where your forgot to install the mariadb-devel packages as described above, see also bug_8882 and this mailing list posting.

If you want to build the Slurm REST API daemon named slurmrestd (from Slurm 20.02 and newer):

rpmbuild -ta slurm-$VER.tar.bz2 --with mysql --with slurmrestd

The RPM packages will typically be in $HOME/rpmbuild/RPMS/x86_64/ and should be installed on all relevant nodes.

Installing RPMs

The RPMs to be installed on the head node, compute nodes, and slurmdbd node can vary by configuration, but here is a suggested starting point:

  • Head/Master Node (where the slurmctld daemon runs), Compute, and Login nodes:

    export VER=17.02.10       # If you have Slurm version 17.02
    yum install slurm-$VER*rpm slurm-devel-$VER*rpm slurm-munge-$VER*rpm slurm-perlapi-$VER*rpm slurm-plugins-$VER*rpm slurm-torque-$VER*rpm

    From Slurm 17.11 and beyond the RPMs have been restructured, so omit the slurm-munge and slurm-plugins but add the new slurm-example-configs:

    export VER=19.05.3-2
    yum install slurm-$VER*rpm slurm-devel-$VER*rpm slurm-perlapi-$VER*rpm slurm-torque-$VER*rpm slurm-example-configs-$VER*rpm

    On the master node explicitly enable the slurmctld service:

    systemctl enable slurmctld

    The slurm-torque package could perhaps be omitted, but it does contain a useful /usr/bin/mpiexec wrapper script.

    Only if the database service will run on the Head/Master node: Install the database service RPM:

    export VER=19.05.3-2
    yum install slurm-slurmdbd-$VER*rpm

    Explicitly enable the service:

    systemctl enable slurmdbd
  • On Compute nodes you may additionally install the slurm-pam_slurm RPM package to prevent rogue users from logging in:

    yum install slurm-pam_slurm-$VER*rpm

    You may consider this RPM as well with special PMIx libraries:

    yum install slurm-libpmi-$VER*rpm

    Explicitly enable the service:

    systemctl enable slurmd
  • Database-only (slurmdbd service) node:

    export VER=19.05.3-2
    yum install slurm-$VER*rpm slurm-devel-$VER*rpm slurm-slurmdbd-$VER*rpm

    Explicitly enable the service:

    systemctl enable slurmdbd
  • Servers (from Slurm 20.02 and newer) which should offer slurmrestd (which can be used also by normal users) should install also this package:

    yum install slurm-slurmrestd-$VER*rpm

    The slurmctld server and the login nodes would typically include slurmrestd.

Study the configuration information in the Quick Start Administrator_Guide.

Configure Slurm logging

The Slurm logfile directory is undefined in the RPMs since you have to define it in slurm.conf. See SlurmdLogFile and SlurmctldLogFile in the slurm.conf page, and LogFile in the slurmdbd.conf page.

Check your logging configuration with:

# grep -i logfile /etc/slurm/slurm.conf
SlurmctldLogFile=/var/log/slurm/slurmctld.log
SlurmdLogFile=/var/log/slurm/slurmd.log
# scontrol show config | grep -i logfile
SlurmctldLogFile        = /var/log/slurm/slurmctld.log
SlurmdLogFile           = /var/log/slurm/slurmd.log
SlurmSchedLogFile       = /var/log/slurm/slurmsched.log

If log files are configured, you have to create the log file directory manually:

mkdir /var/log/slurm
chown slurm.slurm /var/log/slurm

See the more general description in Bug_8272.

Upgrading Slurm

New Slurm updates are released rather often. Follow the Upgrades instructions in the Slurm_Quick_Start page, see also presentations by Tim Wickberg in the Slurm_publications page. Pay attention to these statements:

  • You may upgrade at most by 2 major versions, see the Upgrades page:

    • Slurm daemons will support RPCs and state files from the two previous major releases (e.g. a version 16.05.x SlurmDBD will support slurmctld daemons and commands with a version of 16.05.x, 15.08.x or 14.11.x).
  • In other words, when changing the version to a higher release number (e.g from 14.11.x to 15.08.x) always upgrade the slurmdbd daemon first.

  • Be mindful of your configured SlurmdTimeout and SlurmctldTimeout values.

  • The recommended upgrade order is that versions may be mixed as follows:

    slurmdbd >= slurmctld >= slurmd >= commands

If you use a database, also make sure to:

  • Make a database dump (see Slurm_database) prior to the slurmdbd upgrade.

  • Start the slurmdbd service manually after the upgrade in order to avoid timeouts (see bug_4450). In stead of starting the slurmdbd service, it may be necessary to start the daemon manually. If you use the systemctl command, it is very likely to exceed a system time limit and kill slurmdbd before the database conversion has been completed.

    The recommended way to perform the slurmdbd database upgrade is therefore:

    time slurmdbd -D -vvv

    See further info below.

This command can report current jobs that have been orphaned on the local cluster and are now runaway:

sacctmgr show runawayjobs

Database upgrade from Slurm 17.02 and older

If you are upgrading from Slurm 17.02 and older to Slurm 17.11 and newer, you must be extremely cautious about long database update times, since in Slurm 17.11 (and newer) some database structures were changed. Read the mailing list thread Extreme long db upgrade 16.05.6 -> 17.11.3, where Lech Nieroda states:

  • To sum it up, the issue affects those users who still have 17.02 or prior versions, use their distribution defaults for mysql/mariadb from RHEL6/CentOS6 and RHEL7/CentOS7, have millions of jobs in their database and would like to upgrade slurm without upgrading mysql.

The patch is also available from and is discussed in bug_6796.

Furthermore, the 17.11 Release Notes states:

NOTE FOR THOSE UPGRADING SLURMDBD: The database conversion process from SlurmDBD 16.05 or 17.02 may not work properly with MySQL 5.1 (as was the default version for RHEL 6).
Upgrading to a newer version of MariaDB or MySQL is strongly encouraged to prevent this problem.

and the 18.08 Release Notes added:

NOTE FOR THOSE UPGRADING SLURMDBD:
The database conversion process from SlurmDBD 16.05 or 17.02 may not work properly with MySQL 5.1 or 5.5 (as was the default version for RHEL 6).
Upgrading to a newer version of MariaDB or MySQL is strongly encouraged to prevent this problem.

NOTE: MariaDB version 5.5 is the default database version delivered with RHEL7/CentOS 7!

More recent MariaDB versions 10.x can be downloaded from the MariaDB_repository. Some further information:

The patch in the above thread should be applied manually to Slurm 17.11 before upgrading the database from 17.02 or 16.05 to 17.11 (do not upgrade by more than 2 Slurm releases!).

Upgrade of MySQL/MariaDB

If you restore a database dump (see Slurm_database) onto a different server running a newer MySQL/MariaDB version, for example upgrading MySQL 5.1 on CentOS 6 to MariaDB 5.5 on CentOS 7, there are some extra steps.

See Upgrading from MySQL to MariaDB about running the mysql_upgrade command:

mysql_upgrade

whenever major (or even minor) version upgrades are made, or when migrating from MySQL to MariaDB.

It may be necessary to restart the mysqld service or reboot the server after this upgrade (??).

Make a dry run database upgrade

Optional: You can test the database upgrade procedure before doing the real upgrade.

In order to verify and time the slurmdbd database upgrade you may make a dry_run upgrade for testing before actual deployment.

Here is a suggested procedure:

  1. Drain a compute node running the current Slurm version and use it for testing the database.

    The following actions must be performed on the drained compute node.

    First stop the regular slurmd daemons on the compute node:

    systemctl stop slurmd
  2. Install the OLD (the cluster's current version, say, NN.NN) additional slurmdbd database RPMs as described above:

    VER=NN.NN
    yum install slurm-slurmdbd-$VER*rpm

    Information about building RPMs is in the Slurm_installation page. Note: From Slurm 17.11 the slurm-sql RPM no longer exists.

  3. Install the database RPM packages and configure the database EXACTLY as described in the Slurm_database page.
  4. Configure the MySQL/MariaDB database as described in the Slurm_database page.

    Copy the configuration files from the main server to the compute node:

    /etc/slurm/slurm.conf
    /etc/slurm/slurmdbd.conf

    Important: Edit these files to replace the database server name by localhost so that all further actions take place on the compute node, not the real database server.

    Configure this in slurmdbd.conf:

    DbdHost=localhost
    StorageHost=localhost

    Configure this in slurm.conf:

    AccountingStorageHost=localhost

    Set up files and permissions:

    chown slurm: /etc/slurm/slurmdbd.conf
    chmod 600 /etc/slurm/slurmdbd.conf
    touch /var/log/slurm/slurmdbd.log
    chown slurm: /var/log/slurm/slurmdbd.log
  5. Copy the latest database dump file (/root/mysql_dump, see Slurm_database) from the main server to the compute node. Load the dump file into the testing database:

    mysql -u root -p < /root/mysql_dump
    If the dump file is compressed: zcat mysql_dump.gz | mysql -u root -p

    Verify the database contents on the compute node by making a new database dump and compare it to the original dump.

  6. Make sure that slurmdbd is running, and start it if necessary:

    systemctl status slurmdbd
    systemctl start slurmdbd

    Make some query to test slurmdbd:

    sacctmgr show user -s

    If all is well, stop the slurmdbd before the upgrade below:

    systemctl stop slurmdbd
  7. At this point you have a Slurm database server running an exact copy of your main Slurm database!

    Now it is time to do some testing. Update all Slurm RPMs to the new version (say, 20.02.2-1) built as shown above:

    export VER=20.02.2-1
    yum update slurm*$VER*.rpm
  8. Perform and time the actual database upgrade:

    time slurmdbd -D -vvv

    and wait for the output:

    slurmdbd: debug2: Everything rolled up

    and do a Control-C.

    Write down the timing information from the time command, since this will be the expected approximate time when you later perform the real upgrade.

    Now start the service as usual:

    systemctl start slurmdbd
  9. Make some query to test slurmdbd:

    sacctmgr show user -s

    and make some other tests to verify that slurmdbd is responding correctly.

  10. When all tests have been completed successfully, reinstall the compute node to its default installation.

Upgrading on CentOS 7

Let's assume that you have built the updated RPM packages for CentOS 7 and copied them to the current directory so you can use yum on the files directly.

Prerequisites before upgrading

If you have installed the pdsh tool, there may be a module that has been linked against a specific library version libslurm.so.30, and yum will then refuse to update the slurm* RPMs. You must first do:

yum remove pdsh-mod-slurm

and then later rebuild and install pdsh-mod-slurm, see the SLURM page.

Upgrade slurmdbd

The upgrading steps for the slurmdbd host are:

  1. Stop the slurmdbd service:

    systemctl stop slurmdbd
  2. Make a mysqldump of the MySQL/Mariadb database (see above).
  3. From Slurm 17.11 the RPM packages have been restructured and you need to update all RPMs:

    export VER=19.05.3-2
    yum update slurm*$VER*.rpm
  4. Start the slurmdbd daemon manually:

    time slurmdbd -D -vvv

    The completion of the database conversion may be printed as:

    slurmdbd: debug2: Everything rolled up

    Then do a Control-C.

  5. Restart the slurmdbd service normally:

    systemctl start slurmdbd
  6. Make some query to test slurmdbd:

    sacctmgr show user -s
Upgrade slurmctld

The upgrading steps for the slurmctld host are:

  1. Change the timeout values in slurm.conf to:

    SlurmctldTimeout=3600
    SlurmdTimeout=3600

    and copy /etc/slurm/slurm.conf to all nodes. Then reconfigure the running daemons and test the timeout values:

    scontrol reconfigure
    scontrol show config | grep Timeout
  2. Stop the slurmctld service:

    systemctl stop slurmctld
  3. Make a backup copy of the StateSaveLocation (check your configuration first) /var/spool/slurmctld directory:

    scontrol show config | grep StateSaveLocation
    tar czf $HOME/var.spool.slurmctld.tar.gz /var/spool/slurmctld
  4. Upgrade the RPMs:

    export VER=19.05.3-2
    yum update slurm*$VER-*.rpm

From Slurm 17.11 there is a new RPM for slurmctld:

yum install slurm-slurmctld-$VER-*.rpm
  1. Enable and restart the slurmctld service:

    systemctl enable slurmctld
    systemctl restart slurmctld
  2. Restore the previous timeout values in slurm.conf (item 1.).
Install slurm-libpmi

From Slurm 17.11 the libpmi.so libraries have been moved to a new RPM. If you need it, install this one:

yum install slurm-libpmi-*.rpm
Upgrade MPI applications

MPI applications such as OpenMPI may be linked against the /usr/lib64/libslurm.so library. In this context you must understand the remark in the Upgrades page:

The libslurm.so version is increased every major release.
So things like MPI libraries with Slurm integration should be recompiled.
Sometimes it works to just symlink the old .so name(s) to the new one, but this has no guarantee of working.

In the thread Need for recompiling openmpi built with --with-pmi? it has been found that:

It looks like it is the presence of lib64/libpmi2.la and lib64/libpmi.la that is the "culprit". They are installed by the slurm-devel RPM.
Openmpi uses GNU libtool for linking, which finds these files, and follow their "dependency_libs" specification, thus linking directly to libslurm.so.

Slurm version 16.05 and later no longer installs the libpmi*.la files. This should mean that if your OpenMPI was built against Slurm 16.05 or later, there should be no problem (we think), but otherwise you probably must rebuild your MPI applications and install them again at the same time that you upgrade the slurmd on the compute nodes.

To check for the presence of the "bad" files, go to your software build host and search:

locate libpmi2.la
locate libpmi.la

TODO: Find a way to read relevant MPI libraries like this example:

readelf -d libmca_common_pmi.so
Upgrade slurmd on nodes

First determine which Slurm version the nodes are running:

clush -bg <partition> slurmd -V         # Using ClusterShell
pdsh -g <partition> slurmd -V | dshbak  # Using PDSH

See the SLURM page about ClusterShell or PDSH.

For the compute nodes running slurmd the procedure could be:

  1. Drain all desired compute nodes in a <nodelist>:

    scontrol update NodeName=<nodelist> State=draining Reason="Upgrading slurmd"

    Nodes will change from the DRAINING to the DRAINED state as the jobs are completed. Check which nodes have become DRAINED:

    sinfo -t drained
  2. Stop the slurmd daemons on compute nodes:

    clush -bw <nodelist> systemctl stop slurmd
  3. Update the RPMs (here: version 19.05.3-2) on nodes:

    clush -bw <nodelist> 'yum -y update /some/path/slurm*19.05.3-2-*.rpm'

    and make sure to install also the new slurmd and contribs packages:

    clush -bw <nodelist> 'yum -y install /some/path/slurm-slurmd*19.05.3-2-*.rpm /some/path/slurm-contribs*19.05.3-2-*.rpm'

    From 17.02 and later slurm-contribs replaces the obsolete packages slurm-seff, slurm-sjobexit, slurm-sjstat.

    Important: From Slurm 17.11 you must explicitly enable the service:

    clush -bw <nodelist> systemctl enable slurmd
  4. For restarting slurmd there are two alternatives:

    1. Restart slurmd or simply reboot the nodes in the DRAINED state:

      clush -bw <nodelist> systemctl daemon-reload
      clush -bw <nodelist> systemctl restart slurmd
        or simply reboot:
      clush -bw <nodelist> shutdown -r now
    2. Reboot the nodes automatically as they become idle using the RebootProgram as configured in slurm.conf, see the scontrol reboot option and explanation in the man-page:

      scontrol reboot [ASAP] [NodeList]

      The ASAP flag is available from Slurm 17.02 (see man scontrol for older versions).

  5. Return upgraded nodes to the IDLE state:

    scontrol update NodeName=<nodelist> State=resume

Finally, restore the timeout values in slurm.conf to their defaults:

SlurmctldTimeout=300
SlurmdTimeout=300

and copy /etc/slurm/slurm.conf to all nodes. Then reconfigure the running daemons:

scontrol reconfigure

Again, consult the Upgrades page before you start!

Removing /etc/init.d/slurm

Obsolete: This section only applies to Slurm 16.05 and older.

On Systemd systems such as RHEL7/CentOS7 the old-style init-script /etc/init.d/slurm should be disabled, see the Slurm_configuration page. This should be done at the initial installation as well as after upgrading. With Slurm 17.02 and newer this bug_3371 has been resolved.

The relevant commands are summarized as:

chkconfig --del slurm
rm -f /etc/init.d/slurm

Then enable and start services using systemctl.

Log file rotation

The Slurm log files may be stored in /var/log/slurm, and they may grow rapidly on a busy system. Especially the slurmctld.log file on the controller machine may grow very big.

Therefore you probably want to configure logrotate to administer your log files. On RHEL and CentOS the logrotate configuration files are in the /etc/logrotate.d/ directory.

Manual configuration is required because the SchedMD RPM files do not contain the logrotate setup, see bug_3904 and bug_2215 and bug_4393. See also the section LOGGING at the end of the slurm.conf page with an example logrotate script (please note that the SIGUSR2 signal applies to 17.11 and newer).

First install the relevant RPM:

yum install logrotate

Create the following script /etc/logrotate.d/slurm which will rotate and compress the slurmctld log file on a weekly basis:

/var/log/slurm/*.log {
      compress
      missingok
      nocopytruncate
      nodelaycompress
      nomail
      notifempty
      noolddir
      rotate 5
      sharedscripts
      size=5M
      create 640 slurm root
      postrotate
              pkill -x --signal SIGUSR2 slurmctld
              pkill -x --signal SIGUSR2 slurmd
              pkill -x --signal SIGUSR2 slurmdbd
              exit 0
      endscript
}

Warning: Do not run scontrol reconfig or restart slurmctld to rotate the log files, since this will incur a huge overhead.

See the NEWS file for changes related to SIGUSR2:

Modify all daemons to re-open log files on receipt of SIGUSR2 signal. This is much than using SIGHUP to re-read the configuration file and rebuild various tables.

Niflheim: Slurm_installation (last edited 2020-09-11 09:16:50 by OleHolmNielsen)