Der Grad der Vernetzung ist drastisch angestiegen. Das weitgehende Fehlen adäquater Hilfsmittel für die Steuerung vernetzter Umgebungen läßt nun die Anwendung von Betriebssystemen, die auf eine einzelne Maschine beschränkt sind, fraglich erscheinen. Gefordert sind jetzt verteilte Betriebssysteme (VBS), die Netze und angeschlossene Rechner als logische Einheit steuern können. Im vierten Teil dieser Serie werden nun zwei konkrete Produkte vorgestellt.

Man kann grob folgende Klassen verteilter Betriebssysteme unterscheiden:

-- VBS-Kerne mit minimaler Funktionalität,

-- integrierte Systeme,

-- objektorientierte Systeme und

-- Systeme, die auf einem Server-Pool-Modell basieren.

Diese Einteilung schließt nicht aus, daß ein System mehreren Klassen angehört. Es kann beispielsweise auf einem Server-Pool-Modell beruhen und dennoch objektorientiert sein.

VBS-Kerne bieten eine fast minimale Anzahl von Funktionen fur das Prozeß-Management, die Speicherverwaltung den Nachrichtenaustausch und die Verwaltung von Hintergrundspeicher-Medien an. Beispiele hierfür sind Accent und Mach von der Carnegie Mellon University (siehe Literaturhinweise Nr. 1 und 2) sowie der V-Kernel der Stanford University (siehe Lit. Nr. 3).

Kompatibel zu älteren Programmen

Integrierte Systeme ermöglichen es, auf jeder Maschine eine in weiten Grenzen konfigurierbare Standardsoftware laufen zu lassen, die die Maschine mit allen benötigten Hilfsmitteln versorgt. Solche Umgebungen entstanden im Umfeld der Betriebssystem-Entwicklung von Unix. Sie stellen daher teilweise die bisherigen Unix-Funktionen zur Verfügung, so daß eine gewisse Kompatibilität zu älteren Programmen gewährleistet ist. Beispiele sind Locus, anfangs entwickelt an der University of California, L.A. und zur Produktreife durch die Locus Inc. geführt (siehe Lit. Nr. 4), D-Unix von den Bell-Laboratories (siehe Lit. Nr. 11), Birlix von der GMD (siehe Lit. Nr. 5), das Cambridge Distributed Operating System (siehe Lit. Nr. 6) und Saguaro von der University of Arizona.

Objektorientierte Systeme halten für die Anwendungen die Sichtweise der abstrakten Objekte und der auf ihnen durchzuführenden ebenfalls abstrahierten Operationen streng durch. Das ist unter anderem der Fall bei Argus vom Massachusetts Institute of Technology MIT (siehe Lit. Nr.7), Eden von der University of Washington (siehe Lit. Nr. 8) Amoeba von der Vrije Universiteit Amsterdam (siehe Lit. Nr. 9).

Systeme, die auf einem Server Pool Modell beruhen, stellen dem Benutzer je einen Verbund von Servern für die angestrebten Services zur Verfügung. Ein einfaches System dieser Klasse ist das Cambridge Distributed Opetating System.

Die grundlegenden Entwicklungen von VBS sind schon bis zu zehn Jahre alt. Solange benötigen Betriebssysteme, um in eine industriell verwertbare Reife zu kommen. Von den vielen Beispielen seien zwei besonders wichtige vorgestellt. Hinweise auf andere enthält die angegebene Literatur. Eine neue Sammlung von VBS und verwandten Systemen gibt Borghoff (siehe dit. Nr. 10)

Das Locus-VBS ist wohl das erste, das Serienreife erreicht hat. Eine VBS-Entwicklung läßt sich technologisch am ehesten im Unix-Bereich ansiedeln. Diese Historie kann auch Locus nicht verleugnen, das schon deshalb besondere Aufmerksamkeit verdient, weil es unter der Bezeichnung TCF zur ersten Realisierung eines verteilten Betriebssystems der IBM geführt hat. Die bei jeder neuen Entwicklung geäußerten Zweifel, ob IBM so etwas auch mitmacht, lassen sich daher im Bereich der VBS sofort ausräumen.

