| Both sides previous revision
Previous revision
Next revision
|
Previous revision
|
hpc-cluster:start [2010/10/21 11:27]
jantha doppelte Verneinung |
— (current) |
| ====== HPC-Cluster am GFZ ====== | |
| |
| Dokumentation des HPC-Clusters im Rahmen des BMBF-Projekts Multi-EM. | |
| |
| ===== Technisches ===== | |
| |
| ==== Zugang ==== | |
| |
| Zugang zum Cluster kann per E-Mail an <koe@gfz-potsdam.de> beantragt werden. Es wird dann ein Profil entsprechend dem Unix-Account erstellt. | |
| |
| Die Anmeldung erfolgt über SSH mittels ''ssh -X glic3'' ("glic3" existiert nicht wirklich, tatsächlich landet man meist auf "glic"). Dateien können per scp oder sftp kopiert werden. Alternativ kann die [[http://glic3:8083/Platform|Weboberfläche]] genutzt werden. | |
| |
| ==== Hardware-Übersicht ==== | |
| |
| Der Cluster besteht momentan aus [[http://rz.gfz-potsdam.de/compute/hardwaredescription.html|202 Knoten]] mit verschiedensten Leistungsmerkmalen. Die Knoten 64 - 202 sind [[http://rz.gfz-potsdam.de/compute/IPoIB-Struktur.html|per Infiniband verbunden]], Speicherplatz bietet das [[http://rz.gfz-potsdam.de/compute/GFZ-10G-IB-Update.html|Panasas Parallel Storage System]]. | |
| |
| ==== Speicherplatz ==== | |
| |
| Es sind 3 Dateisysteme auf den Knoten verfügbar: | |
| |
| * ''/home'' home-Verzeichnis: ''/home/ <group> / <user>'' | |
| * ''/projects'' für spezielle Projekte | |
| * ''/backup'' Platz für Daten die gesichert werden müssen (Dies sollte nicht als Arbeitsverzeichnis benutzt werden!) | |
| |
| Aufgrund des großen Datenvolumens wird nur das backup-Dateisystem gesichert | |
| |
| Das Verzeichnis ''/data/scratch'' kann zum lesen und schreiben auf der lokalen Platte jedes Knotens benutzt werden. | |
| |
| ==== Tools ==== | |
| |
| Sollen Befehle für eine Gruppe von Knoten ausgeführt werden kann man pdsh nutzen: ''pdsh -h show all options'' | |
| |
| Als Editor ist GNU Emacs installiert. | |
| |
| ===== Programme auf dem Cluster ausführen ===== | |
| |
| Die Ressourcen des Clusters werden von der [[http://rz.gfz-potsdam.de/compute/lsf_using/index.html|Platform Load Sharing Facility (LSF)]] verwaltet. Programme laufen auf dem Cluster als **Jobs** und werden zur Ausführung in **[[http://rz.gfz-potsdam.de/compute/tiger_queues.html|Queues]]** eingestellt. Die Queues leiten den Job dann an einen oder mehrere Prozessoren / Hosts weiter. Queues unterscheiden sich unter anderem darin ob (und wenn ja wieviele) Prozessoren parallel genutzt werden, wie hoch die Priorität ist und wie lang die Ausführung brauchen wird. Einige Queues sind für bestimmte Benutzergruppen reserviert. Dieses Verfahren sichert eine gleichmäßige und gerechte Auslastung des Clusters. Das direkte Starten eines Programms auf dem Cluster unter Umgehung der LSF ist daher nicht erlaubt. | |
| |
| ==== Programme ausführen per SSH ==== | |
| |
| === Umgebung einstellen === | |
| |
| Im Normalfall ist die Umgebung nach dem Login für den PGI Compiler sowie parallele Anwendungen mit MPI eingestellt. Mit dem Befehl [[http://rz.gfz-potsdam.de/compute/modules.html|module]] kann die Umgebung geändert werden. | |
| |
| === Anwendung kompilieren === | |
| |
| Durch die mit module gesetzten Pfade kann der passende Compiler mit den nötigen Bibliotheken angeprochen werden. Je nachdem, ob die Anwendung für parallele Ausführung programmiert ist, unterscheidet sich der Befehl. Beispiele: | |
| |
| * Kompilieren einer parallelen Anwendung: ''mpicc -o myapp_parallel my_application_parallel.c'' | |
| * Kompilieren einer nichtparallelen Anwendung: ''pgcc -o myapp_serial my_application_serial.c'' | |
| |
| === Anwendung zur Ausführung an das LSF übergeben === | |
| |
| Es gibt mehrere Möglichkeiten das Programm an das LSF zu übergeben. Alle verwenden den Befehl ''bsub''. | |
| |
| ''bsub'' kennt eine Reihe von Parametern, mit denen die Ausführung des Programms angepasst werden kann. Die wichtigsten sind folgende: | |
| * ''-n <Anzahl der Prozessoren>'' fordert die entsprechende Anzahl an Prozessoren für parallele Ausführung an (default ist 1) | |
| * ''-q <Name der Queue>'' schickt das Programm an die entsprechede Queue (default ist die Default-Queue) | |
| * ''-o <Name der Ausgabedatei>'' leitet die Ausgabe in die entsprechende Datei, wobei ein ''%J'' automatisch durch die vom LSF vergebene eindeutige Job-Id ersetzt wird (default ist Ausgabe per E-Mail an den Benutzer) | |
| |
| Der genaue Aufruf unterscheidet sich, je nachdem ob die Anwendung parallel ausgeführt werden soll oder nicht. | |
| |
| == Parallele Anwendungen == | |
| - (empfohlen) mit dem Wrapper mvapich und mpirun.lsf\\ Beispiel: ''bsub -a mvapich -n 8 mpirun.lsf ./myapp'' schickt das Programm "myapp" an die Default-Queue und fordert 8 Prozessoren für parallele Ausführung an. | |
| - ohne Wrapper mit expliziter Angabe der zu verwendenden Knoten über eine Datei (Hostfile / Machinefile)\\ Beispiel: ''bsub -q qquad -n 4 -machinefile machinefile -o cpip_%J.out mpirun ./cpip'' schickt das Programm "cpip" an die Queue "qquad" und fordert 4 Prozessoren für parallele Ausführung an. Die Ausgabe wird in die Datei ''cpip_<jobid>.out'' geschrieben.\\ Das Machinefile könnte z.B. wie folgt aussehen. Soll ein Knoten mehrfach verwendet werden, z.B. weil er mehrere Prozessoren / Kerne besitzt, dann muss er entsprechend oft in der Datei aufgeführt werden. Im Beispiel wird nur der Knoten "node167" genutzt, dafür aber vierfach. <file - machinefile> | |
| node167 | |
| node167 | |
| node167 | |
| node167 | |
| </file>\\ | |
| - Mit einem Jobskript, welches dynamisch ein Hostfile erzeugt.\\ Beispiel: ''bsub < myscript'' (das Umleitungszeichen "<" ist wichtig, ansonsten wird das Jobskript nicht korrekt geparst)\\ Das Jobskript "myscript" könnte dann wie folgt aussehen. In diesem Beispiel wird das Programm "cpip" an die Default-Queue geschickt und 32 Prozessoren für parallele Ausführung angefordert. Die Ausgabe wird in die Datei ''myjob_<jobid>.out'' geschrieben. Die Zeilen mit ''#BSUB'' am Anfang der Datei bzw. ''mpirun'' am Ende der Datei spezifizieren die Parameter, alles dazwischen kümmert sich um das Hostfile, das im home-Verzeichnis mit dem Namen ''.lsf_<jobid>_mpi.hosts'' erstellt wird und anschließend gelöscht werden kann. <file - myscript> | |
| #!/bin/sh | |
| #BSUB -n 32 | |
| #BSUB -o myjob_%J.out | |
| HOST_FILE=".lsf_${LSB_JOBID}_mpi.hosts" | |
| if [ -d "$HOME" ]; then | |
| HOST_FILE="$HOME/$HOST_FILE" | |
| fi | |
| HOST="" | |
| NUM_PROC="" | |
| FLAG="" | |
| TOTAL_CPUS=0 | |
| for TOKEN in $LSB_MCPU_HOSTS | |
| do | |
| if [ -z "$FLAG" ]; then | |
| HOST="$TOKEN" | |
| FLAG="0" | |
| else | |
| NUM_PROC="$TOKEN" | |
| TOTAL_CPUS=`expr $TOTAL_CPUS + $NUM_PROC` | |
| FLAG="1" | |
| fi | |
| if [ "$FLAG" = "1" ]; then | |
| _x=0 | |
| while [ $_x -lt $NUM_PROC ] | |
| do | |
| echo "$HOST" >> $HOST_FILE | |
| _x=`expr $_x + 1` | |
| done | |
| |
| # get ready for the next host | |
| FLAG="" | |
| HOST="" | |
| NUM_PROC="" | |
| fi | |
| done | |
| mpirun -n $TOTAL_CPUS -hostfile $HOST_FILE ./cpip | |
| </file> | |
| |
| == Nichtparallele Anwendungen == | |
| - direkt\\ Beispiel: ''bsub -o myjob_%J.out ./myprog'' schickt das Programm "myprog" an die Default-Queue. Die Ausgabe wird die Datei ''myjob_<jobid>.out'' geschrieben. | |
| - Mit einem Jobskript\\ Beispiel: ''bsub < myscript'' (Das Umleitungszeichen "<" ist wichtig, ansonsten wird das Jobskript nicht korrekt geparst.\\ Das Jobskript "myscript" könnte etwa so aussehen (mit denselben Parametern wie im Punkt zuvor): <file - myscript> | |
| #!/bin/sh | |
| #BSUB -o myjob_%J.out | |
| ./myprog | |
| </file> | |
| |
| === Verfolgen der Ausführung === | |
| |
| Die Ausführung des Jobs kann man unter anderem mit folgenden Befehlen verfolgen: | |
| |
| * ''bjobs'' zeigt den Status aller laufenden eigenen Programme an. Durch verschiedene Parameter können auch andere Jobs oder weitere Informationen angezeigt werden. | |
| * ''bhist -l nnn'' zeigt Informationen zum Job mit Id "nnn" an, der auch schon beendet sein kann. | |
| * ''bkill nnn'' beendet die Ausführung des (eigenen) Jobs mit Id "nnn". | |
| |
| === Weitere nützliche Befehle === | |
| |
| Die folgenden Befehle geben weitere Informationen über den Cluster, es gibt aber noch viele mehr. | |
| |
| * ''lsid'' zeigt allgemeine Informationen über den Cluster | |
| * ''lshosts'' / ''bhosts'' zeigt alle Hosts | |
| * ''bmgroup'' zeigt alle Hostgruppen | |
| * ''bqueues'' zeigt alle Queues | |
| |
| ==== Programme ausführen über eine grafische Oberfläche ==== | |
| |
| Wer die Kommandozeile vermeiden möchte, kann eine der folgenden Oberflächen für praktisch alle Aufgaben benutzen FIXME: | |
| * xsub | |
| * [[http://glic3:8083/Platform|Weboberfläche von LSF]] | |
| |
| ===== Programme auf dem Cluster debuggen ===== | |
| |
| Beim Debuggen von Programmen auf dem Cluster sind einige Punkte zu beachten: | |
| |
| * Das Programm muss es mit der Option ''-g'' compiliert werden. | |
| * Die Umgebungsvariable ''TOTALVIEW'' muss gesetzt sein und den Dateinamen inklusive Pfad von Totalview enthalten: ''/opt/totalview/bin/totalview''. | |
| * Das Programm darf (vorerst) nicht auf den normalen Knoten laufen, sondern nur lokal auf dem Rechner an dem man eingeloggt ist (''glic''). | |
| * ''mpirun'' muss mit speziellen Parametern gestartet werden um totalview einzubinden.\\ Beispiel: ''mpirun -tv -np 2 -machinefile ./local ./myapp'' startet das Programm myapp auf 2 Prozessoren über Totalview. In der Datei ''local'' sollte als Host nur ''glic'' vorkommen. Es öffnet sich nun ein Fenster von Totalview, in dem man weitere Parameter angeben kann. Dies ist aber nicht nötig, da die Parameter bereits auf der Kommandozeile spezifiziert wurden. Nach Klick auf "OK" kann man mit dem Debuggen des Programms beginnen. | |
| |
| ===== Weitere nützliche Links ===== | |
| |
| [[http://rz.gfz-potsdam.de/compute/PGI/common/doc/index.htm|PGI Users Guide]] | |
| |
| [[http://rz.gfz-potsdam.de/compute/MVAPICH/www/mpich.html|MPI Doc]] | |
| |
| [[http://rz.gfz-potsdam.de/compute/Totalview/index.html|TotalView Doc]] | |
| |
| |
