Direkt zum InhaltDirekt zur SucheDirekt zur Navigation
▼ Zielgruppen ▼

Humboldt-Universität zu Berlin - Computer- und Medienservice

SGE (Sun Grid Engine)



1. Charakteristik von SGE

SGE ist ein OpenSource Produkt der Firma SUN Microsystems (jetzt Oracle). Ein Standard SGE-System besteht aus einer Zelle, die von einem „master host“ verwaltet wird und die eine beliebige Anzahl von "execution hosts" enthält. Die Aufträge werden von den „submition hosts“ abgeschickt.

Bezogen auf das Compute-Cluster überwacht der Master-Server die Aktivitäten der Zelle, während die Rechenknoten die Ausführung der Jobs, die ihnen vom Master-Server zugeteilt werden, überwachen. Alle Aufträge müssen vom Master-Server abgeschickt werden. SGE unterstützt parallele Umgebungen (z.B. OpenMPI) und bietet die Möglichkeit, Jobs an andere Queueing-Systeme zu schicken. Ein Grafisches-User-Interface QMON ermöglicht die Kontrolle des Queueing-Systems. Das Abschicken der Jobs erfolgt gewöhnlich über ein Shell Script. Auf eine Beispielsammlung von Batch-Skripten kann jeder Nutzer über das Verzeichnis

/perm/skripte
zugreifen.

2. SGE-Zelle im Computer- und Medienservice

Alle Knoten des Compute-Clusters sind in der SGE-Zelle "clous" zusammengefasst. Der aktive Login-Server ist gleichzeitig Qmaster und Shadow master, der inaktive nur Shadow Master. Auf allen Knoten laufen die "execution" Dämonen, die die Ausführung der Jobs überwachen.

Die von SGE benötigten Dämonen werden beim Start der Server der Zelle gestartet. Die folgende Tabelle gibt eine Übersicht über die Dämonen auf den Servern der Zelle. Alle Dämonen sind während der gesamten Systemlaufzeit aktiv.

Dämon Funktion Hosts Hosts in CLOU4
qmaster Queue Master Dämon aktiver Master clou
shadowd Shadow Master beide Master clou1/clou2
execd Execution Dämon Knoten node1-32

Zur besseren Zuordnung von Hosts zu Queues (Warteschlangen) wurden die Hosts zu Gruppen zusammengefasst. Konfigurationskommandos:

qconf -sel           listet alle execution hosts
qconf -shgrpl        listet alle Hostgruppen
qconf -shgrp @par_h  listet die Hosts der Gruppe @par_h


3. Queuekonfiguration

Die SGE-Zelle "clous" hostet verschiedene Queues, um den unterschiedlichen Anforderungen der Nutzer gerecht zu werden. Es können parallele, serielle und interaktive Jobs in der Zelle laufen. Für parallele Rechnungen wurden sogenannte Parallele Environments (PE) definiert, die die Anzahl der Slots (zur Verfügung stehende Cores) festlegen. Ein Slot ist hier gleichzusetzen mit einem Prozessor-Core. Folgende PE's sind definiert:

smp       für Shared Memory Anwendungen (bleiben auf einem Knoten)
ompi      für OpenMPI/MPICH Anwendungen, die über mehrere Knoten rechnen

Diesen werden dann den parallelen Queues zugeordnet, siehe Tabelle.

Queue Hostgruppe Priorität Prozessoren PE Joblimit Runlimit Memorylimit
inter @serial_h +15 1 - 4 3 h 1 GB
short @serial_h +10 1 - 4 24 h 4 GB
long @serial_h -5 1 - 4 96 h 16 GB
par_test @test_h +5 8-32 ompi 3 48 h 40 GB
par @par_h 0 8-32 smp 28 7 t 40 GB

Für alle parallelen Programme sind die Queues par und par_test zu verwenden, da diese mehrere Prozessoren auf einem/mehreren Knoten zur Verfügung stellen. Serielle Rechnungen sind an die Queues short oder long abzuschicken. Interaktive Rechnungen sind in die Queue inter zu stellen.

Queue-Kommandos:

qconf -sql       listet alle Queue Namen
qconf -sq par    listet die Parameter der Queue "par"
qstat -f -q par  zeigt den Status der Queue "par" mit allen Instanzen

Folgende Zustände kann eine Queue Instanz haben:

  a/A = Alarm     hohes Load
  d   = Disabled  Queue nimmt keine Jobs an
  E/e = Error     Queue ist im Fehler Zustand

An eine "disabled" Queue können zwar Jobs abgeschickt werden, aber sie kommen nicht zur Abarbeitung. Sie warten in der Queue bis diese wieder in den Zustand "enabled" wechselt.
Nutzer einer Arbeitsgruppe werden auch unter SGE zu einer Gruppe zusammengefasst. Folgende Kommando

qconf -sul      listet die definierten Gruppen
qconf -su cms   listet die Accounts der Gruppe cms

geben weitere Informationen zu den Gruppen und Accounts. Ein zugelassenes Kennzeichen muss in einer dieser Gruppen auftauchen. Die Gruppe muss auch in der globalen Konfiguration eingetragen sein. Anderenfalls kann unter dem Account kein Job an die SGE-Zelle abgeschickt werden.

qconf -sconf | grep user_lists

Für das Abschicken an eine spezielle Queue ist der Konfigurationsparameter "user_lists" der Queue verantwortlich. Auch hier muss die Gruppe eingetragen sein.

qconf -sq par | grep user_lists


4. Abschicken von Jobs

