System-Features fuer High-end-Server

04.03.1994

Fuer hohe Ansprueche braucht Unix Mainframe-Eigenschaften Die Aera der klassischen Mainframes neigt sich dem Ende zu. Statt ihrer erobern sich unter Unix laufende Supercomputer den Platz als Server-Maschinen im Rechenzentrum. Noch jedoch, so gibt Uwe Harms* zu bedenken, fehlen den Unix- Systemen einige Eigenschaften fuer wirklich kritische Einsatzgebiete. In vielen Diskussionen werden die zentralen Mainframes und ihre antiquierten Betriebssysteme totgesagt. In sind dagegen offene Systeme und - so moechte man sagen - private Client-Server-Umgebungen. Dort erhaelt jeder Anwender seinen persoenlichen Rechner mit einer auf seine Beduerfnisse abgestimmten Benutzeroberflaeche. Auf Grund dieser Struktur lassen sich solche Betriebssysteme vergleichsweise schlicht gestalten. Dort sind alle Anwender gleich, nur der Systemverwalter ist aufgrund seiner umfassenden Zugriffsrechte etwas gleicher. Jeder darf fast ungefragt alle greifbaren Betriebsmittel fuer sich reservieren und nutzen.Unix-Systeme arbeiten interaktiv und verwenden daher viele der Arbeitsweisen von Grossrechnern wie etwa Stapel- oder Transaktionsverarbeitung nicht. Nun koennen die Rechnerhersteller das Standardsystem zwar um Mainframe-Techniken erweitern, damit konterkarieren sie allerdings den offenen, universellen Charakter des Unix-Betriebssystems. Genau das geschieht derzeit. Doch manchmal kann sich eine solche Vorgehensweise als durchaus sinnvoll erweisen.Gerade bei Hoechstleistungs-Servern wie Workstation-Clustern, Vektorrechnern oder massiv-parallelen Systemen ist ein komplexeres System erforderlich, rudimentaere Ansaetze reichen hier nicht aus. Schliesslich verlangen Anwender, die fuer diese Computer bis zu mehreren Millionen Mark zahlen, mehr als von einem PC. Da helfen alle Client-Server-Argumente nichts: Hochleistungs-Server gehoeren in das ungeliebte zentrale Rechenzentrum oder als Abteilungs- oder Bereichsrechner in einen besonderen Raum.Benutzerverwaltung und Steuerung von Server- Systemen sind zwingend erforderlich. Die Standardeigenschaften von modernen interaktiven Betriebssystemen wie Unix reichten hierfuer bisher oft nicht aus.Erinnerungen an die 70er Jahre kommen hoch: Wie war das noch beim damaligen technisch-wissenschaftlichen Marktfuehrer Control Data Corp. (CDC) oder im kommerziellen Bereich bei den IBM-Betriebssystemen? Bekannte Mainframe-Eigenschaften werden derzeit in die modernen Betriebssysteme integriert - so schlecht waren die Dinosaurier wohl doch nicht, nur eben monolithischer.Betriebssysteme mit Mainframe-Ausstattung Erfahrene Hersteller im Supercomputing-Bereich wie beispielsweise Convex mit Convex OS und Cray Research mit Unicos haben diese Problematik, auch auf Grund des Drucks der Anwender, erkannt und ihre Erweiterungen um das Basis-Unix gruppiert. Kritikern aus dem Open- Systems-Umfeld sei jedoch eingeraeumt dass Normen und Standards Wildwuchs bei den Erweiterungen verhindern muessen.Einige der wesentlichen Betriebssystem-Eigenschaften fuer Superserver, wie sie wohl auch noch in den kommenden Rechnergenerationen vonnoeten sein werden, sollen hier aufgefuehrt werden. So stellt sich die Frage, wie der Betrieb in einem Rechnerumfeld aus einem oder mehreren Workstation-Clustern mit fuenf bis zehn Systemen, einem grossen Vektorrechner mit acht oder mehr Prozessoren oder gar einem massiv-parallelen System mit 1000 Prozessoren organisiert werden muss.Auf die Systemressourcen greifen viele zu, denn fuer einen Benutzer allein ist ein solches Rechnersystem schlicht zu teuer. Also kann jeder nur einen Anteil an den Betriebsmitteln erhalten. Ein Benutzer benoetigt vielleicht nur 100 der 1000 Prozessoren. Die verbleibende Rechnerleistung kann dann anderen Usern zugeordnet werden.In solchen Umgebungen ist ein ausgereiftes und ausgefeiltes Scheduling von Eingabe und Ausfuehrung erforderlich. Neben der interaktiven Verarbeitung muss auch ein Batch-System vorgesehen und installiert sein. Zeitaufwendige Aufgaben gehoeren nicht in den Dialogbetrieb. So muss es Batch-Job-Klassen geben, die sich beispielsweise nach benoetigter Prozessorzahl, Rechenzeit, Hauptspeicherbedarf, individueller Benutzerprioritaet, Art der Jobs und Benutzergruppe unterscheiden.Diese Batch-Warteschlangen duerfen nicht auf jeweils einer Vorrechner-Workstation abgelegt sein, sondern muessen zentral gehalten werden. Dann kann in einem Cluster der Job an die passende Server-Workstation weitergereicht werden. In diesem Aufgabenbereich haben amerikanische Hochschulen nach Loesungen gesucht und eigene Software auf Unix uebertragen, die Jobs und die Rechenlast verteilt. Damit wurden Betriebssystem- Funktionen durch Anwenderprogramme realisiert.Wird der Job ausgefuehrt, haben Scheduling und Benutzerkontrolle zu funktionieren. Zum Beispiel muss die Zahl der vom Benutzer erzeugten Prozesse begrenzt werden. Der Anwender darf das System nicht mit Aufgaben "vollaufen" lassen. Die Inanspruchnahme des Rechners muss im Mittel dem bereitgestellten Benutzerkontingent entsprechen. Daher muss ein Accounting-Verfahren online entscheiden, wie schnell ein Job im Rechner abgearbeitet wird.Ausserdem muss sich das Rechnersystem passend konfigurieren lassen. Eine bestimmte Anzahl von Prozessoren des massiv- parallelen Systems arbeitet fuer den Dialogbetrieb, andere sind fuer normale, kurze Batch-Jobs reserviert, wieder andere schliesslich haben aufwendige Jobs zu uebernehmen oder solche, die sich durch intensive Ein- und Ausgabetaetigkeit auszeichnen.Abhaengig von der Tageszeit muss automatisch auf ein anderes Bearbeitungsschema umgeschaltet werden, so dass nachts oder am Wochenende langrechnende Jobs viele Prozessoren nutzen koennen. Das klingt alles einfach und logisch, muss jedoch erst im Betriebssystem realisiert werden.Hardwareprobleme muessen geloest werden Erst ein ausgefeiltes Accounting-System ermoeglicht das Abrechnen der Jobs mit allen Ressourcen, die in Anspruch genommen wurden. Solche Informationen sind im augenblicklichen Trend zu klar vorhersagbaren Kosten immer wichtiger geworden. Die Leistung der einzelnen Workstation oder des PCs muss dagegen nicht abgerechnet werden. Aus der parallelen Abarbeitung von mehreren Jobs ergibt sich zwangslaeufig die Forderung nach der Moeglichkeit eines Checkpoint-Restarts: Jobs werden aus dem Rechner ausgelagert, andere geladen. Auch der Anwender muss diese Moeglichkeit nutzen koennen, um langrechnende Jobs gegebenenfalls in Zwischenschritten zu retten. Auf massiv-parallelen Systemen oder den Vektorrechnern werden umfangreiche Probleme geloest, die den Rechner vielleicht Tage oder Wochen in Anspruch nehmen. Wird dann durch einen Hardware-Ausfall der Job abgebrochen, kann an einer vorherigen Stelle wieder aufgesetzt werden, und nur ein kleiner Teil der Rechenzeit ist verlorengegangen.Wie aus Nutzerkreisen zu hoeren ist, treten Hardwareprobleme bei massiv-parallelen Systemen sehr viel haeufiger auf, als man es aus der Mainframe-Welt gewohnt ist. Wenn in einer terminlich knapp geplanten, industriellen Anwendung, beispielsweise dem Crash-Test eines neuen Autos, ein Job nach 20 Stunden abbricht und wieder von vorne begonnen werden muss, ist ein Checkpoint-Restart unabdingbar.Allerdings ist diese Moeglichkeit nicht einfach in ein Betriebssystem fuer Parallelrechner zu integrieren, da alle relevanten Daten des Jobs auf Platte geschrieben werden muessen. Man denke nur an das Herausschreiben der Hauptspeicher-Informationen von 1000 Prozessoren. Bei einer lokalen Speichergroesse von 32 MB pro Prozessor sind dafuer schon 32 GB Plattenplatz vonnoeten. Bei einem Plattenkanal mit einer Datenuebertragungsrate von 100 MB je Sekunde muss man bei einer derartigen Operation mehr als fuenf Minuten warten. Dabei ist noch nicht die interne Leistungsfaehigkeit des Netzwerks beruecksichtigt. Daraus wird deutlich, dass der Checkpoint-Restart nicht nur das Betriebssystem, sondern auch die Ein- und Ausgabeleistung zu unterstuetzen hat.Ein weiteres Unix-Problem sind die haeufig auf 2 GB Plattenspeicher begrenzten Dateien. Auch hier waere es sinnvoller, keine Grenzen bezueglich des Platten- und auch des Hauptspeicherplatzes zu setzen. Hier sollten Erfahrungen aus der Mainframe-Welt genutzt werden, man denke an MVS, MVS/XA und MVS/ESA.Als weitere Zusaetze haben einige Grossrechnerhersteller Operator-Schnittstellen in Betriebssystemen definiert. Der gute alte Operator wird wieder taetig, nachdem er in der Unix-Welt aufs Abstellgleis geschoben wurde.Doch ein Operator hat mehr zu tun, als sich nur um die Zugriffsrechte der Benutzer zu kuemmern, auch wenn er weniger Pflichten hat als der Systemverwalter oder Superuser. Seine Aufgabe ist es, den Ablauf im Rechner per Hand zu steuern, Jobs zu suspendieren, in der Prioritaet vorzuziehen, Baender zu montieren und taeglich modifizierte Dateien zu retten.Diese Aufzaehlung macht klar, dass in einem DV-Umfeld mit Hoechstleistungs-Servern andere Regeln gelten als am Workstation- Arbeitsplatz. Hier werden die alten Eigenschaften, fast moechte man sagen Tugenden, der Betriebssysteme der 70er Jahre neu geschaetzt.*Uwe Harms ist Unternehmensberater in Muenchen und auf Supercomputer spezialisiert.