Verteilte DV mit dem

Locus-Betribssystem

Das Locus-Betriebssystem stellt eine verteilte Version des Unix-Betriebssystems dar. Es besitzt zusätzliche Eigenschaften zugunsten der bei einer verteilten Betriebsweise besonders hohen Anforderungen an Zuverlässigkeit und Verfügbarkeit. Das System erlaubt die transparente Benutzung einer großen Anzahl vernetzter Computer durch die Bereitstellung vieler zugrundeliegender Netzfunktionen. Diese Transparenz reduziert die Kosten für die Software-Entwicklung und -Pflege drastisch und verbessert die Benutzerfreundlichkeit deutlich. Zusätzliche Systemflexibilität Workstations ohne Laufwerke, Vollduplex, Großrechnerzugriff, gemeinsam genutzte transparente Peripherie und inkrementelles Wachstum über einen großen Konfigurationsbereich sind weitere Kennzeichen des Systems.

Transparenz wird durch ein heterogenes Netz mit vielen verschiedenen Rechnern gewährleistet. So lassen sich Programmteile auf dafür spezialisierte Maschinen auslagern und dort anwenden, ohne daß es für den Benutzer einen zusätzlichen Aufwand bedeutet.

Locus unterstützt neben konventionellen Gateways die Korrespondenz mit vernetzten Maschinen, die mit anderen Betriebssystemen arbeiten. Dadurch können mit einigen Parameteränderungen auch bestehende Anwendungsprogramme im Netzenvironment verfügbar gemacht werden. Locus bietet eine Reihe von Möglichkeiten, um Ressourcen im Verteilten System wiederzufinden.

Wesentlicher Bestandteil von Locus ist ein Dateisystem, das auch unter ungünstige Umständen Datenkonsistenz mit Hilfe eines Commit-Mechanismus sicherstellt.

Neben den traditionellen SNA- und SAA-Konzepten baut IBM im Hinblick auf den Einsatz in technisch-wissenschaftlichen Bereichen auch die AIX-Linie aus. Die Kooperation mit Locus hat im Hinblick auf verteilte Systeme interessante Ergebnisse erbracht. So stellt TCF für das AlX-Unix eine Teilimplementierung des Locus-Konzeptes dar.

IBMs TCF erlaubt das Zusammenschalten von bis zu 31 Systemen zu einem Cluster. Die Komponenten können ein buntes Gemisch aus PS/2 der Modelle 70 und 80, RS/6000-Rechnern und einigen /370-Modellen darstellen. Das Betriebssystem setzt die Verwendung eines Ethernetoder Token-Ring-LANs voraus, zumindest aber Kanalverbindung (Channel-to-Channel-Adapter CTCA). Es arbeitet unmittelbar mit dem LAN zusammen. Die logische Verbindung auf Prozeßebene wird durch ein Token-Protokoll synchronisiert welches auf dem Internet Protocol (IP) von TCP/IP basiert. TCP oder UDP werden nicht benutzt. Diese Art der Prozeßkopplung nutzt das LAN optimal, da die Verzögerungszeiten der Logical Link Control vorausgesetzt werden können.

Das Cluster erscheint den Benutzern als ein einziges einheitliches System. Die Menge der vernetzten Rechner wird auf Prozeßebene richtiggehend zusammengeschaltet. Weder Benutzer noch Anwendungsprogramme müssen wissen, wie die Systeme gekoppelt sind oder wo die Daten im einzelnen liegen. Ein Anwender ,der sich bei irgendeimen der TCF-AIX-Systeme anmeldet, hat Zugriff zu allen Ressourcen aller Rechner im Cluster.

