Agenten und verteilte Anwendungen

Präsentation zum Thema: "Agenten und verteilte Anwendungen"—  Präsentation transkript:

1 Agenten und verteilte Anwendungen
Synchronisation und Konsistenzerhaltung in verteilten Anwendungen 13. März 2003

2 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
Gliederung Grundlagen verteilter Anwendungen Einfache Verfahren zur Nebenläufigkeitskontrolle Spezielle Verfahren zur Nebenläufigkeitskontrolle Zusammenfassung Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

3 Grundlagen verteilter Anwendungen
Definition von verteilten Anwendungen nach [BS2000, Seite 59]: ... application, whose functionality is split into a set of cooperating, interacting functional units... ... these functional units can be assigned to different machines... ... the functional units communicate with each other... Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

4 Aufbau von Verteilten Systemen
Verteiltes Rechensystem Netzwerk Verteiltes Ablaufsystem (Verwaltung der Systemobjekte auf die die Komponenten der Anwendung abgebildet werden) evtl. verteiltes BS Verteilte Anwendung Komponente 1 Komponente n ... Komponente 2 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

5 Konsistenz (traditionell) (1)
Aus Datenbanktechnik: Serialisierbarkeit als Korrektheitskriterium des Transaktionskonzeptes Def.: Eine Transaktion ist eine Folge von Operationen, die die Datenbank von einem konsistenten Zustand in einen neuen Zustand überführen, wobei das ACID-Prinzip eingehalten werden muss. Atomicity Consistency Isolation Durability Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

6 Konsistenz (traditionell) (2)
ABER: Nicht alle Eigenschaften des Konsistenzkonzeptes der Datenbanken bei verteilten Anwendungen erwünscht: Isolation der Benutzer Hohe Verfügbarkeit eventuell wichtiger Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

7 Operationsgranularität
Globale Daten (d.h. Daten mehrerer Komponenten) Nebenläufige Zugriffe auf globale Daten führen eventuell zu Inkonsistenz Datei als globales Datum  mögliche Zugriffseinheit Ganze Datei oder Kapitel oder Buchstabe usw. feine Granularität  hoher Netzwerkverkehr grobe Granularität  geringer Grad an Nebenläufigkeit Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

8 Konsistenz (erweitert)
One-Copy-Serializable Serialisierbarkeit im traditionellen Sinn bezüglich eines Replikats Zwei Operationen, die im Konflikt stehen, werden auf allen Replikaten in der gleiche Reihenfolge ausgeführt. Mutual Consistency alle Replikate eines Datums identisch oder konvergieren zum gleichen Zustand Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

9 Nebenläufigkeitskontrolle (CC)
Wichtig um Daten konsistent zu halten Jedoch Erweiterung bei geographischer Verteilung der Rechner: Absturz einzelner Rechner  Verfügbarkeit von Daten Ausfall von Kommunikationsverbindungen Probleme bei verteilten Anwendungen, da häufig eine sehr hohe Verfügbarkeit gewünscht wird. Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

10 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
Partitionierung Partition 1 Partition 2 schwer zu erkennen höchstens in einer Partition darf geschrieben werden Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

11 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
Gliederung Grundlagen verteilter Anwendungen Einfache Verfahren zur Nebenläufigkeitskontrolle (CC) Spezielle Verfahren zur Nebenläufigkeitskontrolle (CC) Zusammenfassung Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

12 Klassifikation der Verfahren
optimistische pessimistische zentrale Kontrolle dezentrale Kontrolle Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

13 Optimistische Verfahren
Erlauben inkonsistente Zustände Bei Datenbank: versucht alle Transaktionen nebenläufig abzuhandeln. Bei Fehler wird Transaktion im Nachhinein abgebrochen Je grober die Granularität, desto mehr Konflikte Je mehr Komponenten, desto mehr Konflikte Konflikt kann bei verteilten Anwendungen nicht immer durch Anwendung behandelt werden (evtl. Benutzeraktion notwendig) Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

14 Pessimistische Verfahren
Inkonsistente Datenbestände werden nicht geduldet Klassifikation: Pessimistische Verfahren Dezentrale Kontrolle Zentrale Kontrolle Ausgezeichnete Kontrolleinheit Token-Verfahren Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

15 Ausgezeichnete Kontrolleinheit
Basiert auf Konzept der Zentralisierung Eine Kontrolleinheit (KE) verantwortlich für alle (Schreib-) zugriffe DATEN Nachteile: Keine weiteren Zugriffe bei Ausfall der KE. Bei Partitionierung auch Lesezugriffe nur in Partition mit KE. Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

