Trainiere dein Modell auf PALMA II

Download this notebook

In diesem Kapitel zeigen wir dir, wie du dein Modell auf dem High Performance Cluster der Uni Münster 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. Registierung 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 IT-Portal der Uni Münster erledigt.

Gehe hierzu im IT-Portal links auf den Punkt “Uni-Kennung und Gruppenmitgliedschaften” und anschließend links im Menü auf den Punkt “… neu beantragen”.

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.

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.

# 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.

Wichtig!

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-System, 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.

2.1 Meinen Code auf PALMA kopieren#

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

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.

Info: 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.

WICHTIG: 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 analog zu cp auf einem Linux-System Dateien kopiert, jedoch auch mit Remote-Computern klarkommt. Möchten wir beispielsweise unsere Trainings-CSV auf PALMA kopieren, können wir lokal mit folgendem Befehl arbeiten:

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 bereits Software 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 sogenannten toolchains gehandhabt. Eine toolchain ist einfach eine 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 job.sh folgendermaßen aussehen:

#!/bin/bash

#   # Sieht aus wie Kommentare, aber das sind keine Kommentare!
#SBATCH --nodes=1                  # Die Anzahl der Knoten, den du reservieren möchtest
#SBATCH --ntasks-per-node=1        # Die Anzahl der Aufgaben/Prozesse pro Knoten
#SBATCH --cpus-per-task=4          # Die Anzahl der CPUs pro Aufgabe
#SBATCH --partition=normal         # Auf welcher Partition Sie den Job einreichen möchten
#SBATCH --time=1:00:00             # Die maximale wallclock time (Zeitlimit, bis zu dem dein Job läuft)

#   # Dieses kleine Beispiel-Training kann auf CPUs durchgeführt werden.
#   # Wenn Sie GPUs benötigen:
#   #SBATCH --gres=gpu:1
#   #SBATCH --partition=gpuv100

#SBATCH --job-name=IncubAItor_DEMO            # Der Name deines Jobs
#SBATCH --mail-type=ALL                       # Erhalte eine E-Mail, wenn dein Job startet, normal beendet oder abgebrochen wird
#SBATCH --mail-user=Ihr_Konto@uni-muenster.de # Dein E-Mail-Adresse

# MODULE WERDEN HIER GELADEN
module load foss/2020a
module load TensorFlow/2.3.1-Python-3.8.2
module load matplotlib
module load scikit-learn

# STARTE DIE ANWENDUNG
srun python3 /home/<erster Buchstabe des usernames>/<username>/incubaitor/2_1_PALMA/app/train.py

WICHTIG: Passe die 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.

INFO: 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 musst, 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 du unter anderem folgende Befehle:

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 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 working directory. 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):

Führe dazu den folgenden Befehl auf deinem Rechner lokal aus:

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 auf PALMA anschauen:

cd $WORK/data

ls

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

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 beschriebenen 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 auf deinem Rechner lokal wieder herunterladen kannst:

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 least: Logge dich wieder von PALMA aus, indem du auf PALMA den Befehl exit eingibst!