Tipps und Tricks

Tipps und Tricks

module load im Job-Script definieren

Um es Ihnen einfach zu machen, übernimmt Slurm beim Submittieren standardmäßig die Umgebung (environment) und die geladenen Module aus der (Login-) Sitzung, aus der Sie den Job abschicken.

Für die Reproduzierbarkeit einer Job-Umgebung ist es jedoch sinnvoll, ein Jobscript mit module purge zu beginnen und dann alle für den Job notwendigen Module explizit mit module load zu laden. Nur so ist sichergestellt, dass beim Programmlauf wirklich nur die gewünschten bzw. notwendigen Module (in ihrer richtigen Version) verwendet werden.

Das gilt insbesondere, wenn man beispielsweise mit module initadd bestimmte Module automatisch in der eigenen ~/.bashrc lädt, weil man sie wieder und wieder in jeder (Login-) Sitzung benötigt.

Archive entpacken im /work/scratch – Achtung automatische Löschung

Das Entpacken von Archiven (z.B. *.zip, *.tar etc.) verursacht oft das Beibehalten der darin enthaltenden „modification time“ aller Dateien. Sind die entpackten Dateien älter als 8 Wochen, können sie durch die automatischen Lösch-Regeln des Scratch-Bereiches bereits einen Tag später verloren gehen.

Es gibt für die verschiedenen Archive-Programme oft eine Option, um die „modification time“ nicht zu übernehmen, sondern für alle entpackten Dateien einen neuen Zeitstempel zu generieren. Für tar hilft beispielsweise die Option -m. Alternativ kann man für alle gerade entpackten Dateien mit dem Kommando „touch“ nachträglich einen neuen Zeitstempel generieren.

Hinweis: Ab dem 18.4.2017 wird die automatische Löschregel für den Scratch-Bereich auf die „creation time“ umgestellt! Die Aktualisierung der „modification time“ ist danach nicht mehr nötig bzw. hat danach keine Wirkung mehr zur Verlängerung der Speicherzeit von Dateien. Mit der Umstellung auf „creation time“ wird zukünftig das tatsächliche Anlegen einer Datei als Maß für das Alter verwendet – und nach einem Datei-Alter von mehr als 8 Wochen automatisch gelöscht.

Fehlender Slurm-Support in der MPI-Anwendung

Viele Anwendungen haben Probleme die richtige Anzahl Rechenkerne im Batchsystem zu nutzen. Das kann beispielsweise an mangelnder Slurm-Unterstützung liegen. Die meisten dieser problematischen Anwendungen bringen ihre eigene MPI-Version mit und müssen daher explizit mit der richtigen Anzahl Rechenkerne und auch dem so genannten Hostfile unterstützt werden.

Als erstes muss dazu ein aktuelles Hostfile generiert werden. Die nachfolgenden Zeilen ersetzen den sonst üblichen Aufruf „mpirun <MPI-Programm>“:

srun hostname > hostfile.$SLURM_JOB_ID
mpirun  -n 64  -hostfile hostfile.$SLURM_JOB_ID  <MPI-Programm>

Die erste Zeile (oben) erzeugt das Hostfile, die zweite Zeile übergibt dem MPI zusätzlich die Anzahl der zu verwendenden Rechenkerne (hier 64) und den Namen des Hostfiles.

Migration von LSF zu Slurm

Eine Hilfe zur Migration der wichtigsten LSF-Befehle und -Parameter in ihre Slurm-Äquivalente finden Sie hier.

Wichtig: Die Auswahl der richtigen Partition (Queue unter LSF) findet unter Slurm weitestgehend automatisch statt (z.B. bei Verwendung von sbatch oder salloc). Ausgenommen davon sind Spezialfälle wie „kurs*“- oder „extension*“-Queues unter LSF – unter Slurm sind das spezielle Partitionen, Reservierungen oder Projekt-Accounts, die Ihre Jobscripts explizit anfordern müssen.

Einrichten der passwortfreien ssh-Kommunikation zwischen Rechenknoten

Parallele Rechnungen über verschiedenen Knoten hinweg, müssen ohne Abfrage des Passwortes miteinander kommunizieren können. Standardmäßig ist das nicht erlaubt. Man kann das aber im eigenen home-Verzeichnis einstellen:

Geben Sie dazu auf dem lcluster1 (oder lcluster2 bis lcluster12) folgende Befehle ein:

Schlüssel generieren: Die Vorgabe des Speicherortes einfach mit <ENTER> übernehmen.

ssh-keygen -P "" -t rsa -C "$LOGNAME@lcluster"

Den erzeugten Schlüssel für den Login eintragen: Sie werden nach Ihrem Login-Passwort gefragt
(bitte eingeben). Die Konfiguration ist damit beendet.

ssh-copy-id -i .ssh/id_rsa.pub localhost

