Etude de la volatilit

1
Etude de la volatilité dans un système de
stockage P2P

• Fabio Picconi LIP6

2
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 dune
  DHT à blocs modifiables

3
Plan

• Réplication dans PAST
• Limitations du protocole de maintenance
• Solutions
• Evaluation

4
Placement des répliques (PAST)
04F2
E25A
Facteur de réplication k 3 Clef 8959
3A79
put( 8959, block )
C52A
AC78
5230
8BB2
8971
2-root
8957
0-root
8954
1-root
73AB
8909
834B
5
Placement des répliques (PAST)
04F2
E25A
Facteur de réplication k 3 Clef 8959
3A79
C52A
AC78
5230
8BB2
8971
8957
Le nœud 8909 doit remplacer le nœud 8954
8954
Le nœud 8954 se déconnecte
73AB
8909
834B
6
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 quil devrait stocker, mais quil ne
  possède pas

7
Protocole de maintenance (PAST)
get( 8959 )
Blocs 8955 8956 8959
Blocs 8955 8956 8959
Blocs 89558956 8959
get( 8956 )
8959
8909
8957
requête 8955
8956
8955
8954
réponse 8956, 8959
8
Limitations

• Réactivité jusquà 10 minutes pour détecter la
  perte dune réplique
• Cohérence la réplique est régénérée à partir de
  nimporte quel autre réplique (pas forcément à
  jour)
• Simplicité pas de distinction entre blocs
  mutables et immutables
• Inefficacité larrivé dun nouveau noeud
  produit leffacement des répliques du noeud
  sortant du replica set (nécessaire pour éviter
  plus de k répliques vivantes en meme temps)

9
Solutions

• Réactivité augmenter la fréquence des requêtes
  envoyées aux voisins (10 minutes ? 1
  minute). Traffic toujours négligeable par
  rapport au transfer 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 dau
  moins 1 réplique correcte

10
Solutions
Facteur de réplication k 10 f 3 Quorum 2f
1 7

Ecriture
Lecture
11
Solutions
Facteur de réplication k 10 f 3 Quorum 2f
1 7

Nœuds byzantins (roll-back)
Nœuds très lents
Ecriture
Lecture
Nœuds pas à jour
Replique correcte (numéro de version plus élevé)
12
Solutions

• Problème un bloc mutable devient inaccessible
  en lecture sil y a moins de 2f1 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

13
Evaluation

• Modification de FreePastry 1.4.1
• Quorums décriture et lecture dans tout accès aux
  blocs mutables
• Réduction de lintervalle de maintenance de 10
  minutes à 1 minute
• Priorité à la régénération des blocs mutables

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

15

16
Priorité à la régéneration de blocs mutables

17
Taille des fetch queue(blocs mutables et
immutables)

18
Arrivée simultanée de50 nouveaux noeuds

19
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 danciennes versions dun bloc
  mutable
• Priorité aux blocs mutables pour éviter des blocs
  perdus
• Problème ouvert larrivée simultanée dun grand
  nombre de noeuds produit la perte de blocs

20
Future work

• Eviter leffacement des répliques lors de
  larrivée de nouveaux nœuds
• Concevoir un système qui distingue les noeuds
  stables de ceux instables
• Proposer un mécanisme dincitations (incentives)
  pour motiver les utilisateurs à rester en ligne

21
Questions ?