Login-Hosts
Batch-System
Format eines Job-Scripts
Jobs mit grossem Memory-Bedarf, Multi-Threaded Programme
Überprüfen der Queues und der Clusternutzung
Ändern und Löschen von Jobs
Array jobs
Diskplatz
Parallele Programme mit MPI
Entwicklungswerkzeuge
Entwicklungswerkzeuge für MPI-Programme
Relevante Manual-Pages

Als Login-Hosts stehen die Rechner

 

• cluster-a.math.tu-berlin.de

• cluster-i.math.tu-berlin.de

• cluster-g.math.tu-berlin.de

• cluster-v.math.tu-berlin.de

• cluster-x.math.tu-berlin.de

   

zur Verfügung.

Die allgemeine Adresse

 

• cluster.math.tu-berlin.de

   

zeigt auf einen der o.g. Login-Hosts (derzeit immer cluster-i).

cluster-a ist ein AMD-basierter Rechner, cluster-i läuft mit Intel-Prozessoren. Für's normale Arbeiten und Job-Submittieren spielt dies keine Rolle, einige Compiler optimieren jedoch für die jeweils aktuelle Hardware-Konfiguration.

Auf den Login-Rechnern bitte nicht rechnen, sie dienen nur zum Editieren und Abschicken von Jobs (s.u.).

Bei cluster-g handelt es sich um einen Intel-Knoten, der darüber hinaus über 2 Tesla C1060 GPU-Karten verfügt. näheres dazu in dem Abschnitt zum GPU-Cluster.

Zugriff auf die /scratch-Disks der Cluster-Knoten ist möglich via den Pfad:

/net/<nodename>.scratch/

also z.B.

%  ls /net/node008.scratch/

Die Cluster laufen derzeit aussschliesslich als Batch-System, d.h. Jobs werden als Job-Script formuliert und mit 'qsub' abgeschickt.
Ein kleines Job-Script kann man z.B. wie folgt erzeugen und abschicken:

% cat > myjob.job <<EOF 
#!/bin/bash --login 
#$ -cwd 
#$ -N myjob 
#$ -o myjob.out 
#$ -j y 

./myprog < inputfile 
EOF 

% qsub myjob.job

Statt 'cat' kann natürlich auch ein beliebiger Texteditor zur Erstellung des Job-Files benutzt werden.

Der Job läuft an, wenn irgendwo die geforderten Ressourcen frei sind. Das kann sofort sein, bei speziellen Anforderungen aber auch Tage dauern. Der Benutzer kann sich über Email informieren lassen, ob Jobs gestartet, beendet oder abgebrochen wurd

Noch einmal das obige Beispiel mit Zeilennummern und ein paar mehr Parameter-Zeilen:

1    #!/bin/bash --login


2    #$ -cwd


3    #$ -N myjob


4    #$ -o myjob.out


5    #$ -j y


6    #$ -l h_rt=86400


7    #$ -m be


8    #$ -M myself@math.tu-berlin.de


9


10   ./myprog < inputfile

Erläuterung:

2) Wechselt ins Verzeichnis, aus dem der Job abgeschickt wurde.

3) Jobname

4) Output-File

5) 'Join'=yes, d.h. Errors zusammen mit Output ins Output-File

6) Angabe der maximalen Laufzeit ('hard real time', in Sekunden).

7) Mail bei Beginn und Ende des Jobs schicken

8) Mail-Adresse (bitte angeben !!)

Die Angabe der maximalen Laufzeit wird dringend empfohlen. Der Cluster-Scheduler wird zum einen kurze Jobs bevorzugen und zum anderen existieren für einige Queues Laufzeitlimiten, teilweise bis hinunter zu 1 Stunde. Die maximale Laufzeit liegt zur Zeit bei 220 Stunden (Stand 11/2010). Längere Laufzeiten sind auf Antrag möglich.

Des weiteren besteht eine Obergrenze für die Memory-Allocation damit weitere Prozessoren und jeweils die andere Hälfte des Speichers noch für andere Jobs verwendet werden können. Siehe unten für Möglichkeiten, mehr Memory zu nutzen. Welche Grenze festgelegt ist, hängt davon ab, welcher Cluster genutzt wird. Eine Anforderung im Job Script betr. freiem Memory wirkt sich damit auch auf die Selektion des Clusters aus (Siehe Beispiel unten).

Sämtliche Job-Parameter, die in einem Script benutzt werden können, dürfen auch auf der Kommandozeile von qsub benutzt werden und haben dann höhere Priorität:

%  qsub -N test -l h_rt=80000 -l mem_free=4G jobscript

Die verfügbaren Parameter lassen sich durch einen Aufruf von

% qconf -sc

anzeigen.

Programme, die das ganze Memory von 4GB (rsp. 16GB oder 32GB) nutzen wollen oder mit mehreren Threads oder Prozessen arbeiten, sollten jeweils eine Cluster-Node mit mehreren Prozessoren komplett reservieren. Dies erreicht man mit der zusätzlichen Zeile

#$ -l exclusive

im Job-Script.