16 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
Token-Verfahren (1) Verschiedene Rechner verantwortlich für Konsistenz Token wandert in virtuellem Ring zwischen den Rechnern umher Rechner mit Token verantwortlich Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

17 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
Token-Verfahren (2) Nachteile: Schwierige Handhabe des Rechnerrings Erweiterbarkeit des Rings Ring muss dynamisch rekonfigurierbar sein (falls Ausfall einzelner Rechner oder Partitionierung) Verlust des Tokens (erkennen und beheben) Vorteil: Höhere Verfügbarkeit als Verfahren mit ausgezeichneter KE Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

18 mit dezentraler Kontrolle
Pessimistische Verfahren Dezentrale Kontrolle Zentrale Kontrolle Ausgezeichnete Kontrolleinheit Token-Verfahren ohne Votierung mit Votierung Einfache Sperrverfahren Floor-Passing-Verfahren Transaktionsverfahren Transformationsverfahren Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

19 Einfache Sperrverfahren
Anfordern und Setzen der Sperre kostet Zeit Sperrgranularität hat entscheidenden Einfluss auf den Grad an Nebenläufigkeit Je nach Art des Systems (z.B: WYSIWIS) muss geklärt werden, ab wann eine Sperre zu setzen ist Zwei Alternativen: Tickle lock Probabilistic lock Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

20 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
Tickle lock Sperre nur so lange wie benötigt Sobald Benutzer nichts mehr tut, wird Sperre automatisch frei gegeben Nachteil: Absturz des Rechners der die Sperre besitzt  gesperrter Teil bleibt bis zu Neustart des Rechners gesperrt Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

21 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
Probabilistic lock Sperre mit automatischem Time-out Ist das Setzen bis zu einem Time-out nicht möglich  Benutzer muss entscheiden (Inkonsistenzen werden in Kauf genommen) gesetzte Sperre bleibt für feste Zeitspanne gesetzt Nachteil: Zeitweise nicht Einhalten der Konsistenz, aufgrund von Kommunikationsverzögerungen. Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

22 Floor-Passing-Verfahren
Verfahren mit wechselnder Kontrolle Sperrmechanismen werden nicht benötigt explizites: Kontrolle wird aktiv vom Benutzer weitergegeben implizites: Vergabe der Kontrolle durch Koordinator Nachteile: Benachteiligung anderer Komponenten Ausfall der Einheit mit Kontrolle Vorteil: keine Benachteiligung von Komponenten Nachteil: Ausfall des Koordinators Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

23 Transformationsverfahren (1)
Von Vorteil bei CSCW-Systemen mit WYSIWIS Eigenschaft Basiert auf Transformation von Operationen Implementationbeispiel: GROVE-Algorithmus (Group outline viewing editor): siehe [BS2000, Seite 202ff] Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

24 Transformationsverfahren (2)
Problemstellung: Benutzer 1 Benutzer 2 „abcd“ „abxcd“ „abcd“ „abcyd“ O1=insert(x,3) O2=insert(y,4) „abxycd“ „abxcyd“ t t Ohne Anpassung der Operationen hängt das Ergebnis von der Reihenfolge der Operationsausführung ab. Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

25 Transformationsverfahren (3)
Operationstransformation, so dass: O`1° O2 = O`2 ° O1 man benötigt: Prioritäten von Operationen (pi = Priorität von Aktion i) Transformationsmatrix T (insert(xi, Posi), insert(xj, Posj),pi,pj) (delete(Posi), insert(xj,Posj),pi,pj) (insert(xi,Posi), delete(Posj),pi,pj) (delete(Posi), delete(Posj),pi, pj) Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

26 Transformationsverfahren (4)
Implementierung der Konfliktpaare von T T11: if (Posi<Posj) then O`i := insert(xi,Posi); elsif (Posi>Posj) then O`i := insert(xi,Posi+1); elsif (xi = xj) then O`i := no-op; elsif (pi > pj) then O`i := insert(xi,Posi+1); else O‘i := insert(xi,Posi); T12: usw. Seien wieder O1=insert(x,3) und O2=insert(y,4). Index als Priorität. O`1 = insert(x,3) bzw. O`2 = insert(y,5) O`1° O2 („abcd“) = „abxcyd“ = O`2 ° O1(„abcd“) Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

27 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
Gliederung Grundlagen verteilter Anwendungen Einfache Verfahren zur Nebenläufigkeitskontrolle (CC) Spezielle Verfahren zur Nebenläufigkeitskontrolle (CC) Zusammenfassung Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

