Grundlagen verteilter Systeme - vsis- ... · Grundlagen verteilter Systeme: Motivation, D fi iti d Ch kt i tikDefinition und Charakteristika vsis inf min uni hh ws 12_13 VIS-1 Grundl-1

Grundlagen verteilter Systeme: Motivation,

D fi iti d Ch kt i tikDefinition und Charakteristika

vsis inf min uni hh ws 12_13 VIS-1 Grundl-1

Gliederungg

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


Historische Entwicklung von Rechensystemeng y

Computing Paradigmen• 1950er Jahre: Einbenutzersysteme• 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

• viele Prozessoren• viele Speichereinheiten

2000er Jahre: Mobile, ubiquitäre Systeme

Einflussfaktoren

• Kommunikationsnetzwerke

• Prozessoren: Leistungsexplosion und Preisverfall dank Miniaturisierung (Moore‘s Law, 1965)

• Netzwerk: Steigende Bandbreite und sinkende Kosten (LAN, DSL)• Mobilität: Steigende Fähigkeiten von Mobilgeräten und breite Verfügbar-

keit von Drahtlosnetzen (WLAN, GSM/UMTS)


Verteilte Anwendungen bzw. Systeme:K ti i t ilt U bKooperation in verteilten Umgebungen

„offener verteilter Markt vonMarkt von Diensten"

Basis:Integration weltweiter

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

Rechnernetze(Inter-/Intranets)

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

Grundvoraussetzungen:Heterogenität und Autonomie


Autonome Datenhaltung• Vielfältige Anwendungen• ...

auf ganz verschiedenen Ebenen, z.B.

Verteilte Systeme / Beispiel: Internety p

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

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

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


Verteilte Systeme / Beispiel: Internety p

intranet

ISP

backbone

desktop computer:

satellite link

server:network link:


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

• lokal verwaltetes Netzwerki t i tä ( B U i C N t k)• 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)interne und externe Dienste (z.B. Drucken vs. Web Server Zugriff)

Desktopcomputers

print and other servers

email server

Web serverLocal areanetwork

email server

File server

other servers

print

the rest of

router/firewall

other servers

the Internet


Verteilte Systeme / Beispiel: Nomadic/Mobile/Ubiquitous ComputingNomadic/Mobile/Ubiquitous Computing

• Drahtlose Netzwerkinfrastrukturzellenbasierte Telefonnetze (UMTS LTE)

• Stationäre EndgeräteAnzeigegeräte (Bildschirm Drucker)— zellenbasierte Telefonnetze (UMTS, LTE)

— WiFi Wireless LAN• Mobile Endgeräte

L t H dh ld PDA t

— Anzeigegeräte (Bildschirm, Drucker)— Kontrollgeräte (Heizung, Fenster,

usw.)

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

Internet

Host intranet Home intranetWAP Wireless LAN gateway

Laptop

Mobile

PrinterCamera

phone

Host site


Camera Host site

Verteilte Systeme / Beispiel: Embedded Systemsy p y

• in Geräten/Fahrzeugen verbaute Mikroprozessoren / Mikrokontroller• meist verbunden durch proprietäre LANs (z B Bus)• 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

• Intelligente Haushaltsgeräte— Gorenje: Multiagent Washing Assistant


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

— User friendly communication in a natural wayy y— 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• 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• 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]Anwendungsdomänen [C/D/K 2012]

Finance and commerce eCommerce e.g. Amazon and eBay, PayPal, online banking and tradingonline 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, , p ,monitoring patients

Education e-learning, virtual learning environments; distance learningdistance 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,


Environmental management sensor technology to monitor earthquakes, floods or tsunamis

Charakteristika verteilte Systeme

Viele Prozessoren, Speicher, Subsysteme...

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

Kommunikation zwischen verschiedenen Knoten erfolgt nur über NachrichtenKommunikation zwischen verschiedenen Knoten erfolgt nur über Nachrichten-austausch

Vorhandensein eines gemeinsamen Ziels, bereitgestellte Leistung wird durch g , g garbeitsteilige Kooperation erbracht

Verteilungstransparenz (mindestens Orts- und Zugriffstransparenz)

Kein gemeinsamer Speicher - aber:

Gemeinsames Wissen um gemeinsamen System(teil-)zustandg y ( )

Keine allen gemeinsame Fehlerquelle

Unabhängiges Fehlerverhalten der Teilsysteme


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

k i bhä i F hl h lt !- 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!


g g

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

LANSpei.

lose gekoppeltProgSpei.Prog

Spei.Prog

Proz.

I/OProz.

I/O

Proz.

I/O

Cach

Prog.

Cach

Prog.

Cach

Prog. GemeinsamerSpeicher

k ltCachCach.Proz.

Cach.Proz.

Cach.Proz.

I/O

. . . eng gekoppeltCach.

SP

SP

SP

SP. . . Array Processor

SingleInstruction

vsis inf min uni hh ws 12_13 VIS-1 Grundl-15I/O

Array ProcessorInstructionMultipleDataProgramm

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 ”that 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

li h l ”accomplish a common goal.”

App Distributed Application 1 Distributed Application 2

MW Distributed Middleware Product(s)

OS Operating System 1 Operating System 2 Operating System 3

HW Host 1 Host 2 Host 3


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

• mangelnde Möglichkeiten der Zentralrechner

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

• Anforderungen neuer Anwendungen

(grafische Benutzerschnittstellen kurze Antwortzeiten )(grafische Benutzerschnittstellen, kurze Antwortzeiten ...)

• weite Verbreitung mächtiger PCs und Workstations

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

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

• geringere Hardware-Kosten (!?!) --> Grosch's Gesetz / Amdahl‘s Law


Gründe verteilter Verarbeitung: technischGründe verteilter Verarbeitung: technisch

Es ist technisch machbar

Reduktion der AntwortzeitenHöhere Verfügbarkeit

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.

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

Geringere Kosten

vorgesehene Operation.

Die aktuelle Größe des Systems kann wegen der Modularität dem jeweiligen Bedarf

Höhere Sicherheit

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: anwendungsspezifischg g p

Autorisierung entspricht VerantwortlichkeitViele Organisationen sind räumlich verteilt und arbeiten hochgradig autonom

Die Abteilung will ihre eigene Maschine

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

Verschiedene Benutzer (-klassen) haben unterschiedliche Anforderungen

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

Integration verschiedener, zunächst unabhängig entwickelter Teilsysteme

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


Gründe verteilter Verarbeitung: funktional / nicht funktionalg

VerteilteAnwendung

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

— Performanz / Skalierbarkeit— Ausfallsicherheit— Ressourcenausnutzung


Arten verteilter Anwendungeng

Verteilung überOrganisationsgrenzen

B2B Offene Dienstmärkte

g g

UnabhängigeAnwendungs- Offene Dienstmärkte

Unternehmensnetzwerke

Virtuelle OrganisationenUnabhängige

Anwendungskomponenten

einfache E t i

B2CVirtuelle OrganisationenUnabhängige

Benutzer

einfacheverteilte

AnwendungUnternehmens-Software-Suite

EnterpriseApplication

Integration (EAI)

Verteilung über

ZentralisierteKontrolle

AnwendungsgrenzenEinzelne Anwendung Homogene

AnwendungsumgebungHeterogene

Anwendungsumgebung


Vorteile verteilter Systeme

+ Abbild organisatorischer Gliederungen (!!!)Abbild organisatorischer Gliederungen (!!!)

+ Erweiterbarkeit / Skalierbarkeit / Modularität

+ höhere Zuverlässigkeit und Verfügbarkeit

+ Replikation (Redundanz!)Replikation (Redundanz!)

+ unabhängiges Fehlerverhalten

+ kurze und vorhersehbare Antwortzeiten (--> Workstations)

+ Kostenvorteile (Hardware vs. Software !?!)Kostenvorteile (Hardware vs. Software !?!)

+ Sicherheit (???)


Nachteile verteilter Systeme

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

- Interferenzen / Abhängigkeiten von Teilkomponenten

P i Eff k ( B F hl )- Propagieren von Effekten (z.B. Fehlern)

