Replikationsarchitekturen Informationsverwaltung von Netzen Sommersemester 2003 Konrad Kretschmer

Inhalt 1/29

Inhalt Hintergrund 1/29

Inhalt Hintergrund - Optimistische Replikation - Datensynchronisation - Selektive Replikation 1/29

Inhalt Hintergrund RUMOR - Optimistische Replikation - Datensynchronisation - Selektive Replikation 1/29

Inhalt Hintergrund RUMOR - Optimistische Replikation - Datensynchronisation - Selektive Replikation - Gossip - Versionsvektoren - Adaptive Ringe - Garbage Collection 1/29

Inhalt Hintergrund RUMOR ROAM - Optimistische Replikation - Datensynchronisation - Selektive Replikation - Gerüchteverkehr - Versionsvektoren - Adaptive Ringe - Abfallbeseitigung 1/29

Inhalt Hintergrund RUMOR ROAM - Optimistische Replikation - Datensynchronisation - Selektive Replikation - Gerüchteverkehr - Versionsvektoren - Adaptive Ringe - Abfallbeseitigung - Das WARD-Modell - Das erweiterte WARD-Modell 1/29

Hintergrund 2/29

Optimistische Replikation Hintergrund 2/29

Optimistische Replikation Hintergrund 2/29 Problem: Versionskonflikte in verteilten Systemen

Optimistische Replikation Hintergrund 2/29 Problem: Versionskonflikte in verteilten Systemen Konservative Algorithmen: Sperrung von Dateien Geeignet für Client-Server-Architekturen Nachteil: Geringe Verfügbarkeit

Optimistische Replikation Hintergrund 2/29 Problem: Versionskonflikte in verteilten Systemen Konservative Algorithmen: Sperrung von Dateien Geeignet für Client-Server-Architekturen Nachteil: Geringe Verfügbarkeit Optimistische Algorithmen: Das Problem wird ignoriert. Versionskonflikte werden gelöst. Geeignet für P2P-Netzwerke Nachteil: Versionskonflikte müssen erkannt werden.

Datensynchronisation Hintergrund 3/29 Informationen über die Datenbestände müssen an alle Teilnehmer geleitet werden.

Datensynchronisation Hintergrund 3/29 Informationen über die Datenbestände müssen an alle Teilnehmer geleitet werden. Sofortige Benachrichtigung

Datensynchronisation Hintergrund 3/29 Informationen über die Datenbestände müssen an alle Teilnehmer geleitet werden. Sofortige Benachrichtigung Kontaktierung eines anderen Teilnehmers bei Änderung der Daten.

Datensynchronisation Hintergrund 3/29 Informationen über die Datenbestände müssen an alle Teilnehmer geleitet werden. Sofortige Benachrichtigung Kontaktierung eines anderen Teilnehmers bei Änderung der Daten. Vorteile: - Das Netz ist schnell auf dem aktuellen Stand.

Datensynchronisation Hintergrund 3/29 Informationen über die Datenbestände müssen an alle Teilnehmer geleitet werden. Sofortige Benachrichtigung Kontaktierung eines anderen Teilnehmers bei Änderung der Daten. Vorteile: - Das Netz ist schnell auf dem aktuellen Stand. - Versionskonflikte treten selten auf.

Datensynchronisation Hintergrund 3/29 Informationen über die Datenbestände müssen an alle Teilnehmer geleitet werden. Sofortige Benachrichtigung Kontaktierung eines anderen Teilnehmers bei Änderung der Daten. Vorteile: - Das Netz ist schnell auf dem aktuellen Stand. - Versionskonflikte treten selten auf. Nachteile: - Oft irrelevante Aktualisierungen

Datensynchronisation Hintergrund 3/29 Informationen über die Datenbestände müssen an alle Teilnehmer geleitet werden. Sofortige Benachrichtigung Kontaktierung eines anderen Teilnehmers bei Änderung der Daten. Vorteile: - Das Netz ist schnell auf dem aktuellen Stand. - Versionskonflikte treten selten auf. Nachteile: - Oft irrelevante Aktualisierungen - Viele Verbindungen zum Netzwerk

