Dokumentation zum Masterprojekt

Hochschule für Technik, Wirtschaft und Kultur Leipzig
Fakultät Informatik, Mathematik und Naturwissenschaften
Dokumentation zum Masterprojekt
Erweiterung einer bestehenden Sun Grid Engine um ein Cluster of Workstations
Betreuer: Prof. Dr.-Ing. Axel Schneider
B. Sc. Michael Schmidt
Matrikelnr.: 52676
15. Januar 2011
Inhaltsverzeichnis
1 Einleitung
1.1 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Theorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Arbeitsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
2
2
2 Umsetzung
2.1 Idee Cluster of Workstations . . . . . . . . . . . . . . . . . . . . .
2.2 Cluster of Workstations mit cron . . . . . . . . . . . . . . . . . . .
2.3 Implementierung des Sun Grid Engine Kalenders mit einer Queue
2.4 Implementierung mit zwei Queues . . . . . . . . . . . . . . . . . .
2.4.1 Mehrere Queues auf unterschiedlichen Ebenen . . . . . . . .
2.4.2 Queues als einfacher Baum . . . . . . . . . . . . . . . . . .
2.5 Anhalten und Wiedereinstellen eines Jobs . . . . . . . . . . . . . .
4
4
4
6
7
7
8
8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Fazit
12
3.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Ausblick für die Masterarbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1
1.1
Einleitung
Aufgabenstellung
Dieses Dokument stellt die Dokumentation zum Masterprojekt dar. Das Masterprojekt ist
ein Pflichtprojekt im Rahmen des Studiengangs Master of Science Informatik an der HTWK
Leipzig. Im Rahmen dieses Studiengangs muss ein Projekt im Umfang von 300 Stunden
absolviert werden.
Die Aufgabe dieses Masterprojekts besteht darin, eine bestehende Sun Grid Engine um
ein Cluster of Workstations (COW) zu erweitern. Mit diesem COW sollen Computer, welche
tagsüber beispielsweise von Sekretärinnen oder anderen Mitarbeitern genutzt werden, in einer
definierten Zeit (in den Nachtstunden) Jobs von der Sun Grid Engine berechnen.
1.2
Theorie
Grid-Computing ist eine Form des verteilten Rechnens, bei der ein virtueller Supercomputer
aus einem Cluster lose gekoppelter Computer erzeugt wird. Es wurde entwickelt, um rechenintensive wissenschaftliche – insbesondere mathematische – Probleme zu lösen.
Von typischen Computerclustern unterscheidet sich Grid-Computing in der wesentlich
loseren Kopplung und der Heterogenität der Computer. Des Weiteren ist ein Grid meistens bestimmt für eine spezielle Anwendung und nutzt häufig standardisierte Programmbibliotheken.
1.3
Arbeitsumgebung
Die Sun Grid Engine des Max-Planck-Institutes für evolutionäre Anthropologie kann als
Rechengrid klassifiziert werden. Bei einem solchen Grid sieht der Anwender nur eine virtuelle
Maschine. Hinter dieser verbirgt sich ein Zusammenschluss von mehreren heterogenen Servern,
welche dediziert für die Berechnung der Jobs zur Verfügung stehen. Wegen der Heterogenität
der einzelnen Knoten wurden für jeden die Grenzwerte angepasst. Bei diesen handelt es sich
zum Beispiel um die Anzahl der verfügbaren Prozessoren oder den maximal verfügbaren
Arbeitsspeicher. Nach diesen Werten werden die Jobs vom Masterhost an die einzelnen Knoten
aufgeteilt und versandt.
Bei dem Grid des Max-Planck-Institutes für evolutionäre Anthropologie handelt es sich
um eine bereits bestehende, produktive Sun Grid Engine (SGE) mit der Softwareversion 6.2
Update 5. Zu Begin dieser Arbeit umfasst die SGE 25 Knoten. Diese Knoten sind dediziert für
diese Sun Grid Engine angeschafft worden und werden auch nur für diese benutzt. Jeder dieser
Knoten besitzt 4, 8, 16 oder 24 Kerne. Somit stehen der Sun Grid Engine insgesamt 424 Kerne
und 510 GB RAM zur Verfügung. Die Jobskripte können in jeder beliebigen Skriptsprache
geschrieben werden, solange diese auf den Systemen installiert ist. Standardmäßig wird die
Debian-Almquist-Shell (dash), die Bourne-Again Shell (bash) oder die C-Shell (csh) genutzt.
Bei diesen Skriptsprachen ist es zudem möglich, bestimmte Übergabeparameter für die SGE
im Skript zu setzen. Zudem ist es möglich, OpenMPI Programme an die SGE zu schicken. Die
2
Jobs, welche derzeit mit Hilfe der SGE bearbeitet werden sind unterschiedlich und können
somit nicht vereinheitlicht werden.
Diese Jobs werden von den Mitarbeitern an die bereits bestehende Sun Grid Engine übergeben. Anschließend werden sie an die verfügbaren Ressourcen aufgeteilt. Bei der Aufteilung
der Jobs werden verschiedene Parameter von der SGE ausgewertet. Wichtige Parameter sind
dabei die Anzahl der CPUs oder der verfügbare Arbeitsspeicher. Diese Parameter können
vom Anwender beim Hinzufügen eines Jobs in die SGE auf der Kommandozeile mit übergeben werden. Falls keine Parameter übergeben werden, werden die Standardwerte aus der
Konfigurationsdatei der SGE genommen.
Dieses Multicomputer-System stößt hin und wieder an die physikalischen Grenzen der Knoten. Das führt dazu, dass eine lange Queue entsteht, in welcher die Jobs stehen, bis genügend
Ressourcen für die Abarbeitung dieser Jobs verfügbar sind. Zum einen verlängert sich somit
die Bearbeitungszeit1 der Jobs und zum anderen stehen gerade in den Nachtstunden mehrere
Desktopsysteme unbenutzt in den Büros. Da die Desktop-Systeme aus leistungsstarken2
Computern bestehen, soll die bestehende SGE um ein Cluster of Workstations erweitert
werden.
Bei der SGE handelt es sich um eine Shared Disk Architektur. Bei dieser haben alle Knoten
des Grids zugriff auf die gleiche Speicherressource. Umgesetzt wurde diese Architektur mit
dem Network File System (NFS) der Version 3. Da auf diesen Netzlaufwerken zusätzlich die
Homelaufwerke der Anwender liegen, könnte theoretisch jeder Computer zum Grid hinzugefügt
werden. Die Gesamtkapazität des NFS beträgt über 300 TB.
Die Kernarbeitszeit der Abteilungen am Max-Planck-Institut liegt zwischen 10 und 16 Uhr.
Beobachtungen zufolge werden die Computer, welche zur Sun Grid Engine hinzugefügt werden
sollen, zwischen 8 und 18 Uhr benutzt. Zu diesen Zeiten wurde noch ein Puffer von zwei
Stunden addiert, sodass an Wochentagen in der Zeit von 22 bis 6 Uhr, sowie am Wochenende
diese Knoten zur SGE hinzugefügt werden sollen. An Wochentagen darf zwischen 6 und 22
Uhr kein Job auf diesen Computern laufen.
Dieses Grid ist bereits im produktiven Einsatz. Deshalb wurde eigens für dieses Projekt
ein dediziertes Testsystem aufgebaut. Die Konfiguration des Testsystems ist identisch mit
der des Produktivsystems. Dieses Testsystem besteht aus einem Server und einem Desktop.
Der Server stellt dabei sowohl den Master der SGE dar, als auch einen Knoten. Der Desktop
wird als weiterer Knoten eingesetzt. Der Masterhost stellt während des Projektes einen Knoten dar, welcher immer für Berechnungen genutzt werden kann (ähnlich wie die Server im
Produktivsystem). Der Desktop stellt eine Workstation dar, welcher nur zu bestimmten Zeiten
für Berechnungen herangezogen werden soll.
1
Mit Bearbeitungszeit ist in diesem Zusammenhang die Zeit gemeint, welche vom ersten Hinzufügen bis zur
erfolgreichen Beendigung des Jobs vergeht.
2
In der Regel haben diese Computer vier Kerne und 4 GB Arbeitsspeicher.
3
2
Umsetzung
2.1
Idee Cluster of Workstations
Studien zufolge bleiben 95% der Leistung eines Computers ungenutzt. Dies liegt zum einen
daran, dass die Hardwarehersteller immer schnellere und leistungsstärkere Hardware produzieren. Zum anderen liegt es aber auch daran, dass viele Computer, gerade in großen Firmen
und Instituten, auch in der Nacht und an Feiertagen laufen, obwohl an diesen nicht gearbeitet
wird. Um diese Ressourcen zu nutzen, wurde in diesem Projekt eine bestehende Sun Grid
Engine um ein Cluster of Workstations erweitert.
Das zeitliche Regime für dieses System ist folgendermaßen geplant:
• Wochentags 6 bis 22 Uhr bleiben die Workstations von der SGE unangetastet.
• Ab 22 Uhr werden diese Knoten zur SGE hinzugefügt.
• An Wochentagen ab 6 Uhr werden diese Knoten aus der Queue der SGE entfernt.
• Jobs, die zu diesem Zeitpunkt noch laufen werden abgebrochen und erneut in die
Jobqueue eingestellt.
Die Umsetzung des COWs erfolgt in drei Schritten. Im ersten Schritt werden verschiedene
Wege, wie bestimmte Knoten zu bestimmten Zeiten in die SGE gestellt und wieder entfernt
werden können, aufgezeigt und getestet. Der zweite Schritt besteht darin, Jobs, welche nach
Ablauf dieses Zeitfensters nicht beendet sind, abzubrechen. Umsetzungsmöglichkeiten für das
Wiedereinstellen dieser Jobs in die Jobqueue werden im dritten Schritt eruiert.
2.2
Cluster of Workstations mit cron
Auf allen Servern der derzeit bestehenden Sun Grid Engine läuft das Betriebssystem Ubuntu.
Ubuntu ist eine Linux-Distribution, die auf Debian basiert. Der cron-Daemon ist eine Jobsteuerung unter unixartigen Betriebssystemen, die wiederkehrende Aufgaben automatisch zu
einer bestimmten Zeit ausführen kann.
Bei der Umsetzung des Cluster of Workstations mit Hilfe des cron-Daemons wird an
jedem Wochentag 22 Uhr automatisch sge_execd ausgeführt. Dies ist ein Dienst, welcher auf
allen Client-Knoten des Grids läuft. Der Masterhost prüft in definierten Zeitabständen, ob
und welche Knoten verfügbar sind. Somit werden die Workstations 22 Uhr in die Liste der
verfügbaren Knoten aufgenommen und Jobs an diese verteilt.
Da der COW an Wochentagen nur bis 6 Uhr im Grid rechnen soll, wird um diese Zeit ein
zweites Skript zum stoppen des sge_execd ausgeführt. Das Problem bei dieser Lösung ist,
dass Jobs, die zu dieser Zeit noch nicht beendet sind, weiter laufen und nicht abgebrochen
werden. Dies hat zur Folge, dass diese Arbeitsplätze erst nach Beendigung des Jobs wieder
dediziert vom Anwender genutzt werden können.
4
Zur Lösung dieses Problems soll das Skript zum Stoppen des Daemons schon 5 Uhr ausgeführt werden. Somit werden an die entsprechenden Knoten ab 5 Uhr keine Jobs versandt. Um
sicherzustellen, dass ab 6 Uhr alle Jobs auf den entsprechenden Knoten beendet sind, wird ein
Limit für die maximale Laufzeit der Jobs von einer Stunde auf den entsprechenden Knoten
definiert. Bei solchen Limits können Soft- und Hardlimits definiert werden. Der Unterschied
zwischen diesen liegt darin, dass bei einem Hardlimit das Signal SIGKILL an den entsprechenden Job geschickt wird. Dies bewirkt den sofortigen Abbruch des Jobs. Bei einem Softlimit
wird hingegen das Signal SIGUSR1 an den entsprechenden Job gesandt. Dies hat zur Folge, dass eventuell definierte Epilog-Skripte nach dem Beenden des Jobs noch ausgeführt werden.
Durch das Starten und Beenden des sge_execd mittels des cron-Daemons wird gewährleistet, dass die Knoten des COWs lediglich zur gewünschten Zeit (wochentags zwischen
22 und 5 Uhr) Jobs vom Masterhost der Sun Grid Engine zugewiesen bekommen. Mit der
Laufzeitbeschränkung auf eine Stunde wird des Weiteren sichergestellt, dass an Wochentagen
nach 6 Uhr alle Jobs auf diesen Knoten beendet sind. Nichtsdestotrotz sind mit dieser Methode
zwei Probleme verbunden:
1. Es können keine Jobs mit einer Laufzeit von mehr als einer Stunde auf den Knoten
ausgeführt werden.
2. Die Jobs werden lediglich abgebrochen, jedoch nicht neu in die Queue gestellt.
Über jeden abgebrochenen Job, wird der Anwender durch eine Mail informiert. In dieser
Mail steht das Signal, mit welchem der Job abgebrochen wurde. Jedoch beinhaltet diese Mail
nicht das Ereignis, welche zu diesem Abbruch geführt hat. Das Problem dabei ist, dass der
Anwender unter Umständen durch diese ungenaue Beschreibung einen Fehler im Job sucht, da
er nicht weiß, dass die Bearbeitungszeit abgelaufen ist. Da die verschiedenen Knoten neben
der unterschiedlichen Anzahl von Kernen auch eine unterschiedliche Taktgeschwindigkeit der
Kerne haben, ist im Vorfeld eine Laufzeitabschätzung der Jobs unmöglich.
Da die Laufzeit eines Jobs sehr stark von der Leistungsfähigkeit des Knotens abhängt,
kann diese vor der Bearbeitung nicht genau bestimmt werden. Bei einer zu hohen Abschätzung
der Laufzeit würden weniger Jobs als möglich an die Workstations gesandt werden, bei einer
zu niedrigen Abschätzung würden die Jobs abgebrochen und müssten noch einmal berechnet
werden. In beiden Fällen würden die Ressourcen des COW nicht voll ausgeschöpft werden.
Eine weitere Möglichkeit, einen solchen Job automatisch nach Ablauf einer bestimmten
Zeit abzubrechen stellt das Softlimit dar. Da der Job bei diesem Limit nicht durch das Signal
SIGKILL, sondern durch das Signal SIGUSR1 abgebrochen wird, ist es möglich, im Anschluss
ein Epilog-Skript auszuführen. Mit Hilfe dieses Skriptes kann geprüft werden, ob der Abbruch
des Jobs durch das Ablaufen der Bearbeitungszeit ausgelöst wurde oder nicht. Falls dies der
Fall ist, könnte durch dieses Skript eine zusätzliche Mail an den Anwender versandt werden,
in der diese Informationen stehen.
Mit Hilfe eines solchen Skriptes ist es zudem möglich, dass der Anwender im Fall des
Abbruches seines Jobs nicht nur darüber Informiert wird, dass der Job wegen eines Zeitlimits
abgebrochen wurde, sondern dieser automatisch wieder zur Queue hinzugefügt wird. In dem
Fall würde dem Job, durch das Wiedereinfügen in die Queue eine neue JobID zugeteilt. Diese
5
würde als zusätzliche Information in der Mail enthalten sein. Dadurch müsste sich der Anwender nicht um das Wiedereinstellen des Jobs kümmern. Der Nachteil dabei ist, dass dem
Job eine neue ID zugewiesen wird. Im Zuge dessen wird dieser Job hinten an die bestehende
Queue angefügt. Dies könnte zur Folge haben, dass Prioritäten, welche diesem Job zugewiesen
wurden, nicht mehr beachtet werden. Zudem würden dabei auch weitere Parameter, welche
der Anwender mit dem Job übergeben hat, nicht beachtet werden.
2.3
Implementierung des Sun Grid Engine Kalenders mit einer Queue
In der Standardinstallation ist bereits eine Schnittstelle für einen Kalender implementiert.
Um diese Funktionalität zu aktivieren muss ein Kalender angelegt werden. Außerdem ist es
notwendig, diesen Kalender einer Queue hinzuzufügen.
Die Definition des Kalenders untergliedert sich in drei Teile:
1. Jahrestag (Datum)
2. Wochentag
3. Uhrzeit.
In diesen Teilbereichen kann die Queue jeweils aktiviert (on), deaktiviert (off ), suspendiert
(suspended) oder fortgesetzt (resume) werden. Dabei ist zu beachten, dass nur eine aktivierte
Queue deaktiviert oder suspendiert werden kann. Bei einer deaktivierten Queue werden vom
Masterhost an die betroffenen Knoten keine weiteren Jobs verteilt. Eine Suspendierung hat
zur Folge, dass laufenden Jobs die CPU-Zeit entzogen wird und zusätzlich während dieser
Zeit keine weiteren Jobs an diese Knoten verteilt werden. Eine Fortsetzung kann lediglich bei
suspendierten Jobs stattfinden. Falls kein Job suspendiert wurde, verhält sich ein Fortsetzen
einer Queue genau wie eine Aktivierung. Bei dieser werden die betroffenen Knoten zur Queue
der SGE hinzugefügt.
In Listing 1 wird die Syntax für einen einfachen Kalender gezeigt. Der Kalendername ist
night. Der 01.01.2011, 06.01.2011 und der 22.04.2011 werden als Feiertage deklariert. An diesen
werden die Knoten den ganzen Tag für die Queue der SGE aktiviert. Zudem wird definiert,
dass an Wochentagen (Montag bis Freitag) zwischen 6 und 20 Uhr von der Sun Grid Engine
kein Job an diese Knoten gesandt werden darf. An Wochenenden (Samstag und Sonntag) ist
das Verhalten wie an Feiertagen, die SGE hat vollen Zugriff auf die Knoten.
Listing 1: Einfacher Kalender der Sun Grid Engine
calendar_name
year
week
night
01.01.2011 ,06.01.2011 ,22.04.2011= on
06:00 -20:00= suspended
Die Zuweisung eines Kalenders zu einer bestimmten Queue oder zu ausgewählten Knoten
wird in der Konfigurationsdatei vorgenommen. Hierzu gibt es drei Wege. Zum einen kann einer
kompletten Queue ein Kalender zugewiesen werden. Dazu wird in der Konfigurationsdatei
<queuename>.q folgende Zeile hinzugefügt:
6
calendar
< calendername >
Des Weiteren gibt es die Möglichkeit, bestimmte Knoten von diesem Kalender auszuschließen. Dazu wird diese Zeile folgendermaßen angepasst:
calendar
< calendername > ,[ host1 = NONE ]
Die dritte Möglichkeit besteht darin, keinen Kalender zu definieren. Hierzu wird als
Kalendername NONE eingegeben. Standardmäßig ist kein Kalender aktiviert. Auch bei dieser
Variante ist es möglich, bestimmte Knoten auszuschließen. Dafür werden diese, wie im zweiten
Fall, hinter der Standarddefinition mit den entsprechenden Kalendern angegeben:
calendar
NONE ,[ host1 = < calendername >]
Zusammenfassend ergibt sich folgende Syntax für die Definition eines Kalenders in der Sun
Grid Engine:
’ calendar ’= < calendarname >( < hostlist >)
Die Definitionen dazu lauten:
< calendarname >= < Name des Kalenders >| ’ NONE ’
< hostlist >= ’ ,[ ’ < Name des Knotens > ’= ’ < calendarname > ’] ’( < hostlist >)
2.4
Implementierung mit zwei Queues
Wie in Abschnitt 2.3 bereits beschrieben, gibt es verschiedene Möglichkeiten den Kalender
der Sun Grid Engine zu implementieren. Einen Standardkalender zu implementieren, ist für
dieses Projekt nicht geeignet. Dies ist darin begründet, dass somit alle Knoten der Sun Grid
Engine nur zu diesen definierten Zeiten arbeiten würden. Eine Möglichkeit, dieses zu umgehen,
besteht darin, dass eine zweite Queue definiert wird. In der ersten Queue befinden sich alle
Knoten, die dediziert für die Sun Grid Engine benutzt werden. Die zweite Queue ist für die
Knoten gedacht, welche lediglich zu bestimmten Zeiten der SGE angehören. Dies bringt zwei
Vorteile mit sich. Zum einen kann der Anwender explizit angeben, ob er nur auf dem COW
rechnen möchte, nur auf dem Hauptsystem, oder auf beiden. Um auf beiden Systemen zu
rechnen, werden beim Hinzufügen des Jobs in die SGE keine weiteren Parameter benötigt. In
diesem Fall werden automatisch alle vorhandenen Queues genommen. Für die anderen beiden
Fälle wird die gewünschte Queue als Parameter an die Sun Grid Engine mit übergeben.
2.4.1
Mehrere Queues auf unterschiedlichen Ebenen
Um die Benutzerfreundlichkeit der SGE zu erhöhen, besteht die Möglichkeit, mehrere Queues
in unterschiedlichen Ebenen zu definieren. Die einfachste Variante hierfür besteht aus einer
Hauptqueue (A.q) und einer Subqueue (B.q). Die B.q ist der A.q direkt untergeordnet. Für
diese Hierarchie muss die B.q lediglich in der Konfigurationsdatei der A.q mit der Zeile
subordinate_list slots=2(B.q) definiert werden. In Listing 2 wird die Struktur dieser
Hierarchie dargestellt.
7
Listing 2: Mehrere Queues auf unterschiedlichen Ebenen
A.q
|
B.q
Dies ist ein einfaches Beispiel für Knoten, auf welchen zwei Jobs gleichzeitig ausgeführt
werden können, zum Beispiel auf Computern mit zwei Prozessoren. Bei diesem Beispiel würden
Jobs nur dann über die B.q auf einem Knoten ausgeführt werden, wenn zu dieser Zeit weniger
als zwei Jobs auf dem Knoten laufen. Für den Fall, dass zwei Jobs von der B.q auf dem Knoten
ausgeführt werden, und ein weiterer Job über die A.q kommt, wird der Job mit der kürzesten
Laufzeit aus der B.q angehalten. Somit läuft nur noch ein Job auf dem Knoten und der Job
aus der A.q kann auf diesem Knoten hinzugefügt werden.
2.4.2
Queues als einfacher Baum
Mehrere Queues in eine einfache Baumstruktur zu definieren, stellt die dritte Variante dar.
Die beiden Subqueues (B.q und C.q) werden dabei in der Hauptqueue (A.q) durch die Zeile
subordinate_list slots=2(B.q:1, C.q:2) definiert. Eine Definition der Hauptqueue in
den Konfigurationsdateien der beiden Subqueues ist auch in diesem Fall nicht nötig. Durch
diese Konfiguration wird ein Baum mit einer Wurzel und zwei Blättern erstellt. Die A.q stellt
die Wurzel dar, die beiden Queues B.q und C.q sind direkte Kinder der A.q. Falls keine anderen
Prioritäten definiert wurden, werden diese anhand der Reihenfolge, in der die Queues definiert
wurden, erstellt. Die erste definierte Subqueue hat somit eine höhere Priorität als die folgenden.
Listing 3: Mehrere Queues als einfacher Baum organisiert
A.q
/ \
B.q C.q
Diese Struktur kann beliebig fortgeführt werden. Bei Bäumen mit einer Tiefe von mehr als
eins ist darauf zu achten, dass in jeder Queue nur die direkten Nachfolger definiert werden.
Im Zuge dieses Projektes wurde die Implementierung über eine Queue gewählt. Die Begründung dafür liegt im geringen administrativen Aufwand und der Flexibilität. Bei diesem
Weg müssen lediglich die Knoten, welche nur zu bestimmten Zeiten der SGE hinzugefügt
werden sollen, definiert werden. Für jeden einzelnen Knoten kann dabei ein anderer Kalender
definiert werden. Für den Fall, dass ein Mitarbeiter in den Erholungsurlaub geht, kann durch
einfaches Bearbeiten der Queue (Löschen des Kalenders für diesen Knoten) der spezielle
Knoten für den kontinuierlichen Einsatz in dieser Zeit definiert werden.
2.5
Anhalten und Wiedereinstellen eines Jobs
Wie in Abschnitt 2.3 beschrieben, gibt es mehrere Möglichkeiten einen Job mit Hilfe eines Kalenders abzubrechen. Zum einen kann durch den Kalender der betreffende Knoten deaktiviert
werden. Dabei laufen alle Jobs auf diesem Knoten weiter. Die Laufzeitabschätzung der Jobs
ist sehr fehleranfällig. Die Suspendierung wird auf der Sun Grid Engine standardmäßig durch
8
das Signal SIGSTOP vorgenommen. Dabei wird dem laufenden Job lediglich die CPU-Zeit
des Knotens entzogen. Das Problem bei diesem Weg ist, dass der allozierte Speicher nicht
freigegeben wird. Bei Jobs, welche viel Speicher alloziert haben, könnte dies für die weitere
Benutzung des Knotens zu einem Performanceverlust führen, da bei Bedarf der allozierte Bereich des Arbeitsspeichers auf eine swap-Partition3 ausgelagert werden muss. Zudem
verlängert dies die Laufzeit eines Jobs um die Zeit, in der der Knoten nicht im Grid integriert ist.
Ein Weg, dieses Problem zu beheben, besteht darin, statt des Signales SIGSTOP das
Signal SIGKILL zu definieren. Dabei würden genau zu der Zeit, in der ein Knoten nicht
mehr für den Grid zur Verfügung steht, alle laufenden Jobs beendet. Der Anwender würde
in diesem Fall eine Benachrichtigung per Mail bekommen und könnte den entsprechenden
Job später neu starten. Bei diesem Lösungsansatz ist allerdings zu beachten, dass die Jobs
lediglich abgebrochen und somit nicht erneut in die Queue hinzugefügt werden. Bei diesem
Lösungsansatz muss der Anwender selbstständig alle abgebrochenen Jobs suchen und neu
starten. Dies bedeutet, neben dem erhöhten Aufwand für den Anwender, unter Umständen
auch eine ungleichmäßige Auslastung der SGE, weil alle Jobs vom Anwender zur gleichen Zeit
gestartet werden.
Zur Lösung dieses Problems müssten die Jobs automatisch, nach dem Beenden, erneut in
die Queue hinzugefügt werden. Das “Rescheduling”4 von einem Job kann auf mehreren Wegen
geschehen. Wie bereits beschrieben, könnte zum Beispiel anstelle des SIGKILL-Signals das
Signal SIGUSR1 versandt werden. Der Vorteil dabei besteht darin, dass ein Epilog-Skript,
welches in der Queue definiert ist, noch ausgeführt wird. In diesem Skript stehen verschiedene
Variablen zur Verfügung. Dabei handelt es sich unter anderem um die aktuelle JobID und den
Namen der Queue, in die der Job hinzugefügt wurde. Anhand dieser Variablen ist es möglich,
den Job mit Hilfe des Epilog-Skriptes erneut in die Queue hinzuzufügen. Anschließend müsste
aus dem Skript heraus eine Mail mit der neuen JobID an den Anwender gesandt werden,
da sich diese in dem Fall ändert. Der Nachteil dabei ist, dass der Job am Ende der Queue
eingestellt wird. Dies könnte zu einer erhöhten Wartezeit, und somit zu einer sehr großen
Bearbeitungszeit führen. Durch den sogenannten “Array-Parameter” ist es möglich, einen
Job in die Queue hinzuzufügen, der mehrfach ausgeführt wird. Dies führt zu einem weiteren
Nachteil dieser Methode, da in diesem Fall nicht nur die abgebrochene Instanz wiederholt
wird, sondern auch alle anderen.
Um dieses Problem zu umgehen, müssen die Jobs so beendet werden, dass sie von der Sun
Grid Engine automatisch erneut zur Queue hinzugefügt werden. Der Vorteil dabei ist, dass
dabei nur diese Instanz des Jobs erneut ausgeführt wird. In der SGE besteht standardmäßig
eine Routine, durch welche Jobs “rescheduled” werden können. Mit Hilfe dieser Routine
werden automatisch alle Jobs, die mit dem Exitstatus 99 beendet werden, erneut in die Queue
eingefügt. Bei dem “Reschedulen” durch die SGE behält der Job die ursprüngliche JobID bei.
Zudem wird der Job am Anfang und nicht an das Ende der Queue eingefügt. Alle Parameter,
die beim Hinzufügen des Jobs übergeben wurden, bleiben erhalten.
3
Unter swap-Partition wird eine Partition verstanden, auf welche die geladenen Pages des Arbeitsspeichers
ausgelagert werden, falls dieser voll ist.
4
Mit “Rescheduling” wird in diesem Fall das automatische Hinzufügen eines abgebrochenen Jobs in die
Ursprungsqueue benannt.
9
Ein Job der Sun Grid Engine besteht grundsätzlich aus einem Skript. Bei diesem Skript
handelt es sich um ein herkömmliches Unix-Shell-Skript. Der Vorteil dabei besteht darin, dass
mit Hilfe einer Signalbehandlung die Unix-Signale abgefangen werden könnten. Sinnvoll ist
dies zum Beispiel bei dem Signal SIGUSR1. Wie bereits erwähnt, muss der Job mit dem
Exitstatus 99 beendet werden, um durch die Sun Grid Engine am Anfang der Queue eingefügt
zu werden. Um das immer dann zu erreichen, wenn das Signal SIGUSR1 an den Job gesandt
wird, muss die folgende Zeile im Skript hinzugefügt werden:
trap " exit 99" SIGUSR1
Auf diesem Wege ist es zwar möglich, den Abbruch eines Jobs zu erzwingen, und falls der
Anwender diese eine Zeile in sein Jobskript hinzugefügt hat sogar einen Job zu “reschedulen”,
allerdings würde es einen hohen administrativen Aufwand bedeuten, diese Zeile in jedem
Skript hinzuzufügen. Eine globale Signalbehandlung würde dieses Problem beheben, ist aber
an dieser Stelle nicht möglich.
Es ist möglich, in der Konfigurationsdatei der SGE Skripte zu definieren, die vor und nach
einem Job ausgeführt werden können. Ein vorgelagertes Skript wird Prolog-Skript genannt.
Falls ein solches definiert ist, wird dies vor dem eigentlichen Job ausgeführt. Die Bearbeitungszeit des Jobs startet erst nachdem dieses Skript beendet wurde. Das sogenannte Epilog-Skript
ist ein Skript, welches nach dem eigentlichen Job ausgeführt wird. Ein Epilog-Skript wird
direkt nach einem Job ausgeführt, der Exitstatus von diesem ist dabei irrelevant. Die einzige
Ausnahme besteht dann, wenn der Job mit dem Signal SIGKILL beendet wurde.
Die Idee, eine Signalbehandlung durchzuführen bestand darin, diese in ein Epilog-Skript
auszulagern. Dazu muss das Jobskript nicht verändert werden. Die einzige Anpassung wird in
der Konfigurationsdatei der Queue vorgenommen. In dieser muss in der Zeile epiloge das
Epilog-Skript mit einem Pfadnamen angegeben werden. Zusätzlich ist darauf zu achten, dass
es sich um einen absoluten Pfad handelt, der von allen Anwendern und Knoten aus erreichbar
ist. Andernfalls ist es nicht möglich, dieses Skript fehlerfrei auszuführen.
Der Lösungsansatz mit Hilfe dieses Skriptes besteht darin, dass nach Beendigung der
Arbeitszeit des Cluster of Workstations alle laufenden Jobs auf den entsprechenden Maschinen durch dieses SIGUSR1-Signal abgebrochen werden. Anschließend wird mit Hilfe des
Epilog-Skriptes überprüft, ob der Job regulär beendet, oder abgebrochen wurde. Falls dieser
abgebrochen wurde, wird in diesem Skript der Exitstatus des Jobs auf den Wert 99 gesetzt
und somit der Job automatisch von der SGE “rescheduled”. Bei einem Test, den Exitstatus
eines Jobs auf diese Art und Weise zu manipulieren ist aufgefallen, dass dieser zwar in die
entsprechenden Variablen geschrieben wird, und in der späteren Auswertung der Jobs als
solches aufgeführt wird, jedoch bekommt dieses Skript nie den SGE-Status “Rescheduled”.
Weitere Tests dieses Phänomens haben ergeben, dass dieser Status direkt nach Beendigung
des eigentlichen Jobs gesetzt wird und anschließend nicht verändert werden kann.
Zusammengefasst lautet das Ergebnis dieser Tests: Um den Exitstatus eines Jobs zu
kontrollieren und mit Hilfe eines Skriptes zu manipulieren, muss dieses Skript zur Laufzeit
des Jobs ausgeführt werden. Das heißt, dass falls die Bearbeitungszeit eines Knotens abläuft,
muss ein Skript parallel zum Job gestartet werden. Auf dieses Skript müssen alle Anwender
der SGE Zugriff haben und dieses ausführen können. In diesem Skript muss bekannt sein,
10
auf welchem Knoten die Rechenzeit abgelaufen ist, die JobID und der Pfad, in welchem die
Variablen des beendeten Jobs gespeichert sind.
Die Aufgabe des Skriptes ist es dann, den Job mit dem Befehl exit 99 zu beenden oder die
entsprechende Variable der SGE auf diesen Wert zu setzen. Da die Jobs auf unterschiedlichen
Knoten ausgeführt werden, und somit die Ordner, in denen diese Variablen gesetzt werden,
variieren, gibt es in der SGE eine Variable, welche den aktuellen voll qualifizierten Pfadnamen
beinhaltet. Der Name dieser Variable lautet bei allen Jobs der SGE SGE_JOB_SPOOL_DIR. Diese
Variable kann im Job oder in einem Skript aus der gleichen Umgebung5 abgefragt werden.
Aus diesen Informationen entsteht folgendes Skript:
Listing 4: Skript zum “Reschedulen” eines Jobs
#!/ bin / sh
echo 25 > $S GE_ JO B_ SP OO L_ DI R / exit_status
pid_job = ‘ cat $S GE _J OB _S PO OL_DI R / job_pid ‘
kill $pid_job
Dieses Skript wird anstelle des Suspend-Signals in der Konfigurationsdatei der SGE angegeben. Somit wird nicht, wie standardmäßig festgelegt, das Signal SIGSTOP ausgeführt,
sondern dieses Skript. Die erste Zeile des Skriptes gibt die Shell an, in welcher dieses ausgeführt
wird. In vorliegenden Fall wurde die Standardshell dash gewählt. Die zweite Zeile setzt den
Exitstatus des Skriptes auf den Wert 25, welcher vom System wie der Befehl exit 99 im
Jobskript interpretiert wird. In der dritten Zeile wird die JobID des laufenden Jobs ermittelt
und in der lokalen Variable pid_job gespeichert. In der letzten Zeile wird dann das Signal
SIGKILL an den Job gesandt, um diesen zu beenden. An dieser Stelle könnte auch ein anderes
Signal, wie beispielsweise SIGUSR1 versandt werden, dafür müsste aber als Umgebung eine
andere Shell, wie zum Beispiel die Bash, für dieses Skript gewählt werden, da dieses Signal in
der dash nicht versandt werden kann. Der einzige Unterschied zwischen diesen beiden Signalen
besteht an dieser Stelle darin, wie der eigentliche Job beendet wird. Dies hat keinen weiteren
Einfluss auf das erneute Ausführen des Jobs.
5
Alle Signale, die an die entsprechenden Jobs gesandt werden und alle Skripte, welche im direkten Zusammenhang zu einem Job ausgeführt werden, haben Zugriff auf die gleichen globalen Variablen.
11
3
Fazit
3.1
Zusammenfassung
Inhalt dieser Arbeit ist es, ausgewählte Desktop PCs zu bestimmten Zeiten zu einer bereits bestehende Sun Grid Engine hinzuzufügen. Bei diesen Computern handelt es sich um
Arbeitsplätze von Mitarbeitern, welche diese in der Zeit zwischen 8 und 18 Uhr benutzen. Die
Umsetzung mit Hilfe des cron-Daemons brachte keinen Erfolg, da mit diesem laufende Jobs
nicht beendet werden können.
Mit Hilfe des Kalenders der Sun Grid Engine konnten diese Jobs für eine definierte Zeit
angehalten werden. Dabei wird den Jobs lediglich die Rechenzeit entzogen, der Arbeitsspeicher
bleibt alloziert. Da dieser virtuelle Speicher anderen Programmen nicht zur Verfügung steht,
stellt auch dies keine Alternative dar. Somit wurde dieser Kalender so weit angepasst, dass
laufende Jobs mit Hilfe eines Skriptes abgebrochen werden und anschließend von der SGE
automatisch am Anfang der Queue erneut hinzugefügt werden. Somit muss sich der Anwender
nicht um ein erneutes Einstellen des Jobs kümmern, falls dieser durch das Ablaufen des Timers
abgebrochen wurde.
3.2
Ausblick für die Masterarbeit
Zusätzlich zu den Computern der Mitarbeiter sollen die Desktop PCs der Forscher zum COW
hinzugefügt werden. Da einige Forscher am Max-Planck-Institut auch außerhalb der Kernarbeitszeit, in den Nachtstunden oder am Wochenende arbeiten, stellen die festen Zeiten eines
Kalenders keine vollständige Lösung des Problems dar. So ist es zum Beispiel möglich, dass ein
Mitarbeiter nach der festgelegten Zeit Programme auf einem Desktop PC ausführt. Zusätzlich
gestartete Jobs der SGE könnten dabei mit diesen Programmen um die CPU-Zeit konkurrieren.
Aus diesem Grund sollen im weiteren Vorgehen zusätzlich einige Bedingungen geprüft werden,
bevor die SGE die Rechenzeit dieser Desktops bekommt. Bei diesen Bedingungen handelt es
sich zum Beispiel um:
• Die Zeit, die seit dem letzten Tastendruck auf dieser Maschine vergangen ist.
• Die Anmeldung am System.
Falls ein Benutzer am System angemeldet ist, stellen sich folgende Fragen:
• Ist der Bildschirmschoner aktiv?
• Wie ist die aktuelle CPU- und Arbeistsspeicherauslastung?
Diese Bedingungen sollen dazu beitragen, dass es ausgeschlossen ist, einen Job mit Hilfe
der SGE an einen Desktop PC zu senden, an dem ein Anwender zu dieser Zeit arbeitet.
Zudem sollen Jobs abgebrochen werden, falls zu deren Bearbeitungszeit ein Anwender diesen
Computer benutzt.
Ein weiterer Einsatz dieses Systems besteht darin, Minijobs (Jobs mit einer Bearbeitungszeit
von weniger als 30 Minuten) zum Beispiel zur Mittagszeit auf Desktop-PCs auszuführen.
12