Slurm installieren und betreiben: Ressourcenverwaltung und Job-Scheduling für Linux-HPC-Cluster

EdwardMoon

Eine Slurm-Installation ist mit der Paketinstallation noch nicht einsatzbereit. Zuerst müssen Uhrzeit und numerische Benutzer- und Gruppenkennungen auf allen Knoten übereinstimmen. Anschließend wird der MUNGE-Vertrauensbereich eingerichtet. Danach folgen der Controller-Dienst slurmctld, der Dienst slurmd auf den Rechenknoten und bei Bedarf slurmdbd zur Speicherung von Jobverlauf und Ressourcennutzung.

Dieser Leitfaden verbindet die einzelnen Betriebsschritte: Rollenverteilung, Paketierung, slurm.conf, Ressourcenisolation mit cgroups, Aufzeichnung von Jobverlauf und Ressourcennutzung, Job-Einreichung und -Prüfung sowie Wartung und Sicherung. Ersetzen Sie die Beispielnamen und Ressourcenangaben durch die tatsächlichen Werte aus slurmd -C.

Begriffsklärung: Mit Accounting bezeichnet Slurm das Erfassen, Speichern und Abfragen der Ausführungshistorie sowie der zugewiesenen und tatsächlich genutzten Ressourcen einzelner Jobs. Dieser Artikel verwendet dafür den Ausdruck Aufzeichnung von Jobverlauf und Ressourcennutzung.

Rollenverteilung und Ausfallbereiche

Voraussetzungen: Knoten, Uhrzeit und UID/GID

Vorwärts- und Rückwärtsauflösung von Hostnamen, identische numerische Benutzerkennungen und NTP-Synchronisierung müssen funktionieren. Nur dann sind MUNGE-Authentifizierung und Job-Eigentümerschaft konsistent. Ohne einen zentralen Verzeichnisdienst wie LDAP müssen feste numerische Kennungen durch die Kontobereitstellung sichergestellt werden.

hostnamectl --static
getent hosts ctrl01
getent hosts node01
id slurm
id hpcuser
timedatectl status
chronyc tracking
chronyc sources -v

Dienstkonten und Verzeichnisse

sudo groupadd --system slurm
sudo useradd --system --gid slurm   --home-dir /var/lib/slurm --shell /sbin/nologin slurm
sudo install -d -o slurm -g slurm -m 0750 /var/lib/slurm/controller
sudo install -d -o root -g root -m 0755 /var/lib/slurm
sudo install -d -o root -g root -m 0755 /var/lib/slurm/slurmd
sudo install -d -o slurm -g slurm -m 0750 /var/log/slurm

SlurmdSpoolDir wird auf Rechenknoten von root verwaltet. Job-Benutzer müssen den Verzeichnispfad jedoch durchlaufen können, um ihre Skripte auszuführen. Legen Sie es deshalb mit root:root und 0755 an. Verwechseln Sie dies nicht mit dem Controller-Zustandsverzeichnis, das slurm:slurm und 0750 verwendet. Prüfen Sie auch für das übergeordnete Verzeichnis /var/lib/slurm den Modus 0755.

Reproduzierbare Slurm-Pakete bereitstellen

Für den Produktionsbetrieb sollten RPM- oder DEB-Pakete aus dem offiziellen Release-Tarball gebaut und in einem internen, signierten Repository festgelegt werden. Wiederholtes make install aus einem Quellverzeichnis erschwert einen reproduzierbaren Betrieb. Halten Sie Haupt- und Nebenversion von Slurm sowie die Build-Optionen der Plugins auf Controllern, Login- und Rechenknoten einheitlich.

sha256sum "${SLURM_TARBALL}"
rpmbuild -ta "${SLURM_TARBALL}"
rpm -qp --queryformat '%{NAME} %{VERSION}-%{RELEASE}
'   ~/rpmbuild/RPMS/*/slurm-*.rpm

Bestimmen Sie die Build-Abhängigkeiten für Distribution, Datenbank, PMIx, hwloc und cgroups anhand der offiziellen Dokumentation und Ihrer internen Unterstützungsmatrix. Installieren Sie nicht nur auf einem einzelnen Controller Pakete aus einem beliebigen Internet-Repository.

Die gebauten Pakete passend zur Knotenrolle installieren

