In diesem Kapitel zeigen wir dir, wie du dein Modell auf dem High Performance Cluster der WWU trainieren kannst.

Der Login-Prozess für das HPC wird in diesem Tutorial verkürzt (aber ausreichend) dargestellt. Für weitere Infos zur Funktionsweise des HPC gibt es ein ausführlichen Wiki unter High Performance Computing.


0. Registrierung auf PALMA

Um Zugriff auf das HPC zu bekommen, musst du (bzw. deine Uni-Kennung) der Nutzergruppe u0clstr zugeordnet sein.

Du kannst dich selbst in die Nutzergruppe eintragen, dies wird über das WWU-IT Portal erledigt.

WWU IT Portal

Gehe hierzu im IT-Portal links auf den Punkt "WWU-Kennung und Gruppenmitgliedschaften" und anschließend links im Menü auf den Punkt "... neu beanragen".

Im nun erscheinenden Dropdown suchst du nach der Nutzergruppe "u0clstr" und beantragst die Mitgliedschaft.

Gegebenenfalls musst du nun bis zu 24 Stunden warten, bis alle Gruppenmitgliedschaften auf den HPC-Systemen aktualisiert sind. Warte also bitte einen Tag, bevor du fortfährst.


Anschließend kannst du deinen SSH-Key hinterlegen. Das bedeutet in einfacher Form, wir teilen dem HPC mit, dass dein Computer vertrauenswürdig ist. Diese Schritte musst du nur einmal für alle Projekte auf deinem Computer wiederholen, dafür jedoch für jeden Computer getrennt. Ohne eine weitere Passworteingabe kann das HPC dadurch sicherstellen, dass nur Personen bzw. Geräte auf das HPC zugreifen, die dazu berechtigt sind.


Eventuell besitzt du bereits einen SSH-Key. Diesen kannst du dann einfach verwenden. Er liegt üblicherweise in deinem Home-Verzeichnis in einem Ordner .ssh/. Falls dieser Ordner leer ist oder nicht existiert, hast du vermutlich noch keinen SSH-Key und musst einen neuen generieren (siehe nächster Abschnitt).

Die SSH-Keys bestehen immer aus einem Pärchen bestehend aus einem privaten und öffentlichen Schlüssel. Es gibt verschiedene Algorithmen mit denen die Schlüssel generiert werden können. Üblicherweise sind die Dateien entsprechend benannt:

Algorithmus

Public Key

Private Key

ED25519 (bevorzugt)id_ed25519.pubid_ed25519
RSA (mindestens 2048-Bit großer Key)id_rsa.pubid_rsa
DSA (veraltet)id_dsa.pubid_dsa
ECDSAid_ecdsa.pubid_ecdsa


Wenn du noch keinen SSH-Key besitzt, musst du ein neues Schlüssel-Paar generieren. Du kannst dazu das Programm ssh-keygen nutzen. Wahrscheinlich hattest du dieses (abhängig von deinem Betriebssystem) bereits installiert oder hast es zusammen mit Git installiert. Führe in einer Konsole den folgenden Befehl aus:

ssh-keygen -t ed25519 -C "<comment>"

Du wirst nun gefragt, wo du das neue Schlüssel-Paar speichern möchtest. Falls du unsicher bist oder keinen besonderen Grund hast, solltest du es bei der Standardeinstellung belassen und diese mit Enter bestätigen.

Als nächstes wirst du nach einem Passwort gefragt. Mit diesem kannst du den Zugriff auf den Schlüssel beschränken. Es ist möglich kein Passwort zu vergeben, aber beachte, dass dann jeder mit Zugang zu deinem Gerät auch auf den Schlüssel zugreifen kann. Mit dem privaten Schlüssel kann man sich gegenüber dem GitLab-Server (und anderen Servern auf denen du deinen öffentlichen Schlüssel hinterlegst) als du ausgeben. Das hier eingegebene Passwort stellt eine zusätzliche Sicherheitshürde dar und muss bei jedem Zugriff auf den Server (bzw. dafür benötigten privaten Schlüssel) eingegeben werden.


Hast du deine SSH-Schlüssel gefunden oder generiert, kannst du diesen im IT-Portal der WWU hochladen. Hierzu gehst du links im Menü auf den Punkt "HPC-Systeme" und anschließend in der erscheinenden SSH-Zugangsbox auf den Button "Einrichten".

