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 viele Prozessoren viele Speichereinheiten Kommunikationsnetzwerke 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ügbarkeit & hohe Datenrate von Drahtlosnetzen (WLAN, GSM/UMTS etc.)
Verteilte Anwendungen bzw. Systeme: Kooperation in verteilten Umgebungen offener verteilter Markt von Diensten" z.b. "Electronic Commerce/E-Business" Grundvoraussetzungen: Heterogenität und Autonomie auf ganz verschiedenen Ebenen, z.b. Basis: Integration weltweiter Rechnernetze (Inter-/Intranets) Unterschiedliche Rechner- und Betriebssystemtypen Vielfältige (Teil-) Netze / Kommunikationsmechanismen Unterschiedliche (Sub-) Organisationen Autonome Datenhaltung Vielfältige Anwendungen...
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 ISP intranet backbone satellite link desktop computer: 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. Stationäre Endgeräte Anzeigegeräte (Bildschirm, Drucker) Kontrollgeräte (Heizung, Fenster, usw.) Handys, Smartphones, Wearable Devices (wie z.b. Pulsmessgerät)
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 autonome 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, Reisegesellschaften 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 nach Anwendungsdomänen [C/D/K 2012] Finance and commerce The information society Creative industries and entertainment Healthcare Education Transport and logistics Science Environmental management ecommerce e.g. Amazon and ebay, PayPal, online banking and trading Web information and search engines, ebooks, Wikipedia; social networking: Facebook and MySpace. online gaming, music and film in the home, usergenerated content, e.g. YouTube, Flickr health informatics, on online patient records, monitoring patients e-learning, virtual learning environments; distance learning GPS in route finding systems, map services: Google Maps, Google Earth The Grid as an enabling technology for collaboration between scientists 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 Nachrichtenaustausch 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 Systeme Definition: collection of independent computers that appears 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 LAN Spei. Prog Spei. Prog Spei. Prog lose gekoppelt Proz. Proz. Proz. I/O I/O I/O Prog. Cach. Proz. Prog. Cach. Proz.... Prog. Cach. Proz. Gemeinsamer Speicher I/O eng gekoppelt S P S P S P... Programm S P I/O Single Instruction Multiple Data Array Processor
Begriffsklärung: Verteiltes System / Verteilte Anwendung Tanenbaum: A distributed system is a collection of independent computers 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 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 (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 Möglichkeit der Verarbeitung vor Ort vs. lange Anfrage an Zentralrechner (insbesondere bei räumlich weit verteilten Anwendungen) Höhere Verfügbarkeit Modulare Wachstumsfähigkeit Reduktion der Antwortzeiten 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. Geringere Kosten 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. deutlich billiger als ein 'großes' System mit Leistung n*x mit gleicher Verfügbarkeit. Höhere Sicherheit Dieser oft behauptete Vorteil erscheint i.a. eher fragwürdig.
Gründe verteilter Verarbeitung: anwendungsspezifisch Autorisierung entspricht Verantwortlichkeit Viele 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 funktional Verteilte Anwendung funktional: Daten sind verteilt Benutzer sind verteilt Ressourcen sind verteilt nicht-funktional Performanz / Skalierbarkeit Ausfallsicherheit Ressourcenausnutzung
Arten verteilter Anwendungen Verteilung über Organisationsgrenzen Unabhängige Anwendungskomponenten Unabhängige Benutzer B2B B2C Offene Dienstmärkte Unternehmensnetzwerke Virtuelle Organisationen Zentralisierte Kontrolle einfache verteilte Anwendung Unternehmens- Software-Suite Enterprise Application Integration (EAI) Einzelne Anwendung Homogene Anwendungsumgebung Heterogene Anwendungsumgebung Verteilung über Anwendungsgrenzen
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 Einprozessorsystemen entstanden 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 Single-Processor System Concurrency Separate Address Spaces Heterogeneity Failure Handling Scalability Fully Distributed System Transparency Security Openness Legend: Processing Unit Memory Communication Link Add Property (Braubach 2007, Pokahr 2007)
Herausforderungen: Einzelprozessorysteme / Getrennte Adressräume Einzelprozessorsysteme Effiziente Entwicklung gebrauchstauglicher Software Allgemeine SE-Probleme (Kundenanforderungen, Wartbarkeit, Projektmanagement) SE-Methoden (Xtreme Programming / Test-Driven Development, Model-Driven Development, 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, Transaktionen) 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, Kommunikationsinfrastruktur, Programmiersprache, Softwareschnittstellen, Sicherheitsmaßnahmen, Informationsrepräsentation, Adapterkomponenten spezielle 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), Redundanz Recovery: Verteilte Transaktionen, Rollback-Mechanismen, Kompensationsaktionen
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 / Caching geographische 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) Standards offene 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: - Level 1: - Level 2 : Zugang zu unabhängigen Rechnern (z.b.ccitt X.3, X.28, X.29) einzelne Rechner explizit adressierbar z.b. remote log in, file transfer, message passing,... oft heterogene Teilnoten (bzw. Netze) einige verteilte Anwendungsprogramme (z.b. email, remote who) sonst noch voneinander unabhängige Rechner email auf der Basis logischer Adressen (z.b. xyz@organisation) Bsp.: Grapevine [Birrel et al. 82] voll verteilungstransparenter Zugang zu entfernten Rechnern Anwendungsprogramme weitgehend wie in zentralisiertem System Interoperabilitä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 using identical operations Location transparency: enables resources to be accessed without knowledge of their physical or network location (for example, which building or IP address). 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, 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 A Knoten B Maschinengrenzen Knoten C Knoten D Kommunikation 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 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 Dekomposition (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 Nachrichtenaustausch 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