N1 Grid Engine (früher Sun Grid Engine)
N1 Grid Engine ist eine Software zum verteilten Rechnen in einem “Grid”, d.h. zum automatischen Verteilen einer Vielzahl von an einer Stelle initiierten Aufträge parallel auf beliebige Rechnern.
Dabei werden die Aufträge jeweils auf den Rechnern im Grid mit den meisten freien Ressourcen (Prozessor-Last, Speicher, ...) ausgeführt, so dass eine optimale Lastverteilung im Grid erreicht wird.
Konfiguration
Abzuarbeitende Aufträge wrden auf sogenannten Submit Hosts “abgeschickt”. Sie werden dann von der Grid Engine-Software an einen der verfügbaren Execution Hosts úbertragen und auf diesem bearbeitet.
Submit Host sind bei uns die Solaris-Server rzdspc5,
rzdspc6 und rzdspc8
und der Linux-Rechner rzblade4.
Es gibt diese Typen von Execution Hosts:
| Anzahl | Modell | Prozessoren | OS | Architektur |
|---|---|---|---|---|
| 3 | Solaris-Server | 4 | Solaris 10 | sol-sparc64 |
| 4 | Solaris-Workstations | 1-2 | Solaris 10 | sol-sparc64 |
| 7 | Linux-Compute-Server | 4 | SuSE Linux 10.0 | lx24-x86 |
| 6 | Linux-PCs | 1 | SuSE Linux 10.0 | lx24-x86 |
Bei Bedarf können vom FBI-RZ weitere Rechner hinzukonfiguriert werden.
Bereitstellung
Die Grid Engine-Software steht im Verzeichnis /local/sge/,
die ausführbaren Programme im Verzeichnis
/local/sge/bin/sol-sparc64 bzw.
/local/sge/bin/lx24-x86.
Wer mit der Grid Engine arbeiten will, sollte sich die Software mit diesem
Codeschnipsel in seiner Datei $HOME/.cshrc bereitstellen,
falls er die Login-Shell /bin/tcsh hat:
if ( -f /local/sge/default/common/settings.csh ) then
source /local/sge/default/common/settings.csh
endif
oder diesem Code in seiner Datei $HOME/.profile,
falls er die Login-Shell /bin/sh oder /bin/bash hat:
if [ -f /local/sge/default/common/settings.sh ]; then
. /local/sge/default/common/settings.sh
fi
Kommandos
Auftragsbearbeitung
qsub: Aufträge abschicken
Mit dem Kommando qsub werden Aufträge (“Batch-Jobs”)
initiiert. Die
auszuführenden Kommandos werden entweder von Standard-Eingabe eingegeben
oder aber stehen in einer Skript-Datei, die beim Aufruf als Argument
angegeben wird:
rzdspc6% qsub povr
your job 217 ("povr") has been submitted
Für jeden Auftrag werden zwei Ausgabedateien
jobname.ojobnummer
und
jobname.ejobnummer
erstellt, in die die Ausgabe (STDOUT) bzw. Fehlerausgabe (STDERR)
des Progammlaufs geschrieben wird.
rzdspc6% ls -o povr.* -rw-r--r-- 1 zierke 23 Apr 20 17:52 povr.e217 -rw-r--r-- 1 zierke 249 Apr 20 17:52 povr.o217
Parameter für qsub (qrsh, qsh)
Parameter für die Grid-Aufträge können in der Kommando-Zeile angegeben werden (hat Vorrang) oder als Schalter in die Skript-Datei eingebettet werden. Letzteres Vorgehen hat den Vorteil, dass ein Standard-Satz von Parametern immer wieder benutzt werden kann.
Das Grid-System setzt für jeden Auftrag eine Reihe von
Umgebungsvariablen, die innerhalb der Skript-Datei abgefragt werden
können (siehe Dokumentation). Über $ARC kann so z.B.
abgefragt werden, auf welcher Rechner-Architektur der Auftrag
läuft, um z.B. Pfade entsprechend zu setzen.
Nachfolgend werden die wichtigsten Schalter aufgelistet; eine vollständige Liste findet sich in der Dokumentation (User's Guide) oder den Manual-Seiten:
| Parameter | Beschreibung |
|---|---|
#$ |
Kennzeichnung für Schalter in der Skript-Datei |
#$ -o <Datei> |
Name der Ausgabedatei |
#$ -e <Datei> |
Name der Datei für das Fehler-Protokoll |
#$ -cwd |
wechselt in das Verzeichnis, aus dem der Auftrag abgeschickt wurde |
#$ -S <Shell> |
Auswahl der gewünschten Shell, z.B. /bin/bash) |
#$ -v <var1,var2, ...> |
Umgebungsvariable übergeben |
#$ -V |
alle Umgebungsvariable übergeben |
#$ -m <b|e|a> |
Mail verschicken bei Beginn, Ende oder Abbruch des Auftrags |
#$ -M <Mail-Adresse> |
Mail an diese Adresse schicken |
#$ -N <Auftrags-Name> |
Angabe des Auftrags-Namens (sonst Name der Skript-Datei) |
#$ -l <Ressource> |
Anforderung spezieller Ressourcen, z.B. verfügbarer Hauptspeicher (real oder virtuell), Rechner-Architektur und vieles mehr. Mit Vorsicht einsetzen! |
#$ -l arch=sol-sparc64 |
Der Auftrag soll unter Solaris laufen. |
#$ -l arch=lx24-x86 |
Der Auftrag soll unter Linux laufen. Dieser Schalter ist wichtig, wenn Software nicht auf beiden Plattformen zur Verfügung steht, oder Pfade speziell zu setzen sind (siehe auch Umgebungsvariable ARC) |
#$ -hold_jid <Job1,Job2,...> |
Angabe von Auftrags-Abhängigkeiten:
Das Grid-System vergibt für jeden angenommenen Rechenjob eine
eindeutige Auftrags-Nummer, die dem Auftraggeber mitgeteilt wird. Der
-hold_jid-Schalter bewirkt nun, dass das aktuelle Skript
erst gestartet wird, wenn alle Aufträge mit den angegebenen Nummern
beendet wurden. |
Beispiel für eine Auftrags-Datei
rzdspc6% cat povr #! /bin/bash -x # @(#) povr version 1.1 call the povray ray tracer # usage: povr sp-filename without extension [cache size] # # Grid Engine parameter #$ -S /bin/bash #$ -cwd #$ -l arch=lx24-x86 # FILE=$1 CACHE=$2 ulimit -t unlimited povray allscene.ini +I$FILE.pov +O$FILE.tga +W512 +H400 +Don +KFI0 +KFF$CACHE +K I0.0 +KF1.0 +KC +FS
Aufruf mit:
rzdspc6% qsub povr RayTracingSceneA 25
Your job 216 ("povr") has been submitted.
qstat: Auftrags-Status
Das Kommando qstat
zeigt die eigenen Aufträge im Grid-System an:
rzdspc6% qstat
job-ID prior name user state submit/start at queue slots
-----------------------------------------------------------------------------
217 0.555 povr zierke r 04/20/2005 17:50:48 all.q@rzdspc65 1
216 0.555 povr zierke qw 04/20/2005 17:49:04 1
In diesem Beispiel läuft Auftrag 217, während Auftrag 216 noch auf Bearbeitung wartet.
Mit weiteren Argumenten kann man sich noch mehr Informationen anzeigen;
z.B. mit qstat -f -pe auf welchen Rechnern gerade wieviele
Aufträge laufen:
rzdspc6% qstat -f -ne queuename qtype used/tot. load_avg arch states ---------------------------------------------------------------------------- all.q@rzblade4.informatik.uni- BIP 1/3 1.07 lx24-x86 ---------------------------------------------------------------------------- all.q@rzblade9.informatik.uni- BIP 1/3 1.02 lx24-x86 ---------------------------------------------------------------------------- all.q@rzpc85.informatik.uni-ha BIP 1/3 1.00 lx24-x86 ---------------------------------------------------------------------------- all.q@rzpc86.informatik.uni-ha BIP 1/3 1.99 lx24-x86
qdel: Auftrag löschen
Mit dem Kommando qdel kann man seine Aufträge aus der
Grid Engine löschen, sowohl laufende Aufträge als noch auf Bearbeitung
wartende Aufträge.
rzdspc6% qdel 217 zierke has registered the job 217 for deletion
qhost: Rechner-Status
Das Kommando qhost zeigt den Status der zum Grid gehörigen Rechner an:
rzdspc6% qhost HOSTNAME ARCH NCPU LOAD MEMTOT MEMUSE SWAPTO SWAPUS --------------------------------------------------------------------- global - - - - - - - rzblade10 lx24-x86 4 0.22 4.0G 1.5G 2.0G 96.0M rzblade4 lx24-x86 4 0.23 4.0G 188.1M 2.0G 0.0 rzblade5 lx24-x86 4 0.00 4.0G 179.7M 2.0G 8.0M rzblade6 lx24-x86 4 0.00 4.0G 164.6M 2.0G 8.8M rzblade7 lx24-x86 4 0.00 4.0G 167.6M 2.0G 8.8M rzblade8 lx24-x86 4 0.00 4.0G 183.4M 2.0G 8.1M rzblade9 lx24-x86 4 0.19 4.0G 184.2M 2.0G 0.0 rzdspc5 sol-sparc64 4 0.35 8.0G 6.7G 24.0G 33.0M rzdspc6 sol-sparc64 4 0.24 16.0G 5.0G 24.0G 0.0 rzdspc61 sol-sparc64 2 0.00 4.0G 930.0M 1.0G 0.0 rzdspc62 sol-sparc64 1 0.00 512.0M 215.0M 1.0G 27.0M rzdspc63 sol-sparc64 1 0.04 512.0M 280.0M 1.0G 52.0M rzdspc64 sol-sparc64 1 0.00 512.0M 252.0M 1.0G 0.0 rzdspc65 sol-sparc64 1 0.00 1.0G 302.0M 1.0G 0.0 rzdspc66 sol-sparc64 1 0.01 1.0G 307.0M 1.0G 0.0 rzdspc8 sol-sparc64 4 0.48 16.0G 4.1G 37.9G 0.0 rzpc37 lx24-x86 1 0.00 1003.2M 91.2M 1004.0M 0.0 rzpc39 lx24-x86 1 0.00 1003.2M 86.4M 1004.0M 0.0 rzpc45 - - - - - - - rzpc84 lx24-x86 1 0.00 1003.2M 88.5M 1004.0M 0.0 rzpc85 lx24-x86 1 0.00 1003.2M 86.5M 1004.0M 0.0 rzpc86 lx24-x86 1 0.00 1003.2M 88.5M 1004.0M 0.0
Die fehlende Load-Angabe bei rzpc45 zeigt, dass dieser
gerade nicht erreichbar ist (ausgeschaltet oder läuft unter Windows).
Interaktive Nutzung der Grid-Engine
Die nachfolgenden Befehle qrsh und qsh
ermöglichen die interaktive Nutzung des Grid, was insbesondere zu Testzwecken
und zur Kontrolle mehrerer abhängiger Auftráge nützlich ist.
Eine Besonderheit besteht dabei darin, dass diese Befehle nur
ausgeführt werden, wenn der Auftrag unmittelbar im Grid ausgeführt werden
kann (!). Eine -auch spätere- Ausführung kann durch den Parameter
-now no erzwungen werden.
Die meisten Optionen für qsub gelten auch für diese
Kommandos.
Die Befehle qrsh und qsh werden über
ssh-Verbindungen realisiert,
so dass eine gesicherte Kommunikation gewährleistet ist; hierzu
ist eine Authentifizierung erforderlich.
qrsh <Befehl>
Führt den angegebenen Befehl (oder ein Skript) im Grid aus. Dabei wird eine Terminalverbindung zum Submit-Host aufrecht erhalten, bis der Auftrag beendet ist. Die Standard-Ein-/Ausgabe erfolgt hier über das Terminal.
Wird qrsh ohne Parameter aufgerufen, wird lediglich eine
Terminal-Verbindung zu einem Grid-Rechner aufgebaut und es können
interaktiv Kommandos oder Skripte gestartet werden.
qsh
Mit dem Kommando qsh wird eine X-Terminal-Verbindung zu einem der Grid-Rechner aufgebaut und es können interaktiv Kommandos oder Skripte gestartet werden.
Hierzu ist erforderlich, dass die DISPLAY-Variable korrekt gesetzt ist und der eigene Bildschirm für X-Zugriff von fremden Rechnern freigegeben ist ("xhost +").
qmon
qmon ist ein interaktives Werkzeug zur Kontrolle der
Grid-Engine.
Es ermöglicht insbesondere das -etwas komfortablere- Starten von
Aufträgen mit Parametern und deren Kontrolle.
Tipps und Tricks
- Standard- Skript-Datei erstellen, im Grid austesten und als Vorlage für weitere Skripte nutzen.
- kein
sttyoder ähnliche Kommandos, die ein angeschlossenes Terminal voraussetzen. - Bei Nutzung von
rsh(oder X-Kommandos in Skript-Dateien) muss die DISPLAY-Variable korrekt gesetzt werden; Wird diese Variante häufiger benutzt, sollte die kontrollierende Workstation als Submit Host eingetragen werden. - Pfade sollten explizit gesetzt und/oder durch
Umgebungsvariable in der Skript-Datei gesetzt werden.
(
/bin/shwird nicht als Login-Shell aufgerufen und führt .profile und .bashrc nicht aus.) - Es gibt eine Reihe von Beispiel-Scripten (unter
/local/sge/examples/jobs), die für ausgefeiltere Grid-Skripte konsultiert werden sollten. Für einfache Anwendungen reicht das obige Beispiel als Vorlage aus.
