einführung in verteilte systeme - vsis homepage · © wl vsis inf min uni hh 07_08 vis2-einf-1...

VIS2-Einf-1© wl vsis inf min uni hh 07_08

Einführung in verteilte Systeme: Motivation,

Definition und Charakteristika

Einführung in verteilte Systeme: Motivation,

Definition und Charakteristika


Verteilte Anwendungen bzw. Systeme:Kooperation in verteilten Umgebungen

z.B. "Electronic Commerce/E-Business"

Basis:Integration weltweiterRechnernetze(Inter-/Intranets)

• Unterschiedliche Rechner- und Betriebssystemtypen• Vielfältige (Teil-) Netze / Kommunikationsmechanismen• Unterschiedliche (Sub-) Organisationen• Autonome Datenhaltung• Vielfältige Anwendungen• ...

„offener verteilter Markt von Diensten"

Grundvoraussetzungen:Heterogenität und Autonomieauf ganz verschiedenen Ebenen, z.B.


Zur Geschichte der Datenverarbeitung

• 1950er Jahre: Einbenutzersysteme• 1960er Jahre: Batch Processing• 1970er Jahre: Mehrbenutzersysteme• 1980er Jahre: Personal Computing• 1990er Jahre: Verteilte Systeme• 2000er Jahre: Mobile, ubiquitäre Systeme

• viele Prozessoren• viele Speichereinheiten• Kommunikationsnetzwerke• größere Zuverlässigkeit ('fault tolerance')• mehr Fähigkeiten (z.B. Parallelität)• Systemverwaltung (!)

+ allgemein: Grafik, Farbe, Multimedia, etc....

"VerteilteSysteme":


Allgemeine verteilte Anwendungen: Beispiele ...

• Überregionale bzw. internationale Unternehmen (Verwaltung von Kundenverzeichnissen, Auftragsbeständen, Produktionsplänen, Lagern, Bestellwesen etc.)

• Reservierungssysteme von Fluggesellschaften, Hotelketten, Autovermietung, Reisegesell-schaften usw.

• Auskunfts- und Auszahlungssysteme bei Banken

• Unterstützung der Büroautomatisierung

• Integrierte Entwurfs-, Planungs- und Produktionssysteme

• Messstellenerfassung und -auswertungssysteme im Bereich der Immissionskontrolle

• Elektronische Mail- und Conferencing-Systeme

• Campus-/Büro-/Filial-(etc.) Netze

• Planung und Verfolgung des Laufes von Zügen bei der Bahn

• Navigationssysteme für viele, autonome, bewegliche Einheiten

• etc.. . . z.B. … + Verteilte elektronische Bibliotheken / Informationssysteme+ Electronic Commerce / E-Business+ Ubiquitäre / mobile Systeme


Motivation für verteilte Systeme (gegenüber zentralisierten Systemen)

• mangelnde Möglichkeiten der Zentralrechner

(Antwortzeiten, Interaktivität, Benutzerschnittstellen, Grafik ...)

• Anforderungen neuer Anwendungen

(grafische Benutzerschnittstellen, kurze Antwortzeiten ...)

• weite Verbreitung mächtiger PCs und Workstations

• fortgeschrittene Netztechnologien (LAN, WAN, MAN, wireless...)

• gemeinsame Nutzung von Ressourcen (bzw. „Diensten“)

• geringere Hardware-Kosten (!?!) --> Grosch's Gesetz ???


Gründe verteilter Verarbeitung: technisch

Es ist technisch machbar

Reduktion der AntwortzeitenHöhere Verfügbarkeit

Modulare Wachstumsfähigkeit

Geringere Kosten

Höhere Sicherheit

Möglichkeit der Verarbeitung vor Ort vs. lange Anfrage an Zentralrechner (insbesondere bei räumlich weit verteilten Anwendungen)

Bei der Verwendung vieler Komponenten betrifft der Ausfall eines Systems nur eine kleine Gruppe von Benutzern/ Daten/ Funktionen - u.U. bleibt sogar die volle Funk-tionalität erhalten.

Da das Architekturprinzip die Kooperation unabhängiger Komponenten ist, ist die Hinzunahme weiterer Komponenten im laufenden Betrieb eine normale, ohnehin vorgesehene Operation.

