Batch Betrieb

Einführung

Zentrale Rechnerresourcen werden von vielen Benutzern gemeinsam genutzt. Anforderungen an diese Ressourcen müssen daher reguliert werden, um Zugriffskonflikte zu vermeiden. Zu diesem Zweck gibt es Software-Systeme, die man als Resource Manager oder auch als Batch System bezeichnet.

Für die RRZN-Computeserver setzen wir als Batch System/Scheduler Maui ein, das auf PBS (Portable Batch System)/Torque basiert.

Jobskripte sind Textdateien, die mit einem Kommando an das Batch System übergeben werden. Für Maui/Torque lautet das Kommando:

qsub <Optionen> <Name des Jobskripts>

Ein Jobskript besteht aus zwei Teilen: Im ersten Teil stehen Direktiven für das Batch System, im zweiten Teil die Kommandos, die man zur Ausführung bringen will (Also Kommandos, die man bei einer interaktiven Sitzung eingeben würde).

Die meisten Optionen des qsub-Kommandos kann man alternativ als Direktiven im Jobskript angeben. Wird eine Option beim Aufruf des qsub-Kommandos angegeben, so übersteuert sie die ihr entsprechende Direktive im Jobskript.

Beispiel

 #!/bin/bash -login
 #PBS -N pingpong
 #PBS -M ich@meine.email.adresse.de
 #PBS -j oe
 #PBS -l nodes=1:ppn=2
 #PBS -l walltime=00:10:00
 #PBS -l mem=2gb
 module load icc impi
 # change to work dir:
 cd $PBS_O_WORKDIR
 mpirun -machinefile $PBS_NODEFILE -np 2 ./ping_pong_advanced_send

Erläuterung:

• Die erste Zeile gibt die Shell an, in der das Skript interpretiert wird (hier die Bash-Shell)
• PBS Direktiven fangen mit "#PBS" an.
• #PBS -N definiert einen Jobnamen. Wird keine Ausgabedatei definiert (#PBS -o), wird die Jobausgabe nach <Jobname>.o<JobID> geschrieben, hier also z.B. pingpong.o3153.
• #PBS -M definiert die Emailadresse für Jobausgaben.
• #PBS -j oe definiert, dass Output und Error in die selbe Datei geschrieben werden.
• #PBS -l fordert Ressourcen an:
• nodes=1:ppn=2 heißt, dass man auf einem Knoten rechnen und dort zwei Prozessorkerne verwenden will.
• walltime=00:10:00 heißt, dass der Job maximal 10 Minuten laufen soll. Er wird also spätestens nach 10 Minuten vom System abgebrochen.
• mem=2gb heißt, dass der Job maximal 2 GB Hauptspeicher benutzen wird. Falls der Job mehr benutzt, wird er abgebrochen.
• Die folgenden Zeilen des Skripts enthalten Kommandos (bzw. Kommentare).
• Falls man die Fehlermeldung bekommt, dass der Befehl "module" nicht vorhanden sei, muss das Kommando "source $MODULESHOME/init/bash" in Job- und Shellskripten aufgerufen werden, um die Modules-Software zu initialisieren. (Man kann auch seine .kshrc bzw. .bashrc Datei geeignet anpassen.)
• Unter PBS stehen Umgebungsvariablen zur Verfügung, über die man in einem Batchjob auf wichtige Informationen zugreifen kann.
• $PBS_O_WORKDIR ist das Verzeichnis, aus dem der Job (mittels qsub) gestartet worden ist.
• Die Datei $PBS_NODEFILE enthält die Knoten auf denen der Job läuft. Diese Information ist wichtig für mpirun (oder mpiexec etc.), womit MPI-Programme gestartet werden.  

Es gibt mehrere Jobqueues: 

test zum Testen. Hier steht nur ein Knoten mit bis zu 12 Prozessoren und 47Gb zur Verfügung. Maximale Walltime ist 6 Stunden.

helena für Programme, die sehr große Hauptspeicheranforderungen haben (z.B. hunderte von Gigabyte) oder hochgradig parallelisiert sind (z.B. bis zu 160 parallele Prozesse), oder beides.

all für alles andere. Normalerweise ist es nicht nötig, weiteres explizit anzugeben. Torque schickt einen Job je nach den angegebenen Ressourcen auf passende Knoten.

all besteht aus mehreren Partitionen, die über die Option -W x=PARTITION:name auch direkt angewählt werden können:

Möchte man mit einem parallelen Programm auf den Rechenknoten eines RRZN-Computeservers interaktiv arbeiten, so muss man das unter der Kontrolle des Batch Systems tun. Das qsub-Kommando stellt dafür die Option -I bereit. Wenn das Programm eine X-Anwendung ist, muss man zusätzlich mit der Option -X die X-Ausgabe auf sein Display lenken.

Beispiel:

orac:~$ qsub -I -X -l nodes=2:ppn=2 -q all
qsub: waiting for job 3584.tclog.rrzn.uni-hannover.de to start
qsub: job 3584.tclog.rrzn.uni-hannover.de ready

knoten01:~$ echo $PBS_NODEFILE
knoten01

knoten01

knoten02

knoten02

knoten01:~$ exit

qsub: job 3584.tclog.rrzn.uni-hannover.de completed
orac:~$ 

Man kann auf die beschriebene Art natürlich nur arbeiten, wenn genügend Ressourcen frei sind und diese vom Batch System zugeteilt werden. Sonst bleibt das "qsub -I" Kommando hängen (und kann mit <ctrl>-c abgebrochen werden).

Mit dem Batchsystem am RRZN wird versucht, sehr verschiedene Anforderungen so angemessen wie möglich zu bedienen. Die Benutzer sollen möglichst fair bedient werden und die Jobs eines Benutzers sollen möglichst geringen Einfluss auf Jobs anderer Nutzer haben.

Die betriebswichtigen Werte für all sind unten tabellarisch dargestellt.

Große Datensätze vom Archivsystem holen und sichern innerhalb eines Batchjobs

Es kommt manchmal vor, dass man sehr große Datensätze hat, die man nicht unbedingt auf BIGWORK langfristig halten möchte.  Oder die Datensätze sollen dauerhaft gesichert werden, aber BIGWORK ist nur ein "Scratch"-Dateisystem.

Eine Lösung für dieses Problem ist, die Daten auf dem RRZN-Archivsystem zu sichern und während der Ausführung eines Jobs die Daten zu holen und am Ende die Ergebnisdaten auch wieder ins Archivsystem zu speichern.  Die Leitung zum Archivsystem ist in Schreibrichtung sehr schnell, so dass große Datensätze schnell gesichert werden können.  Daten vom Archiv zurückzuholen kann länger dauern, da die Daten unter Umständen zuerst vom Band zurückgespielt werden müssen.  Diese zusätzliche Zeit sollte dann in der Walltime-Einstellung im Batchskript berücksichtigt werden.

Um das Archivsystem benutzen zu können, muss Ihr Account freigegeben werden.  Dies wird auf BIAS eingestellt.  Sie loggen sich auf die BIAS-Seite mit Ihrem eigenen Benutzernamen ein und Sie klicken auf den "Ihren Benutzernamen für die Nutzung des Archivsystems zulassen"-Link.  Innerhalb weniger Stunden ist der Zugriff freigeschaltet.

Zugriff erfolgt mittels des "lftp" Kommandos.  Um den Zugriff automatisiert zu ermöglichen,  muss eine Datei mit dem Namen ".netrc" in Ihrem Homeverzeichnis angelegt werden (der Punkt vorne weg ist wichtig!). Sonst würde lftp nach Benuternamen und Passwort fragen.

Diese Datei enthält Ihre Zugangsdaten im Klartext und sollte deshalb unter sehr strikten Sicherheitsbedingungen gehalten werden, d.h. nur für Sie lesbar sein.

Die ".netrc" Datei bekommt folgenden Inhalt:

machine uqfs.rrzn.uni-hannover.de
    login <benutzername>
    password <passwort>

Wie gesagt darf sie nur für Sie alleine lesbar sein:

$ chmod 400 $HOME/.netrc

Die Authentifizierung zum Archivsystem erfolgt über eine verschlüsselte Verbindung und Ihre Zugangsdaten werden deshalb nicht weiter sichtbar sein.  

Es sollte jetzt möglich sein, sich auf dem Archivsystem ohne Passwort einzuloggen.  Dies kann man so testen:

$ lftp -c "open $USER@uqfs.rrzn.uni-hannover.de; ls"

Sie sollten jetzt eine Auflistung Ihres Verzeichnisses auf dem Archivsystem erhalten, ohne dass Sie nach dem Passwort gefragt werden.  Jetzt sind Sie bereit "lftp"  innerhalb eines Batchskriptes zu benutzen.

Im folgenden Beispiel-Batchskript wird ein Verzeichnis unter BIGWORK für die Simulation angelegt, Daten (als gezippte Tar-Archiv-Datei) werden vom Archivsystem geholt, die Dateien werden angeschaut (dies kann man in einem produktiven Skript weglassen), die Tar-Datei wird entpackt und die entpakten Dateien werden angeschaut (auch dies kann weggelassen werden).  Dann erfolgt die Simulation an der entpackten Dateien, die Ergebnisse werden in ein Tar-Archiv komprimiert und diese Daten ins Archivsystem kopiert auch mittels "lftp".

#!/bin/bash -login
#PBS -M ich@meine.mail.adresse
#PBS -j oe
#PBS -m ae
#PBS -l mem=4gb
#PBS -l nodes=1:ppn=1
#PBS -l walltime=05:00:00

# show which computer the job ran on
echo "Job ran on:" $(hostname)

# load the relevant modules
# module load ....

# make and change to work dir:
simulation_dir="$BIGWORK/my_simulation_dir.$$"
mkdir $simulation_dir
cd $simulation_dir

# get the data from the archive
echo "Retrieving input data from archive"
data_filename="simulation_input_data.tar.bz2"
time lftp -c "open $USER@uqfs.rrzn.uni-hannover.de; get $data_filename"

# see the files
ls -l

# unpack the archive
time tar -xvjf $data_filename

# see the unpacked files
ls -l *

# one can now run a simulation on the unpacked files....

# compress the results before sending back to the archive
echo "Compressing results directory"
results_filename="simulation_results.tar.bz2"
time tar -cvjf $results_filename results_directory/

# transfer the results back to the archive
echo "Copying results to archive"
time lftp -c "open $USER@uqfs.rrzn.uni-hannover.de; put $results_filename"

Es ist natürlich möglich nur einen Teil dieses Vorgangs zu benutzen, zum Beispiel, man kopiert nur die Eingabedateien aus dem Archivsystem oder man kopiert nur die Ergebnisse in das Archivsystem.

Jobketten

Es ist möglich, neue Jobs  von laufenden Rechenjobs starten zu lassen.  Im Grunde muss man nur qsub innerhalb des Batchskriptes ausführen mit dem neuen Batchskript-Namen.  Dieses Konzept wird konkreter durch ein Beispiel:

Man stelle sich vor, dass die Eingabe eines Programmes abhängig ist von der Ausgabe eines früheren Laufs.  Man möchte nicht bis zum nächsten Morgen warten, bis man den nächsten Job starten kann (wenn der Erste vielleicht schon mitten in der Nacht fertig geworden ist).  Daher erstellt man eine "Kette" von Batchjobs.  Das erste Jobskript (mit dem Beispielnamen myprog_kette_01.sh) sieht etwa so aus:

#!/bin/bash -login
#PBS -M ich@meine.mail.adresse
#PBS -j oe
#PBS -m ae
#PBS -l mem=4gb
#PBS -l nodes=1:ppn=1
#PBS -l walltime=05:00:00

# show which computer the job ran on
echo "Job ran on:" $(hostname)

# load the relevant modules
# module load ....

# run the simulation
myprog -input InputFile_01.dat -output OutputFile_01.dat


# start the next simulation
qsub myprog_kette_02.sh

Das zweite Jobskript (mit dem Namen myprog_kette_02.sh) sieht dann so aus:

#!/bin/bash -login
#PBS -M ich@meine.mail.adresse
#PBS -j oe
#PBS -m ae
#PBS -l mem=4gb
#PBS -l nodes=1:ppn=1
#PBS -l walltime=05:00:00

