SLURM statt TORQUE
Simple
Linux
Utility for
Resource
Management
SLURM ist wie
TORQUE ein 'Ressource Manager' zum
Betrieb von Clustern, aber weitaus variabler und weiter entwickelt.
SLUM betreibt TASKs statt Cores/CPUs oder NODEs
Slurm erlaubt eine viel exaktere Zuordnung
von Ressourcen zu Berechnungen als Torqe
es kann.
Die wichtigste Größe ist ein
'Task', allgemein und
wörtlich gemeint als 'eine zusammenhängende Aufgabe'.
Erst darum herum ergeben sich die Festlegungen
von Cores/CPUS, Nodes (Maschinen), und weitere.
Die klassischen Fälle sind daher:
-
n=1 Task c=1 CPU (egal wo)
-
n=t Tasks auf N=1 Node (so viel, wie der Node kann)
Es lassen sich in
einem Job auch mehrere
Steps
der Reihe nach anordnen, innerhalb der Ressourcen des
Jobs verschieden angeordnet.
Wobei man dann X Jobs der jeweiligen Art queued, eventuell
auch als Jobarray.
Da Slurm
selber per
mpi Tasks bis auf auf die CPUs verteilen
kann, sind nun aber auch komplexere Jobs möglich, die
mpi oder
normales Threading berücksichtigen, ohne deswegen gleich ganze
Nodes anzufordern:
-
n=t Tasks auf c=nThreads per Task (irgendwo)
- das sind immer n Threads oder per mpi gekoppelte CPUs, die einen Task zusammen bearbeiten
- dabei entspricht ein Task einem Torque Job.
- die Tasks laufen aber wie ein Schwarm parallel.
-
n=t Tasks auf N=x Nodes mit c=nThreads per Task
- exakte Kontrolle, wieviele Berechnungen pro Node
- mit wieviel CPUs pro laufendem Programm
- Mit Zusatzangaben noch feiner festlegbar.
Die typischen Fälle
Wie auch in Torque legt man ein
Jobscript an,
in dem man Parameter festlegt und Aufgaben/Progamme
startet. Extrem vereinfachtes Beispiel:
#!/bin/bash
# ^^^^^^^^^---<<< must be a 'script'
#
# 'n' Tasks (hier EINE cpu)
#SBATCH -n 1
#
# Memory pro cpu in MegaBytes
#SBATCH --mem-per-cpu=512
#
# (wall)time
#SBATCH -t 00:00:59
#
# this job will crash ...
sleep 64
#
und startet den job mit
sbatch jobscript.
Per Default startet der Job dort, wo
sbatch
gerufen wurde, und dort wird auch der Output des
Jobs per Default in
slurm-$SLURM_JOB_ID.log
abgelegt.
Für viele, aber unabhängige Jobs ist das schon alles.
Einige Mögkichkeiten sind aber total neu:
- Es gibt
srun, das etwas sofort ausführt
- als interaktiven Aufruf - nicht sehr erwünscht
- als Aufruf innerhalb eines Jobscripts für mpi
- mit
sview kann man das ganze Cluster beobachten
Simple Jobs, direkt gequeued
Analog zu bisher, aus
#PBS... wird
#SBATCH...
Job Specification |
PBS/Torque |
Slurm |
Anmerkung |
| ??? |
??? |
-n ### |
Zählt Tasks = CPUs |
| Node Count |
-l nodes=n |
-N min-max |
|
| Output Files |
-o [file] -e [file] |
-o [file] e [file] |
|
| Queue/Partition |
-q name |
-p name |
|
| Script directive |
#PBS |
#SBATCH |
|
| Wall Clock Limit |
-l walltime=nn:nn:nn |
-t [min] OR -t [days-hh:mm:ss] |
|
#!/bin/bash
#
# 'n' Tasks (hier EINE cpu)
#SBATCH -n 6
#
# Memory pro cpu in MegaBytes
#SBATCH --mem-per-cpu=2048
#
# (wall)time
#SBATCH -t 00:12:00
#
# this job will crash ...
mpirun -np 6 mein_eigenes_programm p1 p2 p3
#
Jobs mit vorgegebenen Ressourcen, direkt gequeued
#PBS... #SBATCH...
(analog zu bisher, Parameter teils umrechnen)
'mpirun' wird 'srun'
(analog zu bisher:
#PBS... #SBATCH... srun --mpi-openmpi)
to be continued …
Die ganze Tabelle siehe
http://slurm.schedmd.com/rosetta.pdf
-- Cluster.stucki - 27 Apr 2014