Rechenressourcen

Partitionen und deren Laufzeit-Grenzen

Zur Vereinfachung und zur Vermeidung von Fehlern gibt es eine weitgehende Automatik für die Auswahl der richtigen Slurm-Partition.

Ausgenommen hiervon sind lediglich einige Spezialfälle wie beispielsweise Lehrveranstaltungen (Kurse). In diesen Fällen werden Sie gesondert darüber informiert, wie Partition, Reservierung oder Projekt-Account in Jobscripts angegeben werden müssen.

Je nach angegebener maximaler Laufzeit (-t oder --time=) werden Jobs in unterschiedliche Partitionen verteilt. Partitionen für Jobs längerer Laufzeit haben weniger Ressourcen (Rechenknoten), und darum kann die Wartezeit solcher Jobs länger sein.

Job runtime requirement
(-t / --time=…)
Partition Name Nodes assigned
MPI Accelerators
≦ 30' deflt_short all + 4 exclusive
acc_short 8
> 30' ≦ 24h deflt all
acc
> 24h ≦ 7d long 329
acc_long 6
Jobs with a runtime longer than 7d are only possible after coordination with the HPC team and with the use of a special reservation.

Konfiguration der Batchjobs für unterschiedliche Hardware

Standardmäßig werden Jobs auf dem gesamten Cluster und somit auf allen Arten von Knoten aller Phasen (Ausbaustufen) ausgeführt.

Damit Ihr Job auf einer bestimmten oder speziellen Hardware (-Ausstattung) zur Ausführung kommt, müssen Sie spezielle Ressourcen anfordern – wir unterscheiden grundsätzlich nach Prozessor-Typ und nach Beschleuniger-Typ , aber auch nach Sektionen, wie in der nachfolgenden Tabelle aufgeführt.

Alle anderen Eigenschaften Ihrer Jobs wie Laufzeit und Speicherverbrauch werden automatisch so ausgewertet, dass die Jobs auf die passenden Knoten-Typen bzw. Sektionen des Clusters verteilt werden.

Prozessor-Typ
Ressource Sektion Knotennamen Details
avx512 MPI 3 mpsc MPI-Sektion, LB 2 Phase I
NVD 3 gvqc, gaqc ACC-Sektion, LB 2 Phase I
MEM 3 mpqc MEM-Sektion, LB 2 Phase I
avx2 (oder dgx) DGX 1 gaoc ACC section, LB 2 phase I, DGX A100
Beschleuniger-Typ
(wird über „Generic Resources“ ausgewählt, nicht mehr per „constraint/feature“)
GRes Beschleuniger-Typ Knotennamen Details
--gres=gpu Nvidia (allgemein) gvqc,
gaqc
ACC-Sektionen (alle)
--gres=gpu:v100 Nvidia Volta 100 gvqc ACC-Sektion, LB 2 Phase I
--gres=gpu:a100 Nvidia Ampere 100 gaqc ACC-Sektion, LB 2 Phase I
Sektionen
Ressource Sektionsname Knotennamen Details
mpi MPI mpsc MPI Sektionen (alle)
mem1536g MEM mpqc MEM Sektion, LB 2Phase I

Ressourcen bzw. „Features“ können mit der Option -C („constraint“) angefordert und ausgewählt werden. Verschiedene Ressourcen können über ein & (logisches UND) bzw. ein | (logisches ODER) verknüpft werden (siehe Beispiele weiter unten).

GPU-Beschleuniger jedoch werden nicht mehr einfach nur per „feature“, sondern mittels GRes angefordert:

--gres=Klasse:Typ:# Beschleuniger-Anforderung, z.B. GPUs
(wenn nicht angegeben: Typ=any und #=1)

  • --gres=gpu – fordert 1 GPU beliebigen Typs an
  • --gres=gpu:v100 – fordert 1 NVidia „Volta 100“-Karte an
  • --gres=gpu:a100:3 – fordert 3 NVidia „Ampere 100“-Karten an

Um Ihre Job-Scripts nicht immer für wechselnde Anzahlen an GPUs umschreiben zu müssen, können Sie überall dort, wo Ihre Programme die Zahl der zu nutzenden GPUs erwarten, die Variable $SLURM_GPUS_ON_NODE verwenden. Beispiel: … --num-devices=$SLURM_GPUS_ON_NODE.

Wenn Sie für verteiltes Machine/Deep Learning mehrere GPU-Nodes benötigen (z.B. mit „horovod“), müssen Sie mit -N # (und dann -n >=#) explizit mehrere Nodes anfordern (# = 2-8).
Da „GRes“ immer pro Node gelten, darf --gres=gpu:4 nicht überschritten werden, selbst wenn mehrere 4-GPU-Knoten angefordert werden.

Beispiele

-C avx512
Fordert Knoten mit „Advanced Vector Extension (512 Bit)“-Architektur an.
-C "avx512&mem1536g"
Fordert Knoten mit AVX512-Architektur UND 1.5 TByte RAM an.
-C avx512
--gres=gpu:v100:2
Fordert Knoten mit AVX512-Architektur und 2 GPUs vom Typ „Volta 100“ an.