Hier kannst du nun den Inhalt der Datei, die den Öffentlichen Schlüssel (endet mit *.pub) enthält entweder in das Eingabefeld kopieren oder die Datei selbst hochladen.

Achtung!

Achte darauf, dass du auf jeden Fall den öffentlichen Schlüssel hochlädst, gib niemals deinen privaten Schlüssel (ohne Dateiendung) heraus! Mit Hilfe dieses Schlüssels können im schlimmsten Fall andere deine Identität annehmen! Du solltest die privaten Schlüssel also gut hüten. Im Optimalfall hast du ebenfalls für jeden SSH-Zugang zu deinen Systemen ein eigenes Schlüsselpaar.


1. Login auf PALMA

Nach der Registrierung kannst du dich einfach per SSH mit PALMA verbinden. der Befehl lautet wie folgt:

ssh <nutzerkennung>@palma.uni-muenster.de

In diesem Fall wird der Standard SSH-Schlüssel von deinem System zur Anmeldung genutzt.


Solltest du einen speziellen private Key verwenden möchten, so gib diesen entweder explizit im Befehl mittels des Arguments -i  an:

ssh -i ~/.ssh/<private_key_file> <nutzerkennung>@palma.uni-muenster.de

Alternativ kannst du deiner Kommandozeile auch mitteilen, dass du auf PALMA immer einen speziellen Key verwenden möchtest. Füge dazu in der Datei ~/.ssh/config einen Host hinzu:

~/.ssh/config
# Default
Host *
   AddKeysToAgent yes
   IdentityFile ~/.ssh/id_rsa

# For PALMA
Host palma.uni-muenster.de
   AddKeysToAgent yes
   IdentityFile ~/.ssh/<palma_key>


Nun solltest du sehen, dass du auf PALMA eingeloggt bist:

INFO

Du befindest dich nun auf dem Head-Node von PALMA. Bitte starte von hier auf keinen Fall Jobs oder Berechnungen (also nutze niemals z.B. den command python um eine Datei auszuführen, sondern nutze das Job-Sytem, siehe unten!). Dieser Node ist nur für die Anmeldung und für das Scheduling der Arbeiten ausgelegt. Es gibt ein Job-System (slurm), über das Berechnungen auf PALMA sozusagen angemeldet werden, slurm kümmert sich dann darum, dass die angefragten Ressourcen auch wirklich frei sind und führt die Aufgabe dann auf einem freien Knoten aus. Lies dafür bitte unbedingt die folgenden Abschnitte oder die Anleitung des HPC: Getting started

2. Meine Daten auf PALMA

Um auf PALMA rechnen zu können, musst du natürlich dafür sorgen, dass deine Software sowie eventuell zur Ausführung benötigte Daten (zum Beispiel Trainingsdaten) im System verfügbar sind. Hierfür gibt es grundsätzlich zahlreiche Möglichkeiten, wir stellen hier die gängigsten einmal kurz vor.

PfadPurposeVerfügbar aufHinweise

/home/[a-z]/<username>

Beispiel:
/home/m/m_must42
Speicher für Skripte, Binaries, Applications etc.Login und Compute NodesKein Massenspeicher für Daten! Stark begrenzte Kapazität. Hier solltest du deine Software ablegen. Dieses Verzeichnis ist automatisch als $HOME gesetzt.
/scratch/tmp/<username>Temporärer Speicher für In- und Output deiner SoftwareLogin und Compute NodesPersistenter Speicher, bitte kümmere dich darum, deine Ergebnisse regelmäßig herunterzuladen und den Ordner aufzuräumen, um keinen Speicherplatz zu verschwenden. Von diesem System werden keine Backups gemacht! Dieses Verzeichnis ist automatisch als $WORK Variable gesetzt.
/mnt/beeondTemporärer lokaler SpeicherCompute NodeGeeignet für temporäre Daten, die während der Berechnung anfallen.
/cloud/wwu1/<projektname>/<sharename>Cloud-Speicher/SharesLogin (r/w) und Compute Nodes (r)Optimal z.B. für Trainingsdaten. Um eine Freigabe zu erstellen, schaue dir die Cloud Storage Solutions der WWU an und erstelle sie über den OpenStack (siehe Kapitel zum OpenStack hier im Incub.AI.tor)

2.1 Meinen Code auf PALMA kopieren