Datensynchronisation Hintergrund 3/29 Informationen über die Datenbestände müssen an alle Teilnehmer geleitet werden. Sofortige Benachrichtigung Kontaktierung eines anderen Teilnehmers bei Änderung der Daten. Vorteile: - Das Netz ist schnell auf dem aktuellen Stand. - Versionskonflikte treten selten auf. Nachteile: - Oft irrelevante Aktualisierungen - Viele Verbindungen zum Netzwerk - Verbindungen evtl. zu ungünstigen Konditionen

Datensynchronisation Hintergrund 4/29 Periodischer Abgleich

Datensynchronisation Hintergrund 4/29 Periodischer Abgleich Informationen über Änderungen zueinem günstigen Zeitpunkt übertragen.

Datensynchronisation Hintergrund 4/29 Periodischer Abgleich Informationen über Änderungen zueinem günstigen Zeitpunkt übertragen. Vorteile: - Verbindungen zum Netzwerk treten seltener auf.

Datensynchronisation Hintergrund 4/29 Periodischer Abgleich Informationen über Änderungen zueinem günstigen Zeitpunkt übertragen. Vorteile: - Verbindungen zum Netzwerk treten seltener auf. - Keine Verbindungen zum Netzwerk unter schlechten Konditionen.

Datensynchronisation Hintergrund 4/29 Periodischer Abgleich Informationen über Änderungen zueinem günstigen Zeitpunkt übertragen. Vorteile: - Verbindungen zum Netzwerk treten seltener auf. - Keine Verbindungen zum Netzwerk unter schlechten Konditionen. Nachteile: - Das Netzwerk ist seltener auf dem aktuellen Stand.

Datensynchronisation Hintergrund 4/29 Periodischer Abgleich Informationen über Änderungen zueinem günstigen Zeitpunkt übertragen. Vorteile: - Verbindungen zum Netzwerk treten seltener auf. - Keine Verbindungen zum Netzwerk unter schlechten Konditionen. Nachteile: - Das Netzwerk ist seltener auf dem aktuellen Stand. - Versionskonflikte treten häufiger auf.

Selektive Replikation Hintergrund 5/29 Abgleich in feinerer als der Grundgranularität.

Selektive Replikation Hintergrund 5/29 Abgleich in feinerer als der Grundgranularität. - Verringert unnötigen Datentransfer

Selektive Replikation Hintergrund 5/29 Abgleich in feinerer als der Grundgranularität. - Verringert unnötigen Datentransfer - Benötigt größeren Verwaltungsaufwand

FICUS Hintergrund 6/29 - Entwickelt Reines P2P-System - Optimistische Replikation - Arbeitet auf Volume-Ebene - Sofortige Benachrichtigung und Periodischer Abgleich.

FICUS Hintergrund 6/29 - Entwickelt Reines P2P-System - Optimistische Replikation - Arbeitet auf Volume-Ebene - Sofortige Benachrichtigung und Periodischer Abgleich. Nachteile: - Schwer Portierbar auf andere Betriebsysteme - Schlechte Performanz bei hoher Teilnehmerzahl

RUMOR 7/29

RUMOR 7/29 - Entwickelt Basiert auf FICUS - Optimistische Replikation - Arbeitet auf Volume-Ebene - Nur Periodischer Abgleich - Leicht portierbar (C++) - Verwaltet sich mit Hilfe einer Datenbank

RUMOR 8/29 Datenabgleich - Datenabgleich immer zwischen genau zwei Teilnehmern.

RUMOR 8/29 Datenabgleich - Datenabgleich immer zwischen genau zwei Teilnehmern. - Immer nur ein Teilnehmer wird aktualisiert.

RUMOR 8/29 Datenabgleich - Datenabgleich immer zwischen genau zwei Teilnehmern. - Immer nur ein Teilnehmer wird aktualisiert. - Abgleich in drei Phasen: Scanphase, Kontaktierphase und Abgleichsphase.

RUMOR 9/29 Datenabgleich PHASE 1: Scanphase A B DBVolumeDBVolume

RUMOR 9/29 Datenabgleich PHASE 1: Scanphase A B DBVolumeDBVolume Aktualisierung

