etude de la volatilité dans un système de stockage p2p
Post on 15-Mar-2016
35 Views
Preview:
DESCRIPTION
TRANSCRIPT
Etude de la volatilité dans un système de stockage P2P
Fabio Picconi – LIP6
Motivation
Problème de la volatilité (churn) dans les réseaux pair-à-pair toujours pas résolu
Couches de routage tolérantes à la volatilité (Bamboo, MSPastry), mais question encore ouverte concernant la couche DHT
Etude des effets de la volatilité des nœuds d’une DHT à blocs modifiables
Plan
Réplication dans PAST Limitations du protocole de maintenance Solutions Evaluation
Placement des répliques (PAST)
04F2
3A79
5230
834B8909
8954
8957
8BB2
AC78
C52A
E25A
73AB
8971
put( 8959, block )
0-root
2-root
1-root
Facteur de réplication k = 3
Clef = 8959
Placement des répliques (PAST)
04F2
3A79
5230
834B8909
8954
8957
8BB2
AC78
C52A
E25A
73AB
8971
Facteur de réplication k = 3
Clef = 8959
Le nœud 8954 se déconnecte
Le nœud 8909 doit remplacer le nœud 8954
Protocole de maintenance (PAST)
Chaque noeud A émet une requête toutes les 10 minutes à tous ses voisins logiques.
envoyer_requete() {pour chaque voisin logique V
envoyer liste de clefs stockées localement à V attendre la réponse de V ajouter les clefs retournées par V à la liste de clefs à régénérer
}
recevoir_requete() { recevoir la liste de clefs stockées par A répondre à A avec toutes les clefs stockées localement qu’il devrait
stocker, mais qu’il ne possède pas}
Protocole de maintenance (PAST)
8909
8954
8957
Blocs895589568959
Blocs895589568959
Blocs895589568959
requête8955
réponse8956, 8959
get( 8956 )
get( 8959 )
8955 8956
8959
Limitations
Réactivité : jusqu’à 10 minutes pour détecter la perte d’une réplique
Cohérence : la réplique est régénérée à partir de n’importe quel autre réplique (pas forcément à jour)
Simplicité : pas de distinction entre blocs mutables et immutables
Inefficacité : l’arrivé d’un nouveau noeud produit l’effacement des répliques du noeud sortant
du replica set (nécessaire pour éviter plus de k répliques vivantes en meme temps)
Solutions
Réactivité : augmenter la fréquence des requêtes envoyées aux voisins (10 minutes 1 minute).Traffic toujours négligeable par rapport autransfer des blocs.
Cohérence : utilisation de quorums de lecture et écriture– Nombre de répliques = 3f + 1
– Quorum d’écriture = 2f + 1
– Quorum de lecture = 2f +1
– Ecriture et lecture forment une intersection d’au moins 1 réplique correcte
Solutions
Facteur de réplication k = 10
f = 3
Quorum : 2f + 1 = 7
Ecriture
Lecture
Solutions
Facteur de réplication k = 10
f = 3
Quorum : 2f + 1 = 7
Ecriture
Lecture
Nœuds byzantins (roll-back)
Nœuds très lents
Replique correcte(numéro de version plus élevé)
Nœuds pas à jour
Solutions
Problème : un bloc mutable devient inaccessible en lecture s’il y a moins de 2f+1 répliques vivantes.
Situation bloquante : le bloc ne peut plus être régénéré, même si plusieurs répliques
existent Priorité à la réplication de bloc mutables
– Un noeud va régénérer des blocs immutables seulement après avoir fini de régénérer tous les blocs mutables
Evaluation
Modification de FreePastry 1.4.1 :– Quorums d’écriture et lecture dans tout accès aux blocs
mutables
– Réduction de l’intervalle de maintenance de 10 minutes à 1 minute
– Priorité à la régénération des blocs mutables
Evaluation
Tests :– DHT de 50 noeuds stoquant
400 fichiers de 1 Mo
Environ 80000 blocs, ou 100 Mo par noeud de la DHT (k = 11)
– Emulation liens ADSL (10 mbps downstr, 1 mbps upstr)
– Latences entre 10 et 250 ms.
– Arrivée de nouveaux noeuds selon un processus de Poisson(même effet que le départ de noeuds existants)
Maintenance Interval = 10 min
456789
10
11
0%
10%
20%
30%
40%50%
60%
70%
80%
90%
100%
600 1200 1800 2400 3000 3600 4200 4800 5400
Time (seconds)
Maintenance Interval = 10 min
45
6
7
8
91011
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
600 1200 1800 2400 3000 3600 4200 4800 5400
Time (seconds)
Maintenance Interval = 1 min
456789
10
11
0%
10%
20%
30%
40%50%
60%
70%
80%
90%
100%
600 1200 1800 2400 3000 3600 4200 4800 5400
Time (seconds)
Maintenance Interval = 1 min
45
6
7
8
9
1011
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
600 1200 1800 2400 3000 3600 4200 4800 5400
Time (seconds)
UCB fi rst
4567
8
9
10
11
0%
10%
20%
30%
40%50%
60%
70%
80%
90%
100%
0 500 1000 1500 2000 2500 3000 3500
Time (seconds)
UCB/ CHB
45678
9
10
11
0%
10%
20%
30%
40%50%
60%
70%
80%
90%
100%
0 500 1000 1500 2000 2500 3000 3500
Time (seconds)
Priorité à la régéneration de blocs mutables
Taille des fetch queue(blocs mutables et immutables)
Maintenance Interval = 1 min
4
5
6
7891011
0%
10%
20%
30%
40%50%
60%
70%
80%
90%
100%
600 660 720 780 840 900 960 1020 1080 1140 1200
Time (seconds)
Maintenance Interval = 1 min
4
5
6
7
891011
0%
20%
40%
60%
80%
100%
600 660 720 780 840 900 960 1020 1080 1140 1200
Time (seconds)
Arrivée simultanée de50 nouveaux noeuds
Conclusions
Algorithme de réplication original pas adapté à une DHT stoquant des blocs mutables et immutables
Utilisation des quorums pour éviter la régéneration d’anciennes versions d’un bloc mutable
Priorité aux blocs mutables pour éviter des blocs «perdus»
Problème ouvert : l’arrivée simultanée d’un grand nombre de noeuds produit la perte de blocs
Future work
Eviter l’effacement des répliques lors de l’arrivée de nouveaux nœuds
Concevoir un système qui distingue les noeuds «stables» de ceux «instables»
Proposer un mécanisme d’incitations (incentives) pour motiver les utilisateurs à rester en ligne
Questions ?
top related