Die aktuelle Größe des Systems kann wegen der Modularität dem jeweiligen Bedarf besser angepasst werden. N 'kleine' Systeme mit jeweiliger Leistung x sind i.d.R. deut-lich billiger als ein 'großes' System mit Leistung n*x mit gleicher Verfügbarkeit.

Dieser oft behauptete Vorteil erscheint i.a. eher fragwürdig.


Gründe verteilter Verarbeitung: anwendungsspezifisch

Viele Organisationen sind räumlich verteilt und arbeiten hochgradig autonom

Anwendungen werden zunächst für eigene lokale Zwecke entwickelt und erst später (ev.) integriert

Arbeit erfordert PCs, Workstations, Mini- oder Großrechner, Number-Cruncher oder...

Bsp.: Fluglinien mit Reisebüros, Banken mit Investmentfirmen, Firmenzentrale mit neu erworbener Tochterfirma etc.

Autorisierung entspricht Verantwortlichkeit

Die Abteilung will ihre eigene Maschine

Verschiedene Benutzer (-klassen) haben unterschiedliche Anforderungen

Integration verschiedener, zunächst unabhängig entwickelter Teilsysteme


Charakteristika verteilte Systeme

Viele Prozessoren, Speicher, Subsysteme...

Kopplung autonomer Verarbeitungsknoten (Prozessor/Speicher-Paare) durch ein Kommunikationsmedium

Kommunikation zwischen verschiedenen Knoten erfolgt nur über Nachrichten-austausch

Vorhandensein eines gemeinsamen Ziels, bereitgestellte Leistung wird durch arbeitsteilige Kooperation erbracht

Verteilungstransparenz (mindestens Orts- und Zugriffstransparenz)

Kein gemeinsamer Speicher - aber:

Gemeinsames Wissen um gemeinsamen System(teil-)zustand

Keine allen gemeinsame Fehlerquelle

Unabhängiges Fehlerverhalten der Teilsysteme


Charakteristik verteilter SystemeDefinition: „A distributed system is a collection of independent computers that appears to its users as a single coherent system“

Beispiele zur Abgrenzung:

• Multiprozessorsystem mit gemeinsamen Speicher+ mehrere Prozessoren,Verteilung, Kommunikation - kein unabhängiges Fehlerverhalten!

• Ethernet-LANs mit verbindenden Bridges+ viele Prozessoren,Verteilung, Kommunikation, unabhängiges Fehlerverhalten - kein gemeinsamer Zustand!

• Diskless Workstations mit NFS-Server+ viele Prozessoren, Verteilung, Kommunikation, unabhängiges Fehlerverhalten - kein gemeinsamer Zustand!


Architekturalternativen:"Lose" vs. "eng" gekoppelte (verteilte) Systemalternativen

Spei.

Cach.

Proz.

I/O

LAN

Proz.

Programm

Prog.

Cach.Proz.

Prog.

Cach.Proz.

Prog. GemeinsamerSpeicher

I/O

SP

SP

SP

SP

. . .

. . .

I/O

lose gekoppelt

eng gekoppelt

Array Processor

ProgSpei.

Proz.

I/O

ProgSpei.

Proz.

I/O

Prog

SingleInstructionMultipleDataProgramm

Cach.


Vorteile verteilter Systeme

+ Abbild organisatorischer Gliederungen (!!!)

+ Erweiterbarkeit / Skalierbarkeit / Modularität

+ höhere Zuverlässigkeit und Verfügbarkeit

+ Replikation (Redundanz!)

+ unabhängiges Fehlerverhalten

+ kurze und vorhersehbare Antwortzeiten (--> Workstations)

+ Kostenvorteile (Hardware vs. Software !?!)

+ Sicherheit (???)


Nachteile verteilter Systeme

- Abhängigkeit vom Netzwerk („Interconnectivity“)(Netzwerkpartionierung, zusätzliche Fehlerfälle)

- Interferenzen / Abhängigkeiten von Teilkomponenten

- Propagieren von Effekten (z.B. Fehlern)

- Folgen hoher Komponentenzahl (Engpässe!)

- Partielles Fehlerverhalten

- weniger Flexibilität bei der Zuweisung von Ressourcen

- kein gemeinsamer Zustand (auch: keine gemeinsame Uhr)

- Sicherheit (Verteilung, offene Server-Schnittstellen, BS-Nachrichten,...)

- Koordinationsprobleme (!!!)


