Starthilfe - Wegweiser
Auf dieser Seite werden die ersten Schritte zur Nutzung des HPC-Clusters Hummel erläutert sowie Besonderheiten der Nutzung in folgenden Abschnitten beschrieben:
- Login
- Front-End-Knoten
- Betriebssystem
- Arbeitsumgebung (rc-Dateien)
- Datenhaltung
- Disk-Quotas
- Software
- Übersetzung von Quellcode (Compilierung)
- Interaktives Testen von Programmen
- Nutzung des Batch-Systems
Eine allgemeine Einführung in das Hochleistungsrechnen ist zu finden auf der Seite:
Login
Der Rechner, von dem aus eine Anmeldung erfolgen soll, muss sich im Netz der Universität Hamburg befinden. Von außerhalb der Universität muss VPN genutzt werden.
Es sind zwei Login-Gateways verfügbar, die über secure shell (ssh) unter folgenden Adressen angesprochen werden können:
hummel1.rrz.uni-hamburg.de hummel2.rrz.uni-hamburg.de
Zu beachten ist, dass die beiden Login-Knoten lediglich Gateways sind, über die man sich zum eigentlichen Arbeiten auf einem der Front-End-Knoten anmelden muss. Auf den Login-Knoten steht nur grundlegende System-Software zur Verfügung. Die Verzeichnisse $HOME
und $WORK
sind verfügbar, sodass Daten über die Login-Knoten per secure copy (scp) transferiert werden können.
Hinweis für MacOS-Nutzer: Das Terminal sendet mitunter ungültige locale-Variablen, was dafür sorgt, dass beim Login Module nicht geladen werden können. Folgen Sie dem Hinweis unter https://blog.remibergsma.com/2012/07/10/setting-locales-correctly-on-mac-osx-terminal-application/.
Front-End-Knoten
Auf den Front-End-Knoten meldet man sich von einem Login-Knoten aus per ssh
an:
ssh front1 ssh front2
Man kann diese zwei Stufen (in einer UNIX-Shell) auch zusammenfassen, mittels
ssh -t yourHummelUsername@hummel1.rrz.uni-hamburg.de ssh front1
gelangt man direkt auf den Front-End-Knoten und hat auch weiterhin ein interaktives Terminal (dank -t
). Für X11-Weiterleitung muss man dies für beide Maschinen angeben:
ssh -X -t yourHummelUsername@hummel1.rrz.uni-hamburg.de ssh -X front1
Eine weitere Alternative für fortgeschrittene Nutzer ist die Konfiguration eines ProxyCommand
für OpenSSH, um transparent auf die Front-Ends zuzugreifen.
Die Front-End-Knoten sind zwei (im Prinzip) beliebige Compute-Knoten. Die hostnames bleiben dementsprechend nodeABC
. In der Regel handelt es sich um node001
und node002
. Zum Anmelden sollen immer die Namen front1
oder front2
verwendet werden, um in jedem Fall auf einem für die Front-End-Funktionalität vorgesehenen Knoten zu arbeiten!
Betriebssystem
Auf allen Compute-Knoten läuft dasselbe Betriebssystem. Das Betriebssystem ist CentOS 7.
Arbeitsumgebung (rc-Dateien)
Das Heimatverzeichnis $HOME
ist zunächst leer. Bis auf das .ssh
-Verzeichnis sind keine weiteren rc-Dateien wie .profile
oder .bashrc
vorhanden.
Datenhaltung
Es ist wichtig, die Datenhaltung zu planen. Besonderheit auf Hummel: Das Heimatdateisystem ist im Batch-Betrieb schreibgeschützt! Das Heimatverzeichnis $HOME
dient vor allem zur Bereitstellung der eigenen Arbeits- und Software-Umgebung (Programme und Skripte). Daten sollen grundsätzlich auf $WORK
gespeichert werden. Batch-Jobs müssen in $WORK
oder temporären Verzeichnissen arbeiten. Siehe dazu:
Disk-Quotas
Auf /home
und /work
sind Disk-Quotas aktiviert. Die Nutzung der eigenen Quota kann man sich mit dem Kommando
rrz-quota
anzeigen lassen. Zur Disk-Quota auf /work
tragen auch Daten in $RRZ_GLOBAL_TMPDIR
bei!
Software
Software wird über Environment-Modules zur Verfügung gestellt, siehe dazu:
Die Module sind in drei Gruppen abgelegt:
/sw/BASE
: Basis-Software (insbesondere Umgebungen zur Übersetzung von Quellcode)/sw/TOOL
: Software-Werkzeuge (z.B. Text-Editoren, Versionsverwaltung)/sw/APP
: Applikationen (z.B. Quantenchemie-Programme)
Viele Software-Pakete werden über die NetBSD Packages Collection (pkgsrc) bereitgestellt. Falls Software vermisst wird, sollte man immer zunächst dort schauen. Generell findet man in der neuesten pkgsrc-Umgebung Software, die typischeweise in Linux-Distributionen vorhanden ist. In die neueste pkgsrc-Umgebung wechselt man mit dem Kommado (darin steht YYYY für eine Jahreszahl und Q für ein Quartal):
module switch env env/YYYYQQ-gcc-openmpi
Übersetzung von Quellcode (Compilierung)
Die Auswahl der Software-Umgebung für die Übersetzung von Quellcode erfolgt über Environment-Modules wie oben beschrieben. Für die kommerziellen Compiler (Intel und PGI) stehen je zwei Floating-Licences zur Verfügung.
Die Übersetzung erfolgt auf einem der Front-End-Knoten. Als Arbeitsverzeichnis soll nach Möglichkeit $WORK
gewählt werden. Lauffähige Programme wird man im Heimatverzeichnis $HOME
ablegen.
Für das Übersetzen von Quellcode sind zwei Szenarien vorgesehen:
- Wenn für die Übersetzung (viele) weitere Pakete benötigt werden, empfiehlt sich der Wechsel in die neueste pkgrsc-Umgebung.
- Wenn bestmögliche Performance erzielt werden soll, empfiehlt sich die Nutzung des Intel-Compilers
durch Wechsel in das neueste
env/intel-...
. Dazu werden möglicherweise (wenige) weitere Pakete benötigt, die in aller Regel als Module bereits verfügbar sind.
Interaktives Testen von Programmen
Beim interaktiven Testen von (parallelen) Programmen werden leicht so viele Ressourcen in Anspruch genommen, dass andere Nutzer beeinträchtigt werden. Aufgrunddessen nutzt man zum Testen interaktive Ressourcen, die vom Batch-System bereitgestellt werden. Das Verfahren ist auf der Seite Interaktives Arbeiten unter Kontrolle des Batch-Systems beschrieben. Man achte darauf, temporärer Verzeichnisse ($TMPDIR) passend zu nutzen.
Nutzung des Batch-Systems
Das Batch-System wird für alle Produktionsläufe genutzt. Es kann natürlich auch für kurze Testläufe genutzt werden. Die wichtigsten Informationen zum Batch-System findet man auf der Seite Batch-Verarbeitung.
Eine Besonderheit ist, dass Batch-Jobs nicht in das Heimatdateisystem /home
schreiben können! Damit wird erzwungen, dass das Arbeitsverzeichnis in der Regel in $WORK
liegt. Auch die Batch-Log-Datei kann nicht unter $HOME
angelegt werden: wenn das Arbeitsverzeichnis beim Abschicken unter $HOME
liegt, erhält man keine Batch-Log-Datei (es sei denn, man hat mit --output
/--error
die Ausgabe nach $WORK
spezifiziert).
Außerdem achte man darauf,
- temporärer Verzeichnisse ($TMPDIR) passend zu nutzen
- und Partitionen und Job-Limits geeignet zu wählen.
Starten paralleler Programme mit mpirun
Ein mit MPI parallelsiertes Programm wird im Batch-Script mit
mpirun binary [arguments]gestartet.
mpirun
erbt die Anzahl der zu startenden Prozesse von SLURM.
(Der Programmstart mit srun
funktioniert auf Hummel nicht!)
Nutzung beider GPUs (CUDA-Devices) in der gpu
Partition
Beide CUDA-Devices der K80-GPUs können auf einfache Weise benutzt werden, indem im Batch-Skript zwei CUDA-Programme im Hintergrund gestartet werden, die jeweils eines der beiden CUDA-Devices nutzen:
CUDA_VISIBLE_DEVICES=0 cudaBinary1 [arguments1] & CUDA_VISIBLE_DEVICES=1 cudaBinary2 [arguments2] & wait(Das
wait
Kommando veranlasst den Batch-Job zu warten, bis beide Hintergrundprozesse
beendet sind.)
Kontrolle der Ressourcennutzung / Job-Reports
Vom RRZ erstellte Job-Reports bieten die Möglichkeit zu kontrollieren, ob ein Batch-Job die angeforderten Ressourcen wirklich genutzt hat. Insbesondere ist zu überprüfen, ob alle Rechenkerne (bei GPU-Jobs beide CUDA-Devices) wirklich genutzt werden. Siehe dazu die Beschreibungen der RRZ-Tools: