Replikationsarchitekturen Informationsverwaltung von Netzen Sommersemester 2003 Konrad Kretschmer

Präsentation zum Thema: "Replikationsarchitekturen Informationsverwaltung von Netzen Sommersemester 2003 Konrad Kretschmer"—  Präsentation transkript:

1 Replikationsarchitekturen Informationsverwaltung von Netzen Sommersemester 2003 Konrad Kretschmer (kkretsch@inf.fu-berlin.de)

2 Inhalt 1/29

3 Inhalt Hintergrund 1/29

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

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

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

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

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

9 Hintergrund 2/29

10 Optimistische Replikation Hintergrund 2/29

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

12 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

13 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.

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

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

16 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.

17 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.

18 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.

19 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

20 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

21 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

22 Datensynchronisation Hintergrund 4/29 Periodischer Abgleich

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

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

25 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.

26 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.

27 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.

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

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

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

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

32 FICUS Hintergrund 6/29 - Entwickelt 1990 - 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

33 RUMOR 7/29

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

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

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

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

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

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

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

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

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

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

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

45 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

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

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

48 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

49 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

50 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

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

52 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

53 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

54 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

55 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

56 RUMOR Adaptiver Ring 15/29 Beispiel 9 8 1 4 2

57 RUMOR Adaptiver Ring 15/29 Beispiel 9 8 1 4 2

58 RUMOR Adaptiver Ring 15/29 Beispiel 9 8 1 4 2 5

59 RUMOR Adaptiver Ring 15/29 Beispiel 9 8 1 4 2 5

60 RUMOR Adaptiver Ring 15/29 Beispiel 9 8 1 4 2 5

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

62 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

63 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

64 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

65 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

66 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

67 ROAM 16/29

68 ROAM - Entwickelt 1998 - 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

69 ROAM 17/29 Das WARD-Modell

70 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).

71 ROAM 18/29 Das WARD-Modell

72 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.

73 ROAM 20/29 Das WARD-Modell Beispiel 1 8 20 2 7 6 5 10 12 3 15 4

74 ROAM Das WARD-Modell Beispiel 1 8 20 2 7 6 5 10 12 3 20/29 4 15

75 ROAM Das WARD-Modell Beispiel 1 8 20 2 7 6 5 10 12 3 15 20/29 4

76 ROAM Das WARD-Modell Beispiel 1 8 20 2 7 10 12 15 20/29 6 5 3 4

77 ROAM Das WARD-Modell Beispiel 1 8 20 2 7 10 12 15 20/29 6 5 3 4

78 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

79 ROAM Das WARD-Modell Beispiel 1 8 20 2 7 10 12 15 22/29 6 5 3 4

80 ROAM Das WARD-Modell Beispiel 1 8 20 2 7 10 12 15 22/29 6 5 3 4

81 Das WARD-Modell Beispiel 1 8 20 2 7 10 12 15 22/29 ROAM 6 5 3 4

82 Das WARD-Modell Beispiel 1 8 20 2 7 10 12 15 22/29 ROAM 6 5 3 4

83 Das WARD-Modell Beispiel 1 8 20 2 7 10 12 15 22/29 ROAM 6 5 3 4

84 Das WARD-Modell Beispiel 1 8 20 2 7 10 12 15 22/29 ROAM 6 5 3 4

85 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

86 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

87 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

88 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

89 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

90 ROAM Beispiel 1 8 20 2 7 10 12 15 26/29 6 5 3 Das erweiterte WARD-Modell 4

91 ROAM Beispiel 1 8 20 2 7 10 12 15 26/29 6 5 3 Das erweiterte WARD-Modell 4

92 ROAM Beispiel 1 8 20 2 7 10 12 15 26/29 6 5 3 Das erweiterte WARD-Modell 4

93 ROAM Beispiel 1 8 20 2 7 10 12 15 26/29 6 5 3 Das erweiterte WARD-Modell 4

94 ROAM Beispiel 1 8 20 2 7 10 12 15 26/29 6 5 3 Das erweiterte WARD-Modell 4

95 Beispiel 8 20 2 7 10 12 15 26/29 6 5 3 Das erweiterte WARD-Modell 1 ROAM 4

96 Beispiel 8 20 2 7 10 12 15 26/29 6 5 3 Das erweiterte WARD-Modell 1 ROAM 4

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

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

99 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)

100 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)

101 Fazit 27/28

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

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

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

105