Prinzip verteilter Client/Server-Systeme: Verteilte Dienstnutzung und -koordination

2 wichtige Aspekte: Kooperation und Transparenz

Knoten BKnoten A

Knoten C Knoten D

Maschinengrenzen

Softwarekomponenten

Kommunikation


„Transparenz“-Eigenschaften verteilter Systeme

• ZugriffsZugriffstransparenz

• OrtsOrtstransparenz

• NebenlNebenlääufigkeitsufigkeitstransparenz

• ReplikationsReplikationstransparenz

• FehlerFehlertransparenz

• MigrationsMigrationstransparenz

• LeistungsLeistungstransparenz

• SkalierungsSkalierungstransparenz


„Transparencies“ (nach Coulouris/Dollimore/Kindberg)

• Access transparency: enables local and remote resources to be accessed using identical operations.

• Location transparency: enables resources to be accessed without knowledge of their location.

• Concurrency transparency: enables several processes to operate concurrently using shared resources without interference between them.

• Replication transparency: enables multiple instances of resources to be used to increase reliability and performance without knowledge of the replicas by users or application programmers.

• Failure transparency: enables the concealment of faults, allowing users and application programs to complete their tasks despite the failure of hardware or software components.

• Mobility transparency: allows the movement of resources and clients within a system without affecting the operation of users or programs.

• Performance transparency: allows the system to be reconfigured to improve performance as loads vary.

• Scaling transparency: allows the system and applications to expand in scale without change to the system structure or the application algorithms.


Techniken zur Realisierung verteilter Systeme

• Fragmentierung von Daten

• Lokale Kopien (Replikation) entfernter (HW+SW) Komponenten zur Effizienz- und Verfügbarkeitssteigerung ('Caching', 'Stashing', o.ä.)

Generelles Problem: „Tradeoff“ Verfügbarkeit vs. Konsistenz

Ziel: hohe Lokalität der Daten

• Partitionierung von komplexen Diensten (z.B. Datenverwaltung)

• Aufrufe entfernter Dienste und Funktionen (Zugriff auf entfernte Ressourcen z.B. mittels ‚Remote Procedure Call‘, RPC)

• zustandslose vs. zustandsbehaftete Server


Netz-Systemalternativen:„Workstation/Server“-Modell

LAN

WS WS

WS

WS

WS

Druck-Server

- 1 Prozessor pro Benutzer (Graphik...)

- Data Sharing via File Server (Programm, DB, SW-Lib. Bull. Board, Doku.,...)

- spezialisierte Server zur Nutzung gemeinsamer Ressourcen (!)

- Bsp. V-System [Stanford 82], XDS [XEROX 77], Argus [MIT 83]

FS

FS

FS: FileServer

WS: Work-station


Netz-Systemalternativen:„Prozessor-Pool“-Modell

- >1 Prozessor pro Benutzer

- dynamische Zuweisung von Prozessoren

- spezialisierte Server zur Nutzung gemeinsamer Ressourcen (Name, Time, PrintAuthentification, ..)

- Bsp. CDCS (Needham/Herbert [Cambridge 80])

LAN

Druck-Server

PAD

TT

T

T

T

PADT TT

ProzessorPool

T: Terminal

PAD: Packet As-/Disassembler (Ter-minal Concentrator)


„Prozessor Pool“-Modell vs. „WS/Server“-Modell

Vorteile des "Prozessor-Pools": • bessere Ausnutzung der Ressourcen

• Flexibilität bzgl. des Lastaufkommens

• Kompatibilität mit zentral. Systemen

• heterogene Prozessoren (Spezialisierung)

• aber: Probleme bei Graphik (Komm.!)

Vorteile des "WS / Server"- Modells

• grafische, interaktive Benutzerschnittstellen, Fenstertechnik

• lokale Verarbeitungsmöglichkeit

• integrierende Kommunikations-Software


Netz-Systemalternativen: „Hybrides“ Modell

- >1 Prozessor pro Benutzer

- Vereinigung des "Prozessor Pools" mit dem "WS / Server"-Modell

- Bsp. Amoeba [Mullender/Tanenbaum, Amsterdam 84ff]

LAN

Druck-Server

PAD

TT

TT

TProzessor

Pool

WS

WS WS

- Proc. Pool- Workstation- OS Kernel


Netz-Systemalternativen: „Integriertes“ Modell

- <= 1 Prozessor pro Benutzer

- Verbindung heterogener HW-Plattformen

- keine spezialisierten Server

- Bsp. Sun NFS [UNIX BSD 4.2 85] (verteiltes Dateisystem), Locus [Popek/UCLA 85]Newcastle Connection [Brownbridge, Randall et al. 82]

LAN

PAD

WS WS

Mikro-Computer

T

T

T

T

T

Mini-Computer

T T T

T

T T

T

T

T

T

T

T

- Verteilungstransparenz- einheitliches verteiltes BS- z.T. autonome Knoten


Schrittweise Verallgemeinerung:Grade von Verteilungstransparenz

- Level 0:Zugang zu unabhängigen Rechnern (z.B.CCITT X.3, X.28, X.29)einzelne Rechner explizit adressierbarz.B. remote log in, file transfer, message passing, ...oft heterogene Teilnoten (bzw. Netze)

- Level 1: einige verteilte Anwendungsprogramme (z.B. eMail, remote who)sonst noch voneinander unabhängige RechnereMail auf der Basis logischer Adressen (z.B. xyz@organisation)Bsp.: Grapevine [Birrel et al. 82]

- Level 2 :voll verteilungstransparenter Zugang zu entfernten RechnernAnwendungsprogramme weitgehend wie in zentralisiertem SystemInteroperabilität auf der Basis von Standards !Bsp.: Distributed (e.g. NFS) File Services


Aufbau von (verteilter) Systemsoftware

KommandointerpreterEditoren ...Compiler

Spiele ...FlugreservierungBanksystem

Alternative Sichtweisen eines (verteilten) Betriebssystems...

...als „„erweitere / virtuelleerweitere / virtuelle““ MaschineMaschineZiel: zunehmend „komfortable“ Abstraktion von Systemeigenschaften

...als „BetriebsmittelverwalterBetriebsmittelverwalter“Aufgaben: Allokation / Vermittlung / Verwaltung von Ressourcen –d.h. (u.a.) von Speichern, Prozessen, Geräten, Netzschnittstellen etc.

Anwendungen

System-programme

Hard-ware

Rechensystem

physikalische Geräte

Maschinensprache, Mikroprogrammierung

BetriebssystemBetriebssystem


Zur Erinnerung: Betriebssystem-Architekturen

Operateur5

Benutzerprogramme4

0

1

2

3

Prozessorvergabe/Multiprogrammierung

Speicherverwaltung

Prozesskommunikation

Ein-/Ausgabeverwaltung

B) Virtuelle MaschineBsp: IBM /370 mit VMS

A) Geschichtetes SystemBsp: THE (Dijkstra 68)

C) Client/Server-ModellKernClient

KernServer

KernServer

Inter-Prozesskommunikationzentral

modularer Aufbau, flexibel, erweiterbar, ...

BS-(micro)Kern(el)

VM / 370CMS CMSCMS

/370 Hardware

Virtuelle /370 Virtuelle /370 Virtuelle /370


Betriebssystemunterstützung: Systemalternativen

A) Mono-Prozessor:MicrokernelMicrokernel-Architektur User

Applic.

Microkernel

Hardware

MemoryMangmt.

ProcessModule

...

B) Multi-Prozessor: • DOS (Distributed OS): eng gekoppeltes BS für Multi-Prozessoren und homogene Multi-Computer

• NOS (Network OS): lose gekoppeltes BS für heterogene

Multi-Computer (LAN und WAN)

• Middleware: zusätzliche Ebene oberhalb des NOS zur Implemen-tierung allgemeiner Dienste

OS Interface

System call

OS Interface OS Interface


Verteilte Betriebssystem-Alternativen

Kernel Kernel Kernel

Distributed Applications

Netzwerk

Rechner A Rechner B Rechner C

B) Multiprocessor/Multicomputer /Verteiltes BS:

Distributed OS System Services

...

NetworkOS services

Kernel

...

NetworkOS services

Kernel

NetworkOS services

Kernel


Netzwerk


A) Netzwerk-BS:

+ Autonomie- Transparenz

+ Transparenz- Autonomie


Verteilte Betriebssystem-Alternativen (ff.)

C) Middleware-basiertes verteiltes (Betriebs-) System:

Kernel Kernel Kernel


Netzwerk


NetworkOS

services

...

NetworkOS

services

NetworkOS

services

Middleware Services

