ion stoica, robert morris, david karger, m. frans kaashoek, hari balakrishnan mit and berkeley...
TRANSCRIPT
Ion Stoica, Robert Morris, David Karger,M. Frans Kaashoek, Hari Balakrishnan
MIT and Berkeley
Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications
Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications
OutlineOutline
Motivazioni
Consistent hashing
Chord
Valutazione delle prestazioni
Conclusioni e Discussioni
MotivazioniMotivazioni
Come trovare dati in un sistema distribuito di File Sharing?
il Lookup è il problema fondamentale
Internet
PublisherKey=“LetItBe”
Value=MP3 data
Lookup(“LetItBe”)
N1
N2 N3
N5N4Client ?
Solutioni DecentralizzateSolutioni Decentralizzate Routing di messaggi (Freenet, Tapestry, Chord, CAN,…)
Internet
PublisherKey=“LetItBe”
Value=MP3 data
Lookup(“LetItBe”)
N1
N2 N3
N5N4Client
matching esatto !?!?!
RoutingRouting
Definire una metrica (utile!!!!)
Mantenere basso il numero di hop
Mantenere bassa la dimensione della tabella di routing
Mantenere le caratteristiche in presenza di una variazione rapida del numero di nodi
Per gli autori: Chord: efficienza e semplicità
Chord OverviewChord Overview
Fornisce un servizio di lookup peer-to-peer:
Lookup(key) Indirizzo IP
Chord non memorizza dati
Come trova un nodo?
Come mantiene le tabelle di routing ?
Come gestisce l’ingresso e la uscita di nodi?
Caratteristiche di ChordCaratteristiche di Chord
Efficiente: O(Log N) messaggi per lookup
N è il numero totale di nodi presenti
Scalabile: O(Log N) stati per nodo
Robusto: mantiene le performance anche in presenza di variazioni notevoli del numero di nodi.
Assume che non ci siano partecipanti maliziosi
Identificatori in ChordIdentificatori in Chord
spazio degli identificatori a m bit sia per le
risorse (Chiavi) che per i nodi
identificatore di Chiave = SHA-1(Chiave)chiave=“LetItBe” ID=60SHA-1
IP=“198.10.10.1” ID=123SHA-1
identificatore di Nodo = SHA-1(indirizzo IP)
Entrambi sono distribuiti uniformemente
Come si associano gli ID di Chiave agli ID di nodo?
Consistent Hashing [Karger 97]Consistent Hashing [Karger 97]
Una chiave (risorsa) è memorizzata nel primo nodo che segue in senso orario
32
90
123 20
5
ID a 7-bit
0IP=“198.10.10.1”
101
60Chiave=“LetItBe”
Consistent HashingConsistent Hashing
Consistent HashingConsistent Hashing
Le funzioni Hash mappano chiavi in interi. Sono utilizzate, ad es, per memorizzare dati in un pool di cache
Con p cache una possibile funzione è
x -> ax+b (mod p)
Cosa accade se varia p ?
Se la usassimo in un sistema P2P ?
Consistent HashingConsistent Hashing
In particolare se varia p: è assicurato un Bilanciamento sul numero di dati per posizione Molti dati devono cambiare posizione Il numero di posizioni che un dato può potenzialmente raggiungere non è limitato
Consistent HashingConsistent Hashing
Per definizione un Consistent Hashing deve godere di opportune proprietà:
Bilanciamento Monotonicità Spread Carico
Consistent HashingConsistent Hashing
Bilanciamento:
Per ogni sottoinsieme V di posizioni (nodi) ed n dati, il numero di dati per ogni posizione è O(n/|V|) con alta probabilità.
Monotonicità:
Se al variare di p le posizioni (i nodi) disponibili passano da V1 a V2 con V1 V2, la migrazione dei dati deve avvenire solo verso posizioni appartenenti a V2 , ma non a V1 .
Consistent HashingConsistent Hashing
Spread:
Al variare di p il numero di posizioni che un dato può assumere è limitato.
Carico:
Al variare di p il numero di dati che una posizione accoglie è limitato.
Consistent HashingConsistent Hashing Funzioni Hashing Consistenti esistono ?
Siano K(x) ed N(x) due funzioni casuali che hanno come codominio l’intervallo [0,1).
Definiamo la seguente funzione Hash: Utilizziamo K(x) per mappare le chiavi Utilizziamo N(x) per mappare i nodi
La chiave i viene memorizzata nel nodo j se la differenza
|K(i)-N(j)| è la minima su tutti i nodi j.
Consistent HashingConsistent Hashing
0 1
Bilanciamento ? Monotonicità ? Spread ? Carico ?
LookupLookup Supponiamo che ogni nodo ha informazioni su tutti gli altri
richiede informazini globali Tabelle di routing O(N) la Lookup O(1)
32
90
123
0
Hash(“LetItBe”) = 60
10
55
Dove è “LetItBe”?
“90 ha 60”
60
Chord: Lookup di BaseChord: Lookup di Base
32
90
123
0
Hash(“LetItBe”) = 60
10
55
Dove è “LetItBe”?
“90 ha 60”
60
Ogni nodo conosce il successore
La Lookup O(N)
Tavola dei FingerTavola dei Finger
Ogni nodo conosce altri m nodi nell’anello
la distanza cresce esponenzialmente
8080 + 20
112
96
16
80 + 21
80 + 22
80 + 23
80 + 24
80 + 25 80 + 26
Tavola dei FingerTavola dei Finger
il Finger i del nodo n punta alla posizione n+2i-1
Se non c’è, punta al nodo subito successivo
120
8080 + 20
112
96
16
80 + 21
80 + 22
80 + 23
80 + 24
80 + 25 80 + 26
Tavola dei FingerTavola dei Finger
01
2
3
4
15
14
13
11
12
89
10
7
6
5
141
210
successor(1)=1
0
successor(2)=3
successor(6)=6
successor(9)=9
successor(10)=13
successor(14)=15
6
9
successor(0)=0
01
2
3
4
15
14
13
11
12
89
10
7
6
5
141
210
0
6
9
i succ node
1 2 3
2 3 3
3 5 6
4 9 9
i succ node
1 10 13
2 11 13
3 13 13
4 1 1
i succ node
1 14 15
2 15 15
3 1 1
4 5 6
Algoritmo LookupAlgoritmo Lookup
01
2
3
4
15
14
13
11
12
89
10
7
6
5
14
i succ node
1 2 3
2 3 3
3 5 6
4 9 9
i succ node
1 10 13
2 11 13
3 13 13
4 1 1
i succ node
1 14 15
2 15 15
3 1 1
4 5 6
LookupLookup
Vale la seguente proprietà:
Per il protocollo Chord ad m bit in un qualunque intervallo di ID di ampiezza 2m/N, il numero di ID di nodi atteso è 1 e O(log N) con alta probabilità
LookupLookup
E’ possibile mostrare il seguente teorema:
Il numero di nodi che deve essere contattato per trovare un successore in una rete con N nodi è O(log N) con alta probabilità.
A partire da questo risultato si può affermare che il numero di Hop necessari per effettuare una query è O(log N)
LookupLookup
Supponiamo che il nodo n debba trovare il successore di k.
Sulla dase dell’algoritmo viene prima cercato l’immediato predecessore, chiamamolo p, di k e poi viene chiesto a p di cercare il successore di k
A tale scopo il nodo n contatta il più vicino predecessore di k a lui noto. Supponiamo il nodo sia f ≠ n e sia l’i-esimo finger per n.
Per definizione di finger, f è a distanza almeno 2i-1 da n.
Poichè l’(i+1)-esimo finger di n supera k, n è a distanza al più 2i da p ed f è a distanza al più 2i-1 da p.
La distanza tra il nodo che sta processando la query ed il predecessore p dimezza ad ogni passo.
LookupLookup
La Lookup impiega O(Log N) hop
32
10
5
20
110
99
80
60
Lookup(19)
19
LookupLookup
Poichè la distanza iniziale è al più 2m, in m passi raggiungiamo p
In log N passi la distanza tra il nodo che sta processando la chiave ed il nodo p si riduce a 2m /N.
Poichè le chiavi sono distribuite in maniera uniforme, il numero di chiavi in un intervallo di ampiezza 2m /N è O(log N) con alta probabilità.
Sono quindi necessari, con alta probabilità, altri O(log N) passi per raggiungere p e quindi il successore di p
JoinJoin
Processo in tre passi:
Inizializza tutti i finger dei nuovi nodi
Aggiorna i finger dei nodi esistenti
Trasferisci le chiavi dal successore ai nuovi nodi
lazy finger update:
Initializza solo i finger al nodo successore
Periodicamente verifica il successore ed il predecessore
Periodicamente rinfresca il contenuto della tavola dei finger
Joining the Ring - Step 1Joining the Ring - Step 1
Inizializza la nuova tavola dei finger
individua un nodo nella rete
Chiedi al nodo di di cercare i finger del nuovo nodo
Raccogli i risultati
36
1. Lookup(37,38,40,…,100,164)
60
40
5
2099
80
Joining the Ring - Step 2Joining the Ring - Step 2
Aggiorna i finger dei nodi esistenti
il nuovo nodo chiama una funzione di aggiornamento sui nodi esistenti
I nodi esistenti possono ricorsivamente aggiornare i finger di altri nodi
N36
N60
N40
N5
N20N99
N80
Joining the Ring - Step 3Joining the Ring - Step 3
Trasferisci le chiavi dal successore al nuovo nodo
Vengono trasferite solo le chiavi nel range
Copia le chiavi 21..36da 40 to 36
3038
36
60
40
5
2099
80
30
38
26.join(friend) -> 26.successor = 32
26.stabilize -> 32.notify(26)
21.stabilize -> 21.successor=26 -> 26.notify(21)
Join di un nodoJoin di un nodo
Analisi del protocolloAnalisi del protocollo
Vale il seguente lemma:
Se al tempo t esiste un arco tra p ed s, allora per ogni t’>t ci sara’ un arco tra p ed sPer induzione sul tempo.
Suppopniamo che dopo t avvenga una join. L’arco tra p ed s non viene toccato dalla join e quindi permane.
Supponiamo avvenga una stabilize.
Consideriamo il momento in cui il nodo p cambia successore da s ad a. Questo avviene perchè p ha contattato s ed s gli ha detto di a. Inoltre p<a<s.
Analisi del protocolloAnalisi del protocollo
s ha saputo di a ad un tempo precedente e questo può essere avvenuto solo perchè s è stato un successore diretto di a.
Per ipotesi induttiva se esisteva un arco (il successore) tra a ed s, esiste un arco tra a ed s in tutti gli istanti successivi.
In particolare nell’istante in cui p cambia il successore. Essendo p<a<s il cambiamento del successore di p non influisce in alcun modo sull’arco tra a ed s.
Inoltre anche dopo il cambiamento esiste un arco tra p ed s.
Analisi del protocolloAnalisi del protocollo
Tutti gli archi tra x ed y, che utilizzavano l’arco tra p ed s, erano tali che p ed s erano interni ad x y. Ma tutti i nodi aggiunti all’arco p s sono interni a p s ed a maggior ragione interni ad x y.
Se un nodo è capace di risolvere una query, sarà sempre capace di farlo in futuro
Ad un tempo prefissato dopo l’ultima join i puntatori al successare saranno corretti per tutti i nodi
Analisi del protocolloAnalisi del protocollo
E’ possibile mostrare il seguente teorema:
Se ogni operazione di join e` alternata con quella di stabilizzazione, allora dopo un fissato tempo dall’ultima join i puntatori al successore formano un ciclo su tutti i nodi della rete.
Analisi del protocolloAnalisi del protocollo
Se due nodi condividono il successore, uno dei due cambierà il puntatore al successore.
Il suo nuovo successore sarà più vicino del nodo cui puntava in precedenza.
Ogni operazione di stabilizzazione potrebbe richiedere al più n passi.
Dopo n2 passi siamo quindi certi che tutti i nodi puntano al successore ed i puntatori formano un unico ciclo con tutti i nodi.
Join di un nodoJoin di un nodo
E’ possibile mostrare il seguente teorema:
Se abbiamo una rete stabile con N nodi ed effettuiamo N join alla rete,
Se tutti i puntatori ai successori sono corretti,
Allora il Lookup di una risorsa avrà necessità di O(log N) hops con alta probabilità.
Join di un nodoJoin di un nodo
Se utilizziamo i vecchi finger arriviamo in O(log N) hops al vecchio predecessore della risorsa. Con alta probabilità tra due vecchi nodi ci saranno al più O(log N) nuovi nodi.
Se i successori dei nuovi nodi sono corretti, in al più O(log N) passi la risorsa sarà raggiunta.
Gestione dei FallimentiGestione dei Fallimenti
I fallimenti dei nodi possono causare lookup scorretti
120
113
102
80
85
10
Lookup(90)
80 non conosce il corretto successore e quindi il lookup fallisce
Gestione dei FallimentiGestione dei Fallimenti
Usa la lista dei successori
Ciascun nodo conosce r successori
Dopo il fallimento si utilizza il primo successore rimasto
Si correggono i successori per garantire un corretto lookup
La lookup è corretta con alta probabilità
r può essere scelto in modo da rendere la probabilità di fallimento della lookup arbitrariamente piccola.
ValutazioneValutazione
lookup veloci in sistemi di grandi dimensioni
Variazione contenuta del costo di lookup
Robusto rispetto a molti fallimenti
Gli Esperimenti confermano i risultati teorici
Costo del lookupCosto del lookup
il costo è O(Log N) come previsto dalla teoria
la costante è 1/2
Number of Nodes
Avera
ge M
ess
ag
es
per
Looku
p
Implementazioni attualiImplementazioni attuali
Libreria Chord: 3,000 linee di C++
Include:
concurrent join/fail
Proximity-based routing
controllo di carico per nodi eterogenei
Resistente a spoofed node IDs
ProPro
Based on theoretical work (consistent hashing)
Proven performance in many different aspects
“with high probability” proofs
Robust (Is it?)
ControContro
NON semplice (confrontato con CAN)
join è complicato
richiede molti messaggi ed aggiornamenti
il meccanismo di aggiornamento leggero non è chiaro con che velocità converge
La tabella di Routing cresce con il numero di nodi
Il caso peggiore di lookup può essere molto lento