rpmbuild installiert keine Pakete. Bereiten Sie vor dem Build alle benötigten Plugin-Abhängigkeiten vor: beispielsweise MUNGE-Entwicklungsbibliotheken, hwloc, libbpf und D-Bus für cgroup v2 sowie MySQL-/MariaDB-Entwicklungsbibliotheken für die Speicherung von Job- und Nutzungsdaten. Stellen Sie die gebauten RPMs derselben Version im internen Repository bereit und installieren Sie je nach Knotenrolle die folgenden Pakete. Prüfen Sie zuerst, ob das Repository tatsächlich Ihren verifizierten Build und die gewünschte Version enthält.

# Verfügbare Versionen und Herkunft im internen Repository prüfen
dnf info slurm slurm-perlapi slurm-slurmctld slurm-slurmd slurm-slurmdbd
# ctrl01
sudo dnf install slurm slurm-perlapi slurm-slurmctld
# Auf jedem Rechenknoten von node01 bis node04
sudo dnf install slurm slurm-perlapi slurm-slurmd
# Auf dem Login-Knoten
sudo dnf install slurm slurm-perlapi
# Auf acct01, wenn Jobverlauf und Ressourcennutzung gespeichert werden sollen
sudo dnf install slurm slurm-slurmdbd

Den MUNGE-Vertrauensbereich einrichten

Alle Teilnehmer eines Clusters benötigen denselben MUNGE-Schlüssel. Verteilen Sie ihn über einen geschützten Konfigurationsverwaltungskanal und beschränken Sie den Lesezugriff auf den Benutzer munge. MUNGE muss vor Slurm gestartet werden.

sudo /usr/sbin/mungekey --create
sudo chown munge:munge /etc/munge/munge.key
sudo chmod 0400 /etc/munge/munge.key
sudo systemctl enable --now munge
munge -n | unmunge

Übertragen Sie den auf dem Controller erzeugten Schlüssel sicher auf alle Knoten und vergleichen Sie Eigentümer und Prüfsummen. Geben Sie den Schlüsselinhalt weder auf der Kommandozeile noch in gewöhnlichen Protokollen aus.

sudo stat -c '%U:%G %a %n' /etc/munge/munge.key
sudo sha256sum /etc/munge/munge.key
remunge

slurm.conf aus der tatsächlichen Hardwarekonfiguration ableiten

Schätzen Sie CPU-, Sockel-, Kern- und Speicherwerte nicht. Führen Sie slurmd -C auf jedem Rechenknoten aus und erstellen Sie NodeName-Definitionen für Gruppen identischer Hardware.

slurmd -C
lscpu
free -m
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS

ClusterName=hpc-prod
SlurmctldHost=ctrl01
SlurmUser=slurm
StateSaveLocation=/var/lib/slurm/controller
SlurmdSpoolDir=/var/lib/slurm/slurmd
SlurmctldLogFile=/var/log/slurm/slurmctld.log
SlurmdLogFile=/var/log/slurm/slurmd.log

AuthType=auth/munge
SelectType=select/cons_tres
SelectTypeParameters=CR_Core_Memory
SchedulerType=sched/backfill
ProctrackType=proctrack/cgroup
TaskPlugin=task/cgroup

AccountingStorageType=accounting_storage/slurmdbd
AccountingStorageHost=acct01
JobAcctGatherType=jobacct_gather/cgroup

NodeName=node[01-04] CPUs=32 RealMemory=125000 State=UNKNOWN
PartitionName=compute Nodes=node[01-04] Default=YES MaxTime=2-00:00:00 State=UP

Ressourcenisolation mit cgroup v2

Speichern Sie die folgende Konfiguration in cgroup.conf im selben Konfigurationsverzeichnis wie slurm.conf. Verteilen Sie die zuvor erstellte slurm.conf konsistent auf alle beteiligten Knoten. Ist die dauerhafte Speicherung von Jobverlauf und Ressourcennutzung noch nicht eingerichtet, lassen Sie AccountingStorageType und AccountingStorageHost weg oder kommentieren Sie beide Zeilen aus. Aktuelle Slurm-Versionen deaktivieren diese Speicherung durch ein nicht gesetztes AccountingStorageType; der entfernte Plugin-Name accounting_storage/none darf dafür nicht angegeben werden. Führen Sie die Schritte mit sacct und sacctmgr in diesem Fall erst nach der Einrichtung von slurmdbd und Datenbank aus.

CgroupPlugin=autodetect
ConstrainCores=yes
ConstrainRAMSpace=yes
ConstrainDevices=yes