Benutzerprozesse laufen auf einer beliebigen CPU im System, unabhängig davon, auf welchem Rechner der Anwender angemeldet ist. Darüber hinaus können, geeignete Programmierung vorausgesetzt, verschiedene Prozesse zwischen den Zentraleinheiten aufgespalten werden. Ein Editiervorgang läßt sich beispielsweise auf ein PS/2-System auslagern, während eine kompliziertere Berechnung auf dem Host abgearbeitet wird. Für Administratoren ist es sogar möglich, einen laufenden Prozeß von einem System aufein anderes umzuleiten.

Alle Betriebsmittel im Cluster erhalten einen einheitlichen Namen und werden von allen Stellen aus mit diesem Namen referenziert (Namenstransparenz). Objekte können die Maschine wechseln, ohne daß sich dabei aus der Perspektive der Benutzer etwas ändert (Ortstransparenz). Kommandos und Optionen ergeben immer den gleichen Effekt, gleichgültig, wo man sie aufruft (semantische Transparenz).

Im Gegensatz zu der generellen Zielvorstellung bei verteilten Systemen wird die Auslastung nicht automatisch ausgeglichen. Dafür hat die IBM spezielle Kommandos vorgesehen.

Die Verwaltung des AlX-Clusters ist denkbar einfach. Computer können nach Bedarf hinzugefügt oder weggenommen werden. Das TCF bemüht sich stets darum, so viele Ressourcen wie möglich verfügbar zu halten. Dies ist vor allem für Anwendungen sinnvoll, die eine gewisse Zuverlässigkeit verlangen. Dort kann TCF die Bereitstellung einer Mindestleistung vornehmen.

Locus und TCF sind wichtige Prototypen der VBS-Technologie, die jedoch beide nicht vermarktet werden, sondern als Beispiele für die Realisierbarkeit verteilter Betriebssysteme dienen. Die Hersteller haben eingesehen, daß das Beharren auf einer proprietären Betriebssystem-Welt unangemessen und auch zu teuer ist. So stehen heute die Techniken von Konsortien wie der Open Software Foundationen (OSF) im Vordergrund. Diese Entwicklung soll in der nächsten und abschließenden Folge unserer Serie behandelt werden.

Litereratur:

1. Fitzgerald; Rashid: The integration of virtual memory management and interprocess communication in Accent: Proc. 10th International Symposion on Operating Systems Principles, ACM New York 1985

2.Rashid ; Robertson: Accent: A communication oriented network operating system kernel:Proc. 8th Int. Symp. on Operating Systems Principles. ACM New York 1981

3. Cheriton: The V Kernel: A Software Base for Distributed Systems, IEEE Soft ware, Band 1, Nr. 2, April 1984

4. Popek; Walker: The Locus Distributed System Architecture, MIT Press, Cambridge 1985

5. Goos, G.; Härtig, H.; Kühnhauser, W.E.;- Streich, H.: Structure of the Birlix Operating System GMD,Jahresbericht 1985, Selbstverlag GMD 1986, und dieselben: Distribution in the Birlix Operating System, NTG-Fachberichte, Band 1992, VDE-Verlag 1986

6. Needham; Herbert: The Cambridge Distributed Operating System, Addison Wesley, Reading 1982

7. Liskov ;B.: Overwiev of the ARGUS language and system, Lab. for Comp. Sc., MIT, Cambridge, Massachusetts, Februar 1984

8. Almes; Black; Lazowska; Noe: The EDEN System, a technical rewiev, IEEE ToSE, SE-l l, Januar 1985

9. Mullender, Tanenbaum: The Design of a Capability-Based Distributed Operating System, The Computer Journal, Band 29, Nr.4, 1986

10. Borghoff: A Catalogue of Distributed File/Operating Systems, Springer Verlag Berlin-Heidelberg-New York 1992

11. Che; Haggerty; KirslÝs; Luderer; Marshall: A Distributed Unix System based on a virtual circuit switch, ACM New York 1981