Der Job läuft dann auf einem freien Cluster-Knoten (sobald einer frei ist!). Welcher Art dieser Knoten ist wird von weiteren Selektions-Flags eingeschränkt (so vorhanden).

Das Kommando qstat zeigt die laufenden und wartenden Jobs an:

%  qstat


job-ID  prior   name       user         state submit/start at     queue          slots ja-task-ID


-------------------------------------------------------------------------------------------------


4636 0.50500 matlab     zeppo        r     08/31/2006 22:19:48 all.q@node02       2


4531 0.50500 comsol     pippo        r     08/25/2006 18:05:38 all.q@node04       2


4632 0.50500 meinprog   blump        r     08/31/2006 10:12:18 all.q@node07       2


4621 0.55500 mpitest    npasched     qw    09/01/2006 08:44:36                   10

Optionen wie '-u username' oder '-s r' schränken die Liste ein. Siehe 'man qstat'.

Einige der Job-Parameter können auch nach dem Abschicken des Jobs noch geändert werden, teilweise sogar noch wenn der Job schon läuft. Hierzu dient das Kommando qalter. Es kennt im Wesentlichen dieselben Optionen wie qsub und setzt die entsprechenden Parameter für die angegebene Job-ID. Jobs, die falsch aufgesetzt, abgeschickt oder sonstwie beseitigt werden sollen, werden mit dem Kommando qdel unter Angabe der Job-ID entfernt. Beispiel:

%  qstat -u npasched


job-ID  prior   name       user         state submit/start at     queue          slots ja-task-ID


-------------------------------------------------------------------------------------------------


   4621 0.55500 mpitest    npasched     qw    09/01/2006 08:44:36                   10


%  qalter -m a 4621


modified mail options of job 4621


%  qdel 4621


npasched has deleted job 4621

Es kommt ab und zu vor, dass ein Job-Script mit einer grossen Anzahl Datensätzen laufen soll und dies im Prinzip auch parallel tun könnte. Die offensichtliche Methode, nämlich einfach n nur leicht differierende Job-Scripts zu schreiben und abzuschicken, ist sicherlich ab n > 3 eher lästig. Eine elegantere Lösung sind sog. Job-Arrays, wo ein einziges Job-Script abgeschickt wird, versehen mit der Weisung in n Kopien zu starten. Ein entsprechendes qsub Kommando sieht so aus:

%  qsub -t 10-30:2 jobscript

Das obige Kommando schickt das Script jobscript ins Batch-System und erzeugt dort 11 Kopien, die jeweils eine sog. TASK_ID zugewiesen bekommen im Bereich [10..30] mit Abstand 2, also 10 12 14 16 ....

Im Job-Script steht die Task-ID an zwei Stellen zur Verfügung:

1) Im Script-Header:

Hier können z.B. die Namen der Output-Files um die Task-ID ergänzt werden, so dass jede Kopie in ein eigenes File schreibt:

#$ -o job.$TASK_ID.out

2) Im Script selbst:

Hier steht die Task-Id in der Environment-Variable $SGE_TASK_ID und kann im Script selbst oder in von dort gestarteten Prozessen gelesen und genutzt werden.

#!/bin/bash --login


#$ -cwd


#$ -N matlab_run


#$ -o matlab_run.$TASK_ID.out


#$ -j y


#$ -m be


#$ -M myself@math.tu-berlin.de


 

matlab -nosplash -nodisplay < input.$SGE_TASK_ID.m

Hier noch ein Beispiel für einen Matlab-Input, der die Task-ID direkt liest:

task_id = str2num( getenv('SGE_TASK_ID') )


 

x = floor( task_id / 160 )


y = task_id - x * 160


 

.....

Jobs bekommen ein temporäres Verzeichnis zugewiesen, in dem vom Job erzeugte Files abgelegt werden können. Das Verzeichnis erreicht man über die Variable $TMPDIR. Es befindet sich auf der lokalen Festplatte des Knotens, auf dem der job ausgeführt wird und wird am Ende des Jobs gelöscht, wertvolle Daten sind von dort also am Ende des Jobs wegzukopieren.

Kleinere Mengen Daten können im Home-Verzeichnis gelagert werden und werden dort jede Nacht gesichert. Die Anfangs-Quota ist relativ restriktiv. Bitte melden, falls der Platz nicht ausreicht !

Für grössere Datenmengen gibt es das Verzeichnis /work/$USER.

ACHTUNG: Dieses Verzeichnis ist nicht im täglichen Backup enthalten !

Ausserdem existiert das Verzeicnis /lustre, das ähnlich wie /work dimensioniert ist, aber deutlich schneller sein sollte. Hier können bei der Verarbeitung eines jobs entstehende grosse Datenmengen schnell und ohne Belastung der für das /work-Verzeichnis zuständigen fileserver gespeichert werden.

Allerdings ist /lustre nur für temporäre Speicherung von Daten gedacht. Die Systembetreuung behält sich das Recht vor, dort ältere Dateien von Zeit zu Zeit löschen.

Für paralle Programme mit MPI sollte man ein Job-Script ähnlich dem folgenden benutzen:

#!/bin/bash --login


#$ -cwd


#$ -pe ompi* 4


#$ -N mpitest


