Das Condor-Batchsystem im Rahmen des Morfeus-Projektes
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Das Condor-Batchsystem im
Rahmen des Morfeus-Projektes
Eine kurze Einführung für Benutzer
Thomas Bauer
Universität Münster
IVV Naturwissenschaften
November 2004
http://www.condorproject.org
http://www.uni-muenster.de/IVVNWZ/Morfeus
http://www.uni-muenster.de/IVVNWZInhaltsverzeichnis
1 Einleitung 3
2 Benutzung von Condor 4
2.1 Voraussetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Anmeldung (condor store cred) . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Priorität abfragen (condor userprio) . . . . . . . . . . . . . . . . . . . . 5
2.4 Aktueller Status des Pools (condor status) . . . . . . . . . . . . . . . . . 5
2.5 Jobs abschicken (condor submit) . . . . . . . . . . . . . . . . . . . . . . . 6
2.6 Benötigte Ressourcen angeben (requirements) . . . . . . . . . . . . . . . 7
2.7 Abfrage der Queue (condor q) . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.8 Jobs aus der Queue löschen (condor rm) . . . . . . . . . . . . . . . . . . . 9
2.9 Warum startet mein Job nicht? . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Der Morfeus-Pool 11
3.1 Ressourcen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Laufzeiten von Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Verschiedenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1 Arbeitsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.2 Pfade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4 Beispiele 13
4.1 Ein einführendes Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Beispiel eines Massenjobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5 Links 17
6 Condor Public License 18
21 Einleitung
• Haben Sie ein Programm, das eine Berechnung durchführt, die möglicherweise einige
Stunden dauert?
• Eventuell wollen Sie dieses Programm auch noch mehrmals mit verschiedenen Pa-
rametern ausführen?
• Damit ist stundenlange Wartezeit vorprogrammiert!
• Gleichzeitig stehen fast überall Computer, die zeitweise nicht benutzt werden. Be-
sonders nachts geht somit wertvolle Rechenzeit verloren.
Es ist das Ziel des Projektes Morfeus1 diese ungenutzte Rechenleistung in der IVV
Naturwissenschaften für deren Mitglieder nutzbar zu machen. Besonders Benutzer von
Linux, MacOS, Tru64 UNIX (ALPHA OSF/1) und Windows sind angesprochen.
Das Batchsystem Condor (http://www.condorproject.org) ist ein intelligentes Queu-
eingsystem. Es ist für Umgebungen entwickelt, in denen Computer nicht 24 Stunden am
Tag benutzt werden. Condor eignet sich daher ideal für das Projekt Morfeus.
Die Funktionsweise sei an dieser Stelle kurz erläutert. Ein Computer agiert als Central-
Manager. Er verwaltet den Computer-Pool und entscheidet, wann und wo ein Job gestartet
wird. Wann ein Job gestartet wird, hängt davon ab, wie gut die Priorität des Benutzers
ist. Wo ein Job gestartet wird hängt davon ab, ob der Computer gerade vor Ort benutzt
wird. Sitzt beispielsweise ein Student im CIP-Pool am einem Computer, so wird auf die-
sem Computer kein Job gestartet.
Falls ein Benutzer sich auf einem Computer einloggt, auf dem gerade ein Job läuft, so
wird der Job sofort angehalten. Wird der Computer wieder frei, setzt Condor den Job
auf diesem Computer fort, und zwar an der Stelle, an der er unterbrochen wurde.
Falls der Computer, von dem aus Sie den Job losgeschickt haben, oder der Computer auf
dem der Job gerechnet wird, neugestartet wird, kann Condor den Job nicht anhalten
und später weiterrechnen. Stattdessen wird der Job abgebrochen und sofort in dem Pool
neu in die Queue gestellt.
Überlegen Sie sich also gut, wie lange ihre Jobs im Condor-Pool laufen sollen. Es gibt
zwar theoretisch unbegrenzte Rechenzeit, praktisch ist die Rechenzeit jedoch begrenzt, da
die Computer in NWZnet gelegentlich automatisch aufgrund von Updates neugestartet
werden müssen.
1
Morfeus steht für Multiple Orphaned Ressources for Educational Use
32 Benutzung von Condor
Dieses Kapitel soll die elementaren Funktionen des Condor-Systems erläutern. Auf die
speziellen Eigenschaften des Morfeus-Pools (das ist der Condor-Pool der IVV Natur-
wissenschaften) wird in Kapitel 3 eingegangen.
Für Condor gibt es keine graphische Benutzeroberfläche, daher müssen alle Befehle über
die Kommandozeile (Command-Prompt) eingegeben werden.
2.1 Voraussetzung
Zunächst benötigen Sie einen Computer, auf dem die Condor-Software installiert ist.
Falls Sie keinen solchen Computer zur Verfügung haben, können Sie den Terminalserver
NWZhome benutzen.
(http://www.uni-muenster.de/IVVNWZ/terminalserver-de.html)
Die Benutzung von Condor auf dem Terminalserver ist völlig identisch zu der Benutzung
auf einem Computer, auf dem Sie sich vor Ort einloggen. Beachten Sie jedoch unbedingt
Ihre requirements (Abschnitt 2.6), da auf dem Terminalserver Windows Server 2003
installiert ist.
2.2 Anmeldung (condor store cred)
Haben Sie sich für einen Computer2 entschieden, von dem Sie Ihre Jobs abschicken wollen,
so müssen Sie sich einmalig anmelden. Das machen Sie durch Ausführen des Befehls:
condor store cred add
Condor fordert Sie nun auf Ihr Passwort zu hinterlegen. Das Passwort muss identisch mit
ihrem NWZnet-Passwort sein. Nach dieser einmaligen Anmeldung können Sie Condor
nun vollständig benutzen.
Wichtig:
• Diese Anmeldung müssen Sie auf jedem Computer durchführen, von dem aus Sie
einen Job abschicken wollen.
• Falls Sie Ihr NWZnet-Passwort ändern, so müssen sie auch das Condor-Passwort
ändern. mitteilen. Führen Sie dazu
condor store cred delete
und danach wieder
condor store cred add
aus.
2
Die beschriebene Anmeldeprozedur muss nur für Windows-Rechner durchgeführt werden.
42.3 Priorität abfragen (condor userprio)
Um die Prioritäten der Benutzer des Pools abzufragen führen Sie
condor userprio -all -allusers
aus. Es ist zu beachten, dass ein höherer Zahlenwert der Priorität eine schlechtere Priorität
bedeutet. Die beste Priorität ist 0.5.
Die Jobs der Benutzer mit besseren Prioritäten werden vor den Jobs der Benutzer mit
schlechteren Prioritäten gestartet, wenn es einen Mangel an zur Verfügung stehenden
Computern gibt.
Wichtig: Diese Priorität ist nicht mit der Priorität zu verwechseln, die Sie für Ihre eigenen
Jobs einstellen (Abschnitt 2.7).
2.4 Aktueller Status des Pools (condor status)
Durch das Kommando
condor status
rufen Sie aktuelle Informationen über alle Mitglieder des Pools ab.
Name OpSys Arch State Activity Mem
PFT23.nwznet. WINNT50 INTEL Claimed Suspended 1024
PCTP04.nwznet WINNT50 INTEL Unclaimed Idle 512
PCTP06.nwznet WINNT50 INTEL Claimed Busy 512
PCPI05.nwznet WINNT50 INTEL Owner Idle 512
In dem Beispiel oben wurden die Spalten LoadAv und ActvtyTime aus Platzgründen weg-
gelassen.
Durch Name wird der Computername angegeben. Beachten Sie, dass der Name nach dem
13. Zeichen abgeschnitten wird.
OpSys gibt die Art des Betriebssystems an. WINNT50 steht in diesem Fall für Windows
2000. Arch gibt die Architektur des Prozessors an. Eine komplette Übersicht der im Mor-
feus-Pool z. Zt. unterstützten Betriebssysteme und Prozessorarchitekturen finden Sie in
Abschnitt 3.1.
Durch State wird die momentane Verfügbarkeit des Computers angezeigt. Steht State
auf Unclaimed, so bedeutet das, dass ein Job durch Condor auf dem Computer gest-
artet werden kann. Steht State auf Owner heißt das, dass der Computer gerade vor Ort
benutzt wird. Wenn State auf Claimed steht, bedeutet das, dass Condor einen Job auf
dem Computer gestartet hat.
Anhand von Activity lässt sich erkennen, ob der Prozessor gerade ausgelastet ist. Idle
bedeutet, dass der Prozessor gerade nicht beschäftigt wird. Steht Activity auf Busy
heißt das, dass ein Job durch Condor momentan auf dem Computer ausgeführt wird.
Suspended bedeutet, dass zwar ein Job auf dem Computer gestartet wurde, der Job aber
zurückgestellt ist, weil der Computer gerade vor Ort benutzt wird.
Die Größe des physikalischen Arbeitsspeichers lässt sich in der Spalte Mem erkennen.
5Um weitere Informationen über die Computer des Pools zu erhalten, führen Sie das Kom-
mando
condor status -server
aus. Sie erhalten nun unter anderem die Mips (Million Instructions Per Second) und die
KFlops (Kilo Floatingpoint Operations Per Seconds) für jeden Computer.
Name OpSys Arch Memory Disk Mips KFlops
PFT23.nwznet. WINNT50 INTEL 1024 1577756 2555 831774
PCTP04.nwznet WINNT50 INTEL 512 16071392 2665 826138
PCTP06.nwznet WINNT50 INTEL 512 15503396 2167 829924
PCPI05.nwznet WINNT50 INTEL 512 14984136 2623 831124
Bei den KFlops und Mips handelt es sich um ein Maß für die Leistungsfähigkeit der
Prozessoren. Ein höherer Zahlenwert entspricht einem leistungsstärkeren Prozessor.
2.5 Jobs abschicken (condor submit)
Um einen Job abschicken (submitten) zu können, müssen Sie zunächst eine Job Submission
File schreiben. In diese Datei kommen alle wichtigen Informationen, die Condor benötigt
um den Job ordnungsgemäß zu verarbeiten.
Erzeugen Sie mit einem Editor Ihrer Wahl eine Datei, in der mindestens die drei folgenden
Zeilen stehen:
universe = vanilla
executable = job.exe
queue
Die erste Zeile teilt Condor mit, in welcher Umgebung der Job bearbeitet werden soll.
Für alle Jobs muss derzeit3 universe = vanilla gewählt werden.
Mit executable teilen Sie Condor mit, welches Programm ausgeführt werden soll.
Durch queue wird der Job Submission File beendet. Alle auf diese Zeile folgenden Ein-
träge werden ignoriert!
Neben diesen Pflichteinträgen gibt es noch eine Fülle von weiteren nützlichen Einträgen,
von denen an dieser Stelle nur die wichtigsten aufgeführt werden sollen. Weiterführende
Informationsquellen sind in Kapitel 5 zu finden.
log = Logdatei.log In der angegebenen Datei werden nützliche Informationen über
den Programmverlauf angezeigt.
input = Eingabe.in Haben Sie ein Programm, das Eingabe per Tastatur erfordert, so
müssen Sie diese Eingabe schon vorher in einer input-Datei speichern.
output = Ausgabe.out In die angegebene Datei wird die gesamte Ausgabe, die norma-
lerweise auf den Bilschirm erscheinen würde abgespeichert.
3
Condor unterstützt noch weitere universes, im Morfeus-Pool wird derzeit aber nur das Vanilla-
Universe unterstützt.
6error = Fehlermeldungen.err In diese Datei werden alle Fehlermeldungen des Be-
triebssystems, die das Programms verursacht, abgespeichert.
transfer input files = Datei1,Datei2,Datei3 Falls das Programm zusätzliche Da-
teien benötigt, müssen diese hier aufgelistet werden.
requirements = An dieser Stelle können die benötigten Ressourcen festgelegt werden.
Legen Sie nichts fest, wird der Computer, von dem aus submittet wird als Refe-
renz genommen. Die genaue Benutzung dieses Eintrages entnehmen Sie bitte dem
Abschnitt 2.6.
Alle diese optionalen Einträge müssen vor queue stehen, sonst werden sie ignoriert!
Die Dateinamen und Endungen können frei gewählt werden.
Nachdem Sie Ihre Job Submission File angefertigt haben, können Sie den Job ab-
schicken. Das machen Sie mit dem Kommando
condor submit job.sub
Sobald der Job beendet ist, werden alle Ergebnisse wieder in das Verzeichnis zurückge-
schrieben, von wo aus der Job submittet wurde.
2.6 Benötigte Ressourcen angeben (requirements)
Es ist nicht zwingend nötig, Condor mitzuteilen, welche Ressourcen Sie genau benötigen.
Geben Sie nichts an, so nimmt Condor automatisch an, dass Ihr Job das Betriebssystem
und die Prozessorarchitektur4 benötigt, von dem aus Sie submitten.
Benutzer des Terminalservers NWZhome sollten beachten, dass auf diesem Windows
Server 2003 als Betriebssystem installiert ist. Wählen Sie bei den requiremnts also auf
jeden Fall ein Betriebssystem, da kein einziger Computer mit Windows Server 2003 zum
Ausführen eines Jobs bereit steht.
Falls Sie eine oder mehrere bestimmte Anforderungen an den Computer haben, der Ihren
Job ausführen soll, so müssen Sie das Condor in der Job Submission File mit dem
Eintrag requirements mitteilen. Jeder Computer hat bestimmte Attribute, die Sie mit
condor status -long Computername
abfragen können. Die meisten dieser Attribute werden Sie nicht interessieren, daher sind
in Tabelle 1 nur die wichtigsten aufgelistet
Tabelle 2 stellt die wichtigsten Vergleichsoperatoren zusammen. Mit diesen Operatoren
lassen sich Bedingungen (requirements) in der Job Submission File erstellen.
4
Ihr Programm wird natürlich nur unter dem Betriebssystem und der Prozessorarchitektur laufen, für
die es auch compiliert wurde
7Attribut Beschreibung Beispiel
ARCH Prozessorarchitektur (String) ”INTEL”
ARCH TYPE Prozessortyp (String) ”P4”
Name Name der Maschine (String) ”PFT23.nwznet.uni-muenster.de”
Disk Festplattenplatz in kB 3098618
Memory RAM in MB 512
OpSys Betriebssystem (String) ”WINNT50”
KFlops Kilo Floating Point Operations Per Second 960000
Mips Million Instructions Per Second 2300
Tabelle 1: Die wichtigsten Attribute der Computer. String bedeutet, dass der Wert in
Anführungsstriche(” ”) gesetzt werden muss. Siehe hierzu auch das Beispiel am Ende
dieses Abschnitts.
== Gleich < Kleiner als
|| Oder > Größer als
&& Und = Größer gleich
Tabelle 2: Vergleichsoperatoren
Beispiel:
Ich benötige Windows 2000 oder Windows XP und mindestens 500 MB RAM. In meiner
Job Submission File muss dann stehen:
requirements=(((OpSys==”WINNT50”)||(OpSys==”WINNT51”))&&(Memory>=500))
Beachten Sie unbedingt den Unterschied zwischen dem ”vergleichenden Gleich” (==) und
dem Gleichheitszeichen (=) zum Setzen der requirements!
82.7 Abfrage der Queue (condor q)
Durch das Kommando
condor q
wird die lokale Queue angezeigt. Das bedeutet, dass Sie nur Informationen über die Jobs
erhalten, die von dem Computer aus abgeschickt wurden, auf dem Sie das Kommando
aufrufen. Möchten Sie die Jobs im gesamten Condor-System einsehen, so müssen Sie
das Kommando
condor q -global
ausführen.
ID OWNER SUBMITTED RUN TIME ST PRI SIZE CMD
482.0 tombauer 7/8 09:51 0+03:32:25 I 0 57.3 phondos.exe
484.0 falter 7/8 10:55 0+02:28:59 R 0 104.5 strukfit.exe
ID ist die Job-ID, die Condor Ihrem Job zugewiesen hat. OWNER ist der Benutzer, der
den Job abgeschickt hat. Anhand von SUBMITTED erkennen Sie, wann der Job abgeschickt
wurde. RUN TIME gibt die Zeit an, die der Job bereits im Condor-Pool verweilt. Möchten
Sie hingegen die bisher verbrauchte CPU-Zeit sehen, so ist das Kommando
condor q -global -cpu
auszuführen.
Die Spalte ST gibt den momentanen Status des Jobs an. R bedeutet Running und heißt,
dass der Job läuft. I steht für Idle und bedeutet, dass der Job nicht ausgeführt wird. Es
kann verschiedene Gründe haben, warum der Job nicht aufgeführt wird. Um die Ursache
zu finden schauen Sie in Abschnitt 2.9.
Anhand von PRI lässt sich eine vom Benutzer eingestellte Priorität für den Job erkennen
(siehe offizielles Condor-Manual, Abschnitt 2.6.4). SIZE gibt die Größe des Jobs an.
Falls Sie abfragen möchten, auf welchen Computern die Jobs gerade ausgeführt werden,
so führen Sie aus:
condor q -global -run
2.8 Jobs aus der Queue löschen (condor rm)
Um einen Job aus der Queue zu löschen führen Sie aus:
condor rm ID
ID ist dabei die entsprechende Job-ID, die Sie mit condor q (Abschnitt 2.7) abfragen. Es
können natürlich nur die eigenen Jobs aus der Queue gelöscht werden!
92.9 Warum startet mein Job nicht?
Nachdem Sie Ihren Job abgeschickt haben, sollten Sie einige Sekunden warten und dann
mit condor q nachschauen, ob in der Spalte ST ein R für Running steht.
Steht dort hingegen ein I bedeutet das, dass der Job momentan im Idle-Status ist. Um
nachzuschauen, warum er nicht startet, sollten Sie dann zuerst ein
condor q -analyze
ausführen.
Durch diesen Befehl erhalten Sie eine Liste der folgenden Form
12 are rejected by your job’s requirements
10 reject your job because of their own requirements
5 match, but are serving users with a better priority in the pool
0 match, match, but reject the job for unknown reasons
7 match, but will not currently preempt their existing job
4 are available to run your job
Die meisten dieser Zeilen sind selbsterklärend. An dieser Stelle soll jedoch auf drei Punkte
hingewiesen werden.
• Wenn in der letzten Zeile steht, dass Maschinen bereit stehen den Job zu starten,
heißt das, dass Sie sich nur noch einige Sekunden (manchmal Minuten) gedulden
müssen bis Condor den Job startet.
• Steht hingegen in der 4. Zeile eine von Null verschiedene Zahl, so bedeutet das, dass
Condor nicht weiß, warum der Job nicht gestartet wird. In diesem Fall müssen Sie
Ihr Programm und gegebenfalls Ihren Job Submission File überprüfen.
Eine Fehlerursache kann sein, dass Sie Ihr Passwort geändert haben und diese Ände-
rung Condor nicht mitgeteilt haben. Näheres finden Sie in Abschnitt 2.2.
• Es kann auch passieren, dass Sie in Ihren requirements Anforderungen gestellt
haben, die im ganzen Pool nicht verfügbar sind. In diesem Fall steht unter der
Tabelle noch der Eintrag:
WARNING: Be advised:
No resources matched request’s constraints
Check the Requirements expression below:
Der Job wird also niemals starten. Löschen Sie den Job aus der Queue (Abschnitt
2.8) und überprüfen Sie Ihre requirements. Starten Sie ihren Job dann erneut
(Abschnitt 2.5).
103 Der Morfeus-Pool
Dieses Kapitel beschäftigt sich mit den speziellen Eigenschaften des Morfeus-Pools.
3.1 Ressourcen
Im Morfeus-Pool sind größtenteils Computer aus den CIP-Pools der Biologie, Chemie
und Physik vertreten. Diese CIP-Computer erfüllen zwei Aufgaben. Zum einen können
die Benutzer von diesen Computern aus Jobs abschicken und zum anderen werden diese
Computer als Rechenknoten benutzt, solange niemand an dem Computer sitzt.
Aufgrund der Vielfältigkeit von Betriebssystemen und Prozessorarchitekturen in der IVV
Naturwissenschaften sind auch in dem Morfeus-Pool viele Varianten (siehe Tabelle 3)
vertreten.
Betriebssysteme Prozessorarchitekturen
MacOS X ”OSX” Macintosh ”PPC”
Tru64 Unix ”OSF1” Alpha ”ALPHA”
Windows 2000 ”WINNT50” Intel ”INTEL”
Windows XP ”WINNT51”
Windows 2003 ”WINNT52”
Tabelle 3: Ressourcen im Morfeus-Pool
Die aktuelle Mitgliederliste des Morfeus-Pools ist recht dynamisch, da mit der Zeit im-
mer mehr Computer in den Pool aufgenommen werden. Daher kann an dieser Stelle keine
Aufzählung der verfügbaren Ressourcen angegeben werden. Informieren Sie sich also im-
mer vor der Benutzung von Morfeus über den aktuellen Status des Pools (Abschnitt
2.4), ob die für Sie benötigten Ressourcen vorhanden sind.
Falls Ihr Programm beispielsweise unter Linux kompiliert wurde, kann es nicht auf ei-
nem Windows-Knoten gerechnet werden. Es ist aber sehr wohl möglich, diesen Job von
einem Windows-Rechner aus an einen Linux-Knoten abzuschicken. Beachten Sie jedoch
unbedingt die korrekte Einstellung der requirements (Abschnitt 2.6).
3.2 Laufzeiten von Jobs
Es gibt keine generelle Begrenzung von Laufzeiten. Um zu verhindern, dass einige Benut-
zer mit einer Vielzahl von Langläufern den Pool für andere Benutzer unbenutzbar machen,
wurde jedoch ein Mechanismus eingebaut, der Jobs unterbrechen kann. Falls die Priorität
(siehe Abschnitt 2.3) eines Benutzers mit einem Job, der momentan von Condor auf ei-
nem Knoten gerechnet wird, um eine Größenordnung schlechter ist als die Priorität eines
Benutzers, der einen Job neu in die Queue schickt, so wird der Job des Benutzers mit
der schlechteren Priorität gestoppt und erst wieder neu gestartet, sobald wieder genug
Ressourcen zur Verfügung stehen.
Eine weitere Begrenzung der Laufzeit sind gelegentliche Neustarts der Computer. Die-
se Neustarts können z.B. durch automatisch eingespielte Patches hervorgerufen werden.
Findet so ein Neustart auf einem Computer statt, von dem aus ein Job submittet wurde
11oder auf dem momentan ein Job gerechnet wird, so muss Condor den Job abbrechen
und startet ihn sofort auf einem anderen Knoten neu, falls die passenden Ressourcen zur
Verfügung stehen.
3.3 Verschiedenes
3.3.1 Arbeitsverzeichnis
Das Arbeitsverzeichnis hat mehrere Funktionen. Zum einen lagern Sie dort Ihre Job
Submission File und zum anderen schreibt Condor alle Ergebnisdateien, log-Dateien,
Output-Dateien, usw. in genau dieses Verzeichnis zurück, sobald der Job beendet wurde.
Beachten Sie, dass Condor ALLE Dateien wieder zurückschreibt. Haben Sie beispiels-
weise während ihr Job von Condor bearbeitet wurde eine Ihrer Input-Dateien in dem
Arbeitsverzeichnis editiert, so wird Condor diese Datei nach Beendigung des Jobs über-
schreiben. Die Job Submission File ist davon nicht betroffen.
Bei der Wahl Ihres Arbeitsverzeichnisses haben Sie fast freie Wahl. Sie können entweder
ein lokales oder ein Netzlaufwerk wählen.
Aufgrund einer speziellen Konfiguration in NWZnet ist es jedoch nicht möglich, das
Homeverzeichnis (I:-Laufwerk) für diesen Zweck zu benutzen. Ferner sollten Sie sich
überlegen, ob Sie ein lokales Laufwerk als Arbeitsverzeichnis benutzen wollen, wenn Sie
keinen eigenen Arbeitsplatzrechner besitzen. Da Condor die Ergebnisse wieder in das
lokale Verzeichnis zurückschreibt, müssen Sie sich genau an diesen Computer begeben,
um Ihre Ergebnisse abzuholen.
3.3.2 Pfade
Sind in Ihrem Programm Pfadangaben gemacht worden, so müssen Sie diese entfernen.
Öffnet Ihr Programm beispielsweise eine Datei Q:\PROGRAMS\CALC\PARAMETER.DAT so ist
der komplette Pfad Q:\PROGRAMS\CALC\ aus dem Programmcode zu entfernen. Beach-
ten Sie aber, dass diese Datei in Ihrer Job Submission File als mit zu transferieren-
de Datei mit angegeben wird (Abschnitt 2.6). In diesem Beispiel muss also die Zeile
transfer input files = Q:\PROGRAMS\CALC\PARAMETER.DAT in Ihrer Job Submission
File stehen.
Legt Ihr Programm Unterverzeichnisse an, so wird Condor Ihren Job nicht verarbei-
ten können. Wenn Sie Condor benutzen möchten müssen Sie dieses Feature aus Ihrem
Programmcode streichen.
124 Beispiele
4.1 Ein einführendes Beispiel
Das Programm
ef no.exe
läuft unter Windows 2000 und benötigt zum Starten mehrere Dateien, und zwar
ioef.dat, lco 31b.EFI, LCO 31B.SKP, LCO 31B.STK.
Als Output produziert das Programm die Datei
lco 31B.ef.
Da das Programm eine etwas längere Laufzeit, hat macht es Sinn dieses Programm nicht
lokal laufen zu lassen, sondern auf dem Condor-Pool.
Zuerst müssen Sie sich an einen Computer begeben, auf dem die Condor-Software in-
stalliert ist. Haben Sie keinen solchen Computer zur Verfügung, können sie sich auch auf
den Terminalserver NWZhome einloggen.
Nach dem Einloggen öffnen Sie sich einen Command-Prompt, per
Start→Accessiores→Command Prompt.
Nun erstellen Sie sich am besten zuerst ein Arbeitsverzeichnis. In diesem Fall soll es auf
dem Laufwerk Z: das Unterverzeichnis lauf1 sein. Dazu tippen Sie in das Command
Prompt (und bestätigen mit Enter):
C:\> Z:
Z:\> md lauf1
Z:\> cd lauf1
Als nächstes muss die Job Submission File geschrieben werden (siehe auch Abschnitt
2.5). Sie soll in diesem Fall ef no.sub heißen. Dazu tippen Sie in die Kommandozeilen-
eingabe ein:
Z:\lauf1> edit ef no.sub
Es öffnet sich der Microsoft DOS Editor.
Wie in Abschnitt 2.5 beschrieben, müssen Sie nun nun einige Informationen angeben, die
den Job betreffen. In diesem Fall beinhaltet die Datei:
universe=vanilla
executable=ef no.EXE
transfer input files=ioef.dat, lco 31b.EFI, LCO 31B.SKP, LCO 31B.STK
requirements=(OpSys==”WINNT50”)&&(Mips > 2000)
output=ef.out
log=ef.log
error=ef.err
queue
Bei den requirements wurde also lediglich verlangt, dass der auszuführende Knoten das
Betriebssystem Windows 2000 und der Prozessor mindestens 2000 Mips hat.
Um den Job starten zu können, müssen zuvor noch alle Dateien in das Verzeichnis
13Z:\lauf1> hineinkopiert werden. Dieses Kopieren können Sie sich auch ersparen, indem
Sie in der zweiten und dritten Zeile den Dateien den vollen Pfad voran schreiben.
Haben Sie sich nicht schon vorher auf dem Computer, an dem Sie gerade sitzen, bei Con-
dor angemeldet, so müssen Sie dieses nun tun:
Z:\lauf1> condor store cred add
Account: tombauer@NWZNET
Enter password:
Confirm password:
Password has been stored.
Der Job kann dann gestartet werden. Das geschieht mit dem Befehl:
Z:\lauf1> condor submit ef no.sub
Submitting job(s).
Logging submit event(s).
1 job(s) submitted to cluster 87.
Der Job ist nun gestartet. Als nächstes sollten Sie per
Z:\lauf1> condor q
ID OWNER SUBMITTED RUN TIME ST PRI SIZE CMD
87.0 tombauer 7/8 09:51 0+03:32:25 R 0 0.9 ef no.exe
1 jobs; 0 idle, 1 running, 0 held
schauen, ob der Job auch wirklich läuft und nicht im Idle-Status hängt. Da in der Spalte
ST ein R steht läuft der Job, das heißt aber nicht, dass dieser Job auch wirklich gerade
gerechnet wird. Es könnte beispielsweise sein, dass sich einige Sekunden nach dem Sub-
mitten ein Benutzer an den Computer gesetzt hat, auf dem der Job gerade ausgeführt
wird. Um das zu überprüfen wird zuerst nachgeschaut, auf welchem Knoten der Job ge-
rade gerechnet wird:
Z:\lauf1> condor q -run
ID OWNER SUBMITTED RUN TIME HOST(S)
87.0 tombauer 7/8 09:51 0+03:32:25 PCFT04.NWZNET.UNI-MUENSTER.DE
Der Job läuft also gerade auf dem Rechner PCFT04.NWZNET.UNI-MUENSTER.DE.
14Um den Status dieses Rechners zu überprüfen führen Sie aus:
Z:\lauf1> condor status PCFT04
Name OpSys Arch State Activity Mem
PCFT04.nwznet WINNT50 INTEL Claimed Busy 512
Da bei Activity Busy steht, wird der Job gerade wirklich bearbeitet.
Nachdem der Job fertig bearbeitet wurde, wird die Ergebnisdatei in das Verzeichnis
Z:\lauf1 zurückkopiert.
Da es bei diesem Lauf keine Probleme gab ist die Datei ef.err leer. Die Output-Datei
ef.out enthält die Standard-Bildschirmausgabe des Programms ef no.exe. Die Log-
Datei ef.log enthält Informationen über den Verlauf des Jobs, z.B. wann er gestartet
wurde, wann er beendet wurde und wann er angehalten bzw. fortgesetzt wurde.
154.2 Beispiel eines Massenjobs
Es kommt vor, dass Sie ein Programm haben, welches mit mehreren, verschiedenen Pa-
rametersätzen gestartet werden soll. Natürlich könnten Sie jeden Job einzeln mit dem
entsprechenden Parametersatz starten, jedoch gibt es eine elegantere Lösung.
In diesem Beispiel wird ein Programm bench.exe betrachtet, das über die Tastaturein-
gabe einen Zahlenwert fordert und das Ergebnis auf den Bildschirm ausgibt. Dieses Pro-
gramm soll für die drei Zahlenwerte 10.000, 100.000 und 1.000.000 auf dem Condor-Pool
gerechnet werden. Nachdem ein Arbeitsverzeichnis angelegt und die bench.exe hinein-
kopiert wurde, muss wieder eine Job Submission File, in diesem Fall bench.sub, ge-
schrieben werden. Der Inhalt dieser Datei lautet:
universe=vanilla
executable=bench.exe
requirements=(OpSys==”WINNT50”)&&(Mips > 2000)
input=bench.in$(PROCESS)
output=bench.out$(PROCESS)
log=bench.log
error=bench.err
queue 3
Die letzte Zeile gibt an, dass das Programm dreimal gestartet werden sollen. Wenn Sie
diesen Job also einmal submitten, wird die Auszuführende bench.exe auf drei verschiede-
nen Computern gestartet, allerdings mit drei verschiedenen Input-Dateien. Der besondere
Trick bei dieser Job Submission File ist das Makro $(PROCESS). Es gibt an, um den
wievielten dieser drei Jobs es sich handelt. Für den ersten Job ist $(PROCESS)=0, für
den zweiten $(PROCESS)=1 und für den dritten $(PROCESS)=2. Es müssen also vor dem
Abschicken des Jobs die drei Input-Dateien bench.in0, bench.in1 und bench.in2 er-
stellt werden. Die Datei bench.in0 muss lediglich die Zahl 10000 enthalten, die Datei
bench.in1 den Wert 100000 und die Datei bench.in2 die Zahl 1000000.
Das Abschicken dieses Job erfolgt wie gewohnt über den Befehl:
Z:\bench> condor submit bench.sub
Es werden nun die drei Jobs mit den drei verschiedenen Input-Dateien auf drei verschie-
dene Rechner geschickt. Sobald einer dieser Jobs fertig gerechnet wurde, werden wieder
alle Ergebnisdateien, in diesem Fall bench.out0, bench.out1 und bench.out2 in das
Verzeichnis Z:\bench> zurückgeschrieben.
165 Links
Zum Schluss dieser Dokumentation sei noch auf weiterführende Informationsquellen ver-
wiesen.
Offizielle Homepage des Morfeus-Projektes
http://www.uni-muenster.de/IVVNWZ/Morfeus/
Offizielle Homepage des NWZhome-Terminalservers
http://www.uni-muenster.de/IVVNWZ/Terminalserver-de.html/
Offizielle Homepage des Condor-Batchsystems:
http://www.cs.wisc.edu/condor/
Beiträge der Condor-Mailinglist:
http://lists.cs.wisc.edu/archive/condor-users/
Offizielles Manual zu Condor
http://www.cs.wisc.edu/condor/manual/
176 Condor Public License
Version 1.1, October 30, 2003
Copyright
c 1990-2003 Condor Team, Computer Sciences Department, University of Wisconsin-Madison,
Madison, WI. All Rights Reserved. For more information contact: Condor Team, Attention: Professor
Miron Livny, Dept of Computer Sciences, 1210 W. Dayton St., Madison, WI 53706-1685, (608) 262-0856
or miron@cs.wisc.edu.
This software referred to as the Condorr Version 6.x software (”Software”) was developed by the Con-
dor Project, Condor Team, Computer Sciences Department, University of Wisconsin-Madison, under the
authority of the Board of Regents of the University of Wisconsin System and includes voluntary contri-
butions made to the Condor Project (”Copyright Holders and Contributors and the University”). For
more information on the Condor Project, please see http://www.condorproject.org/.
Installation, use, reproduction, display, modification and redistribution of this Software, with or without
modification, in source and binary forms, are permitted. Any exercise of rights under this license including
sublicenses by you is subject to the following conditions:
1. Redistributions of this Software, with or without modification, must reproduce this Condor Public
License in: (1) the Software, and (2) any user documentation or other similar material which is
provided with the Software.
2. Any user documentation included with a redistribution must include the following notice:
“This product includes software from the Condorr Project
(http://www.condorproject.org/)” Alternatively, if that is where third-party acknowledgments
normally appear, this acknowledgment must be reproduced in the Software itself.
3. Any academic report, publication, or other academic disclosure of results obtained
with this Software will acknowledge this Software’s use by an appropriate citation.
4. The name Condor r is a registered trademark of the University of Wisconsin-Madison. The trade-
mark may not be used to endorse or promote software, or products derived therefrom, and, other
than as required by section 2 and 3 above, it may not be affixed to modified redistributions of this
Software without the prior written approval, obtainable via email to condor-admin@cs.wisc.edu.
5. To the extent that patent claims licensable by the University of Wisconsin-Madison are necessarily
infringed by the use or sale of the Software, you are granted a non-exclusive, worldwide, royalty-
free perpetual license under such patent claims, with the rights for you to make, use, sell, offer to
sell, import and otherwise transfer the Software in source code and object code form and derivative
works. This patent license shall apply to the combination of the Software with other software if,
at the time the Software is added by you, such addition of the Software causes such combination
to be covered by such patent claims. This patent license shall not apply to any other combinations
which include the Software. No hardware per se is licensed hereunder.
If you or any subsequent sub-licensee (a ”Recipient”) institutes patent litigation against any entity
(including a cross-claim or counterclaim in a lawsuit) alleging that the Software infringes such
Recipient’s patent(s), then such Recipient’s rights granted (directly or indirectly) under the patent
license above shall terminate as of the date such litigation is filed. All sublicenses to the Software
which have been properly granted prior to termination shall survive any termination of said patent
license, if not otherwise terminated pursuant to this section.
6. DISCLAIMER
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
AND THE UNIVERSITY ”AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, IN-
CLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILI-
TY, OF SATISFACTORY QUALITY, AND FITNESS FOR A PARTICULAR PURPOSE OR
USE ARE DISCLAIMED. THE COPYRIGHT HOLDERS AND CONTRIBUTORS AND THE
UNIVERSITY MAKE NO REPRESENTATION THAT THE SOFTWARE, MODIFICATIONS,
18ENHANCEMENTS OR DERIVATIVE WORKS THEREOF, WILL NOT INFRINGE ANY PA-
TENT, COPYRIGHT, TRADEMARK, TRADE SECRET OR OTHER PROPRIETARY RIGHT.
7. LIMITATION OF LIABILITY
THE COPYRIGHT HOLDERS AND CONTRIBUTORS AND ANY OTHER OFFICER, AGENT,
OR EMPLOYEE OF THE UNIVERSITY SHALL HAVE NO LIABILITY TO LICENSEE OR
OTHER PERSONS FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL,
EXEMPLARY, OR PUNITIVE DAMAGES OF ANY CHARACTER INCLUDING, WITHOUT
LIMITATION, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, LOSS OF USE,
DATA OR PROFITS, OR BUSINESS INTERRUPTION, HOWEVER CAUSED AND ON ANY
THEORY OF CONTRACT, WARRANTY, TORT (INCLUDING NEGLIGENCE), PRODUCT
LIABILITY OR OTHERWISE, ARISING IN ANY WAY OUT OF THE USE OF THIS SOFT-
WARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
8. Certain uses and transfers of the Software or documentation, and/or items or software incorpo-
rating the Condor Software or documentation, may require a license under U.S. Export Control
laws. Licensee represents and warrants that all uses and transfers of the Condor Software or do-
cumentation and/or any items or software incorporating Condor shall be in compliance with U.S.
Export Control laws, and Licensee further understands that failure to comply with such export
control laws may result in criminal liability to Licensee under U.S. laws.
9. The Condor Team may publish revised and/or new versions of this Condor Public License (”this
License”) from time to time. Each version will be given a distinguishing version number. Once
Software has been published under a particular version of this License, you may always continue
to use it under the terms of that version. You may also choose to use such Software under the
terms of any subsequent version of this License published by the Condor Team. No one other than
the Condor Team has the right to modify the terms of this License.
For more information:
Condor Team
Attention: Professor Miron Livny
7367 Computer Sciences
1210 W. Dayton St.
Madison, WI 53706-1685
miron@cs.wisc.edu
http://www.cs.wisc.edu/ miron/miron.html
NOTICES
• This product includes software developed by and/or derived from the Globus Project
(http://www.globus.org/) to which the U.S. Government retains certain rights. Copyright (c) 1999
University of Chicago and The University of Southern California. All Rights Reserved.
• Some distributions of Condor include a compiled, unmodified version of the GNU C library. The
complete source code to GNU glibc can be found at http://www.gnu.org/software/libc/.
19Sie können auch lesen