RUMOR 10/29 Datenabgleich PHASE 2: Kontaktierphase A B DBVolumeDBVolume Kontaktierung

RUMOR 10/29 Datenabgleich PHASE 2: Kontaktierphase A B DBVolumeDBVolume Kontaktierung Vergleich

RUMOR 11/29 Datenabgleich PHASE 3: Abgleichsphase A B DBVolumeDBVolume Transfer

RUMOR Gossip - Beim Abgleich werden auch gesammelte Daten anderer Teilnehmer übertragen. 12/29

RUMOR - Beim Abgleich werden auch gesammelte Daten anderer Teilnehmer übertragen. - Nachrichten werden unregelmäßig, aber zuverlässig weitergeleitet. 12/29 Gossip

RUMOR - Beim Abgleich werden auch gesammelte Daten anderer Teilnehmer übertragen. - Nachrichten werden unregelmäßig, aber zuverlässig weitergeleitet. - Teilnehmer muss sich nur mit einem weiteren Teilnehmer abgleichen und kann danach das Netzwerk verlassen. 12/29 Gossip

RUMOR Versionsvektoren - Werden verwendet um Versionskonflikte zu erkennen. 13/29

RUMOR Versionsvektoren - Werden verwendet um Versionskonflikte zu erkennen. - Jedes Volume jedes Teilnehmers hat einen eigenen Versionsvektor. 13/29

RUMOR Versionsvektoren - Werden verwendet um Versionskonflikte zu erkennen. - Jedes Volume jedes Teilnehmers hat einen eigenen Versionsvektor. - Versionsvektoren halten die Aktualisierungen der Dateien fest. 13/29

RUMOR Versionsvektoren - Werden verwendet um Versionskonflikte zu erkennen. - Jedes Volume jedes Teilnehmers hat einen eigenen Versionsvektor. - Versionsvektoren halten die Aktualisierungen der Dateien fest. - Versionsvektoren werden in der Kontaktierphase des Abgleichs verglichen. 13/29

RUMOR Versionsvektoren - Werden verwendet um Versionskonflikte zu erkennen. - Jedes Volume jedes Teilnehmers hat einen eigenen Versionsvektor. - Versionsvektoren halten die Aktualisierungen der Dateien fest. - Versionsvektoren werden in der Kontaktierphase des Abgleichs verglichen. - Bei Konflikt werden automatisierte Korrekturverfahren angewendet. 13/29

RUMOR Adaptiver Ring - Alle Teilnehmer erhalten bei Anmeldung einen eindeutig vergleichbaren Schlüssel. 14/29

RUMOR Adaptiver Ring - Alle Teilnehmer erhalten bei Anmeldung einen eindeutig vergleichbaren Schlüssel. - Durch die Schlüssel sind Nachfolger und Vorgänger eindeutig bestimmt. 14/29

RUMOR Adaptiver Ring - Alle Teilnehmer erhalten bei Anmeldung einen eindeutig vergleichbaren Schlüssel. - Durch die Schlüssel sind Nachfolger und Vorgänger eindeutig bestimmt. - Größter Schlüssel wird mit kleinstem Schlüssel verbunden. Es entsteht ein Ring. 14/29

RUMOR Adaptiver Ring - Alle Teilnehmer erhalten bei Anmeldung einen eindeutig vergleichbaren Schlüssel. - Durch die Schlüssel sind Nachfolger und Vorgänger eindeutig bestimmt. - Größter Schlüssel wird mit kleinstem Schlüssel verbunden. Es entsteht ein Ring. - Neue Teilnehmer erhalten mit dem Schlüssel einen festen Platz im Ring. 14/29

RUMOR Adaptiver Ring - Alle Teilnehmer erhalten bei Anmeldung einen eindeutig vergleichbaren Schlüssel. - Durch die Schlüssel sind Nachfolger und Vorgänger eindeutig bestimmt. - Größter Schlüssel wird mit kleinstem Schlüssel verbunden. Es entsteht ein Ring. - Neue Teilnehmer erhalten mit dem Schlüssel einen festen Platz im Ring. - Wenn Teilnehmer das Netzwerk verlassen, schließt sich der Ring automatisch. 14/29

