CIP Cluster

Das CIP Cluster besteht aus 2 Knoten mit je 8 GPUs. Es ist möglich, eine variable Menge (1-8) GPUs zum Ausführen von compute Jobs zu bekommen. (Siehe unten) Für CPU compute sind die regulären CIP Clients zu verwenden. Siehe auch Raumverzeichnis.

Diese Seite besteht aus mehreren Sektionen:

Einführung (Begriffe, Befehle, Optionen, Beschränkungen)
Beispiele (salloc, srun, sbatch, Debug Shell)

Tipps und Tricks (Bilder, IO Performance, SSH)
Weitere Dokumentation (Links)

Einführung

Auf der cipslurmlogin und auf allen GPU-Knoten ist das Home-Verzeichnis (~) das GPU Home, daher sollte die Arbeit von dort aus durchgeführt werden. Auf den regulären CIP Clients ist ~ das reguläre Home; das GPU Home ist dort zusätzlich unter /proj/gpuhome verfügbar, daher sollten Daten und Code dorthin kopiert werden, bevor Jobs eingereicht werden. Das reguläre Home ist auf dem Cluster nicht verfügbar. Bevor mit dem Cluster gearbeitet werden kann, ist es zudem notwendig, sich über einen CIP Rechner auf der cipslurmlogin anzumelden. Von dort aus kann Software für das Cluster kompiliert werden. Ebenfalls können über den Slurm Workload Manager Jobs gestartet werden.

Begriffe

Shell: (In den Beispielen bash) Führt Befehle des Benutzers aus und interpretiert Skripte.
Job: Ein Auftrag, ein Programm auszuführen, welches dann die gewünschte Arbeit tätigt.
Knoten: Ein Knoten, der Ressourcen (vor allem GPUs) bereitstellen kann.
Allokation: Die Menge der einem Job zugewiesenen Ressourcen (GPU/CPU/Arbeitsspeicher).
Schritt: Eine Arbeitseinheit innerhalb eines Jobs, ausgeführt über srun; kann parallel zu anderen Schritten laufen.

Befehle

Für alle Befehle sind auch entsprechende Manpages vorhanden, in denen man Details nachlesen kann.

Art	Befehl	Beschreibung
Start	`salloc [options]`	Startet einen Shell Job.
Start	`sbatch [options] <job_script>`	Startet einen Batch Job.
Start	`srun [options] <job_script>`	Startet einen interaktiven Job.
Info	`squeue`	Zeigt die Liste aller Jobs an. (Egal ob in der Warteschlange oder bereits laufend.) Mit `-o` lässt sich die Ausgabe anpassen, z.B. um den Knoten eines laufenden Jobs zu finden.
Info	`scontrol show job [jobID]`	Zeigt detaillierte Informationen über einen Job an. (Alle eigenen, wenn nicht angegeben.)
Info	`sinfo`	Gibt Informationen über das gesamte Cluster und den Knotenzustand aus.
Debug	`srun --jobid=<jobID> --overlap --pty /bin/bash -l`	Startet `bash` in einem bereits eingelasteten Job. (Nützlich, wenn man einen bereits laufenden Job untersuchen will.)
Stop	`scancel <jobID>`	Bricht einen Job ab. (Egal ob in der Warteschlange oder laufend.)
Stop	`scancel -u $USER`	Bricht alle eigenen Jobs ab.

Jobs können auch aus anderen Jobs gestartet werden. ACHTUNG: Endlosschleifen oder Rekursion sind zu vermeiden.

Optionen für `salloc`, `sbatch`, `srun`

Option	Beschreibung
`-t, --time=HH:MM:SS`	Setzt die maximale Ausführungszeit.
`--job-name=<name>`	Setzt einen Namen, relevant für Befehle wie `squeue`
`--export=NONE`	Umgebungsvariablen der Shell NICHT weitergeben
`--gres=gpu:<count>`	Anzahl an GPUs für den Job setzen, es gehen bis zu 8
`--ntasks=<N>`	Setzt die Anzahl paralleler Aufgaben innerhalb eines Jobs
`--nice=<level>`	Kann verwendet werden, um Jobs mit niedriger Priorität in der Warteschlange zu legen (höhere Werte -> niedrigere Priorität).
`--parsable` (Nur sbatch)	Sorgt für parsebaren Output der Slurm Befehle
`--immediate=<seconds>` (Nur srun)	Maximale Zeit in der Warteschlange beschränken, der Job bricht ab, wenn nicht in dieser Zeit eingelastet.
`--overlap` (Nur srun)	Erlaubt das Teilen von Ressourcen mit bereits laufenden Jobs. (Nützlich zum Verwalten.)

