Grundlagen verteilter Systeme: Motivation,

Definition und Charakteristika

Gliederung

• Geschichte der Rechensysteme, • Definition und Begriffsklärung• Motivation, Gründe für Verteilung• Herausforderungen• Techniken zur Realisierung

Historische Entwicklung von Rechensystemen

Computing Paradigmen• 1950er Jahre: Einbenutzersysteme• 1960er Jahre: Batch Processing• 1970er Jahre: Mehrbenutzer- / Timesharing-Systeme• 1980er Jahre: Personal Computing• 1990er Jahre: Verteilte Systeme• 2000er Jahre: Mobile, ubiquitäre Systeme• 2010er Jahre: „Internet of Things“

Einflussfaktoren• Prozessoren: Leistungsexplosion und Preisverfall dank Miniaturisierung

(Moore‘s Law, 1965)• Netzwerke: Steigende Bandbreite und sinkende Kosten (LAN, DSL)• Mobilität: Steigende Fähigkeiten von Mobilgeräten und breite Verfügbar-

keit & hohe Datenrate von Drahtlosnetzen (WLAN, GSM/UMTS etc.)

• viele Prozessoren• viele Speichereinheiten• Kommunikationsnetzwerke

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.

Verteilte Systeme / Beispiel: Internet

• ARPANet, 1969: Unangreifbares Netzwerk durch dezentralen Aufbau (technische Basis: Internet Protocol Stack, DNS, …)

• Nach Öffnung für öffentliche Nutzung: Infrastruktur für Dienste (WWW, Email, IRC, FTP, VoIP, Instant Messaging, …)

• Anwendungen im WWW— Informationsangebot (Institutionen, Firmen, Vereine, Privatpersonen, …)— E-Business (Amazon, Ebay, Online Banking, …)— Kollaborative Anwendungen „Web 2.0“ (Wikipedia, Blogs, …)— …

Verteilte Systeme / Beispiel: Internet

intranet

ISP

desktop computer:

backbone

satellite link

server:network link:

Verteilte Systeme / Beispiel:Intranet-basiertes (Büro-) Informationssystem

• lokal verwaltetes Netzwerk• meist proprietär (z.B. Uni-Campus-Netzwerk)• Schnittstellen zum Internet (Sicherheitsaspekte, u.a. Firewalls)• interne und externe Dienste (z.B. Drucken vs. Web-Server Zugriff)

Verteilte Systeme / Beispiel: Nomadic/Mobile/Ubiquitous Computing

• Drahtlose Netzwerkinfrastruktur— zellenbasierte Telefonnetze (UMTS, LTE)— WiFi Wireless LAN

• Mobile Endgeräte— Laptops, Handhelds, PDAs etc.— Handys, Smartphones, “Wearable” Devices (wie z.B. Pulsmessgerät)

• Stationäre Endgeräte— Anzeigegeräte (Bildschirm, Drucker)— Kontrollgeräte (Heizung, Fenster,

usw.)

Verteilte Systeme / Beispiel: Embedded Systems

• in Geräten/Fahrzeugen verbaute Mikroprozessoren / Mikrokontroller• meist verbunden durch proprietäre LANs (z.B. Bus)

• Kontrollsysteme im Flugzeug— ‚Flight Management and Guidance System‘ (FMGS) von Airbus (Navigation,

Flugsteuerung, Treibstoffmanagement)

• Kontrollsysteme im Automobilbereich— Mercedes S-Klasse von 1991 führt den CAN-Bus (Bosch) zur Vernetzung

eingebetteter Steuergeräte ein— modernere Generationen der S-Klasse (ab ca. 2005) besitzt mehr als 50 auto-

nome Prozessoren (-> 100km rein autonome Fahrt im Verkehr in D in 2013)

• Intelligente Haushaltsgeräte— Gorenje: Multiagent Washing Assistant

Verteilte Systeme / Beispiel: Embedded Systems• Gorenje 2006(!): Quest for new generations of household appliances

— User friendly communication in a natural way— Certain degree of intelligence: autonomy, planning, reasoning, learning

capabilities

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+ Soziale Netzwerke / Spiele (!)

