1 Jens Pflüger, Transaktionaler Schutz für Wartungsoperationen in Overlaynetzen Jens Pflüger 04. November 2005 Betreuender Professor: Prof. Dr. Ing. Klemens Böhm Betreuender Mitarbeiter: Dipl. Inform. Michael Klein DIPLOMARBEIT Universität Karlsruhe, Institut für Programmstrukturen und Datenorganisation
2 Jens Pflüger, Projekt-Kontext DIANE Angebote & Nachfragen müssen: beschrieben werden zu einander kommen abgeglichen werden Geräte müssen zur Ressourcen- bereitstellung motiviert werden Document Service In: -- Out: article on GROUP-BY operator Mehr über SQL? ? = $$$ DIANE = Dienste in Ad-hoc-Netzen Dienstankündigung / Dienstsuche
3 Jens Pflüger, Overlay-Netze Logische Struktur über vorhandenem Netzwerk Liefert Mehrwert Eigenschaften: Besitzen Struktur (dezentral verwaltet) Teilnahme-Status (Login / Logout) Adaption der Struktur wegen Änderungen am physischen Netzwerk nötig Vorteile bei der Dienstsuche: ohne Infrastruktur funktionsfähig Ressourcenschonend (Geschickte Weiterleitung von Nachrichten) Für dynamische Umgebungen geeignet BF D A CE physisches Netz Overlay A CE
4 Jens Pflüger, Lanes - Overlay Parallele Anordnung von Knoten- Bahnen ( Lanes) Anycast-Routing in x-Richtung für Dienstsuche Austausch und Speicherung von Dienstankündigungen innerhalb der Lane ( alle Lane-Mitglieder erscheinen von außen gleich) Vorteil: Begrenzung der Dienstankündigungs- und -suchnachrichten gegenüber Fluten Wartungsoperationen und Optimierungen zur Anpassung der Struktur: Login, Logoff, Lane-Splitting, Lane- Merging, Lane-Reparatur,... any cast any cast Dienstankündigung Dienstsuche
5 Jens Pflüger, Schwierigkeiten Algorithmen für die einzelnen Aufgaben zu entwickeln ist relativ einfach Probleme treten bei paralleler Ausführung mehrerer Mechanismen oder bei Fehlern auf: Gegenseitiges Überschreiben von Änderungen (Lost Updates) Unerlaubtes Lesen der geschriebenen Werte (Dirty Reads, Non-Repeatable Reads) Inkonsistenz der Struktur !! Grundsätzliche Lösung: Fehler müssen erkannt werden Betroffene Operationen müssen abgebrochen werden können Ihre Wirkung muss zurückgesetzt werden
6 Jens Pflüger, Beispiel Split-Request (1) Split-Complete (3) 7 Login (2)
7 Jens Pflüger, Stand der Forschung Lanes Pastry, Chord, BambooCAN Tapestry Beschriebene Probleme sind keine Lanes-spezifischen Phänomene Wie gehen existierende Overlays damit um ? Untersuchung existierender Overlay-Implementierungen, die zur Dienstsuche verwendet werden (können)
8 Jens Pflüger, Stand der Forschung (2) Entwicklung protokollspezifischer Lösungen: komplex schwer zu überschauen schlecht wartbar Lösungsansätze nicht übertragbar Minderung der Probleme durch: Fehlertolerante Strukturen Routingtabellen keine speziellen Overlay-Strukturen (z.B. bei Tapestry) Nicht allgemein einsetzbar! Periodische Reorganisationsmaßnahmen Internet-Bereich Temporäre Inkonsistenzen Prioritätsbasierte Lösungen Globale Serialisierung Keine Parallelität, Timeouts
9 Jens Pflüger, Eigener Ansatz Transaktionaler Operationsschutz
10 Jens Pflüger, Ansatz Entwicklung eines allgemeinen Schutzsystems Erkennung von Fehlern Abbrechen von betroffenen Operationen Zurücksetzen ihrer Wirkung Generizität Eigenständiges System Einfachere Entwicklung neuer Overlays Grundüberlegung: Die beschriebenen Probleme treten auch in Datenbank- systemen auf! Transaktionen beheben dort diese Schwierigkeiten Overlay-Operationen würden auch korrekt ablaufen, wenn sie transaktional geschützt sind
11 Jens Pflüger, Transaktionales Schutzsystem Verwendung eines verteiltem DBMS: Unterschiede: nur wenige zu schützende Datenwerte geringe Zahl paralleler Operationen pro Knoten viele Knoten an einer Operation beteiligt A C I D - Eigenschaft Hohe Fehlerwahrscheinlichkeit DB-Metadaten Strukturdaten Eigene Fehlerbehandlung durch die Overlay-Mechanismen T T K TA Knoten DBMS Overlay-Netz verteiltes DBMS Overlay-Operation verteilte TA
12 Jens Pflüger, Systemaufbau Lokale Konsistenz Globale Konsistenz
13 Jens Pflüger, Lokale Konsistenz Verwendung gängiger Schedule-Protokolle Strenge Sequentialität 2-Phasen-Sperr-Protokoll Vorabsperrendes Protokoll Optimistisches Vorgehen … Leichte Austauschbarkeit und Erweiterung Gemeinsame Schnittstelle Vorgegebene Infrastruktur: Sperrenverwaltung Deadlock-Vermeidung Deadlock-Erkennung Log-Management (nicht dauerhaft)
14 Jens Pflüger, Globale Konsistenz 2-Phasen-Commit-Protokoll:
15 Jens Pflüger, PC-Anpassungen Koordinator = Initiator der Operation Allen Teilnehmern bekannt Koordinator lernt Teilnehmer erst über Abstimmungs- nachrichten kennen (s.u.) keine initialen Abstimmungsaufforderungen Get-To-Know-Protokoll: Jeder Knoten protokolliert automatisch sämtliche Nachrichten einer Operation mit. Korrespondenz-Adressen werden mit Stimme übermittelt optional C Partitionierung True 2, (4) True 1, 3 True - True 2 Problem: System soll so generisch wie möglich sein (d.h. so wenig zusätzliche Informationen von oben wie möglich!)
16 Jens Pflüger, Aufwandsbetrachtung Commit-Protokoll ist aufwändig: prinzipiell 4(n-1) Nachrichten 3(n-1) Nachrichten bei zuverlässigem Transportprotokoll (keine expliziten Acks) n bei einigen Operationen groß! (z.B. Login) Verbesserungen: Anpassungen des 2-Phasen-Commits (Get-To-Know- Protokoll) nur noch 2(n-1) Nachrichten Nur Schutz der strukturkritischen Operationen und Operationsteile Ping/Pong Dienst- aktualisierung Timeout Reparatur erfolgreich LaneBroken transaktional geschützter Kern Vorbereitung Nachbearbeitung SessionID: 2 SessionID: 3 SessionID: 1
17 Jens Pflüger, Evaluation - Szenario Verwendung der Diane-Service-Benchmark SB6: 25 Knoten Erstes Angebot: U(60, 1000) s Angebotszahl: max. 5 Angebotsfrequenz: U(120, 240) s Suchfrequenz: U(60, 120) s Modifikationen: Simulationsdauer: 1000 s Erster Login: U(30, 1000) s Logouts möglich (nach 40 s Idle-Zeit) Relogins (min. 10 s nach Logout) Entfernen von Angeboten (Haltezeit: 120 s) Einstellungen bei Lanes: Lane-Größe: 3-10 Ping-Intervall: 15 s
18 Jens Pflüger, Live-Demo
19 Jens Pflüger, Effizienz 300 Simulations- läufe beschr. Szenario: Zusatzaufwand durch Trans- aktionen: 19% Verhältnis TA- Sonstige: 39% var. Netznutzung: Untersuchung anhand versch. Logout-Raten Zusatzaufwand: 7,5 – 22% Nachrichtenverteilung / Zusatzaufwand Zusatzaufwand bei variabler Netzlast
20 Jens Pflüger, Effektivität Je 50 Simulationsläufe Netzlast 1: wie im Szenario beschrieben Netzlast 2: 50 Knoten, Logout nach 30 s Nach jedem Simulationslauf: Test der Konsistenz der aufgebauten Lanes- Struktur (Inter- und Intra-Lanes-Verbindungen) Test des schutzlosen Systems durch speziellen Scheduler Testlaufanteil mit inkonsistentem Ergebnis
21 Jens Pflüger, Live-Demo (2)
22 Jens Pflüger, Zusammenfassung & Ausblick Probleme bei parallelen Wartungsoperationen in Overlays: Lost Updates Non-Repeatable Reads Dirty Reads Entwicklung eines transaktionalen Schutzsystems Große Ähnlichkeit zu verteilten Datenbanksystemen Eigenständige Komponente Erhebliche Fehlerreduktion bei Mehraufwand bis ca. 22% Ausblick: Einsatz für andere Overlays Funktionsfähige, korrekte, individuelle Lanes-Realisierung Weitere Commit- und Scheduleprotokolle
23 Jens Pflüger, Ende Vielen Dank für die Aufmerksamkeit! Fragen ?
24 Jens Pflüger, Anhang
25 Jens Pflüger, Lokale Konsistenz - Datenspeicherung Gruppenzuordnungen (Anycast- adressen) werden von einem dem Netzwerk nahem Overlay verwaltet kein direkter Schutz möglich Verwendung eines optimistischen Ansatzes: Durchführung von Änderungen in TA- lokalem Bereich Festschreiben der Änderungen erst nach erfolgreichem Abschluss Abschlussprüfung auf zwischenzeitliche Änderungen Alle anderen Strukturdaten verwaltet das Overlay selbst Phys. Schicht Sicherung Netzwek Transport Overlay Benutzer Scheduler Anycast-Overlay
26 Jens Pflüger, Pastry Neighborhood-Set Leaf-Set kleinergrößer Knoten ID Routing-Tabelle d4213f d462ba d46a01 d471f1 d46a1c 65a1fc Route(d46a1c) d1a08e
27 Jens Pflüger, CAN – Content Addressable Network x y 10 VID
28 Jens Pflüger, Chord StartInt.Nachf. 7[7,0)0 0[0,2)0 2[2,6)3 StartInt.Nachf. 1[1,2)1 2[2,4)3 4[4,0)6 StartInt.Nachf. 2[2,3)3 3[3,5)3 5[5,1)6 StartInt.Nachf. 4[4,5)6 5[5,7)6 7[7,3)0
29 Jens Pflüger, Tapestry FE A B4F E391 4A6D 57EC AA Buch XY (4378) Buch XY (4378) Publizierung Objektpointer Anfrage
30 Jens Pflüger, Evaluation - Ergebnisse
31 Jens Pflüger, Lineares 2PC
32 Jens Pflüger, PC