Beschränkungen

Damit jeder Zugriff bekommen kann, gibt es zentrale Zeitlimits, sowie Scheduling. Ressourcen werden fair verteilt, je größer der Job (zum Beispiel mehr Grafikkarten), desto länger dauert das Einlasten. Sollte einem das maximale Zeitlimit nicht reichen, kann man zusätzliche Jobs in die Warteschlange stellen, um die Arbeit fortzusetzen. (Durch zum Beispiel wiederholtes Ausführen von sbatch)

Die cipslurmlogin ist zum Kompilieren und zum Bearbeiten der Warteschlange gedacht. Schweres Compute sollte auf ihr nicht ausgeführt werden, kleine Aufgaben wie das Kompilieren sind aber in Ordnung.

Die Homes sind über NFS eingebunden, so wie auf den anderen CIP Clients. Befehle wie tail -f funktionieren wie gewohnt, aber NFS bietet weniger Garantien als ein lokales Linux-Dateisystem - die Atomizität ist zum Beispiel nicht gewährleistet.

Beispiele

Die Beispiele auf dieser Seite machen mehrere Annahmen:

Die Dateien, deren Namen mit compute beginnen, sind die Programme, welche ausgeführt werden sollen.
Die [arguments] sind die möglichen Argumente für das compute Programm.
Es wird im GPU Home gearbeitet; für echte Projekte empfiehlt es sich, projektspezifische Unterordner anzulegen und aus diesen zu arbeiten. Slurm Jobs übernehmen ihr Arbeitsverzeichnis von ihrem Startort, bei Ausführung von salloc, sbatch und srun.

`salloc` Shell Job

salloc erstellt einen Job mit einer Shell; man bekommt also eine Allokation, deren Ressourcen man interaktiv benutzen kann.

xy12abcd@cipslurmlogin:~$ salloc --gres=gpu:1
xy12abcd@cipgpu00:~$ ./compute
output
xy12abcd@cipgpu00:~$ exit
xy12abcd@cipslurmlogin:~$

`srun` Interaktiver Job

Mit srun kann man Programme auf einer Allokation ausführen; diese Operation blockiert und bleibt an der Shell, so dass es möglich ist, mit dem laufenden Programm zu interagieren.

xy12abcd@cipslurmlogin:~$ srun --gres=gpu:1 ./compute [arguments]
output
Prompt: Interactive User Input
mehr Output
xy12abcd@cipslurmlogin:~$

`sbatch` Batch Job

sbatch legt ein Skript zur Ausführung in die Warteschlange und kommt sofort zurück. Die Ausgaben des Jobs kann man in der Datei slurm-<JobID>.out finden.

xy12abcd@cipslurmlogin:~$ sbatch ./batch.sh
Submitted batch job 1234
xy12abcd@cipslurmlogin:~$ cat slurm-1234.out
Ausgaben des Jobs
xy12abcd@cipslurmlogin:~$

Das Beispiel Skript unten zeigt 3 mögliche Wege, einen Job zu gestalten, sowie optionale Schritte, um Fehler zu vermeiden und Software nachzuladen.

batch.sh:

#!/bin/bash -l
#
# Alle #SBATCH Direktiven müssen aufeinander folgen.
# Eine nicht-Kommentar-Zeile beendet den Direktiven-Block.
#SBATCH --gres=gpu:1
#SBATCH --time=hh:mm:ss
#SBATCH --job-name=job123
#SBATCH --export=NONE

# bash bricht die Ausführung ab, bei Fehlern oder nicht deklarierten Variablen.
set -eu

