Sistemi strutturati - the Netgroup at Politecnico di Torino

Livio Torrero - Politecnico di Torino
Algoritmi per protocolli peer-to-peer
Reti strutturate: casi di studio
Livio Torrero ([email protected])
09/2009
Livio Torrero - Politecnico di Torino
CHORD
•  CHORD realizza un DHT con le seguenti caratteristiche:
–  Load balance: CHORD distribuisce uniformemente le chiavi fra
i nodi
–  Scalabilità: le operazioni di lookup sono efficienti
•  Richiedono O(log(N)) messaggi scambiati fra i nodi (N = #peer)
–  Robustezza: CHORD è in grado d modificare dinamicamente le
routing table dei nodi per riflettere i mutamenti della rete (nodi
che entrano o escono)
•  CHORD fornisce il metodo lookup(key) che ritorna
l’indirizzo IP del nodo responsabile per la chiave
•  CHORD si basa sul consistent hashing
2
Livio Torrero - Politecnico di Torino
Consistent hashing in CHORD
• 
Se N è il numero di nodi presenti sulla rete, al variare di N si
desidera che:
–  Si garantisca l’uniformità della distribuzione delle chiavi sui nodi
–  La quantità di dati da rimappare nel sistema sia bassa
• 
Il consistent hashing organizza i nodi in un cerchio modulo
(m = #bit ID)
0
1
6
m=3 #bit chiave
2
4
3
• 
L’algoritmo di hash usato è SHA1
• 
Gli ID dei nodi sono i codici hash ottenuti dagli indirizzi IP
• 
• 
Gli ID delle chiavi sono i codici hash ottenuti dalle chiavi
NOTA: gli ID dei nodi e gli ID delle chiavi sono nello stesso spazio
3
Livio Torrero - Politecnico di Torino
CHORD: assegnazione delle chiavi (1/2)
•  La chiave k è assegnata al primo nodo n sull’anello il cui
identificatore è uguale o maggiore all’identificatore di k
•  La metrica di distanza in CHORD è la differenza lineare
•  Si dice n=successor(k)
–  n, il nodo responsabile di k è detto successore di k
–  CHORD espone la chiamata find_successor per localizzarlo
4
Livio Torrero - Politecnico di Torino
CHORD: assegnazione delle chiavi (2/2)
• 
La metrica di distanza è unidirezionale
–  Data una distanza D e un nodo x, esiste un solo nodo y per cui d(x,y) = D
–  Tutti i lookup per una stessa chiave convergono sullo stesso path
–  E’ utile fare caching dei risultati dei lookup sui nodi intermedi
• 
All’arrivo di un nuovo peer questi riceve alcune chiavi del nodo che lo
segue sull’anello
–  Ora è il nuovo responsabile per quelle chiavi
–  Es: cosa succede in figura se entrasse il nodo 7?
–  7 = successor(6) => la chiave 6 è spostata dal nodo 0 al nodo 7
5
Livio Torrero - Politecnico di Torino
CHORD: lookup scalabile (1/5)
•  Per fare le ricerche ogni nodo in teoria ha bisogno solamente
di conoscere il nodo che segue
Dove si trova la
chiave 5?
0
Chiave 5
1
6
2
4
3
•  CHORD assicura la validità di questi puntatori
•  Tuttavia questo non è sufficiente per garantire prestazioni
accettabili
–  Ricerca lineare
6
Livio Torrero - Politecnico di Torino
CHORD: lookup scalabile (2/5)
•  Si supponga invece che il nodo abbia informazioni
su TUTTI gli altri nodi (routing table completa)
Dove si trova la
chiave 5?
0
Chiave 5
1
6
2
4
3
•  Impraticabile: richiede N entry nella routing table!
–  N = numero nodi nell’overlay!
7
Livio Torrero - Politecnico di Torino
CHORD: lookup scalabile (3/5)
•  Per ottimizzare CHORD mantiene le finger table
–  È una lista di nodi che forma una sorta di “routing table” del
peer
–  Al più m nodi, a regime O(log(N)) distinti in finger table
•  Ogni entry della finger table copre una porzione dello
spazio delle chiavi
•  Ciascuna entry contiene un next hop a cui inoltrare la
richiesta per una chiave nello spazio coperto dalla
entry
8
Livio Torrero - Politecnico di Torino
CHORD: lookup scalabile (4/5)
•  Io nodo interrogato sono il nodo responsabile per la chiave
cercata?
•  Sì:
–  Rispondo alla richiesta
•  No:
–  Determino la entry della finger table che copre l’intervallo
desiderato
–  Inoltro all’host memorizzato come next hop nella entry la
richiesta
9
Livio Torrero - Politecnico di Torino
CHORD: lookup scalabile (5/5)
•  Allontanandosi dal nodo gli intervalli sono sempre più grandi
–  Ogni nodo è in grado di determinare con maggior precisione il nodo
responsabile di chiavi più vicine al suo identificatore
•  Continuando a cercare sull’anello mi avvicino sempre più a nodi vicini
alla chiave cercata
10
Livio Torrero - Politecnico di Torino
CHORD: esempio di lookup
•  Esempio:
•  Nodo 3 vuole trovare chi gestisce la chiave 1 (= successor(1))
• 
1 [7,3) : quindi 3 manda una query al nodo 0 (entry #3
della finger table)
•  1
[1,2): il nodo 0 conosce successor (1) e lo dice a 3
11
Livio Torrero - Politecnico di Torino
CHORD: join dei nodi
• 
L’entrata o l’uscita dei nodi nell’overlay può avvenire in qualsiasi
momento
• 
Perché tutto funzioni si DEVE garantire che:
–  Il successore di ogni nodo sia noto
–  Per ogni chiave k, successor(k) ne sia il responsabile
• 
Inoltre è auspicabile che le finger table siano corrette
• 
Al join, un nodo n deve:
–  Inizializzare le entry della sua finger table
•  Per ogni i calcola finger[i].start e lo fa cercare da un qualsiasi nodo della DHT
–  Aggiornare le finger degli altri nodi inserendosi in esse se necessario
–  Muovere sul nodo n tutte le chiavi di cui è responsabile
• 
La join realizzata in questo modo è molto aggressiva.
• 
In realtà si utilizza un algoritmo più leggero ma più complesso che
supporta join multiple simultanee
12
Livio Torrero - Politecnico di Torino
CHORD: uscita dei nodi
•  L’uscita dei nodi si potrebbe trattare come una failure degli
stessi e non fare nulla
•  Per ottimizzare, quando un nodo esce dall’overlay (graceful
leave):
–  Trasferisce le chiavi di cui è responsabile al suo successore
–  Aggiorna il puntatore al nodo che lo precede del nodo che lo
segue sull’anello
–  Aggiorna il puntatore al nodo che lo segue del nodo che lo
precede sull’anello
13
Livio Torrero - Politecnico di Torino
Kademlia
•  Sistema di lookup che utilizza una metrica di
distanza basata su XOR
•  Date due chiavi x e y la loro distanza è
d(x,y)=x xor y
–  Xor bit a bit
•  Realizza una topologia ad albero basata sulla
metrica
•  Kademlia utilizza query parallele asincrone
•  Gli identifcatori delle risorse sono chiavi su 160 bit
(SHA-1)
14
Livio Torrero - Politecnico di Torino
Kademlia: binary tree
•  Kademlia tratta i nodi come foglie di un albero binario
–  La posizione di un nodo è determinata dal suo prefisso
univoco più corto
•  Il primo sottoalbero a sinistra è la prima metà che non
contiene il nodo e così via, ricursivamente
•  Kademlia garantisce che il nodo con prefisso univoco 000
conosca almeno un nodo in ciascuno degli altri
sottoalberi
15
Livio Torrero - Politecnico di Torino
Routing delle query in kademlia
•  La routing table di ogni nodo in kademlia contiene almeno
un nodo di ogni sotto albero.
–  Diversamente da Chord ogni entry della routing table contiene
più di un nodo
–  Nodi della stessa entry appartengono al medesimo sottoalbero
–  Conoscendo almeno un rappresentante per ogni sotto albero è
possibile raggiungere qualunque nodo sull’overlay
16
Livio Torrero - Politecnico di Torino
Kademlia: binary tree
• 
Grazie alla conoscenza di tutti i sotto alberi ogni nodo può trovare
qualsiasi altro nodo dell’albero
• 
Un nodo attraverso la sua routing table riesce a localizzare in una
serie di passaggi successivi qualsiasi nodo sull’albero in modo
ottimale
• 
La routing table è organizzata come un insieme di k-bucket
17
Livio Torrero - Politecnico di Torino
Kademlia: metodi esportati
•  Kademlia offre 4 funzioni:
–  PING: verifica se un nodo è attivo
–  STORE: memorizza la coppia <chiave, valore> nel nodo più
vicino alla chiave
• 
STORE(chiave)
Le informazioni vengono replicate
<chiave, valore>
–  FIND_NODE: data una chiave ritorna (IP, porta, NodeID)
per i k nodi più vicini alla chiave.
•  I k nodi possono provenire da più k-bucket se il k-bucket più
vicino non è pieno
–  FIND_VALUE: variante della precedente per ottenere un
valore data una chiave
18
Livio Torrero - Politecnico di Torino
Kademlia: memorizzare dati sull’overlay
•  Procedura utilizzata per memorizzare nuovi dati nell’overlay
–  Un nodo desidera memorizzare una entry contenente dati
sull’overlay
•  Il nodo che vuole inserire nuovi dati, localizza i k nodi piu’
vicini alla chiave relativa ai dati da memorizzare
•  Viene quindi eseguita una STORE su ciascuno di essi
•  Ogni nodo che ha memorizzato una coppia chiave valore
ripubblica ogni coppia chiave/valore entro un ora
•  L’originatore della coppia ripubblica la coppia ogni 24 ore
19
Livio Torrero - Politecnico di Torino
Confonto tra CHORD e Kademlia
•  In CHORD la routing table è rigida
–  Richiede costose operazioni per essere mantenuta in
caso di failure di un nodo
•  Kademlia offre una routing table flessibile
–  Metrica di distanza simmetrica oltre che
unidirezionale
–  Esiste sempre più di un percorso alternativo
–  Le ricerche sono parallelizzate
–  La manutenzione della routing table è più bassa
–  Le entry della routing table di Kademlia sono liste di
nodi: maggiore robustezza
•  E’ possibile dimostrare che il numero di entry nella
routing table di Kademlia è logaritmico
20
Livio Torrero - Politecnico di Torino
Limiti delle DHT (1/3)
•  I client p2p sono transienti per natura
–  Il tempo di connessione media per un nodo è di 60min
•  In Gnutella se un nodo perde tutti i vicini prova
semplicemente a riconnettersi
•  Nelle DHT il problema è più grave (almeno in CHORD)
–  L’uscita di un nodo graceful (=“annunciata”) comporta in
genere O(log(n)) operazioni per mantenere coerenti le
strutture dati
–  Un uscita graceless (senza annuncio è trasferimento
preventivo di informazioni di stato) ha esiti peggiori
•  Richiede tempo per:
–  Rilevare la failure
–  Replicare i dati persi dal peer disconnesso
21
Livio Torrero - Politecnico di Torino
Limiti delle DHT (2/3)
•  Le ricerche di parole chiave sono più numerose delle
ricerche esatte
–  Le DHT si prestano a ricerche esatte
•  Dato il nome esatto di un file lo localizzano
–  E’ possibile implementare richerche per parole chiave nelle
DHT, ma è costoso
–  Le p2p non strutturate non hanno di questi problemi: perché le
ricerche si fanno sulla base di informazioni contenute nei
singoli nodi
•  Le DHT trovano un ago in un pagliaio, i p2p non strutturati
no
–  Gnutella non può garantire di poter trovare una singola copia
di un file a meno che la query non raggiunge tutti i nodi
22
Livio Torrero - Politecnico di Torino
Limiti delle DHT (3/3)
•  Tuttavia la distribuzione delle richieste privilegia i file più
replicati
–  Questo limita gli svantaggi delle reti non strutturate
23