Beschreibung des Jobspooling Systems
Allgemeine Beschreibung für Anwender
Das Jobspooling System nimmt an einer zentralen Stelle Aufträge für Jobs an, die von dort aus an verschiedene leistungsstarke Rechner vermittelt werden. Dabei wird versucht, gewisse Fairness-Aspekte einzuhalten. Es bietet sich also an, rechenintensive und zeitunkritische Prozesse darüber abzuwickeln.
Aus Sicherheitsgründen können nur ausführbare Dateien in einem speziellen Verzeichnis gestartet werden, die keine weiteren Kommandozeilenparameter erhalten dürfen. Das soll verhindern, dass beliebige Befehle für andere Benutzer ausgeführt werden können. Das ist natürlich keine Einschränkung, da diese Startskripte ja beliebige Befehle enthalten können.
Existiert im Homeverzeichnis eine Datei .jspath, so gibt diese den Namen des Verzeichnisses an, in dem die Startskripte liegen müssen. Ansonsten werden sie im Homeverzeichnis erwartet. Ausgaben an stdout und stderr werden in die Datei ~/<jspath>/output-<jobname>-<hostname> geschrieben, wobei <jspath> den durch .jspath festgelegten Pfad angibt, <jobname> den Namen des auszuführenden Jobs, und <hostname> den Namen des Rechners, auf dem der Job bearbeitet wird/wurde.
Zur Interaktion mit dem Jobspooling-System wird der Client jsq.pl benutzt. Für Simulationen auf den Laborrechnern liegt dieser Client im Pfad /usr/Labor-IV/bin, für Simulationen auf unserem "Grid-Cluster" im Verzeichnis /home/lab/jobspool (NFS-mount labhome:/opt/export/home/labor.IV/atlas). Die einzelnen Rechenknoten dieses Clusters heißen übrigen atlas-0 bis atlas-9.
Ein Job wird eingequeued mit
> jsq.pl enqueue <jobname>
wobei <jobname> der Name der auszuführenden Datei ist und keine Slashes oder Leerzeichen enthalten darf. Mit
> jsq.pl list
erhält man eine Liste der eigenen Jobs, die gerade bearbeitet werden oder die noch gequeued sind.
Um Jobs zu löschen, kann man
> jsq.pl remove <regexp>
aufrufen; <regexp> ist eine Perl Regular Expression und gibt an, welche Jobs aus der Queue entfernt werden sollen. Alternativ kann man die entsprechenden Dateien oder deren X-bit löschen.
Zu beachten ist noch, dass das Arbeitsverzeichnis immer das Homeverzeichnis ist, auch wenn ein anderer <jspath> festgelegt wurde! Im Skript könnt ihr natürlich beliebig in andere Verzeichnisse wechseln.
Generell ist noch zu sagen, dass das System zwar versucht, die Ressourcen fair zu verteilen, gewisse Spielregeln aber vom Benutzer trotzdem beachtet werden sollten: Sollen viele Jobs mit vorraussichtlich extrem lange Bearbeitungszeiten eingequeuet werden, so ist es angebracht, dies versetzt zu tun (beispielsweise mit dem UNIX-Kommando at), damit die Wartezeit für später eingequeuete Jobs anderer Nutzer nicht allzu hoch ist.
Bei Unklarheiten helfe ich gerne weiter: Christian de Waal <dewaal@cs.uni-bonn.de>
Technische Details für neugierige Zeitgenossen
Im Verzeichnis /usr/Labor-IV/jobspool finden sich verschiedene Dateien:
jobspool.log
In dieser Datei wird sämtliche Kommunikation mit dem Server gesammelt. Insbesondere ist zu sehen, welche Benutzer welche Jobs eingequeued haben, welche Stationen diese Jobs bearbeiten und mit welchem Aufwand deren Bearbeitung verbunden war. Dieser Aufwand wird irrefürenderweise in einem time-Feld gemeldet, der dortige Wert wird aber gemessen in BogoBI, berechnet als Rechenzeit des Prozesses multipliziert mit den aus /etc/procinfo ausgelesenen BogoMIPS und einem Korrekturfaktor, der sich aus eigenen Beobachtungen des Verhältnisses von verbrauchter CPU-Zeit zu BogoMIPS ergibt und in /usr/Labor-IV/jobspool/bogo_correction festgehalten ist, geteilt durch 1000.
jobspool.usr
Hier wird für jeden Benutzer festgehalten, wieviele seiner Prozesse derzeit bearbeitet werden und wieviel BogoBI sich auf seinem Konto angesammelt haben. Für jeden abgeschlossen Job werden die aufgewendeten BogoBI auf das Konto des Benutzers aufaddiert, während sie zu gleichen Teilen von den Konten aller Nutzer subtrahiert wird (allerdings sind nur Werte größer 0 zulässig). Diese Werte werden verwendet, um zu bestimmen, welcher Benutzer den nächsten freien Rechner zugewiesen bekommt, und zwar ist das der Nutzer, für den der Wert <laufende Jobs> * <BogoBI pro Job> + <angesammelte BogoBI> am geringsten ist, wobei <BogoBI pro Job> durch die maximale Differenz der Kontostände der um den nächsten freien Rechner konkurrierender Nutzer geteilt durch 8,5 gegeben ist, mindestens aber 25,000 und höchstens 100,000 beträgt.
Der aufmerksame Leser merkt, dass es sich bei den BogoBIs also um eine Art Währung handelt, die zwischen den Nutzern ausgetauscht wird. Die Gesamtmenge der in sich in Umlauf befindenden BogoBIs beträgt 1,000,000.
jobspool.run
...
jobspool.queue
...