1 / 21

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

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

india-keith
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 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 Le nœud 8909 doit remplacer le nœud 8954 8957 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 qu’il devrait stocker, mais qu’il 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 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 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 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. Priorité à la régéneration de blocs mutables

  16. Taille des fetch queue(blocs mutables et immutables)

  17. Arrivée simultanée de50 nouveaux noeuds

  18. 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

  19. 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

  20. Questions ?

More Related