Beispielanwendungen verteilter Systeme – nachAnwendungsdomänen [C/D/K 2012]

Finance and commerce eCommerce e.g. Amazon and eBay, PayPal, online banking and trading

The information society Web information and search engines, eBooks, Wiki-pedia; social networking: Facebook and MySpace.

Creative industries and entertainment

online gaming, music and film in the home, user-generated content, e.g. YouTube, Flickr

Healthcare health informatics, on online patient records, monitoring patients

Education e-learning, virtual learning environments; distance learning

Transport and logistics GPS in route finding systems, map services: Google Maps, Google Earth

Science The Grid as an enabling technology for collabo-ration between scientists

Environmental management sensor technology to monitor earthquakes, floods or tsunamis

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: „ … collection of independent computers thatappears to its users as a single coherent system“ (s.u.)

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 Datei-Server+ mehrere Prozessoren, Verteilung, Kommunikation - kein unabhängiges Fehlerverhalten!

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

Spei.

Cach.

Proz.

I/O

LAN

Proz.

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.

Begriffsklärung: Verteiltes System / Verteilte Anwendung

• Tanenbaum: “A distributed system is a collection of independent computersthat appears to its users as a single coherent system.”

MW Distributed Middleware Product(s)

OS Operating System 1 Operating System 2 Operating System 3

HW Host 1 Host 2 Host 3

Begriffsklärung: Verteiltes System / Verteilte Anwendung

• Galli: “A distributed system is a collection of heterogeneous computers and processes connected via a network. This collection works closely together to accomplish a common goal.”

MW Distributed Middleware Product(s)

App Distributed Application 1 Distributed Application 2

OS Operating System 1 Operating System 2 Operating System 3

HW Host 1 Host 2 Host 3

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 / Amdahl‘s Law

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 Funktionalitä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

Gründe verteilter Verarbeitung: funktional / nicht funktional

• funktional:— Daten sind verteilt— Benutzer sind verteilt— Ressourcen sind verteilt

• nicht-funktional— Performanz / Skalierbarkeit— Ausfallsicherheit— Ressourcenausnutzung

VerteilteAnwendung

Arten verteilter Anwendungen

einfacheverteilte

AnwendungUnternehmens-Software-Suite

EnterpriseApplication

Integration (EAI)

B2C

B2B Offene Dienstmärkte

Unternehmensnetzwerke

Virtuelle Organisationen

Verteilung überAnwendungsgrenzen

Einzelne Anwendung HomogeneAnwendungsumgebung

HeterogeneAnwendungsumgebung

Verteilung überOrganisationsgrenzen

ZentralisierteKontrolle

UnabhängigeBenutzer

UnabhängigeAnwendungs-komponenten

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 (!!!)

Verteilte Systeme: Pitfalls

• Programmierung ist im Kontext von zentralisierten Einprozessorsystemenentstanden— imperative Programmierung <-> von Neumann Architektur

• Verteilung wird im Entwurf nicht berücksichtigt; d.h. allg. Annahmen:(Peter Deutsch, Sun Microsystems)

— Das Netzwerk ist zuverlässig.— Das Netzwerk ist sicher.— Das Netzwerk ist homogen.— Die Topologie ändert sich nicht.— Die Latenzzeit beträgt null.— Die Bandbreite ist unbegrenzt.— Die Übertragungskosten betragen null.— Es gibt genau einen Administrator.

Business Example and Challenges

• Example: Provider of an online book store (e.g. in the World Wide Web)— Customers can connect their computer to your computer (web server):

• browse your inventory• get access to electronic data• place orders• …

Business example – challenges I

• What if— Your customer uses a completely different hardware? (PC, MAC,…)— … a different operating system? (Windows, Unix,…)— … a different way of representing data? (ASCII, EBCDIC,…)

⇒ Heterogeneity

• Or— You want to move your business and computers to the Caribbean (because of the

weather)?— Your client moves to the Caribbean (more likely)?

⇒ Distribution transparency

Business example – challenges II

• What if— Two customers want to order the same item at the same time?

⇒ Concurrency