stat -fc %T /sys/fs/cgroup
scontrol show config | grep -E 'ProctrackType|TaskPlugin|SelectType'
systemd-cgls --no-pager

Jobverlauf und Ressourcennutzung mit slurmdbd speichern

Für eine langfristige Verwaltung von Jobverlauf, Nutzung nach Slurm-Konten und QoS werden slurmdbd und eine unterstützte SQL-Datenbank benötigt. Je nach Betriebsgröße kann der SQL-Server auf einem separaten Host laufen.

Im folgenden Beispiel laufen slurmdbd und ein unterstützter MariaDB-/MySQL-Server gemeinsam auf acct01. Bereiten Sie zunächst die Datenbankinstallation, InnoDB-Unterstützung und Sicherungsrichtlinie vor. Legen Sie in einer Datenbankadministratorsitzung die Datenbank slurm_acct_db und den Datenbankbenutzer slurm an. Gewähren Sie diesem Benutzer ausschließlich Rechte auf diese Datenbank. Tragen Sie das echte Passwort gemäß Ihrem Verfahren zur Geheimnisverwaltung ein; übergeben Sie es nicht als Shell-Befehlsargument und speichern Sie es nicht in Verlaufsdateien. Wird SQL in größeren Umgebungen ausgelagert, müssen sowohl StorageHost als auch der zugelassene Verbindungshost des Datenbankkontos angepasst werden.

-- SQL-Beispiel für eine Sitzung mit Datenbankadministratorrechten
CREATE DATABASE slurm_acct_db;
CREATE USER 'slurm'@'localhost' IDENTIFIED BY 'REPLACE_WITH_UNIQUE_SECRET';
GRANT ALL ON slurm_acct_db.* TO 'slurm'@'localhost';
SHOW ENGINES;

Speichern Sie die folgenden Angaben in /etc/slurm/slurmdbd.conf und ersetzen Sie StoragePass durch das tatsächliche Passwort des zuvor angelegten Datenbankkontos. Der SQL-Benutzer slurm und der Betriebssystembenutzer slurm sind verschiedene Konten. Starten Sie den Dienst nicht mit einer leeren Konfiguration oder dem unveränderten Beispielpasswort.

AuthType=auth/munge
DbdHost=acct01
DbdPort=6819
SlurmUser=slurm
StorageType=accounting_storage/mysql
StorageHost=localhost
StorageUser=slurm
StoragePass=REPLACE_WITH_UNIQUE_SECRET
StorageLoc=slurm_acct_db
LogFile=/var/log/slurm/slurmdbd.log
PidFile=/var/run/slurmdbd.pid

Bewahren Sie Datenbankzugangsdaten in slurmdbd.conf mit dem Modus 0600 oder in einem System zur Geheimnisverwaltung auf. Sie gehören weder in Artikeltexte noch in Git.

# Eine vorhandene Datei zuerst sichern; nicht durch eine leere Datei ersetzen.
sudo install -d -m 0755 /etc/slurm
sudo touch /etc/slurm/slurmdbd.conf
sudo chown slurm:slurm /etc/slurm/slurmdbd.conf
sudo chmod 0600 /etc/slurm/slurmdbd.conf
sudoedit /etc/slurm/slurmdbd.conf
sudo systemctl enable --now slurmdbd
sudo journalctl -u slurmdbd -b --no-pager

Registrieren Sie Cluster und legen Sie Slurm-Konten sowie Benutzerzuordnungen (Associations) gemäß Ihrem Änderungsverfahren an. Ein Slurm-Konto (Account) fasst die Ressourcennutzung eines Projekts oder einer Organisationseinheit zusammen; es ist kein Betriebssystem-Anmeldekonto. Eine Association ist die Zuordnung von Cluster, Slurm-Konto, Benutzer und gegebenenfalls Partition. Bewahren Sie sacctmgr-Ausgaben und Datenbanksicherungen auf. Bestimmen Sie vor Löschbefehlen das Ziel eindeutig durch reine Abfragen.

sudo sacctmgr add cluster hpc-prod
sudo sacctmgr add account research Description='Research'
sudo sacctmgr add user hpcuser Account=research
sacctmgr show cluster
sacctmgr show association tree

Dienste in der richtigen Reihenfolge starten und prüfen