28 Spezielle Verfahren Pessimistische Verfahren Zentrale Kontrolle
Aus dem Bereich der verteilten Dateisysteme Spezielle Verfahren Pessimistische Verfahren Zentrale Kontrolle Dezentrale Kontrolle Ausgezeichnete Kontrolleinheit Token-Verfahren ohne Votierung mit Votierung Einfache Sperrverfahren Floor-Passing-Verfahren Transaktionsverfahren Transformationsverfahren Kodierungsverfahren Gitterprotokoll Mit Mehrheitsentscheidung gewichtetes write-all-read-any mit Zeugen Available-Copy dynamisches Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

29 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
Gitterprotokoll Logische Organisation der dateibesitzenden Rechner Lesender Zugriff: min. 1 Rechner pro Spalte Schreibender Zugriff: + alle Rechner einer Spalte Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

30 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
Votierungsverfahren Rechner stimmen über einen Lese- oder Schreibwunsch ab Hoher Kommunikationsbedarf Korrekte Verwendung der Sperren wird vorausgesetzt Gut bei großen Datenblöcken Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

31 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
Datenblock Datenblocknummer Versionsnummer Sperrzustand Datenblockinhalt Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

32 Gebrauch des Datenblocks (1)
5 ... k 6 ... k 6 ... „ XX „ „ YY „ „ YY „ Rechner 1 Rechner 2 Rechner 3 Zustand vor Lesen Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

33 Gebrauch des Datenblocks (2)
7 ... k 7 ... k 6 ... „ ZZ „ „ ZZ „ „ YY „ Rechner 1 Rechner 2 Rechner 3 Zustand nach Schreiben Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

34 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
Votum und Quorum Votum: Stimmzahl der Rechner, die den Zugriff gestatten (d.h. erreichbar und keine Sperre gesetzt) Quorum: untere Schranke bei deren Erreichen oder Übertreffen der Zugriffswunsch gestattet wird Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

35 Votieren mit Mehrheitsentscheidung
Jeder Rechner hat genau eine Stimme Bsp.: Rechnernetz mit 4 Rechnern und vollständig repliziertem Datenbestand  QU = 3  {{R1,R2,R3},{R1,R2,R4},{R1,R3,R4},{R2,R3,R4}} 1 1 R2 R1 R3 R4 1 1 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

36 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
Gewichtetes Votieren Unterschiedliche Stimmgewichte si für die Rechner (S = ∑i si) Für Lesequorum (QUl) und Schreibquorum (QUs) gilt: QUl + QUs > S 2 * QUs > S Vorteile: Null-Votum (Rechner mit si=0) wirkt leistungs-erhöhend beim Lesen (schneller Zugriff) QUl und QUs können auf erwartete Zugriffshäufigkeiten abgestimmt werden Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

37 Gewichtetes Votieren: Beispiel
2 1 R1 R2 1 1 R3 R4 QU = 3 {{R1,R2},{R1,R3},{R1,R4},{R1,R2,R3}} Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

38 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
write-all-read-any Jeder Rechner hat Stimmgewicht = 1 QUl = 1 QUs = n Vorteil: schneller Lesezugriff Nachteil: schwierig bei Änderungen Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

39 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
Votieren mit Zeugen k 7 ... Rechner ohne Datenblock, aber mit Stimmberechtigung Vorteile: Höhere Verfügbarkeit Geringer Speicherplatzbedarf Bei Ausfall eines Rechners erweiterbar zu voller Kopie Nachteil: Stimmmehrheit erreichbar, aber aktuellste Version nicht dabei (Zeuge hat höchste Versionsnummer), d.h. nur Schreiben möglich Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

40 Available-Copy-Verfahren (1)
Schreibt nur aktuell erreichbare Datenblockkopien fort Abgestürzte Rechner aktualisieren sich bei Neustart Jeder Rechner hat Stimmgewicht = 1 QUl = 1 1 ≤ QUs ≤ n Nur für LANs geeignet Problem: Im Falle einer Partitionierung werden nicht erreichbare Datenblockkopien nicht fortgeschrieben und bei einer Vereinigung der Partitionen werden diese Kopien nicht aktualisiert. Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

41 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
Gliederung Grundlagen verteilter Anwendungen Einfache Verfahren zur Nebenläufigkeitskontrolle Spezielle Verfahren zur Nebenläufigkeitskontrolle Zusammenfassung Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