• Or— The database with your inventory information crashes?— Your customers computer crashes in the middle of an order?

⇒ Fault tolerance

Business example – challenges III

• What if— Someone tries to break into your system to steal data?— … sniffs for information?— … your customer orders something and doesn’t accept the delivery saying he

didn’t?

⇒ Security

• Or— You are so successful that millions of people are visiting your online store at

the same time?

⇒ Scalability

Business example – challenges IV

• When building the system…

— Do you want to write the whole software on your own (network, database,…)?— What about updates, new technologies, changes, maintenance etc.?

⇒ Reuse and Openness (Standards)

Herausforderungen: Überblick

(Braubach 2007, Pokahr 2007)

Legend: Processing Unit Memory Communication Link

Separate Address Spaces

Add Property

Single-ProcessorSystem

Concurrency

…

Heterogeneity Failure Handling

Scalability

OpennessSecurity

Fully DistributedSystem

Transparency

Herausforderungen: Einzelprozessorysteme / Getrennte Adressräume

• Einzelprozessorsysteme— Effiziente Entwicklung gebrauchstauglicher Software— Allgemeine SE-Probleme (Kundenanforderungen, Wartbarkeit, Projektmanagement)

SE-Methoden (Xtreme Programming / Test-Driven Development, Model-DrivenDevelopment, Agile Methoden)Entwurfstechniken (UML u.a.)Softwarebausteine (generische u. domänenspezifische Frameworks)

• Getrennte Adressräume— Autonome Verarbeitungseinheiten— Neue potentielle Fehlerquelle durch Kommunikationskanäle— SE-Probleme durch nachrichtenbasierte Kommunikation (synchron/asynchron)— Kein globaler Zustand

Abstraktion von nachrichtenbasierter Kommunikation (z.B. über RPC/RMI) Techniken zum Testen und Debuggen

Herausforderungen: Nebenläufigkeit

• Nebenläufigkeit— nebenläufigen Zugriff auf gemeinsam genutzte Ressourcen ermöglichen/

verwalten

— Wahrung der Konsistenz bei Race-Conditions— Synchronisation zwischen Prozessen— Fairness bei exklusiven Ressourcen sicherstellen— Deadlocks vermeiden, verhindern, erkennen

Algorithmen / Verfahren (wechselseitiger Ausschluss, Scheduling, Trans-aktionen)Modelle (z.B. Producer / Consumer)Verifikation mit formalen Entwurfstechniken (z.B. Petri-Netze)

Herausforderungen: Heterogeneität

• Heterogenität— Interoperabilität zwischen heterogenen Komponenten ermöglichen

— Inkompatibilitäten zwischen gewachsenen Teilsystemen— Unterschiedliche Geräte o. Client-Software auf Anwenderseite— Heterogenität bezüglich Betriebssystem, Hardwarearchitektur, Kommunika-

tionsinfrastruktur, Programmiersprache, Softwareschnittstellen, Sicherheits-maßnahmen, Informationsrepräsentation, …

Adapterkomponentenspezielle Middleware (z.B. ESBs)

Herausforderungen: Fehlerbehandlung

• Fehlerbehandlung— Fehlertoleranz: Störungen (engl.: fault) bzw. Ausfälle von Teilkomponenten

sollen nicht zum Ausfall (engl.: failure) des Gesamtsystems führen— Ausfall (Def.): Der angebotene Dienst entspricht nicht mehr der Spezifikation

— partielle Fehler— Erkennung von Fehlern, bestimmen von Fehlerursachen

Erkennung: Checksummen, Heartbeat, …Maskierung/Tolerierung: Timeouts, Anfragen wiederholen, Fehlersemantiken (at-most/ at-least/ exactly once), RedundanzRecovery: Verteilte Transaktionen, Rollback-Mechanismen, Kompensations-aktionen

Herausforderungen: Skalierbarkeit

• Skalierbarkeit— Das System sollte durch Hinzunahme von Ressourcen an steigende Problemgrößen

angepasst werden können ( Linearität bezgl. Kosten/Systemgröße)— Problemgröße: Anzahl der Benutzer, Anzahl der Knoten, geographische Ausdehnung,

