Amazon.de Widgets
Skip to content
1.Februar 2011 / Patrick

Parallel Computing mit SGE, MPI und Oscar

closeDieser Beitrag wurde vor über 3 Monaten veröffentlicht. Die darin beschriebenen Informationen sind mit Vorsicht zu geniessen, da sie bereits veraltet oder nicht mehr gültig sein könnten. Solltest du von Neuerungen oder Verbesserungen wissen, so freue ich mich über einen klärenden Kommentar.

Wie bereits früher schon beschrieben habe ich mir aus ein paar Sun Fire Maschinen einen Cluster mittels dem Cluster Framework Oscar zusammengebastelt. Als Queueing-System habe ich dafür Sun Grid Engine (SGE) verwendet.

Leider hatte ich null Erfahrung damit und immer nur mit Single-Jobs zu arbeiten ist ja auch dämlich, wozu hat man denn einen Cluster ;)

Also habe ich mich ein bisschen schlau gemacht.
Damit parallel computing funktioniert, muss zuerst das parallel environment erstellt werden. Sonst bekommt man immer einen Fehler wie diesen:

1
2

Unable to run job: job rejected: the requested parallel environment "mpi" does not exist.
Exiting.

Oscar legt während der Installation automatisch ein Profil an. Dieses heisst da “make”, welches wir direkt so verwenden.

Für unseren Job erstellen wir nun eine Datei, welche danach das eigentliche Programm startet.
Dazu habe ich im Ordner /home, welcher ja bei allen Slaves gemountet ist, eine beliebige Datei openmpi-test mit folgendem Inhalt erstellt:

1
2
3
4
5
6
7
8
9
10
11

[root@lcc102 test1]# cat openmpi-test 
#!/bin/bash
#$ -N openmpi-test
# Here we tell the queue that we want the orte parallel enivironment and request 5 slots
# This option take the following form: -pe nameOfEnv min-Max
# Where you request a min and max number of slots
#$ -pe mpi 5-10
#$ -cwd
#$ -j y
mpirun -n $NSLOTS mpi-ring
exit 0

Darin werden nun weitere Parameter festgelegt. So mit -N der Name, -pe zuerst der Name (wie oben definiert) des parallel environment und das Minimum beziehungsweise Maximum der benötigten Slots. Dann noch mit -cwd, dass das aktuelle Verzeichnis (CurrentWorkDirectory) als Arbeitsverzeichnis verwendet werden soll und mit -j y dass Output und Error in eine Datei geschrieben werden.
Dann folgt die Applikation oder das Script das ausgeführt werden soll. In meinem Fall ein Testscript von MPI.

Nun muss noch das Programm, mpi-ring, vorbereitet werden. Dazu muss die Datei hier heruntergeladen und im /home abgelegt werden, worauf diese kompiliert wird:

1

[root@lcc102 test1]# mpicc mpi-ring.c -o mpi-ring

Bevor der Job nun aber übermittelt wird, musste ich noch einen anderen Fehler beheben!
So waren bei mir 2 von 3 Nodes im Error-Status, wahrscheindlich noch von der Installation her. Jedoch kann eine Queue im Error-Status keine Jobs aufnehmen, also müssen diese zuerst wieder freigegeben werden.
Entdeckt habe ich das ganze mehr oder weniger zufällig, als ich mir die Queues angesehen habe mit qstat -j:

1
2
3

[root@lcc102 common]# qstat -j
scheduling info:            queue instance "all.q@lcc103" dropped because it is temporarily not available
                            queue instance "all.q@lcc105" dropped because it is temporarily not available

qstat -f zeigte mir dann auch den Status:

1
2
3
4
5
6
7
8
9

[root@lcc102 common]# qstat -f
queuename                      qtype used/tot. load_avg arch          states
----------------------------------------------------------------------------
all.q@lcc103                   BIP   0/4       0.00     lx26-x86      E
----------------------------------------------------------------------------
all.q@lcc104                   BIP   1/4       1.00     lx26-x86      
     90 0.56000 my_script  root         r     01/25/2011 14:54:51     1        
----------------------------------------------------------------------------
all.q@lcc105                   BIP   0/4       0.00     lx26-x86      E

Das Zurücksetzen in den normalen Status ist aber halb so wild:

1

qmod -cq all.q

Bekommt man sowas, ist alles gut:

1
2
3

root@lcc102.ch.power.alstom.com changed state of "all.q@lcc103" (no error)
Queue instance "all.q@lcc104" is already in the specified state: no error
root@lcc102.ch.power.alstom.com changed state of "all.q@lcc105" (no error)

Auch qstat -j sollte nun wieder sauber sein:

1
2

[root@lcc102 common]# qstat -j
scheduling info:            There are no messages available

Klappt also auch das, sind wir bereit den ersten Job zu übermitteln.

Nun kann das Script mit qsub an die Queue übergeben werden:

1

qsub openmpi-test

Und mit qstat kann man seinem Job zusehen:

1

qstat

Dies kann in etwa so aussehen:

1
2
3

job-ID  prior   name	   user         state submit/start at     queue                          slots ja-task-ID
-----------------------------------------------------------------------------------------------------------------
    112 0.61000 openmpi-te root         r     01/29/2011 08:52:21 all.q@lcc103                      10

Oder wenn man wissen will, auf welchem Node was läuft nimmt man den folgenden Befehl:

1
2
3
4
5
6
7
8
9
10
11
12

[root@lcc102 test1]# qstat -u \* -f
queuename                      qtype used/tot. load_avg arch          states
----------------------------------------------------------------------------
all.q@lcc103                   BIP   4/4       0.00     lx26-x86      
    112 0.61000 openmpi-te root         r     01/29/2011 08:52:21     4        
----------------------------------------------------------------------------
all.q@lcc104                   BIP   4/4       1.00     lx26-x86      
     90 0.51000 my_script  root         r     01/25/2011 14:54:51     1        
    112 0.61000 openmpi-te root         r     01/29/2011 08:52:21     3        
----------------------------------------------------------------------------
all.q@lcc105                   BIP   3/4       0.02     lx26-x86      
    112 0.61000 openmpi-te root         r     01/29/2011 08:52:21     3

Und wenn ein Job mal nicht laufen will, so gibt es mit -j immer weitere Informationen:

1

qstat -j
Abgelegt unter Cluster