Zur Überprüfung der Konfiguration: Es sollte jetzt möglich sein, sich ohne Passwort auf einen anderen Login-Knoten (z.B. lcluster4) einzuloggen.

ssh lcluster4

Damit ist die Einrichtung abgeschlossen.

Abschließende Job Details

Mit dem nachfolgenden Kommando kann man sich nach Beendigung eines Jobs mit der <JobID> noch Details über die Ressourcen-Ausnutzung (CPU, Memory etc.) ausgeben lassen.

seff <JobID>

Eine ausführlichere Alternative mit noch mehr Details erhält man auch mit dem nachfolgenden Kommando.

sacct -l -j <JobID>
tuda-seff <JobID>

Gültigkeitsdauer des eigenen Accounts

Das Ablaufdatum des eigenen Benutzeraccounts kann mit dem Script /shared/bin/account_expire abgefragt werden.

Die Laufzeit Ihres Benutzeraccounts ist unabhängig von der Laufzeit bzw. Gültigkeit aller Projekte, denen Sie zugeordnet sind.

Fileübertragung zum und vom Lichtenberg HPC

Vor den Rechnungen auf dem Lichtenberg müssen Ihre Daten auf die Filesysteme des Lichtenberg-Rechners und danach Ihre Resultate wieder zurück übertragen werden.

Wir empfehlen folgende Verfahren:

Einmalige Übertragungen: scp

So wie man sich per ssh auf den Loginknoten anmeldet, können Dateien und Verzeichnisse mit dem SSH-Werkzeug scp übertragen werden.

Benutzen Sie hierfür ebenfalls die Loginknoten, denn diese haben leistungsfähige Netzwerkanschlüsse auch in das Campus-Netz der TU (wir betreiben keine speziellen input/output-Knoten).

Bei großen Text-/ASCII-Dateien wird die im SSH-Protokoll enthaltene, optionale Kompression (-C) empfohlen, die verlustfrei & transparent beim Transfer dafür sorgt, die Netzwerk-Bandbreite zu schonen und die den Transfer beträchtlich beschleunigen kann.
Lassen Sie die Kompression weg, wenn bereits vorkomprimierte Daten wie JPG-Bilder oder Videos in modernen Containerformaten (mp4, OGG) übertragen werden sollen.

Beispiel:

tuid@hla0003:~ $ scp -Cpr myResultDir mylocalworkstation.inst.tu-darmstadt.de:/path/to/my/local/resultdir

Details: man scp

Wiederholte Transfers: rsync

Fälle wie „zur Analyse mit grafischen Werkzeugen brauche ich die Berechnungsergebnisse umgehend auf meiner lokalen Workstation-Platte“ oder „die Rohdaten aus meinen lokalen Experimenten müssen umgehend auf den Lichtenberg zur Auswertung“ sind mit scp nur unzureichend abzubilden. Sowie man ein Verzeichnis auf dem Lichtenberg zu einem lokalen bei sich im Institut weitgehend synchron halten möchte, wäre wiederholtes scp ineffizient, da es keine Ahnung von „Änderungen“ hat und blindlings alles immer wieder überträgt (auch das, was schon im Ziel vorhanden ist).

Hier kann rsync helfen. Wie scp ein Kommandozeilen-Werkzeug zur Dateiübertragung zwischen (entfernter) Quelle „SRC“ und (entfernter) „DEST“ination, kann es anders als scp aber erkennen, welche Dateien in „SRC“ geändert wurden und überträgt nur diese. Kleine Dateien werden dabei im Ganzen (neu) übertragen, bei großen analysiert rsync die Änderungen (gesichert durch Prüfsummen) und überträgt nur die geänderten Blöcke.

Während der erste Transfer eines gefüllten Verzeichnisbaums in sein noch leeres Ziel kaum schneller sein wird als mit „scp -Cr“, laufen spätere Synchronisierungen drastisch schneller, weil nur noch geänderte (Teile von) Dateien übertragen werden (unveränderte Dateien sind ja schon da).

Zusammengefaßt: ungeänderte Datein gehen ab dem zweiten Transfer gar nicht mehr über die Leitung, geänderte kleine im Ganzen und bei geänderten großen Dateien überträgt rsync nur die Änderungen (Delta).

Beispiel:

tuid@hla0003:~ $ rsync -aH myResultDir mylocalworkstation.inst.tu-darmstadt.de:/path/to/my/local/resultdir

Details: man rsync,

Achtung: sowohl scp als auch rsync sind nur „Einweg“-Werkzeuge! Wenn sich zwischen zwei Transfers eine Datei in „DEST“ ändert, wird sie beim nächsten Transfer von ihrer (alten) Version in „SRC“ überschrieben.

Nicht verfügbar auf dem Lichtenberg:

FTP(S), sFTP, HTTP(S), rcp und andere ältere, (Klartext-) Protokolle.