- Folgen hoher Komponentenzahl (Engpässe!)

- Partielles Fehlerverhalten

- weniger Flexibilität bei der Zuweisung von Ressourceng g

- kein gemeinsamer Zustand (auch: keine gemeinsame Uhr)

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

- Koordinationsprobleme (!!!)


Verteilte Systeme: Pitfallsy

• Programmierung ist im Kontext von zentralisierten Einprozessorsystemenentstandenentstanden— 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 zuverlässig.— Das Netzwerk ist sicher.— Das Netzwerk ist homogen.— Die Topologie ändert sich nicht.— Die Latenzzeit beträgt null.— Die Bandbreite ist unbegrenzt.g— Die Übertragungskosten betragen null.— Es gibt genau einen Administrator.


Business Example and Challengesp g

• 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• get access to electronic data• place orders• …


Business example – challenges Ip g

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

⇒ Heterogeneity

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

weather)?Y li t t th C ibb ( lik l )?— Your client moves to the Caribbean (more likely)?

⇒ Distribution transparency


Business example – challenges IIp g

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

⇒ Concurrency

• OrThe database with your inventory information crashes?— The database with your inventory information crashes?

— Your customers computer crashes in the middle of an order?

⇒ Fault tolerance


Business example – challenges IIIp g

• What ifSomeone tries to break into your system to steal data?— 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?

⇒ Securityy

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

the same time?

⇒ Scalability


Business example – challenges IVp g

• 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: Überblickg

Single-ProcessorSystem

…

Separate Address Spaces

Concurrency Heterogeneity Failure Handling

Scalability

Fully DistributedSystem

OpennessSecurity

System

Transparency

Legend: Processing Unit Memory Communication Link Add Property


(Braubach 2007, Pokahr 2007)

Herausforderungen: Einzelprozessorysteme / Getrennte AdressräumeEinzelprozessorysteme / 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 Verarbeitungseinheiteng— Neue potentielle Fehlerquelle durch Kommunikationskanal— SE-Probleme durch nachrichtenbasierte Kommunikation (synchron/asynchron)— Kein globaler ZustandKein globaler Zustand

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


Herausforderungen: Nebenläufigkeitg

• Nebenläufigkeitnebenläufigen Zugriff auf gemeinsam genutzte Ressourcen ermöglichen/— 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 TransAlgorithmen / Verfahren (wechselseitiger Ausschluss, Scheduling, Trans-aktionen)Modelle (z.B. Producer / Consumer)Verifikation mit formalen Entwurfstechniken (z.B. Petri-Netze)


Herausforderungen: Heterogeneitätg

• HeterogenitätInteroperabilität zwischen heterogenen Komponenten ermöglichen— 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-, g p , ,maßnahmen, Informationsrepräsentation, …

AdapterkomponentenAdapterkomponentenspezielle Middleware (z.B. ESBs)


Herausforderungen: Fehlerbehandlungg

• FehlerbehandlungFehlertoleranz: Störungen (engl : fault) bzw Ausfälle von Teilkomponenten— 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 Fehlerursacheng ,

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


Herausforderungen: Skalierbarkeitg

• Skalierbarkeit— Das System sollte durch Hinzunahme von Ressourcen an steigende Problemgrößen— 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 LawAmdahl s Law — Designgrenzen: Y2K, IPv4, …

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


Herausforderungen: Offenheitg

• Def. Offenes System:" a system that implements sufficient open specifications for interfaces— "... 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 toto 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) Standardsde-jure (vs. de-facto) Standardsoffene Standardisierungsgremien (Anwender und Hersteller)z.B. ANSI, IETF, W3C, ISO, IEEE, OMG, Trade associations,...


Herausforderungen: Sicherheitg

• Sicherheit im Sinne von Security (vs. Safety)Sicherstellen dass Ressourcen/Dienste (nur) für autorisierte Benutzer— 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 DatenKryptographische Verfahren (Vertraulichkeit/Integrität/Authentizität von Daten, Nicht-Abstreitbarkeit von Aktionen)Verfahren zur Erkennung von DOS-Attacken (Verfügbarkeit gewährleisten)