# show which computer the job ran on
echo "Job ran on:" $(hostname)

# load the relevant modules
# module load ....

# run the simulation
myprog -input OutputFile_01.dat -output OutputFile_02.dat

Und das war's eigentlich.  Man kann dieses Konzept erweitern zu komplexeren Beispielen, aber das Grundkonzept bleibt dasselbe.

Die neue Jobskripte könne auch dynamisch im alten Skript erzeugt werden, was für Parameterstudien nützlich ist, wenn man den nächsten Parameter noch nicht kennt zur Ausführungszeit des ersten Skripts. Man sollte aber auf jeden Fall sicherstellen, dass das neue Skript an seinem Ort liegt, wenn man es aufrufen will, und man sollte sich auch im gleichen Verzeichnis befinden (oder den vollen Pfad angeben). Der Phantasie sind keine Grenzen gesetzt.

Umgebungsvariablen von der Shell in den Batchjob kopieren

Manchmal ist es gewünscht, dass Umgebungsvariablen, die in der Shell in der man auf dem Login-Knoten arbeitet, auch im Job zur Verfügung stehen.  Es ist möglich diese Variablen entweder einzeln, oder alle, die in der Umgebung sind, zum Batchjob zu kopieren und damit die Variablen für den Job zur Verfügung stellen.  Dies würde erlauben, zum Beispiel, dass man Parameter zum eigentlichen Programm beim Submittieren übergeben kann.  Damit man Umgebungsvariablen an Batchskripte weitergeben kann, benutzt man die -v PBS-Option:

#PBS -v PARAM1,PARAM2,PARAM3,...

Dies ist eine Komma-getrennte Liste von Umgebungsvariablennamen, die bereits in der aktuellen Shell existieren.  Man kann mit der -V Option (also großgeschrieben) alle Umgebungsvariablen dem Batchskript übergeben, aber dies ist meist zu viel und ist nicht empfohlen.

Hier ist ein Beispiel:  Man möchte eine Parameterstudie machen und dem Programm die x, y und z Breite eines Volums übergeben.  Diese Werte müssen aber in verschiedenen Batchjobs submittiert werden, damit Job 1 verschiedene Werte als Job 2 bekommt und entsprechend das Programm übergibt.  Zuerst das Batchskript (Dateiname: env_var_in_job.sh):

#!/bin/bash -login
#PBS -M ich@meine.mail.adresse
#PBS -j oe
#PBS -m ae
#PBS -l mem=1gb
#PBS -l nodes=1:ppn=1
#PBS -l walltime=01:00:00

#PBS -v XWIDTH,YWIDTH,ZWIDTH

# show which computer the job ran on
echo "Job ran on:" $(hostname)

# change to working directory
cd $PBS_O_WORKDIR

# load the relevant modules
# module load ....

echo "XWIDTH = $XWIDTH"
echo "YWIDTH = $YWIDTH"
echo "ZWIDTH = $ZWIDTH"

# run the simulation
./myprog $XWIDTH $YWIDTH $ZWIDTH

Das Programm myprog ist in unserem Beispiel ein simples (ausführbares) Shellskript, aber hoffentlich kann man sehen wie man die Ideen in konkreten Beispielen einsetzen kann.

#!/bin/bash

# myprog: Example program to show the usage of the -v PBS option

xwidth=$1

ywidth=$2

zwidth=$3

echo "My box has the following dimensions: $xwidth x $ywidth x $zwidth"

Wir stellen jetzt die Umgebungsvariablen ein und setze den Job in die Warteschlange ab:

$ XWIDTH=1 YWIDTH=2 ZWIDTH=3 qsub env_var_in_job.sh

und sollten die folgende Ausgabe erhalten:

$ cat env_var_in_job.o456103
Job ran on: estragon.rrzn.uni-hannover.de
XWIDTH = 1
YWIDTH = 2
ZWIDTH = 3
My box has the following dimensions: 1 x 2 x 3

Man könnte also mehrere Simulationen mit unterschiedlichen x-Breiten so absetzen:

for i in $(seq 1 5)

do

    XWIDTH=$i YWIDTH=2 ZWIDTH=3 qsub env_var_in_job.sh

done