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. Nachdem in den vorhergehenden Teilen dieser Serie die Aufgaben solcher Systeme erläutert wurden, sollen jetzt konkrete Probleme geschildert werden.
Die Entwicklung der Rechnernetze führt zu einem immer höheren Durchsatz zwischen den beteiligten Knoten. Wide Area Networks (WANs) mit Verzögerungen und beschränkter Bandbreite können durch Satellitenverbindungen, Glasfaser-Overlays und Metropolitan Networks abgelöst werden. Lokale Netze (LANs) realisieren einen Durchsatz, der etwa fünf bis 25 Prozent der Leistung eines rechnerinternen Kanals beträgt.
Das Netz muß transparent sein
Diese Erweiterung der Bandbreite und die Reduzierung der Verzögerungen, gekoppelt mit dem Preisverfall, zwingen Hersteller wie Kunden dazu, die Bedeutung von Verbindungen zwischen Systemen auf verschiedenen Software-Ebenen zu überdenken. Der wichtigste Ansatz dabei ist, das Netz transparent für den Benutzer und die Anwendungsprogramme zu machen. Transparenz bedeutet, daß die Ressourcen unabhängig von dem Ort, an dem sie implementiert sind, benutzt werden können und systemweit einheitlich benannt sind, so daß der Anwender die Gliederung in Knoten nicht sieht.
Es müssen natürlich Mechanismen zur Kontrolle einer solchen Verteilung von Ressourcen auf unterschiedliche Netzrechner existieren, um eine Optimierung vornehmen zu können. Diese Kontrolle sollte jedoch streng von den Systemaufrufen getrennt werden, die dem Zugriff auf die Ressourcen dienen.
Man steht jedoch in einigen Bereichen auch vor neuen Problemen: Software-Entwicklung und -wartung verursachen bei heutigen Rechnern immer höhere Kosten. Das Zusammenschließen einzelner Rechner zu einem verteilten System stellt einen neuen Trend dar. Dabei wird allerdings häufig vergessen, daß verteilte Software schwierig zu entwickeln und zu warten ist. Der Grund : Die Benutzerschnittstelle zum Programm ist oft anders als bisher, und im Gegensatz zu lokalen Zugriffen gestaltet sich zum Beispiel die Dateiverwaltung wesentlich komplizierter.
Aus diesem Sachverhalt läßt sich folgern, daß in einem VBS häufiger und vor allem andersartige Fehler auftreten als bisher. Dies betrifft vor allem die partiell transienten Ausfälle, bei denen ein Gerät in einer verteilten Umgebung nur vorübergehend nicht verfügbar ist. Allerdings kann in solchen Fällen die gestartete Aktion weiterlaufen, sofern das System in geeigneter Weise tolerant gegenüber derartigen Fehlern gestaltet ist. Dies betrifft besonders die Kommunikation. Stand-alone-Systeme werden üblicherweise nach dem Auftreten eines Fehlers mit der Berechnung nicht fortfahren.
Wesentliche Probleme beim Aufbau verteilter Umgebungen stellen die Durchsetzung der Transparenz auf verschiedenen Ebenen des Systems, Autonomie, Namensgebung sowie Heterogenität innerhalb der VBS-Umgebung dar. Die Lösungsansätze sind dabei keineswegs einheitlich. So kann die Transparenz in verschiedenen Ebenen des verteilten Systems realisiert werden. Denkbar sind :
- ein transparentes Nachrichtennetz im Rahmen der Device-Treiber des Betriebssystem-Kerns,
- Transparenz durch zusätzliche Software für die Verteilung der Betriebsmittel und Funktionen zwischen Anwendungen und dem Betriebssystem der Stellenmaschinen,
- Transparenz durch eine systemweit einheitliche, mit entsprechenden Ergänzungen versehene Programmiersprache; der Benutzer programmiert dann in einer virtuellen Programmierumgebung, und
- Transparenz im Rahmen einer verteilten Datenbank.
Alle Benutzer nutzen die Ressourcen
Die Transparenz auf der Betriebssystem-Ebene anzusiedeln bedeutet, daß alle Benutzer des Systems an den für sie nicht sichtbaren Ressourcen partizipieren und sie für ihre Bedürfnisse zuschneiden können (Customizing). Dafür wird ein globaler Namen-Abbildungsmechanismus gebraucht. Es müssen eine standardisierte Interprozeß-Kommunikation im Netz und verteiltes Wiederaufsetzen nach Systemausfällen möglich sein. Ist die Transparenz im Datenbanksystem oder in der Programmiersprache realisiert, kommen ausschließlich die Benutzer in ihren Genuß, die diese Produkte auch verwenden. Dies hat besonders dann Schwierigkeiten zur Folge, wenn eine Anwendung in mehreren Umgebungen benutzt wird.
Verteilungsmechanismen lassen sich in einer Programmiersprache zur Verfügung stellen. Dazu sollte sie mit entsprechenden Sprachprimitiven, die die Erstellung von verteilten Programmen erleichtern, ausgestattet sein.
Compiler und Runtime-System sind zudem verantwortlich für eine Reihe von Services. So wird oftmals ein Remote Procedure Call (RPC) als zentrales Element einer solchen Lösung angegeben. Wichtig ist dabei, daß die Remote-Ausführung einer Aufgabe möglichst genauso gehandhabt werden kann, als wäre sie lokal abzuarbeiten. Restriktionen sind mit unter notwendig
Manchmal sind jedoch Restriktionen nötig, zum Beispiel das Verbot des Sharings globaler Variablen unter den Prozeduren, die an verschiedenen Stellen ausgeführt werden. Durch spezielle Protokolle lassen sich solche Variablen in einem LAN unterstützen, ohne daß die Leistung gravierend sinkt.
Dennoch kann es zu Schwierigkeiten bei der Semantik der Programmausführung kommen. An dieser Stelle sei darauf hingewiesen, daß Idee und Realisierung einer solchen Sprache nicht notwendigerweise nur durch ein VBS, sondern auch durch andere anwendungsbezogene Systemarchitekturen, etwa IBMs SAA, unterstützt werden. Digital Equipment verwendet beispielsweise für Decnet eine universelle E/A-Sprache als Vorform einer die Transparenz unterstützenden Programmiersprache.
Neben der Transparenz gehört die Benennung von Objekten zu einer der wesentlichen Aufgaben in verteilten Umgebungen. Schwierigkeiten entstehen oft durch eine kontextunabhängige Abbildung zwischen Ressourcen und Namen, da zur Wahrung der Ortstransparenz unbedingt eine Abhängigkeit zwischen Stellennamen und Objektnamen vermieden werden muß. Eine globale Benennung aus der Perspektive einer Stelle hilft hier nicht weiter. Es ist immer vorstellbar, daß zwei oder mehrere gleiche Namen entstehen, die in verschiedenen Umgebungen verschiedene Bedeutung haben.
Fragen, die im Zusammenhang mit Heterogenität auftreten, seien hier nur kurz erwähnt. Sie werden sowohl bei den Rechner- und Netzwerktypen als auch bei den verschiedenen Betriebs- und Dateisystemen relevant.
Unterschiede zwischen den Rechnern im Netz bestehen vor allem in Instruktionssätzen, Datenrepräsentationen und in der Konfiguration. Detaillierte Schilderungen zum Themenkreis Heterogenität findet sich in: Baumgarten, U., Kauffels, F.-J., Verteilte Betriebssysteme: Fundament von Integration und Automatisierung moderner Unternehmensnetze und deren Operation, Serie in der Zeitschrift "Datacom", Hefte 3,5,6,8, Bergheim 1992.
Entwicklungstrends bei Betriebssystemen
Die Weiterentwicklung von Betriebssystemen läuft zweigleisig. Einerseits werden die derzeit gängigen Produkte den neuen Anforderungen angepaßt. Andererseits entstehen in zunehmendem Maße neue Systeme, die von Haus aus für verteilte Datenverarbeitung konzipiert sind.
Vorangetrieben wurde die Innovation in den letzten Jahren durch den Unix-Boom. Die zunehmende Verbreitung des Multiuser-Betriebssystems sowie seiner Derivate und vor allem die damit verbundenen Standardisierungsbemühungen haben es zu einem zentralen Produkt auch für die verteilte Datenverarbeitung reifen lassen.
Diese Aktivitäten werden von unabhängigen Organisationen, Anwendergruppierungen und von Herstellerkonsortien getragen. Zu nennen sind in diesem Kontext die Open Software Foundation (OSF), Unix International (UI), das X/Open-Konsortium, das Standardisierungsgremium Posix sowie Herstellerzusammenschlüsse wie die inzwischen auseinandergebrochene ACE-Gruppe und die gemeinsamen Aktivitäten der Firmen IBM und Apple.
Ziel all dieser Organisationen ist es, vorhandene Techniken und Schnittstellen zu vereinheitlichen, wobei nicht selten eine Gruppe ihren Standard gegen den einer anderen durchzusetzen versucht.
Für den Netzwerkbereich von Bedeutung sind vor allem das TCP/IP-Protokoll sowie das Network Computing System (NCS) und Open Network Computing (ONC).
Bei verteilten Umgebungen spielen vor allem OSFs Distributed Computing Environment DCE und Objekttechniken wie Distributed Objekt Management Facility (DOMF) eine Rolle. (wird fortgesetzt)