42 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
Zusammenfassung Grundlagen verteilter Anwendungen Konsistenz  Nebenläufigkeit Verteilte Anwendungen häufig eingebettet in verteilte Systeme ( weitere Möglichkeiten der Synchronisation, z.B. Multicast-Synchronisationsprotkolle, Arbeiten mit Zeitstempeln, usw.) Verschiedene Verfahren, die verteilte Anwendungen benutzen können Verfahren abhängig von Anwendung (Replikation, gewünschter Grad an Nebenläufigkeit, Anzahl der Teilnehmer, Anwendungsbereich (LAN, WAN,...),...) Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

43 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
Verfahren Pessimistische Optimistische Zentrale Kontrolle Dezentrale Kontrolle Ausgezeichnete Kontrolleinheit Token-Verfahren ohne Votierung mit Votierung Einfache Sperrverfahren Floor-Passing-Verfahren Transaktionsverfahren Transformationsverfahren Gitterprotokoll Mit Mehrheitsentscheidung Gewichtetes Write-all-read-any Mit Zeugen Available-Copy Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

44 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
FRAGEN ? Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

45 Entwurf verteilter Anwendungen
Schnittstelle zu anderen Komponenten (was ist entfernt verfügbar?) Wie können Komponenten im Netzwerk lokalisiert werden? Umgang mit Fehlermeldungen? Erwünschter Grad an Unabhängigkeit? Datenaustausch ( z.B. durch RPC, gemeinsame Datenstrukturen, Nachrichten,...)? Replikation der Daten? Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

46 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
Literatur (Auszug) [BS2000] Borghoff, Schlichter: Computer-Supported Cooperative Work: Introduction to Distributed Applications [MA1994] Mayer: Synchronisation in kooperativen Systemen [HH1994]: Herrtwich, Hommel: Nebenläufige Programme [CO2001]: Coulouris, Dollimore, Kindberg: Distributed Systems – Concepts and Design [TA2002]: Tanenbaum, van Steen: Distributed Systems – Principles and Paradigms Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

47 Transaktionsverfahren
Auf Prinzip der Transaktionen Von Vorteil, wenn Transaktionen sehr kurz und Konflikte schnell auflösbar Einsetzbar, wenn zu erwarten, dass Benutzung der gemeinsamen Datenbestände asynchron erfolgt (d.h. geringe Konfliktwahrscheinlichkeit) Systeme mit dieser Kontrolle stützen sich häufig auf Datenbanksysteme ab Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

48 Serialisierbarkeit (1)
Zwei Transaktionen T1 und T2 sind serialisierbar, wenn das Ergebnis ihrer Ausführung dem Ergebnis einer seriellen Ausführung von T1 und T2 in einer beliebigen Ordnung entspricht (d.h. T1  T2 oder T2  T1) Funktioniert nur, wenn T1 und T2 nicht im Konflikt stehen Stehen im Konflikt, wenn gleiches Datum betroffen und eine der Transaktionen eine Schreiboperation ist Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

49 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
Coterie Rechnermengen, die ein Lesen oder Schreiben durchführen dürfen. Def.: A set C of node sets is called a coterie if the following three conditions are true: Empty set condition: If ci is a node in C then ci is not empty. Intersection condition: If ci and cj are node sets in C then their intersection is not empty. Minimality condition: There are no node set pairs ci and cj in C such that ci cj. Mit einer Coterie kann man ein Votum überprüfen ∩ Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

50 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
Kodierungsverfahren Neben Synchronisation wird versucht Speicherplatz zu sparen und die Datensicherheit zu erhöhen Grundidee: Kodieren der Datei d in N Stücke der Größe |d|/M, so dass M (disjunkte) Stücke genügen, um die Datei zu rekonstruieren. Unautorisierter Benutzer muss in M Rechner eindringen, um an die Datei zu kommen und muss diese dann noch entschlüsseln. Synchronisation und Konsistenzerhaltung in verteilten Anwendungen

51 Synchronisation und Konsistenzerhaltung in verteilten Anwendungen
Dynamisches Votieren Ziel: Fehlertoleranz in der Quorumpartition erhöhen. Viele Stimmanteile außerhalb der Partition und deshalb schwer ein erfolgreiches Votum zu erzielen neue Zuordnung der Stimmen innerhalb der Quorumpartition Gruppen-Konsensus: Bestimmen eines Koordinators und dann abstimmen über neue Stimmgewichte (Mehr-Phasen-Commit-Protokoll) Autonomes Vorgehen: Eigenständiges Ändern der Stimmgewichte. Dieses muss vor Anwendung durch eine Mehrheit der stimmberechtigten Rechner akzeptiert werden Synchronisation und Konsistenzerhaltung in verteilten Anwendungen