Inhalt des Dokuments
Benutzung der Cluster
Für rechen- und
speicherintensive Aufgaben stehen im Forschungsrechnerbereich drei
Cluster aus 64bit-Opteron- und Westmere-Rechnern zur Verfügung. Die
einzelnen Rechner der Cluster sind weitestgehend kompatibel mit den
Arbeitsplatzrechnern des Instituts und erlauben damit die einfache
Auslagerung rechenintensiver Arbeiten vom Arbeitsplatzrechner auf die
Cluster. Anderseits können durch spezifische Kompilierung von
Programmen für diese Rechnerarchitektur eigene Programme deutlich
beschleunigt werden, insbesondere wenn sogar die Möglichkeit der
Parallelverarbeitung genutzt wird.
Weitere Möglichkeiten
zur Bearbeitung rechen- und speicherintensiver Aufgaben stehen Ihnen
im erweiterten Compute-Serverbereich des Institutes zur Verfügung,
der dem Forschungsrechnerbereich angegliedert ist. Für diesen Bereich
muss man sich gesondert anmelden. Bitte informieren Sie sie sich über
die Möglichkeiten und Bedingungen auf den Dokumentationsseiten zum
Compute-Serverbereich [1].
Im folgenden finden Sie
detailierte Angaben zur Nutzung der Cluster im
Forschungsrechnerbereich:
- Technische Daten
- Auslagerung kleinerer Programme
- 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 (viele ähnliche Jobs mit verschiedenen Daten)
- Parallele Programme mit MPI
- Entwicklungswerkzeuge
- Entwicklungswerkzeuge für MPI Programme
- Relevante Manual-Pages
- Betreuung/Kontakt
Technische Daten
Cluster 1
Merkmal | Wert |
---|---|
Anzahl Nodes (vom Forschungsnetz aus zugänglich) | derzeit
13 |
Prozessoren (je
Node) | 2 x Opteron 252 (2.6 GHz) |
Memory (je Node) | 4
GB |
Netzwerk
(intern) | Infiniband + Gigabit Ethernet |
Bandbreite | ~800 MB/s
(MPI) |
Netzwerk (nach
aussen) | Gigabit
Ethernet |
Cluster 2
Merkmal | Wert |
---|---|
Anzahl Nodes (vom Forschungsnetz aus zugänglich) | derzeit 17 |
Prozessoren
(je Node) | 2 x DualCore-Opteron 2218 (2.6
GHz) |
Memory (je
Node) | 16 GB (1 Node mit 32 GB) |
Netzwerk (intern) | Infiniband + Gigabit
Ethernet |
Bandbreite | ~1500 MB/s
(MPI) |
Netzwerk (nach
aussen) | Gigabit
Ethernet |
Cluster 13
Merkmal | Wert |
---|---|
Anzahl Nodes (vom Forschungsnetz aus
zugänglich) | 5 |
Prozessoren (je Node) | 2 x Intel
Xeon X5650 Hexa-Core |
Memory (je Node) | 48
GB |
Netzwerk
(intern) | QDR Infiniband + Gigabit
Ethernet |
Bandbreite | ~3400 MB/s
(MPI) |
Netztwerk (nach
außen) | Gigabit Ethernet |
Cluster 16
Merkmal | Wert |
---|---|
Anzahl Nodes (vom Forschungsnetz aus
zugänglich) | 4 |
Prozessoren (je Node) | 2 x Intel
Xeon X2630v2 Hexa-Core |
Memory (je Node) | 64
GB |
Netzwerk
(intern) | QDR Infiniband + Gigabit
Ethernet |
Bandbreite | ~3700 MB/s
(MPI) |
Netztwerk (nach
außen) | Gigabit Ethernet |
Auslagerung von Programmen
Für die einfachste Nutzung des Clusters,
insbesondere für interaktive Programme (d.h. mit User-Input), benutzt
man am besten das cluster-Kommando. Beispiele:
% Cluster matlab -nosplash -nodisplay
< inp
oder einfach:
%
Cluster matlab
(In den obigen und den
folgenden Beispielen ist % jeweils der
Kommando-Prompt
der Shell)
Anmerkung: In früheren Versionen dieser Anleitung wurde das Cluster-Kommando mit kleinem 'c' geschrieben. Wegen eines Namens-Konflikts in neueren Linux-Versionen sollte ab jetzt die großgeschriebene Variante benutzt werden.
Das Cluster-Kommando startet die Programme im
selben Directory, in dem Cluster aufgerufen wurde,
vorausgesetzt, dass genügend Platz auf dem Cluster frei ist. Falls
dies nicht der Fall ist, beendet Cluster mit einer
entsprechenden Fehlermeldung. In solchen Fällen empfiehlt es sich,
die Programme im Batch-Mode in die Queue zu stellen.
Das Programm bleibt dann in einer Warteschlange und startet, wenn
entsprechende Ressourcen auf dem Cluster frei werden. Für interaktive
Programme wie im zweiten Beispiel oben ist dies nicht unbedingt
sinnvoll, für das erste Beispiel jedoch durchaus. Wie man das macht,
illustrieren die folgenden Beispiele:
1. Mit der
-now no Option zu Cluster:
% Cluster -now no matlab -nosplash
-nodisplay < inp
2. Durch Schreiben eines
kleinen Job-Scripts und Abschicken desselben mit
qsub:
% cat > matlab.job
<<EOF
#!/bin/bash --login
#$ -cwd
#$ -N matlab
#$ -o matlab.out
#$ -j y
matlab -nosplash -nodisplay <
inp
EOF
% qsub matlab.job
Statt 'cat' kann natürlich auch ein beliebiger Texteditor zur
Erstellung des Job-Files benutzt werden.
Der Unterschied
zwischen beiden Methoden ist, dass im zweiten Fall der Job komplett
unabhängig von der aktuellen Terminal-Session abgearbeitet wird. Im
ersten Fall muss das Fenster offen bleiben.
Format eines Job-Scripts
Noch einmal das obige
Beispiel mit Zeilennummern und ein paar mehr Parameter-Zeilen:
1 | #!/bin/bash
--login |
---|---|
2 | #$
-cwd |
3 | #$
-N matlab |
4 | #$ -o
matlab.out |
5 | #$ -j y |
6 | #$ -l
h_rt=86400 |
7 | #$ -m
be |
8 | #$
-M myself@math.tu-berlin.de |
9 | |
10 | matlab -nosplash
-nodisplay < inp |
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 (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
besteht ohne weitere Angaben ein Laufzeitlimit von 12
Stunden. Des weiteren besteht eine Obergrenze für die
Memory-Allocation von 2GB damit der zweite Prozessor
und 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.
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 jobscript
% Cluster -N test2 -pe mp 2
matlab -nosplash -nodisplay < inp
Jobs mit grossem Memory-Bedarf, Multi-Threaded Programme
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 zwei oder vier
Prozessoren komplett reservieren. Dies erreicht man mit der
zusätzlichen Zeile
#$ -pe mp 2 -l
cluster1
oder
#$ -pe mp 4 -l
cluster2
im Job-Script. Im ersten Falle läuft
der Job auf einem 4GB-Knoten mit 2 Prozessoren, im zweiten mit (mind.)
16GB und 4 Prozessorkernen.
Überprüfen der Queues und der Clusternutzung
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
Ändern und Löschen von Jobs
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
Array Jobs
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
.....
Weiter nutzbare Environment-Variablen:
- $SGE_TASK_LAST : Die letzte Task-ID
- $SGE_TASK_STEPSIZE : Der angegebene Step-Size.
Parallele Programme mit MPI
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
module add ompi-1.2.2
mpirun -np $NSLOTS myprog
Die rote vier 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 alle verfügbaren
PEs:
PE-Name | Cluster |
Prozesse/Knoten |
---|---|---|
mp | * |
n |
mpi1 | * |
1 |
mpi2 |
* | 2 |
mpi4 |
* | 4 |
mpi |
* | fill |
ompi1_1 | 1 | 1 |
ompi1_2 | 1 | 2 |
ompi1_n | 1 |
fill |
ompi2_1 |
2 | 1 |
ompi2_2 |
2 | 2 |
ompi2_4 | 2 | 4 |
ompi2_n | 2 |
fill |
Es bedeuten
hier:
n: so wie angegeben
fill: Ein
Knoten bekommt so viele Prozesse wie Platz ist, dann kommt der
nächste Knoten dran.
*: egal
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.
Entwicklungswerkzeuge
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:
Hersteller | Name des
Compilers | Sprache | Installierte
Versionen | Modul |
---|---|---|---|---|
Gnu | gcc | C89,
C991 | 4.1.2 | |
g++ | ISO C++
89 | 4.1.2 | ||
g77 | Fortran77 | 4.1.2 | ||
gfortran | Fortran77,
Fortran90 | 4.1.2 | ||
Intel | ifort | Fortran77,
Fortran901 | 9.0.25, 9.1.36, 10.1.018,
11.0.069 | ifc* |
icc | C89,
C991 | 9.0.23, 9.1.42, 10.1.018,
11.0.069 | icc* | |
icpc | ISO C++ 89 | 9.0.23,
9.1.42, 10.1.018, 11.0.069 | icc* | |
PathScale2) | pathCC | ISO
C++ 89 | 2.0, 2.1, 2.2.1, 2.3, 2.4,
2.5,3.0,3.1 | pathscale-* |
pathcc | ISO C89,
C99 | 2.0, 2.1, 2.2.1, 2.3, 2.4, 2.5, 3.0,
3.1 | pathscale-* | |
pathf77 | Fortran77 | 2.0,
2.1, 2.2.1, 2.3, 2.4, 2.5, 3.0,
3.1 | pathscale-* | |
pathf90 | Fortran90 | 2.0, 2.1,
2.2.1, 2.3, 2.4, 2.5, 3.0, 3.1 | pathscale-* | |
pathf95 | Fortran95 | 2.0,
2.1, 2.2.1, 2.3, 2.4, 2.5, 3.0,
3.1 | pathscale-* | |
Portland | pgcc | C89 | 6.0.5,
6.1, 6.2.6, 7.0-4, 7.1-1, 7.2-4 | pgi-* |
pgCC | ISO C++ 89 | 6.0.5,
6.1, 6.2.6, 7.0-4, 7.1-1, 7.2-4 | pgi-* | |
pgf77 | Fortran77 | 6.0.5, 6.1,
6.2.6, 7.0-4, 7.1-1, 7.2-4 | pgi-* | |
pgf90 | Fortran90 | 6.0.5,
6.1, 6.2.6, 7.0-4, 7.1-1, 7.2-4 | pgi-* | |
pgf95 | Fortran95 | 6.0.5, 6.1,
6.2.6, 7.0-4, 7.1-1,
7.2-4 | pgi-* |
1) teilweise
2) Seit Ende Nov.
08 sind keine Lizenzen mehr verfügbar
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
gaussian03 module-cvs pathscale-2.0
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 starcd-3.24
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
Entwicklungswerkzeuge für MPI-Programme
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. Die hierfür relevanten Module heissen:
Modulname |
Erklärung |
---|---|
ompi-gcc-1.2.2 | OpenMPI 1.2.2 mit
gcc |
ompi-pathscale-1.2.2 | "
mit pathscale |
ompi-pgi-1.2.2 | "
mit Portland |
Betreuung/Kontakt
Die Cluster werden betreut von
- Norbert Paschedag, MA 368, Tel. 314 29264
- Sven Grottke, MA 368, Tel.: 314 29283
Bei Fragen zum Cluster oder Problemen mit der
Nutzung senden Sie bitte eine Email an die Betreuer
[2](clust_staff)http://www.math.tu-berlin.de/cgi-bin/revchaddr.pl?ed.nilreb-ut.htam*ffats_tsulc
[3]
puteserver
nfrage/parameter/de/font2/maxhilfe/id/54604/?no_cache=1
&ask_mail=Xep4agADOH9TwNmQ7Pg6NG18AyUKLselFADxRwEwF
CCGzeG%2BfTvZJA%3D%3D&ask_name=CLUST%20STAFF
d.nilreb-ut.htam*ffats_tsulc
h/v_menue/lehrrechnerbereich/parameter/de/font2/maxhilf
e/
parameter/de/font2/maxhilfe/
blick/parameter/de/font2/maxhilfe/