1. Uhrzeit, Namensauflösung und UID/GID auf allen Knoten prüfen.
2. MUNGE starten und lokale sowie knotenübergreifende Authentifizierungsnachweise testen.
3. Bei Speicherung von Job- und Nutzungsdaten zunächst slurmdbd und die Datenbankverbindung prüfen.
4. slurmctld auf dem Controller starten.
5. slurmd auf den Rechenknoten starten.
6. Konfiguration und Knotenzustand mit scontrol und sinfo prüfen.

# Nur auf dem Controller ctrl01 ausführen
sudo systemctl enable --now slurmctld
# Den folgenden Befehl auf jedem Rechenknoten ausführen
sudo systemctl enable --now slurmd
systemctl --no-pager --full status slurmctld
systemctl --no-pager --full status slurmd
scontrol ping
sinfo --long
scontrol show nodes

Den Cluster mit interaktiven und Batch-Jobs testen

srun --partition=compute --nodes=1 --ntasks=1   hostname
srun --partition=compute --nodes=2 --ntasks-per-node=2   /bin/hostname

#!/usr/bin/env bash
#SBATCH --job-name=smoke-test
#SBATCH --partition=compute
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=2
#SBATCH --time=00:05:00
#SBATCH --output=slurm-%j.out

set -euo pipefail
hostname
srun --label /bin/hostname

JOB_ID=$(sbatch --parsable smoke-test.sbatch)
squeue --job "$JOB_ID"
sacct --jobs "$JOB_ID"   --format=JobID,State,Elapsed,AllocCPUS,MaxRSS,ExitCode
scontrol show job "$JOB_ID"

Knoten für Wartung sperren, wieder freigeben und sicher betreiben

sudo scontrol update NodeName=node03   State=DRAIN Reason='planned maintenance'
scontrol show node node03
squeue --nodelist=node03

sudo scontrol update NodeName=node03 State=RESUME
sinfo --nodes=node03 --long

Setzen Sie Knoten im Zustand DOWN oder DRAIN nicht ungeprüft auf RESUME. Untersuchen Sie zuerst Reason, slurmd-Protokolle, Hardwareereignisse und den Dateisystemzustand. Entscheiden Sie bei laufenden Jobs entsprechend Ihrer Betriebsrichtlinie, ob diese beendet, erneut eingereiht oder abgebrochen werden sollen.

sudo journalctl -u slurmd --since '-30 minutes' --no-pager
sudo journalctl -u slurmctld --since '-30 minutes' --no-pager
scontrol show node node03
sdiag

Sicherung und Wiederherstellung

• slurm.conf, cgroup.conf, gres.conf und die Quellen Ihrer Verteilungsautomatisierung unter Versionskontrolle halten.
• StateSaveLocation unter Berücksichtigung der Dienstkonsistenz sichern und die Zugriffsrechte erhalten.
• Die slurmdbd-Datenbank transaktionskonsistent sichern und die Wiederherstellung testen.
• Den MUNGE-Schlüssel gesondert in einem verschlüsselten Geheimnisspeicher aufbewahren und Zugriffe nachvollziehen.
• Einen Standby-Controller nach dem offiziellen Hochverfügbarkeitsverfahren einrichten und seinen slurmctld-Daemon laufen lassen. Es darf nur einen aktiven Scheduler geben; Slurm soll die Übernahme und Rückkehr des Standby-Daemons koordinieren. Lassen Sie niemals zwei unabhängige primäre Controller denselben Zustand schreiben.

Offizielle Dokumentation und weiterführende Anleitungen

• SchedMD: SlurmdSpoolDir-Berechtigungen und slurm.conf
• SchedMD: Datenbank für Jobverlauf und Ressourcennutzung
• SchedMD: erforderliche Einstellungen in slurmdbd.conf

• SchedMD: Schnelleinstieg für Slurm-Administratoren
• SchedMD: Konfigurationswerkzeug für slurm.conf
• SchedMD: Leitfaden zu cgroup v2
• Rocky Linux installieren und die grundlegende Absicherung einrichten
• SSH-Schlüsselauthentifizierung und sichere Administrationskonten

Die Slurm-Einrichtung ist nicht schon abgeschlossen, wenn die Daemons als active gemeldet werden. Erst wenn MUNGE-Authentifizierung, Ressourcenisolation, Jobs über mehrere Knoten, Aufzeichnung von Jobverlauf und Ressourcennutzung, Drain/Resume sowie Sicherung und Wiederherstellung erfolgreich getestet sind, ist der Cluster betriebsbereit. Automatisieren Sie diese Prüfungen, damit sie nach Knotenerweiterungen und Versionsupdates wiederholt werden können.