Allgemeine Informationen

CONDOR ist ein freies Batch-System, das an der University of Wisconsin-Madison entwickelt wurde. CONDOR wurde unter dem Leitsatz entwickelt, den Besitzer eines Computers nicht in seiner Arbeit zu stören.

Deshalb steht ein Computer CONDOR nur dann zur Verfügung, wenn der Computer frei ist, d.h. weder durch einen lokalen Job (z.B. Mathematica, Maple, etc.) benutzt wird, noch der Besitzer an der Tastatur arbeitet. Läuft gerade ein CONDOR-Job und beginnt der Benutzer an seinem Computer mit der Arbeit, so unterbricht CONDOR den Job (siehe weiter unten).

Es existieren derzeit zwei unabhängige CONDOR-Pools:

• "Desktop-Pool"
  In diesem Pool sind viele Desktop-Maschinen zusammengeschlossen. Die installierte CONDOR-Version ist 7.4.4. Der Master ist lxtsdb1.
• "P4-Pool"
  Dieser Pool besteht aus den verbleibenen Pentium-4-Maschinen, die früher den ersten Pentium-4-Cluster gebildet haben. Die Version ist ebenfalls 7.4.4, tatsächlich werden die selben Binaries verwendet, lediglich beim Master unterscheidet sich die Konfiguration. Der Master ist hier <tt>weiterhin lxtacl1</tt>.

Welche Rechner sind im Pool?

Auf dem jeweiligen Master, also lxtsdb1 oder lxtacl1, liefert das Programm 'condor_status', eine Liste der Rechner im Pool.

Programme interaktiv laufen lassen

Man kann von einem Rechner des Pools jedes Programm über CONDOR abschicken. Der einfachste Weg:

  condor_run Programm Parameter_1 Parameter_2 ... Parameter_n 

führt das angegebene Programm mit den angegeben Parametern aus. Als Startversuch kann man z.B. 'condor_run hostname' benutzen.

Programme im Hintergrund ausführen

Hat man mehrere Programme, die man über CONDOR laufen lassen will, so ist condor_run unpraktisch, da die Konsole erst wieder mit Beendigung des Programmes frei wird. In diesem Fall schreibt man eine bzw. mehrere Job-Dateien.

Job-Datei: programm.cmd

universe     = vanilla 
getenv       = true 
executable   = programm 
output       = /net/home/lxtsfs1/tp[a-e]/account/prog/programm.log 
error        = /net/home/lxtsfs1/tp[a-e]/account/prog/programm.log 
log          = /net/home/lxtsfs1/tp[a-e]/account/prog/programm.jlg 
initialdir   = /net/home/lxtsfs1/tp[a-e]/account/prog 
arguments    = 1 2 3 
notification = error queue 

Mit condor_submit programm.cmd (auf einem Rechner, der im Pool ist!) wird das Programm dann im Hintergrund über CONDOR auf einem freien Rechner ausgeführt. Texteingabe in das Programm ist nicht möglich, die Textausgabe und die Fehler landen hier in derselben Datei programm.log. In der Datei programm.jlg schreibt CONDOR, wann und wo der Job gestartet bzw. fertig worden ist. Das Arbeitsverzeichnis wird mit initialdir angegeben. Im Falle eines Fehlers erhält man eine e-mail. universe=vanilla bedeutet, dass der Job einfach angehalten wird, wenn der Benutzer des Computers, auf dem der Job läuft, zurückkehrt (siehe weiter unten).

Hat man einen Job abgeschickt, so kann man mit condor_q überprüfen, ob und wo er ausgeführt wird. Mit condor_rm Jobnummer kann man einen Job löschen.

Mit dem Programm condor_status erhält man Informationen über den Status des gesamten CONDOR-Pools. Eine grafische Darstellung der Auslastung des Pools ist derzeit nicht möglich.

Programme migrieren lassen

Wenn man nicht möchte, dass sein Programm z.B. durch Rückkehr des Benutzers an den Computer, auf dem das Programm ausgeführt wird, unterbrochen wird, so muss man noch einen Schritt weiter gehen.

Das Programm muss dann im Quelltext vorliegen und mit dem Programm condor_compile erzeugt werden. Das geht so:

Angenommen, das Programm wird normalerweise mit dem Kommando f77 hello.f -o hello erzeugt. Dann gibt man stattdessen ein: condor_compile f77 hello.f -o hello (d.h. man stellt den Befehl condor_compile einfach davor). Das geht auch mit anderen Compilern, z.B. cc, g++, gcc, g77, ...

Das so erzeugte Programm hello kann man wie sonst auch mit CONDOR abschicken. Anstelle dass das Programm angehalten wird, wird es jetzt auf einen anderen freien CONDOR-Rechner migrieren.

Dieses Verfahren funktioniert nur eingeschränkt. Grund ist, dass die Binärpakete von Condor nicht für SUSE verfügbar sind und SUSE auch nicht offiziell unterstützt wird. Wir müssen deswegen die die Binärpakete für RedHat einsetzen, die aber i.a. nicht mit den Compilern für SUSE kompatibel sind.

Bedingungen an Jobs stellen

Soll der Job nur auf bestimmten Rechnern laufen, so kann dies in dem obigen Job-Skript geschehen, indem vor der Zeile queue

requirements = (Machine != "lxtc448.physik.rwth-aachen.de" \ 
                && Machine != "lxta311.physik.rwth-aachen.de") rank = TARGET.Mips 

Die erste Anweisung wird strikt befolgt, d.h. der Job wird nie auf lxtc448 und lxta311 laufen. Die zweite Anweisung sorgt dafür, dass von allen übringen freien Maschinen die bevorzugt werden, die eine höhere Rechenleistung erbringen.

condor_compile unter SUSE

Die folgenden Bemerkungen beziehen sich auf früherer Versionen, da das Problem aber prinzipieller Natur ist, könnten sich hier auch Hinweise für aktuelle Problemlösungen finden!

Das CONDOR-System wird unter RedHat entwickelt. Deswegen kommt es bei neueren SuSE-Versionen zu Problemen beim Einsatz von condor_compile, das für das Standard-Universum von CONDOR benötigt wird (siehe "Programme migrieren lassen"). Für C- und FORTRAN-Programme wurde nun eine Lösung gefunden, sie funktioniert leider nicht für C++-Programme. Dazu übergibt man zusätzlich zu den bisher benutzten Compiler-Optionen noch

-Wl,--start-group -lc -lnss_files -lnss_dns -lresolv -Wl,--end-group

an den Compiler. Nun sollten sich die Programme kompilieren lassen und auch mit dem Checkpoiting-System laufen.

Update: Dies funktioniert leider nicht mit einer "Full Installation of condor_compile", wie in Abschnitt 3.10.3 des CONDOR-Manuals beschrieben. Das heißt, daß condor_compile make nicht funktioniert; man kann stattdessen das condor_compile in sein Makefile schreiben.
Update 2: Bei/Ab der Condor-Version 6.6.6 scheint es nun auch wieder ohne die oben genannten Tricks zu funktionieren.