RUMOR Adaptiver Ring 15/29 Beispiel

RUMOR Adaptiver Ring 15/29 Beispiel

RUMOR Adaptiver Ring 15/29 Beispiel

RUMOR Adaptiver Ring 15/29 Beispiel

RUMOR Adaptiver Ring 15/29 Beispiel

RUMOR Garbage Collection - Keine Freigabe von Ressourcen, wenn nur lokal keine Namen und Verweise auf die Daten vorhanden sind. 15/29

RUMOR - Keine Freigabe von Ressourcen, wenn nur lokal keine Namen und Verweise auf die Daten vorhanden sind. - Anfrage an den Nachfolger im adaptiven Ring. 15/29 Garbage Collection

RUMOR - Keine Freigabe von Ressourcen, wenn nur lokal keine Namen und Verweise auf die Daten vorhanden sind. - Anfrage an den Nachfolger im adaptiven Ring. - Anfrage wird durch Gossip durch das Netzwerk geleitet. 15/29 Garbage Collection

RUMOR - Keine Freigabe von Ressourcen, wenn nur lokal keine Namen und Verweise auf die Daten vorhanden sind. - Anfrage an den Nachfolger im adaptiven Ring. - Anfrage wird durch Gossip durch das Netzwerk geleitet. - Jeder Teilnehmer prüft, ob die zu löschenden Daten bei ihm vorhanden sind. 15/29 Garbage Collection

RUMOR - Keine Freigabe von Ressourcen, wenn nur lokal keine Namen und Verweise auf die Daten vorhanden sind. - Anfrage an den Nachfolger im adaptiven Ring. - Anfrage wird durch Gossip durch das Netzwerk geleitet. - Jeder Teilnehmer prüft, ob die zu löschenden Daten bei ihm vorhanden sind. - Informationen über nicht verbundene Teilnehmer befinden sich in den Datenbanken verbundener Teilnehmer. 15/29 Garbage Collection

RUMOR - Keine Freigabe von Ressourcen, wenn nur lokal keine Namen und Verweise auf die Daten vorhanden sind. - Anfrage an den Nachfolger im adaptiven Ring. - Anfrage wird durch Gossip durch das Netzwerk geleitet. - Jeder Teilnehmer prüft, ob die zu löschenden Daten bei ihm vorhanden sind. - Informationen über nicht verbundene Teilnehmer befinden sich in den Datenbanken verbundener Teilnehmer. - Wenn die Daten im Netzwerk nicht mehr existieren können die Ressourcen freigegeben werden. 15/29 Garbage Collection

ROAM 16/29

ROAM - Entwickelt Basiert auf RUMOR und FICUS - Schwerpunkt der Änderungen: Vorteile für mobile Teilnehmer - Kein reines P2P-System, sondern hybride Form zwischen P2P und Client-Server 16/29

ROAM 17/29 Das WARD-Modell

ROAM 17/29 Das WARD-Modell - Teilnehmer werden in Gruppen aufgeteilt. - Gruppierung erfolgt nach Verbindungskonditionen. - Verbindungen zu Teilnehmern innerhalb einer Gruppe sollen häufiger auftreten als Verbindungen zu Teilnehmern in verschiedenen Gruppen. - Die Gruppen heißen WARDs (Wide-Area-Replication-Domains).

ROAM 18/29 Das WARD-Modell

ROAM 19/29 Das WARD-Modell - Jeder WARD hat einen WARD-Master. - Der WARD-Master ist die Schnittstelle zwischen den Teilnehmern des WARDs zu Teilnehmern anderer WARDs. - Der WARD-Master wird willkürlich gewählt. - Bei Trennung des WARD-Masters vom Netzwerk kann schnell und mit geringem Aufwand ein neuer WARD-Master gewählt werden. - Die Teilnehmer eines WARDs werden in einem adaptiven Ring angeordnet. - Die WARD-Master aller WARDs werden in einem adaptiven Ring angeordnet. - Zwei Schichten.

ROAM 20/29 Das WARD-Modell Beispiel

ROAM Das WARD-Modell Beispiel /