# Umgebung sauber starten (--export=NONE), aber die unten geladenen Module für die srun-Schritte sichtbar machen
unset SLURM_EXPORT_ENV

# Job-Umgebung einrichten (Module laden, Daten vorstufen, ...)
# Die `-l` Option im Shebang ist zum Laden von Modulen nötig.
# (Nicht nötig, wenn keine Module geladen werden.)
module load <modules>

# 1. Im Job Skript kann direkt Arbeit getätigt werden; dafür einfach das entsprechende Programm ausführen.
./computeJob [arguments]

# 2. Jobs können optional auch mittels srun in mehrere Schritte zerlegt werden.
# Dies entspricht NICHT einer parallelen Ausführung.
srun ./computeStep1 [arguments]
srun ./computeStep2 [arguments]

# 3. Zum parallelen Ausführen `#SBATCH --ntasks=2` in den Direktiven-Block oben einfügen
# Unterscheidung der Prozesse dann über die Umgebungsvariable `SLURM_PROCID`
srun ./computeTwice [arguments]

# Es können auch Folge-Jobs gestartet werden
# ACHTUNG: Gefahr von Endlosrekursion
# Dieses Beispiel führt ein anderes Skript aus.
# Natürlich können auch andere Skripts ausgeführt werden
sbatch ./next.sh

Laufenden Job debuggen

Es ist möglich, eine Shell neben einen bereits laufenden Job zu erstellen, um diesen zum Beispiel zu debuggen. Man bekommt keine weiteren Ressourcen, nur eine Shell in derselben Allokation wie den zuvor gestarteten Job.

xy12abcd@cipslurmlogin:~$ sbatch ./batch.sh
Submitted batch job 1234
xy12abcd@cipslurmlogin:~$ srun --jobid=1234 --overlap --pty /bin/bash -l
xy12abcd@cipgpu00:~$ [debug-Befehl]
debug Dinge
xy12abcd@cipgpu00:~$ exit
xy12abcd@cipslurmlogin:~$

Tipps und Tricks

Bilder

Netpbm ist ein einfaches Bildformat, das mit plain printf geschrieben werden kann - ohne Bildbibliothek, wahlweise vollständig textbasiert. Die perfekte Wahl, wenn man Bilder aus einem Job ausgeben will, ohne von schwerem Tooling abhängen zu müssen.

Eine Konvertierung zu anderen Formaten ist natürlich möglich, zum Beispiel mit magick <input>.ppm <output>.png, und auch eine darauffolgende Kompression mit Befehlen wie pngcrush <input>.png <output>.png.

IO Performance

Die Arbeitsverzeichnisse liegen auf einem anderen Server und werden über NFS gelesen und geschrieben. Das Lesen vieler kleiner Dateien erzeugt signifikanten Overhead. Gerade große Datensätze sollten daher zusammengeklebt, also in wenige Dateien aggregiert werden.

Temporäre Dateien können lokal auf einem Knoten abgelegt werden. Hierfür bieten sich /var/tmp (SSD) und /tmp (RAM) an. Hinweis: Der lokale Speicher ist jedem Knoten privat, daher die Ergebnisse in das Arbeitsverzeichnis zurückkopieren.

SSH

Auf cipgpu[0-9]{2}: Wenn man einen laufenden Job hat, ist es möglich, sich direkt auf die GPU Hosts zu verbinden. Hostbasierte Authentifizierung geht hier leider nicht, daher den öffentlichen Schlüssel in .ssh/authorized_keys im GPU Home hinterlegen - er ist derselbe und sowohl auf der cipslurmlogin als auch auf den GPU Knoten verfügbar.

Auf cipslurmlogin mit hostbasierter Authentifizierung: Hierfür kann man einen CIP Rechner als JumpHost benutzen. Eine SSH Config sieht zum Beispiel so aus:

Host cipslurmlogin
    HostName cipterm0.cip.cs.fau.de
    User xy12abcd
    RemoteCommand ssh cipslurmlogin
    RequestTTY yes

Weitere Dokumentation

Offizielle Dokumentation Slurm: salloc, sbatch, squeue, scontrol, srun, sinfo, scancel