…— Green-IT: Abschalten nicht benötigter Ressourcen aus Energie-/Kosteneffizienz

— Bottlenecks— begrenzte Bandbreite— synchrone Kommunikation— Amdahl‘s Law — Designgrenzen: Y2K, IPv4, …

Replikation / Cachinggeographische Verteilung um Lokalitätsgrad zu erhöhen (z.B. DNS, P2P-Systeme)NIO (non-blocking IO)

Herausforderungen: Offenheit

• Def. Offenes System:— "... a system that implements sufficient open specifications for interfaces,

services, and supporting formats to enable properly engineered applications software to be ported across a wide range of systems with minimal changes, to interoperate with other applications on local and remote systems, and to interact with users in a style which facilitates user portability" (Guide to the POSIX Open Systems Environment, IEEE POSIX 1003.0).

— Unvorhersehbarkeit zukünftiger Entwicklungen— de-Facto Standards— zu strikte oder zu wenig spezifische Standards

de-jure (vs. de-facto) Standardsoffene Standardisierungsgremien (Anwender und Hersteller)z.B. ANSI, IETF, W3C, ISO, IEEE, OMG, Trade associations,...

Herausforderungen: Sicherheit

• Sicherheit im Sinne von Security (vs. Safety)— Sicherstellen, dass Ressourcen/Dienste (nur) für autorisierte Benutzer

zugreifbar sind und (nur) in der beabsichtigten Weise verwendet werden können

— Kommunikation über unsichere Kanäle— Anwendung über Organisationsgrenzen hinweg— Offenheit des Systems bietet Möglichkeiten für Angriffe

Kryptographische Verfahren (Vertraulichkeit/Integrität/Authentizität von Daten, Nicht-Abstreitbarkeit von Aktionen)Verfahren zur Erkennung von DOS-Attacken (Verfügbarkeit gewährleisten)

Herausforderungen: Transparenz

• Transparenz— Verteiltes System soll als eigenes System für den Benutzer erscheinen

— Für den Benutzer meist erwünscht (Gegenbeispiel: Drucker)— Fehlertransparenz in niedrigeren Schichten evtl. unerwünscht— Zugriffstransparenz kann unbewusst zu ineffizientem Code führen

bewusster Umgang mit Transparenz

Abwägen zwischen Transparenz und Performance

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

Transparenz-Eigenschaften verteilter Systeme

• Zugriffstransparenz

• Ortstransparenz

• Nebenläufigkeitstransparenz

• Replikationstransparenz

• Fehlertransparenz

• Migrationstransparenz

• Leistungstransparenz

• Skalierungstransparenz

„Transparencies“ (nach Coulouris/Dollimore/Kindberg)

• Access transparency: enables local and remote resources to be accessed usingidentical operations

• Location transparency: enables resources to be accessed without knowledge oftheir physical or network location (for example, which building or IP address).

• Concurrency transparency: enables several processes to operate concurrentlyusing 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, e.g. Web servers

„Transparencies“ (nach Coulouris/Dollimore/Kindberg)

• Failure transparency: enables the concealment of faults, allowing users and application programs to complete their tasks despite the failure of hardware or software components, e.g. message retransmission, failure of a web server node should not bring down the web site

• Mobility transparency: allows the movement of resources and clients within a system without affecting the operation of users or programs, e.g. switching from one name server to another at runtime; migration of an agent/process form one node to another.

• Performance transparency: allows the system to be reconfigured to improve performance as loads vary, e.g., dynamic addition/deletion of components, e.g. switching from linear structures to hierarchical structures when the number of users increase.

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

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

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

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 !

Zusammenfassung: Charakteristika Verteilter 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

Kein gemeinsamer Speicher - aber:

— gemeinsames Wissen um gemeinsamen System(teil-)zustand

— keine allen gemeinsame Fehlerquelle

— unabhängiges Fehlerverhalten der Teilsysteme

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“: Verteilungs-, Orts-, Zugangs-, Replikations-, Fehler-, Migrations-, Performanz-, Scaling-, ...

Zusammenfassung: Probleme bei der Realisierung• 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: 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