Verteilte Betriebssysteme

Vortrag im Fach Rechner- & Betriebssysteme der Bauhaus - Uni - Weimar

Marco Heinszmann

Gliederung:

(1) Begriffsdefinition

(2) Warum verteilte Systeme? - Anwendungsgebiete

(3) Anforderungen an verteilte Betriebssysteme

Gemeinsame Ressourcennutzung
Performance
Zuverlässigkeit
Skalierbarkeit
Offenheit
Transparenz

(4) Hard- und Softwarearchitekturen

(5) Spezifikationen von verteilten Systemen

(6) CORBA ( Common Object Request Broker Architecture )

Begriff:

Ein verteiltes System ist ein Gebilde aus autonomen Rechnern, die dem Benutzer als ein System erscheinen.
[ Tannenbaum ]
Ein verteiltes System ist ein Gebilde aus autonomen Rechnern, die über ein Netzwerk verbunden sind und mit einer verteilten Systemsoftware ausgestattet sind.
[ Coulouris ]
Ein verteiltes System ist ein System mit räumlich verteilten Komponenten, die keinen gemeinsamen Speicher benutzen und einer dezentralen Administration unterstellt sind. Zur Ausführung gemeinsamer Ziele ist eine Kooperation der Komponenten möglich. Werden von den Komponenten Dienste angeboten oder Dienste genutzt, so entsteht ein Client/Server - System, im Falle einer zusätzlichen zentralen Dienstvermittlung ein Tradingsystem.
[ Spaniol, O. ; Popien, C. ; Meyer B. : Dienste und Dienstvermittlung in Client/Server - Systemen ]
immer:mehrere Rechner ( Standort ist beliebig )
immer öfter: autonome Rechner ( Multiprozessoren , LAN, WAN ) Bearbeitung einer gemeinsamen Aufgabe

Einige wichtige Gründe für verteilte Systeme:

Wirtschaftlichkeit
- Risiko der Überlastung einzelner Systemkomponenten wird verringert,
- Rechenleistung wird gebündelt,Parallelität
- gemeinsame Nutzung von Ressourcen
- Im Falle von Ausfällen arbeitet jede Komponente autonom und kann so ggf. den Ausfall von einzelnen Komponenten überbrücken.
Anwendungen mit verteiltem Charakter
- örtliche Verteilung z.B. bei Flugresevierungssystemen, Klinikinforationssystemen
- Quellen von Informationen, Verarbeitungseinheiten und Nutzer können physisch mobil sein.

Wichtigste Anwendungsgebiete:

Road Traffic Informatics
CIM Computer Integrated Manufacturing
Medizin ( Telemedizin )
Multimedia

Anforderungen an verteilte Systeme:

gemeinsame Ressourcennutzung Performance ( Parallelität , Kommunikation )
Zuverlässigkeit ( Fehlertoleranz , Sicherheit )
Offenheit
Skalierbarkeit
Transparenz ( Ortstransparenz , Fehlertranparenz )

Gemeinsame Ressourcennutzung

typische Ressourcen:

Simulation, VR
Datenbanken
Schlüssel- und Passwortverwaltung
globale Informationsdienste im WWW
Printer Services
Client / Server - Paradigma:
Verteilte Objekte ( Distributed Objects ) - Paradigma

Performance

einer der Hauptanwendungsgebiete verteilter Systeme: Parallelisierbarkeit
Parallelisierbarkeit bei z.B. :
- Simulation
- Dateizugriff
- Login
- E - mail Diensten verschiedener Benutzer
erzielbare Wirkung hängt ab von:
- dem Grad der Parallelisierbarkeit des Problems
- Kommunikationsvolumen zwischen Komponenten
- Fehlertoleranzstrategien
- Sicherheitsstrategien ( evtl. aufwendige Verschlüsselungsmechanismen)
Methoden zur Erzielung von Parallelität
- Algorithmenentwurf
- Komponentenentwurf: Trennung von Diensten, Mehrfachinstallation
- Aufgabenverteilung und Koordination
- Lastverteilungsschemata, Migration ® siehe ff.

Zuverlässigkeit

Verfügbarkeit
- ein weiteres wichtiges Pro für verteilte Systeme
- bei einem Ausfall arbeitet das Restsystem ( mit verminderter Leistung ) theoretisch weiter
Sicherheit
Ziele:
- Schutz gegen unbefugten Zugriff auf Daten oder deren Manipulation
- Nicht - Abstreitbarkeit eingegangener Verpflichtungen
- Schutz gegen unbefugte Ressourcenreservierung
Verletzung der Schutzmechanismen erheblich schwieriger als bei monolithischen Systemen durch:
- offene, unkontrollierbare Umgebung
- unterschiedliche Betriebssysteme

Skalierbarkeit

Eigenschaft eines ( verteilten ) Systems, seine Größe ohne Veränderung von System- und Anwendersoftware modifizieren zu können
Anzahl der Benutzer, Workstations, Servermaschinen, Subjekte, Objekte, Clients, Servers sind variabel
Problembereiche sind zentrale Tabellen, Komponenten, Algorithmen

Offenheit