Die einfachste Möglichkeit, deinen Code auf PALMA verfügbar zu machen, ist dein Git-Repository im Home-Ordner zu klonen. Dies ermöglicht auch einfaches Updaten, solltest du deine Skripte weiterentwickeln oder Fehler beheben.

Zum klonen unseres Codes führen wir einfach den clone-Befehl aus:

cd /home/[a-z]/<username>
git clone https://zivgitlab.uni-muenster.de/reach-euregio/incubaitor.git

Nun ist dein Code im Home-Ordner als Git-Repository verfügbar, du kannst mittels

git pull

Neue Änderungen vom Git-Server übernehmen, aber natürlich auch Änderungen, die du gegebenenfalls direkt auf PALMA durchführst, Committen.


Solltest du in einem privaten Repository arbeiten, musst du dich gegebenenfalls auf PALMA im Git einloggen, entweder durch einen Token oder per SSH-Key. Diesen Part ergänzen wir hier demnächst. 

Stop

Bitte führe deinen Code noch nicht aus, wie du es von deinem lokalen Rechner gewohnt bist. Zur Ausführung von Code auf PALMA kommen wir in Abschnitt 3.

2.2 Sonstige Daten auf PALMA verfügbar machen

Um weitere Daten für deine Skripte verfügbar zu machen (beispielsweise einen Trainingsdatensatz), kannst du den scp-Befehl nutzen, der Analag zu cp auf einem Linux-System Dateien kopiert, jedoch auch mit Remote-Computern klarkommt. Möchten wir beispielsweise unsere Trainings-CSV auf PALMA kopieren:

scp -r /pfad/zu/lokalen/dateien <username>@palma.uni-muenster.de:/scratch/tmp/<username>/

Des Weiteren können wir einen usershare einbinden, den wir im OpenStack siehe Kapitel zum OpenStack) erstellen können und auch anderweitig nutzen können.

3. Job-Skript und Module

Auf PALMA ist einige Software bereits installiert und kann über environment module aufgerufen und genutzt werden. Da viele Module, Libraries und sonstige Software von wiederum anderen Libraries abhängig ist, wird dieses System in PALMA in so genannten toolchains gehandhabt. Eine toolchain ist einfach ein Kombination aus Kompilern und Libraries, derzeit gibt es hier foss (freie und open source Software) und intel (proprietär). 

Eine Übersicht der verfügbaren toolchains ist hier einsehbar.

Eine toolchain kann über den Befehl

module load <palma software stack>
module load <toolchain>
# example: 
module load palma/2020a
module load intel/2020a

geladen werden.

Danach ist erneut über den Befehl

module avail

Eine Liste mit den verfügbaren Libraries zu sehen.


Da PALMA mit einem Batch-System arbeitet und die Rechenkapazitäten mit den Berechnungen (jobs) zentral disponiert werden, müssen wir dem System in einem kleinen Skript mitteilen, welche Ressourcen und welche Software wir für unseren Job benötigen. Der Name der *.sh - Datei ist dabei relativ egal, sie kann zum Beispiel job.sh oder job_carprice.sh heißen, falls es verschiedene Dateien gibt.

In unserem Anwendungsfall könnte die Datei folgendermaßen aussehen:

job.sh 
#!/bin/bash

## looks like comments, but this are not comments!
#SBATCH --nodes=1                   # the number of nodes you want to reserve
#SBATCH --ntasks-per-node=1         # the number of tasks/processes per node
#SBATCH --cpus-per-task=4          # the number cpus per task
#SBATCH --partition=normal          # on which partition to submit the job
#SBATCH --time=1:00:00             # the max wallclock time (time limit your job will run)

## This small example training can be done on CPUs.
## If you need GPUs:
##SBATCH --gres=gpu:1
##SBATCH --partition=gpuv100

#SBATCH --job-name=IncubAItor_DEMO         # the name of your job
#SBATCH --mail-type=ALL             # receive an email when your job starts, finishes normally or is aborted

#SBATCH --mail-user=your_account@uni-muenster.de # your mail address

# LOAD MODULES HERE
module load foss/2020a
module load TensorFlow/2.3.1-Python-3.8.2
module load matplotlib
module load scikit-learn


# START THE APPLICATION
srun python3 /home/<first letter of username>/<username>/incubaitor/2_1_PALMA/app/train.py


Passe diese Datei entsprechend an, bevor du sie auf PALMA ausführst.