Basis: Client/Server- (Dienste-) Kooperation auf Anwendungs- und Systemebene!


Vergleich der Betriebssystem-Alternativen

OpenOpenClosedClosedOpenness

VariesYesModeratelyNoScalability

Per nodePer nodeGlobal, distributed

Global, centralRessource management

Model specificFilesMessagesShared memoryBasis for com-munication

NNN1Number of copies of OS

NoNoYesYesSame OS on all nodes ?

HighLowHighVery highDegree of transparency

Middleware-based DS

Network OSDistributed OSMulticomputer

Distributed OSMultiprocessor


Zusammenfassung: Ziele verteilter Programmierung• Performanz: z.B. beschränkte max. Antwortzeiten:

garantiertes Maximum vs. Durchschnittswerte• Gemeinsam genutzte Ressourcen:

Server-Knoten, verteilungstransparenter Zugriff, RPC ...• Modulares Wachstum:

Zerlegung verteilter Anwendungen in 'threads of control', parallele Dekompo-sition (von Daten und Prozessen)'Data vs. function Shipping' (bei wenig/häufigen Änderungen)

• Autonome Knotenkontrolle:'Data Shipping' --> autonome Verarbeitung'Function Shipping' --> autonome Daten

• Zuverlässigkeit und Verfügbarkeit: Netzknoten: 'fail fast'' + stabiler Speicher, zuverlässige Hard- und Software-Komponenten, Duplizieren von Komponenten (log./phys., Redundanz)

• Sicherheit: Knotenautonomie; Verschlüsselung; Function Shipping!

TRADEOFF: Parallele Dekomposition <-vs-> Kommunikationsanforderung !


Probleme bei der Realisierung Verteilter Systeme

• Zugriff auf entfernte Ressourcen in vorab bekannter, möglichst einheitlicher Weise: Heterogenität ? ---> Standardisierung !

--> gemeinsam bekannte Spezifikation von Kooperationsformen („Protokoll“)

• Richtige Zuordnung von Namen (‚Naming‘-Dienste)

• Gemeinsam bekannte Systemzustände bzgl.Protokoll (Synchronisation des Verhaltens) bzw.Daten (verteilte Datenhaltung)

--> dabei möglichst wenig dauerhafte "Zustandsinformation" halten• Robustheit (erreichbar u.a. durch ‚Handshaking‘, ‚Time-out‘, ‚Sequenznummern‘,

‚Checksummen‘,...)

• Sicherheit der Datenübertragung (Zugangskontrolle/ Authentisierung, Kodierung/ Verschlüsselung , sichere Hard- und Software,...)

• Zugriffsschutz: z.B. mit „Capabilities“, d.h. Benutzerobjekten, die Berechtigung für bestimmte Zugriffsarten repräsentieren

• Beweise von Systemeigenschaften ?!


Zusammenfassung: Charakteristika Verteilter Systeme

• „Resource Sharing“: ...bzgl. HW, SW, Daten (trotz Heterogenität!)

• „Openness“: HW/SW, Schnittstellen, Protokolle, technisch/kommerziell

• „Concurrency“: Benutzer (Clients)- / Server - Parallelität

• „Scalability“: HW, SW, Performanz

• „Fault Tolerance“ + „Availability“: HW-/SW-Redundanz

• „Transparency“: Zugangs-, Lokations-, CC-, Replikations-, Fehler-, Migrations-, Performanz-, Scaling-, ...


Zusammenfassung: Vor- und Nachteile verteilter Systeme

Potientielle Vorteile: + Abbild organisatorischer Gliederungen !!!+ Erhöhte Zuverlässigkeit und Verfügbarkeit

(Redundanz von Prozessoren, Daten etc.)+ Erweiterte Fähigkeiten insgesamt - mehr

Leistungsfähigkeit (Kapazität, Parallelität etc.)+ Modularität des Gesamtsystems+ Erweiterbarkeit (‚scalability‘)+ Kostenvorteile (?)+ Sicherheit (??)

Potentielle Probleme: - „Interconnectivity“

- Interferenzen / Abhängigkeiten

- Propagieren von Effekten (z.B. Fehlern)

- Folgen hoher Komponentenzahl (Engpässe!)

- Partielles Fehlerverhalten

einführung in verteilte systeme - vsis homepage · © wl vsis inf min uni hh 07_08 vis2-einf-1...

Documents