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 11:51:34 +02:00
parent 554aca5368
commit 520783d4e0
1 changed files with 25 additions and 85 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

110
Workstations-Getting-Started.md
View File

@ -2,102 +2,26 @@
## Hardware ## Hardware
Für Berechnungen in der Forschung und Lehre stehen an der Fachhochschule verschiedene Workstations zur Verfügung. Eine Übersicht über die Maschinen findest Du hier https://gitea.fhgr.ch/CDS/infrastruktur-dok/src/branch/main Für Berechnungen in der Forschung und Lehre stehen an der Fachhochschule verschiedene Workstations zur Verfügung. Eine Übersicht über die Maschinen findest Du hier ![Übersicht](https://gitea.fhgr.ch/CDS/infrastruktur-dok/src/branch/main "Hardware Übersicht")
Der Cluster basiert auf einer von der Firma Sanitas gespendeten und vom DAViS/CDS auf Open Source Komponenten umgenutzten [Oracle Big Data Applicance X5-2L][4] mit sechs Nodes (Knoten). ## Zugriff
Ein Node besteht aus den folgenden Komponenten Der Zugriff erfolgt über SSH aus den Netzen (WLAN, VPN) der FH Graubünden. Wie eine SSH Verbindung eingerichtet wird, ist hier ![hier](https://gitea.fhgr.ch/CDS/infrastruktur-dok/src/branch/main/Lab-Login-Tutorial.md "SSH Einrichten") beschrieben.
<table>
<tr>
<th>2 x CPU</th>
<td>Xeon E5-2699 v3 @ 2.30GHz</td>
</tr>
<tr>
<th>RAM</th>
<td>128 GB DDR-4</td>
</tr>
<tr>
<th>Disks</th>
<td>12 x 14 TB 7200 RPM SAS</td>
</tr>
</table>
und sieht so aus:
![Beispiel eines Nodes](./images/cluster/Clusternode-Front.png)
Der gesamte Cluster mit Netzwerkequipment so:
![FH Cluster](./images/cluster/Cluster.png)
Für die Intranode-Kommunikation beim Rechnen über RDMA (zum Beispiel MPI) kommt ein High Performance Interconnect auf Basis von Infiniband QDR (40 Gbps) zum Einsatz. Für die Verwaltung der Nodes (SSH, TFTP etc.) steht ein dediziertes 10 GB Ethernet Netz zur Verfügung.
Im Hardwarevergleich steht unser Rechner hier:
| | Notebook | Lithium | CSCS Alps
|----------------------|-----------|-----------|-----------
| **Physische Cores** | 4 Cores | 216 Cores | 65536 Cores
| **Memory (RAM)** | 16 GB | 768 GB | ?
| **Speicherplatz** | 1 TB | 504 TB | 10 PB
| **Energieverbrauch** | 60 W | 5-6 KW | 5-10 MW
| **Interconnect** | 1 Gb/s | 40 Gb/s | 200 Gb/s
Das bedeutet, dass wir hardwaremässig sehr viel kleiner sind als Cluster im Bereich der [Top500][10]. Auf der Anwenderseite sind wir jedoch sehr ähnlich ausgerüstet wie die grossen HPC Forschungscluster. Auf Lithium findet man daher unter anderem folgende Komponenten:
* Slurm für das Job Scheduling
* BeeGFS (paralleles Filesystem) auf dem Scratchlaufwerk /scratch
* MPICH für das verteilte Rechnen
* Warewulf für die Clusteradministration
Im gesamten sind über 300 HPC spezifische Softwarepakete installiert.
## Architektur ## Architektur
Der Fachhochschulcluster besteht aus sechs Knoten (engl. Nodes). Dabei sind die einzelnen Nodes über ein Low Latency, High Bandwith [RDMA Netzwerk][5] miteinander verbunden. Dieses Netzwerk kommt hauptsächlich während einer Berechnung zum Einsatz. Alle Workstations für die Lehre sind nach dem folgenden Muster aufgebaut:
Einer der sechs Nodes ist als "Master", respektive "Headnode" oder "Loginnode" konfiguriert. Dieser ist während einer Berechnung für Koordinations- und Steueraufgaben zuständig und wird zudem zur Verwaltung des Clusters verwendet. Auf diesem Node wird prinzipiell *nicht* gerechnet. * Ein Homeverzeichnis mit einer Quota von 80GB pro Benutzer
* Ein Verzeichnis ```/scratch``` für die temporäre Ablage von grossen Datenmengen. In diesem Verzeichnis bitte keine vertrauliche Daten ablegen
Die eigentliche Rechenaufgabe wird für die parallele Abarbeitung auf die Computenodes verteilt. Nach Abschluss der Berechnung werden die Resultate entweder automatisch durch das verwendete Skript oder manuell über das /scratch oder Homelaufwerk zurück an den Masternode geschickt. * Zugriff auf die GPU ist mit dem Jobs Scheduler Slurm möglich. Wie das funktioniert steht im Abschnitt [Job Schduler und Partitionen](#Job-Scheduler-und-Partitionen)
* Installation von zusätzlichen Paketen kann über Anaconda/Miniconda oder Pip installiert werden
Der Fachhochschule Cluster ist wie folgt aufgebaut: * Für die Arbeit mit Containern ist die Software Apptainer installiert
<img src="./images/cluster/Clusterarchitektur.png" alt="Cluster Architektur" width="600"/>
## Zugriff auf den Cluster
Auf den Cluster kann nur mit SSH zugegriffen werden. Momentan können sich alle Mitarbeitenden des SIIs und alle Studierenden des Studiengangs CDS darauf einloggen. Für den Login braucht es einen SSH Client und einen FHGR Account. Der Zugriff mit SSH funktioniert so:
```
ssh <FH Benutzername>@lithium.fhgr.ch
```
Falls Du den Cluster verwenden möchtest, jedoch nicht zum SII oder CDS Studiengang gehörst, melde dich bitte beim DAViS Admin (thomas.keller@fhgr.ch).
## Starten der Computenodes
Um Energie zu sparen, werden unbenutzte Computenodes automatisch heruntergefahren. Um eine Berechnung zu starten, ist es daher notwendig, dass die Computenodes gebootet sind und sich im Slurmstate 'IDLE' befinden. Sollte der Status mit dem Befehl ```sinfo --all``` als 'down' angezeigt werden, dann müssen die Computenodes gestartet werden. Das Starten aller Nodes ist mit dem folgenden Befehl möglich:
```
sudo /usr/local/bin/start-computeNodes.bash
```
Nach einigen Minuten, sollte der Status des Clusters von 'DOWN' auf 'IDLE' wechseln. Sollte einer der folgenden Status anzeigt werden 'IDLE\*' (mit Stern), 'DRAINED', 'DRAINING', 'FAIL', 'FAILING', 'FUTURE', 'POWER_DOWN', 'UNKNOWN', 'RESERVED' dann informiere bitte den DAViS Administrator.
## 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.
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:
| Anwendergruppe / Partitionen | Debug | Studierende | Mitarbeitende
|------------------------------|-------|--------------|---------------
| Studierende | 5 Min | 3 h | kein Zugriff
| Mitarbeitende | 5 Min | kein Zugriff | 12 h
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.
## Clusterfilesystem und Homeverzeichnis ## Clusterfilesystem und Homeverzeichnis
@ -122,6 +46,22 @@ Der Energiesparmodus wird aktiviert, falls der letzte Slurm Job vor mehr als 90
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] 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
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.
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:
| Anwendergruppe / Partitionen | Debug | Studierende | Mitarbeitende
|------------------------------|-------|--------------|---------------
| Studierende | 5 Min | 3 h | kein Zugriff
| Mitarbeitende | 5 Min | kein Zugriff | 12 h
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.
## Erste Schritte auf dem Cluster ## Erste Schritte auf dem Cluster
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. 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.