#$ -o mpitest.out


#$ -j y


#$ -m be


#$ -M myself@math.tu-berlin.de


 

mpirun -np $NSLOTS myprog

Die '4' gibt hier die gewünschte Anzahl Prozessoren an. Es kann sogar ein Bereich von Prozessoren gewünscht werden:

#$ -pe ompi* 2-8

was den Job mit zwischen 2 und 8 Prozessoren startet (je nachdem was frei ist). Die tatsächlich alloziierte Anzahl ist im Script dann über die Variable $NSLOTS abrufbar.

Die sog. "Parallel Environments" ompi*, wie in den obigen Beispielen mit -pe angefordert werden, sind eine Art Gruppierung für die eigentlichen Queues. Sie bestimmen bei Anforderung von mehr als einem Queue-Slot, ob und wie die Prozesse auf die Knoten verteilt werden. Wegen der Netzwerktopologie der beiden Cluster gibt es eine ganze Reihe dieser ompi* PEs, das '*' in der oben gezeigten Anforderung bedeutet: Nimm irgendeines dessen Name mit 'ompi' anfängt.

Die folgende Liste zeigt das Schema, nach dem die PEs benannt sind:

Was man hier ggf. noch zu wissen braucht, ist die Anzahl Slots / Knoten in jedem Cluster:

In obiger PE-Liste bedeutet:

Das -pe kann also auch so aussehen:

#$ -pe mpi1 2-8

Für Programme, die mit OpenMPI kompiliert wurden, sollten NUR die ompi* PEs benutzt werden.

Die PEs mit Namen 'mpi*' sind für Programme, die ein Ethernet-basiertes MPI verwenden. Eine Liste der Hostnamen findet sich im File

$PE_HOSTFILE

Für den Cluster und die anderen 64bit-Rechner im Institut wurden eine Reihe von zusätzlichen Compilern installiert, die, was die Optimierung für Opteron-Prozessoren angeht, eine höhere Performance versprechen als die normalen gcc Versionen.
Hier eine Übersicht:

¹teilweise.

²Für die Pathscale-Compiler gibt es keine Lizenzen mehr, die Laufzeitumgebung kann aber noch genutzt werden.

Nicht alle Compiler sind im normalen Suchpfad vorhanden. Wenn eine spezielle Version benötigt wird, können die entsprechenden Environment-Variablen mit dem module Kommando gesetzt werden. Beispiel:

%  module add pathscale-2.2.1

Der Name des Moduls kann der obigen Tabelle entnommen werden und wird mit der entsprechenden Versionsnummer ergänzt. Mit module avail erhält man eine Liste der verfügbaren Module:

%  module avail


 

------------------------------- /usr/share/modules/modulefiles --------------------------------


dot                     ifc9.1.36               mvapich-pgi-0.9.8          use.own


g03                     lahey8.0                null                       pgi-7.1-1


gaussian03              module-cvs              pathscale-2.0              pgi-7.2-4


gcc402                  module-info             pathscale-2.1


gcc411                  modules                 pathscale-2.2.1


gridengine              mpich-ch-p4             pathscale-2.3


icc9.0                  mpich-ch-p4mpd          pathscale-2.3.1


icc9.0.23               mvapich-gcc             pathscale-2.4


icc9.1                  mvapich-gcc-0.9.8       pathscale-2.5


icc9.1.42               mvapich-intel-0.9.8     pgi-6.0.5


ifc9.0                  mvapich-pathscale       pgi-6.1


ifc9.0.25               mvapich-pathscale-0.9.8 pgi-6.2.5


ifc9.1                  mvapich-pgi             pgi-7.0-4

Nicht alle aufgelisteten Module betreffen Compiler. Informationen zu einem bestimmten Modul erhält man mit (z.B.):

%  module help pgi-6.0.5


 

----------- Module Specific Help for 'pgi-6.0.5' ------------------


 

Sets up the paths you need to use the Portland 6.0.5 compiler suite as the default

Bei häufiger Benutzung bestimmter Module ist es sinnvoll, entsprechende module-Befehle im ~/.cshrc- oder ~/.bashrc-File unterzubringen. Beispiel:

%  tail ~/.cshrc


 

if ( ${?MODULESHOME} ) then


  module load pathscale-2.4 gcc411


endif


 

#end of .cshrc

Für die Compilierung von MPI-Programmen sollte man die jeweiligen MPI-Compiler-Wrapper mpicc, mpif77 etc. benutzen, die einen der oben genannten Compiler aufrufen und die korrekten MPI-Bibliotheken dazulinken.

Eine Default-Version von OpenMPI ist bereits in den Pfaden enthalten, andere Versionen sind über Module verfügbar.
Die hierfür relevanten Module heissen:

Die Kompilation von MPI-Programmen geht dann nach folgendem Muster:

% mpicc -o myprog myprog.c

% mpif90 -o myprog myprog.f

qsub, qstat, qalter, qdel, ...
mpirun, mpicc, pathcc, pgcc ...

Bei Fragen zum Cluster oder Problemen mit der Nutzung:
Email an: Norbert Paschedag (clust_staff@math.tu-berlin.de)