Herausforderungen: Transparenzg

• TransparenzVerteiltes System soll als eigenes System für den Benutzer erscheinen— 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 VerteilungstransparenzGrade von Verteilungstransparenz

L l 0- 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 passingz.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)B G i [Bi l t l 82]Bsp.: Grapevine [Birrel et al. 82]

- Level 2 :oll erteil ngstransparenter Z gang entfernten Rechnernvoll verteilungstransparenter Zugang zu entfernten Rechnern

Anwendungsprogramme weitgehend wie in zentralisiertem SystemInteroperabilität auf der Basis von Standards !Bsp.: Distributed (e.g. NFS) File Services


p ( g )

Transparenz-Eigenschaften verteilter Systeme

• ZugriffsZugriffstransparenz

• OrtsOrtstransparenz

• NebenläufigkeitsNebenläufigkeitstransparenz

• ReplikationsReplikationstransparenz• ReplikationsReplikationstransparenz

• FehlerFehlertransparenz

• MigrationsMigrationstransparenz

• LeistungsLeistungstransparenz

• SkalierungsSkalierungstransparenz


SkalierungsSkalierungstransparenz

„Transparencies“ (nach Coulouris/Dollimore/Kindberg)p

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

• Location transparency: enables resources to be accessed without knowledge oftheir physical or network location (for example which building or IP address)their 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)p

• Failure transparency: enables the concealment of faults, allowing users and application programs to complete their tasks despite the failure of hardware orapplication 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 f li t t t hi hi l t t h th b f ifrom 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 algorithmswithout change to the system structure or the application algorithms.


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

2 wichtige Aspekte: Kooperation und Transparenzg p p p

Knoten BKnoten A Knoten BKnoten A

Maschinengrenzen

Knoten C Knoten DKommunikation


Softwarekomponenten

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

Zi l h h L k lität d D tZiel: hohe Lokalität der Daten

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

• Aufrufe entfernter Dienste und Funktionen (Zugriff auf entfernte Ressourcen z B mittels Remote Procedure Call‘ RPC)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 ...d l W h t• 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 VerarbeitungData 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!

vsis inf min uni hh ws 12_13 VIS-1 Grundl-46TRADEOFF: 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 durchVorhandensein eines gemeinsamen Ziels, bereitgestellte Leistung wird durch arbeitsteilige Kooperation erbracht

Kein gemeinsamer Speicher - aber:Kein gemeinsamer Speicher aber:

— gemeinsames Wissen um gemeinsamen System(teil-)zustand

keine allen gemeinsame Fehlerquelle— keine allen gemeinsame Fehlerquelle

— unabhängiges Fehlerverhalten der Teilsysteme


Zusammenfassung: Charakteristika Verteilter Systemeg y

• Resource Sharing“: bzgl HW SW Daten (trotz Heterogenität!)• „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 P f• „Scalability“: HW, SW, Performanz

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

• „Transparency“: Verteilungs-, Orts-, Zugangs-, Replikations-, Fehler-, Migrations-, Performanz-, Scaling-, ... , g , , g ,


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)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,...)g , , )

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

B i S t i h ft ?!


• Beweise von Systemeigenschaften ?!

Zusammenfassung: Vor- und Nachteile verteilter Systemeg y

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

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

Leistungsfähigkeit (Kapazität, Parallelität etc.)+ Modularität des Gesamtsystems

E it b k it ( l bilit )+ Erweiterbarkeit (scalability)+ Kostenvorteile (?)+ Sicherheit (??)Sicherheit (??)

Potentielle Probleme: - „Interconnectivity“

Interferenzen / Abhängigkeiten- Interferenzen / Abhängigkeiten

- Propagieren von Effekten (z.B. Fehlern)

- Folgen hoher Komponentenzahl (Engpässe!)


g p ( gp )

- Partielles Fehlerverhalten

Documents

Grundlagen verteilter Systeme - vsis- ... · Grundlagen verteilter Systeme: Motivation, D fi iti d Ch kt i tikDefinition und Charakteristika vsis inf min uni hh ws 12_13 VIS-1 Grundl-1