VQS Version 2
Ein maßgeschneidertes Batchsystem für den Alpha-Cluster

von Peter Marksteiner (Ausgabe 95/3, September 1995)

 

Der überwiegende Anteil an Rechenleistung auf dem neuen Alpha-Cluster wird in Form von seriellen Batchjobs erbracht, die vom Vienna Queueing System (VQS) verwaltet werden. Für den Alpha-Cluster wurde eine frühere VQS-Version, die für den RS/6000-Cluster entwickelt worden war, adaptiert und erweitert. Hier soll nun die Funktionsweise dieser Version 2 des Vienna Queueing System beschrieben werden, wobei vor allem auf die Unterschiede zur Version 1 eingegangen wird. Allgemeine Informationen über den Rechnerbetrieb des Alpha-Clusters finden Sie im Comment 95/2 .

Prinzipien der Batchverarbeitung

Die wichtigste Aufgabe des VQS ist es, dafür zu sorgen, daß die vorhandenen Rechnerressourcen optimal ausgenutzt werden: Ohne geeignete Maßnahmen könnte der Fall eintreten, daß manche Maschinen im Cluster überlastet sind, während andere "leerstehen". Um dies zu vermeiden, werden die Programme der Benutzer nicht unmittelbar durchgeführt; vielmehr werden von den Benutzern Prozeduren ("Jobs") erstellt, die dem Batchsystem zur Verarbeitung übergeben werden.

Das Batchsystem entscheidet dann nach verschiedenen Kriterien, wann ein Job durchgeführt wird. Wenn es nicht möglich ist, mit der Verarbeitung sofort zu beginnen, bleibt der Job in der Warteschlange ("Queue"). Anders als bei interaktiven Aufgaben wie z.B. Textverarbeitung, wo man die Antwort des Computers auf jede Eingabe sofort haben möchte, spielt es bei numerisch intensiven Aufgaben, die Stunden oder Tage an Rechenzeit brauchen, meistens keine Rolle, wenn die Berechnungen erst zu einem späteren Zeitpunkt durchgeführt werden - sofern sich die Wartezeit in erträglichen Grenzen hält.

Eine weitere Aufgabe des Batchsystems ist es, für eine gerechte Verteilung der beschränkten Ressourcen zu sorgen, die sich zahlreiche Benutzer teilen müssen. Im VQS ist eine aufwendige "Scheduling Policy" implementiert, die gewährleistet, daß alle Benutzer angemessene Anteile der Rechenleistung erhalten. Das Fehlen einer adäquaten Scheduling Policy in vielen Batchsystemen ist einer der Hauptgründe, warum für die beiden Cluster am EDV-Zentrum ein eigenes Batchsystem entwickelt wurde, anstatt ein kommerzielles oder ein Public Domain-System zu installieren.

Zur Durchführung eines Jobs wählt das VQS eine beliebige Maschine im Cluster aus, worauf man als Benutzer keinen Einfluß hat. Es ist auch weitgehend unerheblich, auf welcher Maschine ein Job gerechnet wird: Auf allen Maschinen findet man dieselben Benutzerdaten ("Home Directories") und, von wenigen Ausnahmen abgesehen, auch die gleiche Softwareumgebung vor.

Jobklassen und Ressourcen

Die Ressourcen, die es zu verwalten und möglichst gerecht zu verteilen gilt, sind in erster Line CPU-Zeit, Hauptspeicher und Plattenplatz. Plattenplatz bezieht sich hier auf Platz für temporäre Daten ("Scratch Files"). Die CPU-Zeit wird mittels Jobklassen geregelt. In den derzeit definierten Klassen gelten die folgenden Beschränkungen:

Klasse S (short)

300 sec

= 5 min

Klasse M (medium)

6000 sec

= 1h 40 min

Klasse L (long)

86400 sec

= 24 h

Klasse X (extra long)

345600 sec

= 96 h

Die Beschränkung des Hauptspeichers und des Plattenplatzes ist - im Unterschied zur Version 1 - nicht mehr starr mit der Jobklasse verbunden; vielmehr sind beide innerhalb gewisser Grenzen frei wählbar. Dies geschieht durch Angabe der Optionen -m bzw. -d beim Befehl vsubmit. Die gewählten Limits sind bindend (z.B. erhält man die Fehlermeldung write failed, group disk limit reached, wenn man mehr Plattenplatz als angegeben belegen will). Andererseits garantiert das Batchsystem, daß ausreichend Ressourcen verfügbar sind - solange ein Job mit 200 MB Hauptspeicher und 1 GB Plattenplatz rechnet, werden für diesen Job 200 MB (physischer) Hauptspeicher und 1 GB Scratch-Bereich reserviert. Auch steht jedem Batchjob in den Klassen L und X ein Prozessor dediziert zur Verfügung: Ein solcher Batchjob wird an einen Prozessor gebunden, auf dem außer essentiellen Betriebssystem-Operationen keine weiteren CPU-intensiven Prozesse durchgeführt werden.