Zunächst sagen wir dem System, wie viele Knoten wir für unseren Job reservieren möchten, anschließend geben wir weitere Details wie die Anzahl der Tasks/Prozesse pro Node, die Anzahl der CPUs, die maximale Ausführungszeit etc. an. Da wir nur eine kleine Machine-Learning Aufgabe ausführen, benötigen wir keine GPU, diese kann aber ebenfalls reserviert werden, sollten wir GPUs benötigen. Abschließend geben wir ein paar Job-Details an und unsere E-Mail Adresse, an diese schickt das Scheduling-System die Benachrichtigungen, wenn sich der Status unseres Jobs ändert.

Manchmal ist es schwierig, einzuschätzen wie viele Ressourcen du für einen Job benötigst. Hab hier keine Angst, ein wenig auszuprobieren oder zu viele Ressourcen zu belegen. Allerdings gilt: Je mehr Ressourcen du reservierst, desto höher ist die Wahrscheinlichkeit, dass du ein bisschen warten muss bis dein Job startet, da die benötigten Ressourcen gegebenenfalls noch anderweitig reserviert sind.


Nun haben wir das Job-Skript, das unseren Task genau beschreibt und sind soweit startklar zur Ausführung. Hierzu benötigst unter anderem folgende Befehle:

CommandTask
sbatch job.sh
Füge deinen Job zur Warteliste hinzu.
squeue -u <user>

Zeige alle Jobs eines Nutzers an

squeue -u <user> -t RUNNING
Zeige alle laufenden Jobs eines Nutzers
squeue -u <user> -t PENDING
Zeige alle wartenden Jobs eines Nutzers
scancel <job-id>
Brich einen Job ab
scancel -u <user>
Brich alle Jobs eines users ab
scancel --name <jobname>
Brich alle Jobs mit diesem Namen ab


Hast du nun deinen Job ausgeführt, findest du den Log in einer *.txt - Datei, um eventuelle Fehler nachverfolgen zu können.

4. incub.AI.tor Beispiel

Du kannst nun das Beispiel anpassen. Wenn du das Beispiel wie unter Abschnitt 2 gezeigt in dein Home Verzeichnis kopiert hast, kannst du z.B. über den Editor vim (https://www.vim.org/) die Datei job.sh anpassen (vim ist nicht sehr Nutzerfreundlich!), oder die Anpassung zunächst in einem Editor deiner Wahl durchführen und per scp (siehe 2.2) ersetzen.

Das Beispiel benötigt die Daten im Verzeichnis deiner workdir. Die hier genutzten Daten kommen von Kaggle used car dataset. Dieses kannst du lokal herunterladen und dann entweder in dein lokales Repository aufnehmen oder per scp (siehe oben) direkt in deine working directory laden (hier wurde die Datei schon entpackt und der Ordner in data umbenannt):

Auf deinem Rechner!
scp -i $HOME/.ssh/id_rsa_palma -r data <username>@palma.uni-muenster.de:/scratch/tmp/<username>/

Dann liegt dieser Ordner in der working directory und wir können ihn uns anschauen:

Auf PALMA!
cd $WORK/data
ls

und es sollten alle Datensätze aufgeführt sein. Nun müssten wir den job kopieren und starten können:

Auf PALMA!
cd $WORK
cp $HOME/incubaitor/2_1_PALMA/job.sh $WORK
sbatch job.sh

Der Job bekommt eine jobid die dir angezeigt wird. Mit dem oben beschrieben squeue command können wir schauen, ob der Job ausgeführt wird. In der slurm datei können wir uns den Output auch anschauen (vim slurm-<jobid>.out). Wenn der Job durch ist, solltest du in der Working directory einen Ordner models haben, den du wie folgt wieder herunterladen kannst:

Auf deinem Rechner!
scp -i $HOME/.ssh/id_rsa_palma -r <username>@palma.uni-muenster.de:/scratch/tmp/<username>/models models
scp -i $HOME/.ssh/id_rsa_palma <username>@palma.uni-muenster.de:/scratch/tmp/<username>/slurm-<jobid>.out slurm.txt

In slurm.txt kannst du nun den gesamten Python Output sehen, wie es normal unter Python gewesen wäre (inklusive Fehler).

Last but not lead: logge dich wieder von Palma aus indem du

Auf PALMA!
exit

eingibst!