Eigenschaft eines ( Verteilten ) Systems, seine Funktionalität oder Größe erweitern zu können und , verschiedene Komponenten auf verschiedenen Verarbeitungsknoten verarbeiten zu können.
- Hardware: neue Komponenten und Systeme
- Software: neue Dienste, Protokolle
Methoden zur Erzielung von Offenheit:
- Offenlegung von Schnittstellen ( Standardschnittstellen )
- Standardisiertes IPC
notwendig: Wandel der Betriebssysteme

Transparenz

(Un-) Sichtbarkeit der Verteilung von Systemkomponenten
verschiedene Komponenten auf verschiedenen Verarbeitungsknoten verarbeiten zu können.
Transparenz bei:
- · Kommunikation ( lokale und entfernte Objekte werden nicht unterschieden )
- Parallelität ( verschiedene Prozesse nutzen gleichzeitig Objekte, ohne sich gegenseitig zu bemerken )
- Fehlern ( Ausgleichen von Ausfällen durch andere Systemkomponenten )
- Performance ( Leistungsfähigkeit kann z.T. vom System selbst dynamisch angepaßt werden )
- Skalierung

Hardware - Architekturen

allen verteilten Systemen gemeinsam: mehr als ein Prozessor
Klassfikationsschema
- Mehrprozessorsystem: ein einziger, allen Prozessoren gemeinsamer Adressraum
- Mehrrechnersystem: jeder Prozessor hat einen eigenen Adressraum
- Bus: ein Medium verbindet alle Prozessoren
- Kanal: ein separates, geschaltetes Medium verbindet je zwei Prozessoren

Software - Architekturen

Netzwerk - Betriebssysteme
- hohe Autonomie
- inhomogen
- Rechnergrenzen immer noch deutlich sichtbar
Verteilte Betriebssysteme
- einheitliche IPC - Mechanismen
- transparente IPC - Mechanismen
- einheitliches Prozeßmanagement: erzeugen, starten , stoppen
- einheitliches Dateisystem
- einheitlicher Namensraum
- einheitliches Schutzsystem: Benutzeradministration, Mechanismen

Spezifikationen von verteilten Systemen

(1) ODP( Open Distributed Processing )
Wurde von ISO/IEC und ITU-T ( internationale Normierungseinrichtung der Telekommunikationsgesellschaften ) genormt
(2) OSI - Systemmanagement - Managed Objects
(3) CORBA
Object Management Group (OMG),
- mittlerweile mehr als 800 Unternehmen, Unis und Forschungsinstitute
- OMG fehlt allerdings Microsoft, da die ihr eigenes Component Object Model (COM) vorziehen
(4) OSF - Architektur DCE ( Distributed Computing Environment)
OSF ( Open Software Foundation ) - Non - Profit - Organisation
DCE
- Integrierte Menge von Diensten - Plattform welche Entwicklung, Nutzung, und Wartung von verteilten Anwendungen unterstützt
- betriebssystem- und netzwerkunabhängig, kompatibel zu existierenden Umgebungen
- Nachteil: nicht objektorientiert
(5) ANSA - Architektur
· APM 1984
· APM Ltd. Ist Mitglied der OMG
(6) TINA ( Telecommunikations Information Networking Architecture Consortium )
- 1993 gegründet; meist Mitglieder aus Telekommunikationsbranche ( Informationsanbieter, Netzwerk, Dienstbetreiber )
- speziell auf neue Dienste aus Bereichen Multimedia, Telekommunikation, mobile Breitbanddienste ausgerichtet

CORBA ( Common Object Request Broker Architecture ) Die einzelnen Komponenten Der Object Request Broker Als zentrale Komponente im System, dient er der Kommunikation der einzelnen Objekte, Services, Applications usw. untereinander. Grob ausgedrückt liefert er einen Bus, auf den eine Nachricht raufgesprochen werden kann und die auf der anderen Seite auch irgendwann jemand vielleicht interessiert, der sie dann liest. Auf Grund der Wichtigkeit wurde diese Komponente auch als erstes spezifiziert. Application Objects Damit sind die speziellen Lösungen für den Anwender gemeint, also alle Arten von Software, die die anderen Komponenten als Basis für eine umfangreiche Arbeitsumgebung nehmen will. Common Facilities Wenn die Common Object Services die Basisdienste zur Verfügung stellen, dann liefern die Common Facilities (CF) höherwertige Dienste, die aber von allgemeinerem Interesse sind. Es wird unterschieden zwischen Horizontal CF, die Dienste für alle Arten von Anwendungen bereitstellen und Vertical CF, die spezialisierte Dienste für bestimmte Anwendungsgebiete (Z. B. Finanzen, CAD) zur Verfügung stellen. Die CF sind erst in der letzten Zeit angegangen worden, da man zuerst die Basisdienste spezifizieren wollte. Mit verwertbarem Material wird Ende 1996 gerechnet. Es sind aber schon einige Details absehbar, da die meisten (horizontal ist erstmal interessanter) CF angepaßte de-facto-Standards sein werden. So wird man im Bereich Compound Documents CF sich nah an OpenDoc halten und im Bereich System Management CF wird man mit X/Opens SysMan und Tivoli (TME Tivoli Management Environment) schon nahe dran sein. Common Object Services (COS) Sind die nach dem ORB wichtigste Komponente, die bei der Programmierung/Softwareentwicklung die grundlegenden Dienste (Basisdienste) und Handles zur Arbeit mit Objekten zur Verfügung stellen. Einige von ihnen werden später noch genauer dargestellt, darum hier nur ein kurzer Einblick.