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 ?