Praktische Hinweise zum Arbeiten mit VQS

Dieser Artikel soll keine Anleitung zur Verwendung des Vienna Queueing System sein - dazu sei auf die Dokumentation verwiesen (siehe unten). Für Benutzer, die bereits mit VQS vertraut sind, folgen jedoch einige Hinweise zum effizienten Arbeiten mit dem Batchsystem des Alpha-Clusters.

  • Die Verwaltung der Ressourcen durch ein Batchsystem kann nur dann einwandfrei funktionieren, wenn alle rechenintensiven Prozesse über das Batchsystem abgewickelt werden. Aus diesem Grund ist auf allen Maschinen - die interaktive Maschine (a1) ausgenommen - die CPU-Zeit von allen Prozessen außer Batchjobs auf 5 Minuten beschränkt. Auf der interaktiven Maschine ist kein solches Limit implementiert, weil für Tätigkeiten wie Programmentwicklung manchmal auch interaktiv größere Rechenleistungen erforderlich sind. Allerdings wird hier die Priorität von interaktiven Prozessen gegenüber Batchjobs mit zunehmendem Rechenzeitverbrauch stufenweise gesenkt.
  • Beim Befehl vsubmit gibt es zahlreiche Optionen. Diese können nunmehr auch im Job (Shell-Script) selbst angegeben werden, und zwar in Form von Kommentarzeilen, die mit #VQS$ beginnen.
  • Die Version 2 von VQS bietet die Möglichkeit, die Daten in den Scratch-Bereichen auch nach Beendigung des Jobs zu behalten. Dazu gibt man beim Befehl vsubmit die Option -k always an. Mit dem Befehl vremove wird ein Job dann aus dem Batchsystem entfernt und der dazugehörige Scratch-Bereich gelöscht. Die Option -k always sollte möglichst sparsam verwendet werden; auch sollten nicht mehr benötigte Scratch-Daten regelmäßig mit vremove freigegeben werden, um ausreichend freien Plattenplatz zu erhalten. Zwei Wochen nach Beendigung eines Jobs werden die Scratch-Daten automatisch gelöscht.
  • Es empfiehlt sich, nicht mehr Hauptspeicher und Scratch-Bereich anzufordern, als man wirklich braucht. Je größer die angegebenen Werte sind, desto länger wird die Wartezeit. Auch können durch übertriebene Ressourcenanforderungen Jobs anderer Benutzer blockiert werden.
  • Von Zeit zu Zeit ist es notwendig, eine Maschine im Cluster abzuschalten. Bei geplanten Abschaltungen wird üblicherweise gewartet, bis alle Jobs zu Ende gerechnet haben. Allerdings ist es nicht immer möglich, vier Tage zu warten - Jobs in der Klasse X müssen daher in seltenen Fällen abgebrochen werden.
  • In der Klasse X kann man bis zu 800 MB Hauptspeicher anfordern; Jobs mit so großem Hauptspeicherbedarf können aber nur auf zwei der 16 Maschinen rechnen. Deshalb ist bei Jobs mit mehr als 500 MB Hauptspeicherbedarf mit erheblich längeren Wartezeiten zu rechnen.
  • Die Klassen S und M dienen hauptsächlich zum Testen von Shell-Scripts und für kurze Testrechnungen. Jobs in diesen Klassen werden prinzipiell auf der interaktiven Maschine (a1) durchgeführt. In diesen Klassen kann man daher keinen besonders großen Durchsatz erwarten.
  • Nur eine der im letzten Comment angekündigten Neuerungen konnte bis jetzt nicht verwirklicht werden, nämlich die Unterstützung von Paralleljobs. Einerseits liegt das an den unerwarteten Schwierigkeiten, die bei der Installation des "Digital Parallel Software Environment" auftraten, und andererseits daran, daß der Cluster bereits mit seriellen Batchjobs voll ausgelastet ist - sogar während der Sommerferien. Parallelrechnen auf dem Alpha-Cluster wird also bis auf weiteres auf Experimente beschränkt bleiben.

Dokumentation

Online-Hilfe zu VQS erhält man mit dem Unix-Befehl man, z.B. man vsubmit. Mit dem Befehl apropos vqs erhält man eine Liste aller Themen, zu denen es Online-Hilfe gibt.

Ein ausführliches Handbuch für den Alpha-Cluster mit einer detaillierten Beschreibung von VQS Version 2 wird demnächst erscheinen. Zahlreiche Beispiele illustrieren das Erstellen von Shell-Scripts für VQS-Jobs, die optimale Nutzung der Scratch-Bereiche, die Weiterverarbeitung von Scratch-Daten früherer Jobs in Jobketten usw. Zum Großteil wird dieses Handbuch auch über WorldWideWeb abrufbar sein.

VQS Version 1 ist im Handbuch Using the RS/6000 Cluster at Vienna University Computer Center beschrieben, das als PostScript-Datei verfügbar ist.