Vs5.5 1 5.5 Verteilte Hash-Tabellen (distributed hastables, DHT) am Beispiel von Chord (Stoica et al. 2001) Ziel:"Gutes" Verteilen von Informationen auf.

Präsentation zum Thema: "Vs5.5 1 5.5 Verteilte Hash-Tabellen (distributed hastables, DHT) am Beispiel von Chord (Stoica et al. 2001) Ziel:"Gutes" Verteilen von Informationen auf."—  Präsentation transkript:

1 vs5.5 1 5.5 Verteilte Hash-Tabellen (distributed hastables, DHT) am Beispiel von Chord (Stoica et al. 2001) Ziel:"Gutes" Verteilen von Informationen auf mehrere Stationen, bzw. Auffinden einer zuständigen Station Idee:Verteilung / Auffindung mittels Hashing, mit Information als Schlüssel und Station als Bucket - verteilt, alle Stationen sind am Hashing beteiligt, keine muss gesammte Hashtabelle kennen - nichtsequentiell, nebenläufige Anfragen möglich Problem:Ausfallende bzw. neu hinzukommende Stationen Vor.:zuverlässige Unicast-Kommunikation, nicht zerfallendes Netz mit Duplex-Verbindungen

2 vs5.5 2 Zur Erinnerung: Größenänderung einer Hashtabelle - läßt alle Einträge ungültig werden, - erfordert Re-hashing zur Korrektur. Unzuverlässige Stationen (= Buckets), Situation tritt häufig ein! Re-hashig wegen netzweiter Verteilung nicht vertretbar. Grundidee: Konsistentes Hashing mit den Eigenschaften - möglichst gleichmäßige Verteilung von Schlüsseln auf Buckets - minimale Neuzuordung von Schlüsseln bei Größenänderung - u.a. [siehe "Consistent hashing and random trees [...]", Karger et al. 1997]

3 vs5.5 3 Konsistentes Hashing bei Chord: ● Erzeuge für jede Station sowie jede Information einen Identifikator = Integer mit m Bits, mittels eines Basis-Hash (SHA-1) Station: ID node ist SHA-1 über IP-Adresse der Station Information:ID key ist SHA-1 über den Inhalt der Information Basis-Hash bewirkt gleichmäßige Verteilung im ID-Raum. ● Sortiere node sowie key aufsteigend modulo 2 m als Ring ● Weise jeden key einer Station node zu mit node = successor(key) ● successor(key) ist die ersten Stations-ID im Ring, die der Informations-ID key gleicht oder auf diese folgt. Dienst: finde successor(x) im Ring, für beliebige Werte x

4 vs5.5 4 Beispiel: Ring mit m=6, 10 Stationen Nx und 5 Schlüsseln Ky N1N1 N8N8 N1 4 N2 1 N3 2 N3 8 N4 2 N4 8 N5 1 N5 6 K10 K24 K30 K38 K54

5 vs5.5 5 N2 1 N3 2 K30 K24 N2 1 N3 2 K30 K24 N26 (neu ) N2 1 N3 2 K30 K24 N2 6 K24 Neuzuordnun g Neue Station n : - finde Nachfolger n' = successor(n) - übernehme Zuständigkeit von n' für Schlüssel k mit successor(k) = n analog für ausfallende Station. Alle anderen Zuordnungen bleiben erhalten !

6 vs5.5 6 N1N1 N8N8 N1 4 N2 1 N3 2 N3 8 N4 2 N4 8 N5 1 N5 6 K54 Einfachste verteilte Implementierung: Jede Station kennt ihren Nachfolger (sowie Vorgänger) und leitet Anfragen ggf. weiter. Aufwand: Speicher O(1) pro Station, aber Kommunikation O(n) lookup(K54)

7 vs5.5 7 Stabilisierung des Rings bei Hinzukommen einer Station:  Neue Station n fragt beliebige Station nach successor(n), merkt sich diesen als Nachfolger  Alle Stationen geben sich regelmäßig ihrem Nachfolger als Vorgänger bekannt  Alle Stationen fragen regelmäßig ihren Nachfolger nach dessen Vorgänger und setzten diesen ggf. als eigenen Nachfolger N2 1 N3 2 N2 1 N3 2 N26  bei N26 N3 2 N26  bei N21 N2 1 N3 2 N26  bei N21 N26 (neu )  bei N26

8 vs5.5 8 finger table N8+1 N14 N8+2 N14 N8+4 N14 N8+8 N21 N8+16 N32 N8+32 N42 N1N1 N8N8 N1 4 N2 1 N3 2 N3 8 N4 2 N4 8 N5 1 N5 6 Bessere Implementierung: Jede Station n kennt m Nachfolger finger[i] = successor(n+2 i-1 ). Abdeckung des hablen Rings, gute Kenntnis der direkten Nachbarschaft.

9 vs5.5 9 finger table N8+1 N14 N8+2 N14 N8+4 N14 N8+8 N21 N8+16 N32 N8+32 N42 finger table N42+1 N48 N42+2 N48 N42+4 N48 N42+8 N51 N42+16N1 N42+32 N14 finger table N51+1 N56 N51+2 N56 N51+4 N56 N51+8N1 N51+16N8 N51+32 N21 N1N1 N8N8 N1 4 N2 1 N3 2 N3 8 N4 2 N4 8 N5 1 N5 6 K54 Implementierung mit Finger-Tabelle: Jede Station leitet Anfrage x an den höchsten finger < x weiter. Aufwand: Speicher O(m) << O(2 m ) pro Station, Kommunikation O(log n) lookup(K54) N8+32 N42 N42+8 N51 N51+2 N56

10 vs5.5 10 Stabilisierung mit Finger-Tabelle: , ,  wie zuvor  Alle Stationen aktualisieren regelmässig ihre Finger-Tabelle, indem sie die jeweiligen successor(n+2 i-1 ) neu erfragen. [Detail siehe Stoica et al. 2001: "Chord: A scalable peer-to-peer lookup protocol for internet applications"] Chord betrachtet keine Lokalität im Netzwerk, d.h. Stationen mit numerisch aufeinanderfolgenden IDs können geographisch kreuz und quer verteilt sein. Alternative Verfahren beziehen die Lokalität in die Verteilung ein, z.B. Pastry (Rowston/Druschel 2001)