Peter Berger
Im Dezember 1996 wurde nach einer öffentlichen Ausschreibung ein Vektorrechner SX4-B2 des japanischen Herstellers NEC mit 2 Prozessoren, 1 GB Hauptspeicher und 2 GB Erweiterungsspeicher installiert.
Für ein System dieser Leistungsklasse (1800 MFLOPs pro CPU) ist die Entwicklung eines Betriebs- und Scheduling-Konzeptes unbedingt erforderlich, um die Betriebsmittel in optimaler und „gerechter“ Weise den Benutzern zur Verfügung zu stellen. Dieses Konzept wurde vom Benutzerbeirat am 25. April 1997 zustimmend zur Kenntnis genommen.
Die Basis der Betriebsmittelvergabe und des Jobschedulings ist das Projekt, das von einem oder mehreren Usern bearbeitet werden kann. In einem entsprechenden Antrag sind eine Beschreibung des Projektes und die erforderlichen Betriebsmittel (CPU-Zeiten, Massenspeicher (temp. und permanent), max. Hauptspeicher pro Job) anzuführen. Wünschenswert ist eine Zeitabschätzung insgesamt, pro Monat oder pro Woche.
Bei der Vergabe wird diesem Projekt ein Account zugeordnet, der beim Login angegeben werden muß. Weiters wird jedem Account ein Budget zugeordnet, das entweder aus den Angaben des Projektleiters oder aus Vorgaben des EDV-Zentrums erstellt wird.
Derzeitige Realisierung:
Der Username kennzeichnet, wie in UNIX-Systemen üblich, den Benutzer (user-ID) und ist auf den zentralen Systemen des EDV-Zentrums für jeden User eindeutig. Es ist möglich, mehrere User einem Projekt zuzuordnen..
Derzeitige Realisierung:
Als Gruppe im Sinne von UNIX wird das Institut oder die Abteilung eines Institutes definiert. Group-ID und Group-Name sind Funktionen des einreichenden Institutes und werden nach dem EDV-Zentrums-internen Algorithmus bestimmt. Sie sind auf den zentralen Systemen des EDV-Zentrums für jeden Gruppe eindeutig. Wird ein Projekt von mehreren Instituten eingereicht, wird es einem Institut zugeordnet.
Die Beschränkung des Plattenplatzes (Disk-Quotas) wird pro Gruppe durchgeführt, eine aktuelle Information über die Quotas ist mit quota -v erhältlich.
Derzeitige Realisierung:
Die maximale Gültigkeitsdauer eines Accounts ist mit 6 Monaten festgelegt. Die Erfahrung der letzten Monate hat gezeigt, daß es für die Projektleiter nicht einfach ist, den genauen Bedarf an Betriebsmitteln abzuschätzen (vor allem nicht den Hauptspeicherbedarf pro Job und die „vernünftige“ Laufzeit eines Batchjobs). Daher ist eine Testphase von maximal einem Monat vorgesehen, um dann die genauen Limits zusammen mit dem Projektleiter festzulegen.
Der Zugang erfolgt über Ethernet und ATM, der Hostname ist cobra.zserv.tuwien.ac.at (la.zserv ist ein Alias).
Da dieser Rechner vor allem als Produktionssystem gedacht ist und keine Applikationen, die interaktive Jobsteuerung verwenden, laufen, ist eine Zeitbeschränkung für interaktive Jobs und für Jobs im Hintergrund sinnvoll. Weiters wurde aus Sicherheitsgründen ein Autologout bei Inaktivität einer Session unter der tc-shell eingeführt.
Derzeitige Realisierung:
Das Batchsystem NQS basiert auf den Sterling-NQS, es wurde aber in wesentlichen Punkten erweitert und bietet somit die Möglichkeit, eine Jobsteuerung ohne aufwendige Programmierung durchzuführen. Weiters ist die Funktionalität der Steuerung über das Budget gegeben sowie die Checkpoint/Restart-Funktion von Batchjobs.
Wird im Betrieb mehr Hauptspeicher als vorhanden angefordert, so lagert das Betriebssystem einen ganzen Job aus dem Hauptspeicher in den Erweiterungsspeicher (XMU) und dann auf Platte aus (Swap). Die Größe des Swap-Bereiches im Erweiterungsspeicher beträgt 1 GB. Nach einigen Tests hat sich herausgestellt, daß ein Swappen in die XMU eine unwesentliche Verschlechterung des Laufzeitverhaltens der Jobs bewirkt. Es erscheint daher möglich, bei dem derzeitigen Jobprofil den XMU-Swap-Bereich zum Hauptspeicher zu addieren und für diesen Wert die Anzahl der Queues auszulegen. Ein Auslagern auf Platte ist jedoch unbedingt zu vermeiden.
Die maximale Hauptspeicheranforderung pro Job (nicht pro Prozeß) ist bei diesem System eine der entscheidenden Kenngrößen der Queues, die zur Verfügung stehen. Das Zeitlimit ist nur dafür maßgebend, wann ein anderer Job zu rechnen beginnen kann, es kann sehr einfach an die speziellen Bedürfnisse des Projektes angeglichen werden. Das (default) Zeitlimit ist für alle Queues mit 100.000 CPU-Sekunden (27,7 h) festgelegt.
Für den Benutzer ist nur eine (Pipe) Queue sichtbar. Abhängig von den Parametern des Submit-Commands und vom User werden die Jobs in die „richtigen“ Batch-Queues eingereiht. Es sind für jedes Projekt maximal drei Klassen von Queues vorgesehen, die unterschiedliche Memorygröße zulassen (die Werte in den Klammern sind die Werte nach den Ausbau des Hauptspeichers auf 2 GB):
| Queue | sec | MB Hauptspeicher |
| PRx-large | 100.000 | 800 (1000) |
| PRx-med | 100.000 | 400 |
| PRx-small | 100.000 | 128 (150) |
Die Einrichtung dieser Queues erfolgt entsprechend den Anforderungen für das Projekt und ist mit dem Projektleiter abzustimmen.
Durch die Bildung von Queue-Komplexen und der Vergabe entsprechender Run-Limits kann eine Steuerung durchgeführt werden. Diese vorgeschlagenen Run-Limits müssen jedoch dynamisch an die jeweilige Anzahl und die Anforderungen der Projekte angeglichen werden, d.h. wenn es keine Projekte gibt, die 1000 MB Hauptspeicher benötigen, so sind die Run-Limits entsprechend zu setzen, um eine „Vollbeschäftigung“ der beiden CPUs sicherzustellen.
Die Abbildung zeigt beispielhaft die Queues und die Komplexe für drei Projekte mit den Run-Limits.
Es ist möglich, ein globales Submit-Limit für User einzurichten, d. h., wird dieses Limit erreicht, so kann der User keine Jobs in die Queue stellen. Dieses Limit gilt für alle User (global) und kann nicht auf Einzelprojekte vergeben werden. Mit diesem Limit ist es möglich, die Blockierung von Queues durch „Jobketten“ zu unterbinden. Derzeit ist ein Limit von 3 vorgesehen (d. h., ermöglicht mit dem derzeitigen Zeitparameter einen Rechenzeitblock von 83 Stunden pro User). Weiters ist vorgesehen, die Anzahl der User pro Projekt auf maximal 2 Usernummern pro Projekt zu beschränken.