Etude de la volatilité dans un système de stockage P2P Fabio Picconi – LIP6.

Présentation au sujet: "Etude de la volatilité dans un système de stockage P2P Fabio Picconi – LIP6."— Transcription de la présentation:

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 d’une DHT à blocs modifiables

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

4 Placement des répliques (PAST) 04F2 3A79 5230 834B 8909 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

5 Placement des répliques (PAST) 04F2 3A79 5230 834B 8909 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

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 qu’il devrait stocker, mais qu’il ne possède pas }

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

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

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 d’au 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 Ecriture Lecture Nœuds byzantins (roll-back) Nœuds très lents Replique correcte (numéro de version plus élevé) Nœuds pas à jour

12 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

13 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

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 de 50 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 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

20 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

21 Questions ?