Dokumentation des HPC-Clusters im Rahmen des BMBF-Projekts Multi-EM.

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 Weboberfläche genutzt werden.

Der Cluster besteht momentan aus 202 Knoten mit verschiedensten Leistungsmerkmalen. Die Knoten 64 - 202 sind per Infiniband verbunden, Speicherplatz bietet das Panasas Parallel Storage System.

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.

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.

Die Ressourcen des Clusters werden von der Platform Load Sharing Facility (LSF) verwaltet. Programme laufen auf dem Cluster als Jobs und werden zur Ausführung in 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.

Im Normalfall ist die Umgebung nach dem Login für den PGI Compiler sowie parallele Anwendungen mit MPI eingestellt. Mit dem Befehl module kann die Umgebung geändert werden.

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

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.

1. (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.
2. 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.

   machinefile

   node167
   node167
   node167
   node167

   
   

3. 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.

   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

1. 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.
2. 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):

   myscript

   #!/bin/sh
   #BSUB -o myjob_%J.out
   ./myprog

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”.

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

Wer die Kommandozeile vermeiden möchte, kann eine der folgenden Oberflächen für praktisch alle Aufgaben benutzen :

• xsub
• Weboberfläche von LSF

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.

PGI Users Guide

MPI Doc

TotalView Doc