ROAM Das WARD-Modell Beispiel /29 4

ROAM Das WARD-Modell Beispiel /

ROAM Das WARD-Modell Beispiel /

ROAM Das WARD-Modell - Bei Veränderung der Verbindungskonditionen kann es zu einem WARD-Wechsel eines Teilnehmers kommen. - Der Teilnehmer meldet sich beim neuen WARD an und beim alten ab. - Es muss dabei jeweils nur ein anderer Teilnehmer kontaktiert werden (Gossip). - Wenn kein Teilnehmer des alten WARDs verfügbar sein sollte, kann die Abmeldung auch zu einem späteren Zeitpunkt vollzogen werden. 21/29

ROAM Das WARD-Modell Beispiel /

ROAM Das WARD-Modell Beispiel /

Das WARD-Modell Beispiel /29 ROAM

Das WARD-Modell Beispiel /29 ROAM

Das WARD-Modell Beispiel /29 ROAM

Das WARD-Modell Beispiel /29 ROAM

Das erweiterte WARD-Modell - Selektive Replikation durch Einfügen einer dritten Schicht. - Die Dateien eines Volumes werden in jeweils einem Ring angeordnet. - Weniger unnötige Datentransfers. 23/29

ROAM Beispiel 24/29 1 X Y 3 Y 6 X Y 8 X 10 X 2 X Y 12 Y Das erweiterte WARD-Modell

ROAM Beispiel 24/29 1 X Y 3 Y 6 X Y 8 X 10 X 2 X Y 12 Y Das erweiterte WARD-Modell

ROAM Beispiel 24/29 1 X Y 3 Y 6 X Y 8 X 10 X 2 X Y 12 Y Das erweiterte WARD-Modell

ROAM Das erweiterte WARD-Modell - WARD-Wechsel können unnötig Ressourcen verbrauchen, wenn der Wechsel nur für kurze Zeit stattfindet. - WARD-Überlappung erlaubt die zeitlich begrenzte Mitgliedschaft in zwei WARDs gleichzeitig. - Es erfolgt zunächst keine Abmeldung vom alten WARD. - Erst wenn eine Zeitgrenze überschritten wurde, wird die Überlappung beendet. 25/29

ROAM Beispiel / Das erweiterte WARD-Modell 4

ROAM Beispiel / Das erweiterte WARD-Modell 4

ROAM Beispiel / Das erweiterte WARD-Modell 4

ROAM Beispiel / Das erweiterte WARD-Modell 4

ROAM Beispiel / Das erweiterte WARD-Modell 4

Beispiel / Das erweiterte WARD-Modell 1 ROAM 4

Beispiel / Das erweiterte WARD-Modell 1 ROAM 4

Fazit 27/29 - RUMOR und ROAM garantieren den korrekten Datenabgleich. - Problem: Leistungsfähigkeit.

Fazit 27/29 - RUMOR und ROAM garantieren den korrekten Datenabgleich. - Problem: Leistungsfähigkeit. RUMOR N-1 Abgleichsschritte (worst case)

Fazit 27/29 - RUMOR und ROAM garantieren den korrekten Datenabgleich. - Problem: Leistungsfähigkeit. RUMOR N-1 Abgleichsschritte (worst case) ROAM 2N M +M-3 Abgleichsschritte (worst case)

Fazit 27/29 - RUMOR und ROAM garantieren den korrekten Datenabgleich. - Problem: Leistungsfähigkeit. RUMOR N-1 Abgleichsschritte (worst case) ROAM 2N M ROAM wird Leistungsfähiger als RUMOR, wenn 2 3 (Durch Testläufe ermittelt) +M-3 Abgleichsschritte (worst case)

Fazit 27/28

Fazit 27/29 Schwachstellen bei beiden Systemen: - Garbage Collection

Fazit 27/29 Schwachstellen bei beiden Systemen: - Garbage Collection - Geringe Leistungsfähigkeit bei kleinen Abgleichsdaten

Fazit 27/29 Schwachstellen bei beiden Systemen: - Garbage Collection - Geringe Leistungsfähigkeit bei kleinen Abgleichsdaten - Kaum unter realen Bedingungen eingesetzt