staudtyves/infrastruktur-dok
1
0
Fork 0
forked from CDS/infrastruktur-dok
Code Pull Requests Activity

Update Workstations-Getting-Started.md

Browse Source
This commit is contained in:
Thomas Keller 2024-08-16 14:30:07 +02:00
parent 6df1d75e2a
commit eb0a3cd871
1 changed files with 23 additions and 56 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

79
Workstations-Getting-Started.md
View File

@ -18,85 +18,52 @@ Alle Workstations für die Lehre sind nach dem folgenden Muster aufgebaut:
|Ein Verzeichnis ```/scratch``` für die temporäre Ablage von grossen Datenmengen|In diesem Verzeichnis bitte keine vertrauliche Daten ablegen | |Ein Verzeichnis ```/scratch``` für die temporäre Ablage von grossen Datenmengen|In diesem Verzeichnis bitte keine vertrauliche Daten ablegen |
|Slurm für den Zugriff auf die GPUs|Wie das funktioniert steht im Abschnitt [Job Scheduler und Partitionen](#job-scheduler-und-partitionen)| |Slurm für den Zugriff auf die GPUs|Wie das funktioniert steht im Abschnitt [Job Scheduler und Partitionen](#job-scheduler-und-partitionen)|
|Installation zusätzlicher Software|Zusätzlichen Pakete können über die Software Anaconda/Miniconda oder Pip installiert werden. Wie das funktioniert ist zum Beispiel im Dokument ![Installation Tensorflow](https://gitea.fhgr.ch/CDS/infrastruktur-dok/src/branch/main/Installation-Tensorflow.md) beschrieben| |Installation zusätzlicher Software|Zusätzlichen Pakete können über die Software Anaconda/Miniconda oder Pip installiert werden. Wie das funktioniert ist zum Beispiel im Dokument ![Installation Tensorflow](https://gitea.fhgr.ch/CDS/infrastruktur-dok/src/branch/main/Installation-Tensorflow.md) beschrieben|
|Container|Für die Arbeit mit Containern ist die Software Apptainer installiert. Wie mit Apptainer Software installiert werden kann (auch für Software die Rootrechte benötigt) ist auch im Dokument ![Installation Tensorflow](https://gitea.fhgr.ch/CDS/infrastruktur-dok/src/branch/main/Installation-Tensorflow.md) beschrieben.| |Container|Für die Arbeit mit Containern ist die Software Apptainer installiert. Wie mit Apptainer Software installiert werden kann (auch für Software die Rootrechte benötigt) ist im Dokument ![Installation Tensorflow](https://gitea.fhgr.ch/CDS/infrastruktur-dok/src/branch/main/Installation-Tensorflow.md) beschrieben oder in der ![Apptainer Dokumentation](https://apptainer.org/docs/user/latest/)|
*
## Clusterfilesystem und Homeverzeichnis
Auf dem Cluster wird das Homeverzeichnis von jedem Benutzer automatisch mit [NFS][9] auf die Computenodes exportiert. Das heisst, dass auf jedem Node, egal ob Master oder Computenode die Daten des Homeverzeichnisses zur Verfügung stehen. Übrigens: auf deinem Homeverzeichnis steht jedem Anwender 80 GB Speicherplatz zur Verfügung. Wieviel Speicherplatz Du bereits belegt hast, kannst Du mit dem Befehl `quota -fs /` ausfindig machen.
Des weiteren gibt es unter dem Verzeichnis `/scratch` ein geshartes Filesystem mit einer Grösse von ca. 500 TB. Hier kommt BeeGFS, ein paralleles Filesysteme zum Einsatz das Speicherplatz von allen Computenodes unter dem Mountpoint (Verzeichnis) `/scratch` vereint. Daher kann es nur genutzt werden wenn alle Computenodes gestartet sind. Wie das Homverzeichnis ist auch das /scratch Laufwerk von allen Nodes zugreifbar.
Bitte beachte, dass Dateien unter dem Verzeichnis `/scratch` von allen Clusterbenutzern gelesen aber nur vom Dateieigentümer verändert werden können.
## Stromverbrauch und Energiesparmodus
Mit dem Befehl
```
sudo /usr/local/bin/get-powerUsage.bash
```
kann der momentane Stromverbrauch des Clusters in Erfahrung gebracht werden. Dabei ist der Stromverbrauch des High Performance Transports (in unserem Falle Infiniband) nicht mit eingerechnet.
Der Energiesparmodus wird aktiviert, falls der letzte Slurm Job vor mehr als 90 Minuten abgeschlossen wurde oder falls nach dem Start der Nodes 90 Minuten kein Slurmjob gestartet wurde. Solange Slurmjobs ausgeführt werden, werden die belegeten Clusternodes nicht in einen Energiestparmodus versetzt oder ausgeschaltet.
## Installation von zusätzlicher Software
Viele Machinlearning und Deeplearning Frameworks oder Python Module können über Anaconda, Miniconda oder Apptainer installiert werden. Für Anhaltspunkte wie das gemacht werden kann, siehe die Anleitung [Softwareinstalltionen auf den Workstations][8]
## Job Scheduler und Partitionen ## Job Scheduler und Partitionen
Da ein Cluster auch ein Mehrbenutzersystem ist, können dessen Resourcen nicht jederzeit frei verwendete werden. Daher kommt ein Jobscheduler zum Einsatz, der Rechenjobs mit den zur Verfügung stehenden Ressourcen möchglichst optimal zur Ausführung bringt. Auf lithium.fhgr.ch werden die Jobs durch [Slurm][6] verwaltet. Da alle Workstation an der FH auch ein Mehrbenutzersysteme sind, können dessen Resourcen nicht jederzeit frei verwendete werden. Daher kommt ein Jobscheduler zum Einsatz, der Rechenjobs mit den zur Verfügung stehenden Ressourcen möchglichst optimal zur Ausführung bringt. Daher musst Du bei einer GPU Berechnung zwingend ![Slurm](https://slurm.schedmd.com/quickstart.html) verwenden.
Grundsätzlich folgt Slurm auf Lithium dem [FIFO mit Backfill][7] Prinzip. Vereinfacht gesagt bedeutet das, dass der erste eingereichte Job zuerst abgearbeitet wird. Weiter wird die Ressourcennutzung durch sogenannte Partitionen eingeschränkt. Diese bestimmen wie lange ein Benutzer einen Slurm-Job ausführen darf. Momentan sind die folgenden Partitionen konfiguriert: Grundsätzlich folgt Slurm auf den Workstations dem [FIFO mit Backfill][7] Prinzip. Vereinfacht gesagt bedeutet das, dass der erste eingereichte Job zuerst abgearbeitet wird. Weiter wird die Ressourcennutzung durch sogenannte Partitionen eingeschränkt. Diese bestimmen wie lange ein Benutzer einen Slurm-Job ausführen darf. Die möglichen Partitionen kannst Du mit dem Befehl ```sinfo``` anzeigen lassen. Typischerweise gibt es für die Studierenden die foglenden zwei Partition
| Anwendergruppe / Partitionen | Debug | Studierende | Mitarbeitende |Partition | Zweck | Maximale Dauer|
|------------------------------|-------|--------------|--------------- |-------|--------------|----|
| Studierende | 5 Min | 3 h | kein Zugriff | Debug | Zum Testen und Experimentieren| 5 Min|
| Mitarbeitende | 5 Min | kein Zugriff | 12 h | Students| Für lange laufende Berechnungen| 7 Tage|
Falls deine Berechnung weniger als sieben Tage benögtigt, sind dir deine Mitstudierenden sicherlich sehr dankbar, wenn Du den Slurmjob beendest sobald deine Berechnung abgeschlossen ist.
Eine Berechnung die länger als die durch die Partition vorgegebene Zeit läuft wird **abgebrochen**. Diese Limite ist dazu da, damit ein Benutzer nicht irrtümlich oder absichtlich den Cluster für eine unbegrenzte Zeit blockieren kann. Daher empfiehlt es sich dringend, im Skript sogenannte 'Checkpoints' zu implementieren. Wie Checkpoints im Falle von Tensorflow oder Keras implementiert werden, findest Du [hier][11]. Checkpoints schützen übrigens auch vor einem Zeitverlust bei einem Stromausfall. Eine Berechnung die länger als die durch die Partition vorgegebene Zeit läuft wird **abgebrochen**. Diese Limite ist dazu da, damit ein Benutzer nicht irrtümlich oder absichtlich den Cluster für eine unbegrenzte Zeit blockieren kann. Daher empfiehlt es sich dringend, im Skript sogenannte 'Checkpoints' zu implementieren. Wie Checkpoints im Falle von Tensorflow oder Keras implementiert werden, findest Du [hier][11]. Checkpoints schützen übrigens auch vor einem Zeitverlust bei einem Stromausfall.
Falls Du deutlich mehr als die oben erwähnten Zeitspannen für eine Berechnung brauchst, melde dich beim DAViS Admin. Falls Du deutlich mehr als die oben erwähnten Zeitspannen für eine Berechnung brauchst, melde dich beim DAViS Admin.
## Erste Schritte auf dem Cluster Übrigens: sobald deine Berechnung fertig ist, beende auch deinen Slurmjob, zum Beispiel mit ```scancel```. Somit wird die GPU für den nächsten Benutzer freigegeben.
Mit dem Befehl srun kann ein Slurmjob auf dem Cluster ausgeführt werden. Als simples Beispiel dient hier der Befehl 'hostname', der den Namen des lokalen Rechners anzeigt. ## Slurm
Mit dem Befehl srun kann ein Slurmjob auf dem Cluster ausgeführt werden. Als simples Beispiel berechnen wir hier die Primfaktoren einer grossen Zahl:
``` ```
srun -p students -n $((36*5)) -N5 hostname srun -p students -n 64 factor 1234567890123456789012345678901234567890
``` ```
Mit der Option `-p` wird die Partition ausgewählt, im obigen Fall die 'students' Partition. Mit der Option `-n` teilen wir Slurm mit, wieviele parallele Tasks (Prozesse) wir ausführen wollen. Da wir pro Computenode 36 physische Cores haben (Hyperthreading ist deaktiviert) können wir auf dem Cluster maximal 180 Prozesse starten. Die Option `-N` teilt Slurm mit wieviele Computenodes für die Berechnung verwendet werden sollen. Im obigen Fall sollten wir daher genau 180 Zeilen Output erhalten. Mit der Option `-p` wird die Partition ausgewählt, im obigen Fall die 'students' Partition. Mit der Option `-n` teilen wir Slurm mit, wieviele parallele Tasks (Prozesse) wir ausführen wollen. Da wir pro Computenode 36 physische Cores und pro Core zwei hyperthreading Cores zur Verfügung haben, können wir den Parameter `-n` auf maximal 64 setzen. Sobald die Computerresource frei ist, wird der Befehl `srun` ausgeführt und es werden auf der CPU 64 Prozesse gestartet. Sobald die Berechnung abgeschlossen ist, wird das Ergebniss auf der Kommandozeile ausgegeben.
Mit dem Befehl ```squeue``` kann angezeigt werden welche Jobs momentan ausgeführt werden und welche Jobs auf Ressourcen warten. Für nicht-interaktive und länger laufende Jobs ist es sinnvoll `sbatch` zu verwenden. Damit muss nicht gewartet werden bis die Workstation frei wird, sondern der Jobscheduler übernimmt das Skript und bringt es zur Ausführung sobald die Hardwareresourcen frei sind. An welcher Reihe sich mein Job befindet, kann mit dem Befehl
Für nicht-interaktive und länger laufende Jobs ist es sinnvoll `sbatch` zu verwenden. Damit muss nicht gewartet werden bis der Cluster frei wird, sondern der Jobscheduler informiert den Anwender per Mail sobald das Skript zur Ausführung kommt. `squeue` angezeigt werden.
Dafür muss ein Shellskript geschrieben werden das einerseits einen Abschnitt enthält mit Informationen für Slurm (diese Befehle sind mit `#SBATCH` gekenntzeichnet) andererseits einen Abschnitt der den Befehl zum Starten der Berechnungen enthält. Dies könnte zum Beispiel so aussehen: Für `sbatch` muss ein Shellskript geschrieben werden das einerseits einen Abschnitt enthält mit Informationen für Slurm (diese Befehle sind mit `#SBATCH` gekenntzeichnet) andererseits einen Abschnitt der den Befehl zum Starten der Berechnungen enthält. Dies könnte zum Beispiel so aussehen:
``` ```
#!/bin/bash #!/bin/bash
#SBATCH --nodes=5 ## Number of computenodes #SBATCH --output="slurm-%j.out" ## Logfile. The logfile is written to the current directory
#SBATCH --output="slurm-%j.out" ## Logfile #SBATCH --time=1:30:00 ## Time limit. Should be equal or smaller than the partitions time limit. In this example the job will be interrupted after 1h and 30 min.
#SBATCH --time=240:00 ## Time limit. Should be equal or smaller than the partitions time limit #SBATCH --job-name="Mein Test" ## Job name. This will be used in naming directories for the job.
#SBATCH --job-name="test-mpi" ## Job name. This will be used in naming directories for the job. #SBATCH --partition=students ## Partition to launch job in
#SBATCH --partition=staff ## Partition to launch job in
#SBATCH --cpus-per-task=1 ## The number of threads the code will use #SBATCH --cpus-per-task=1 ## The number of threads the code will use
#SBATCH --ntasks-per-node=1 ## Number of tasks (processes/threads) to run #SBATCH --ntasks-per-node=64 ## Number of tasks (processes/threads) to run
#SBATCH --mail-type=BEGIN,END ## Sends a Email when Job starts and when the Job ends
#SBATCH --mail-user=<mail address> ## Mail Address
# Load an environment
module load py3-mpi4py
# Execute the python script and pass the argument '90' # Execute the python script and pass the argument '90'
srun python3 my-mpiProg.py 90 srun python3 my-mpiProg.py 90