Jobs, die an eine Queue abgeschickt werden sollen, können in ein Skript verpackt werden und müssen mit dem Kommando "qsub" abgeschickt werden. Jede Menge Beispielskripte findet man im Verzeichnis:

/perm/skripte/<subdir>

Alle Jobs, die nicht sofort abgearbeitet werden können, kommen in die Liste der wartenden Jobs (Pending-Liste). Ein Job muss auf die Abarbeitung warten, wenn die Anzahl der möglichen Slots für die Queue bereits erreícht ist oder wenn die Anzahl der Jobs, die ein Nutzer/Gruppe in der SGE-Zelle starten darf bereits erreicht sind.

qconf -sq short | grep slots    -> Anzahl Slots für die Queue
qconf -sconf |grep max_u_jobs   -> Anzahl Jobs für den User/Group

Die Queue, in die der Job gestellt werden soll, kann in der Kommandozeile oder im Skript angegeben werden. Die Angabe in der Kommandozeile überschreibt die des Skriptes.

Das Kommando "qstat" liefert dann Informationen zum Status des Jobs.

Der Nutzer erhält als Reaktion auf den Submit-Befehl die Antwort, dass der Auftrag akzeptiert wurde sowie die Nummer des Auftrages. Bei der Angabe einer falschen Queue wird der Auftrag nicht angenommen. Im Falle, dass die Ressourcen-Anforderungen nicht stimmen (z.B. -q short -l h_vmem=10000m), wird der Jobs zwar in die Pending Liste eingefügt, aber der Job startet nicht. Die Gründe bekommt man mit dem Kommando

qstat -j

angezeigt.



4.1. Serielle Jobs

Für serielle Jobs sind die Queues short und long eingerichtet. Um z.B. einen seriellen Gaussian 09 Job in die Queue short zu stellen, sollte man das Skript run_g09_ser ins eigene Arbeitsverzeichnis /work/$USER kopieren, die E-Mail Adresse und weitere Angaben aktualisieren und dann mit dem Kommando qsub abschicken.

cd /work/$USER
cp /perm/skripte/g09/run_g09_ser .
vi run_g09_ser
qsub run_g09_ser
qstat


4.2. Parallele Jobs

Jobs, die auf mehreren Prozessoren laufen sollen, sind in die parallelen Queues par und bigpar zu stellen. Ihnen sind dann die entsprechenden parallelen Environments zugeordnet. Jedes PE hat eine definierte Anzahl von Slots, die dann für alle Queues gesamt gilt. Der Queue par ist das PE "smp" zugeordnet, sie stellt bis zu 8 Slots (Cores) für einen Job zur Verfügung, insgesamt nicht mehr als definiert.

qconf -sp smp | grep ^slots
qconf -sp ompi | grep ^slots

Der Queue bigpar ist das PE ompi zugeordnet, da hier Jobs über einen Knoten hinweg mit Infiniband rechnen können. Zur einfacheren Zuordnung von Hosts wurden Hostgruppen definiert. Diese finden sich in der Zuordnung der Hosts zu den Queues wieder.

qconf -shgrpl
qconf -shgrp @par_h

Da MPICH und OpenMPI unterschiedlich die Hostfiles für den parallelen Lauf einlesen, sind entsprechende Beispiel-Skripte vorhanden. Für MPICH Beispiele, siehe Verzeichnis /parm/skripte/mpich und für OpenMPI siehe Verzeichnis /perm/skripte/ompi. Der eigentliche Programmaufruf erfolgt immer mit mpirun, wobei sich dahinter dann verschiedene Skripte verbergen, da unterschiedliche Module geladen werden.

Das folgende Beispiel

/perm/skripte/mpich/run_mpich_8_pgi

lädt die Compilerumgebung für den Portland Group Compiler in der Version 10.4 und ordnet dem C++ Compiler den pgcc zu. Beim Aufruf von mpicc wird dann der pgcc verwendet. Bei MPICH muss noch der mpd geladen werden, bevor eine Anwendung laufen kann. Es werden 8 Cores des PE smp angefordert, der Job bleibt auf einem Knoten. Nach Beendigung der parallelen Anwendung, müssen alle mpds wieder gestoppt werden mit dem Kommando mpdallexit.

Es kann auch eine variable Anzahl von Cores in der Form -pe smp 4,8 angegeben werden, so werden wenn möglich 8 Cores genommen, der Job laüft aber auch, wenn nur 4 Cores verfügbar sind.



5. Kontrolle der laufenden Jobs

Die Kontrolle der laufenden Jobs erfolgt mit den Kommandos

qstat             Informationen zu den eigenen Jobs
qstat -u \*       Informationen zu allen Jobs in der Zelle
qstat -j          Informationen zu wartenden Jobs

Der Modifikation eines wartenden Jobs dienen die Kommandos

qalter -q par <jobid>              ändert die Queue für den Job
qalter -l h_vmem=1000m  <jobid>    ändert die Memory Anforderung für Job
qalter -pe ompi 16 <jobid>         ändert das parallele Environment des Jobs

Zum Abbrechen oder Anhalten laufender oder wartender Jobs dienen die Kommandos

qdel <jobid>         bricht den Job ab
qmod -sj <jobid>     hält den Job an (suspendiert ihn)
qmod -rj <jobid>     fährt fort mit dem angehaltenen Job       

Alle genannten Kommandos können auch über das Grafische User Interface QMON ausgeführt werden.

qmon -display <remote_display:0>


6. SGE Dokumentationen