GDS – 17/02/061 Gestion de la volatilité dans un système de stockage P2P F. Picconi, P. Sens Regal (LIP6 / INRIA) ACI Masses de Données.

Présentation au sujet: "GDS – 17/02/061 Gestion de la volatilité dans un système de stockage P2P F. Picconi, P. Sens Regal (LIP6 / INRIA) ACI Masses de Données."— Transcription de la présentation:

1 GDS – 17/02/061 Gestion de la volatilité dans un système de stockage P2P F. Picconi, P. Sens Regal (LIP6 / INRIA) ACI Masses de Données

2 GDS – 17/02/062 Problème de la volatilité « Churn » = taux élevé d’ajout de nœuds et de défaillances Le churn : une des causes des dénis de services dans P2P (issue de sources non forcément malicieuses). Nombreuses études sur la résistances aux churns des overlay (cf. Bambou, MSPastry …). => Relative bonne résistance (quelques minutes) de couche basses (KBR) Quid des applications : –Stockage des données Objectif : Etudier le churn dans Past et Pastis

3 GDS – 17/02/063 [Rhea 04] Handling churn in DHT, Usenix Annual Technical Conf. 2004

4 GDS – 17/02/064 Architecture Pastis Internet Distribution des blocs de données racine du bloc réplication Anneau de machines Past Système de fichiers Pastis

5 GDS – 17/02/065 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

6 GDS – 17/02/066 Pastis (2) Deux types de blocs : –CHB (Content Hash Block): blocs de données Non modifiable Auto-certifiant :cle de stockage = Hash(contenu) Lecture : 1 copie suffit –UCB (User Certificate Block) : blocs de méta-données (inodes) Modifiable : clé = H(Clé Publique) Donnée signée Accès : Obtenir un quorum

7 GDS – 17/02/067 Test de la volatilité dans Pastis console devgdx002 netgdx002 172.24.110.2 router Modelnet gdx0002 10.0.0.[1-5] gdx0003 10.0.0.[9-13] … Pastry/Past/Pastis contrôleur noeuds DHT gdx0001 172.24.1.1

8 GDS – 17/02/068 Test de la volatilité dans Pastis console devgdx002 netgdx002 172.24.110.2 router Modelnet contrôleur noeuds DHT gdx0001 172.24.1.1 gdx0002 10.0.0.[1-5] gdx0003 10.0.0.[9-13] … Pastry/Past/Pastis

9 GDS – 17/02/069 Moniteur de contrôle Communique directement avec les noeuds de calcul sans passer par l’émulateur Modelnet Injection de la volatilité (join / leave) –Tue et crée des nœuds de la DHT Observation de l’état global –Ensemble des blocs stockés –Répartition des blocs, nombre de copies –Etat des leafset (voisinage dans l’anneau Past)

10 GDS – 17/02/0610 Injection de volatilité Le contrôleur utilise un processus de poisson A chaque événement il tue un noeud de la DHT et en crée un nouveau On utilise le temps médian de session comme paramètre pour la volatilité t med = N.ln 2 / λ (N = nb. noeuds, λ = param. Poisson)

11 GDS – 17/02/0611 Expérimentations –1 client Pastis utilisant une DHT de 100 nœuds –liens client-stub de 1 mbps –Andrew Benchmark exécuté sur le client Pastis –répertoire contenant 27 fichiers (total 316 Ko) –20 edge nodes et 2 émulateurs Modelnet –10 noeuds DHT par machine physique

12 GDS – 17/02/0612 Expérimentations Nombre de répliques trouvés par le client Pastis lors de l’exécution du Andrew Benchmark en fonction du temps. MST = 60 min Facteur de réplication = 11 Intervalle de maintenance = 1 minIntervalle de maintenance = 5 min

13 GDS – 17/02/0613 Expérimentations MST = 30 min. Un intervalle de maintenance de 5 minutes ne permet pas au protocole de régénération de blocs de réagir suffisamment vite, et l’exécution du AB est bloquée lorsque le client trouve moins de 8 répliques. Intervalle de maintenance = 1 minIntervalle de maintenance = 5 min

14 GDS – 17/02/0614 Retour sur expériences Mauvaise résistance aux « churns » lorsque les nœuds sont chargés Goulot d’étranglement : –le transfert de données : essentiellement des CHB (et non pas la mise à de la structure de l’overlay –Possibilité d’amélioration (limitée) en donnant une priorité plus forte au CHB (cf Présentation GDS du 4 novembre) – Soumission ICPADS 2006 => Nécessité d’un système d’incitation pour « forcer » les nœuds à rester –HotP2P 2006

15 GDS – 17/02/0615 Incitation dans Pastis Objectif : améliorer la stabilité de Pastis 2 mécanismes : (1) Modification du protocole de join (2) Associé une métrique de « réputation » pour chaque nœud qui correspond à la stabilité du nœud Réputation élevée => accès plus rapide, plus grande capacité de stockage

16 GDS – 17/02/0616 Protocole de Join Join en 2 phases : –Phase 1 : Le nœud doit prouver sa stabilité pendant Tphase1 Pas présent dans l’anneau mais relié par un proxy Accès à la DHT limité (plus lent : un saut de plus), pas de stockage de données –Phase 2 : Récupération des réplicats de ses voisins Le nœud doit prouver le stockage de ses réplicats A la fin de la phase 2 : le nom obtient une réputation minimum Le noeud est inséré dans l’anneau –La réputation du nœud évolue au cours du temps

17 GDS – 17/02/0617 Join du nœud A (2) Phase 1 : Connexion au nœud B d’id le plus proche dans DHT – Récupération de son LeafSet A envoie périodiquement des heartbeat à m nœuds du LeafSet de B Après une période Tphase 1 sans défaillance, A entre en phase 2 Phase 2 : Transfert des blocs depuis les m noeuds Liste des blocs transférés maintenue dans les voisins Les voisins vérifient périodiquement que A possède bien les blocs en envoyant des « challenges » : Envoi d’un nombre aléatoire et d’une clé de bloc Fin de la phase 2 lorsque A a récupéré tous les blocs des m nœuds Récupération d’un certificat de chacun des m nœuds Les certificats sont inclus (et vérifiés) dans la demande de Join final

18 GDS – 17/02/0618 Evolution de la réputation Augmentation lorsque le nœud reste connecté –Incrémentation tous les Tup Diminution lors des déconnexions –Décrémentation tous les Tdown(d,n) d : durée de déconnexion n : nombre de voisins en ligne –Réputation = 0 => exclusion de l’anneau Pb : un nœud peut tricher sur sa réputation –Certification : tous les Tup, un nœud demande à ses m voisins un certificat incluant sa nouvelle réputation –Certificat vérifiable avec clé publique des voisins –Audit aléatoire des certificats –Triche => blacklist

19 GDS – 17/02/0619 Réplication et réputation Associé à chaque donnée (bloc) un niveau de stabilité Répliqué le bloc jusqu’à ce que la somme de réputation des nœuds de stockage = niveau de stabilité Stabilté(B) = 14 Racine B 25 4 1 2 Stockage = 2 11 14 Avantages : Réplication dynamique en fonction de la stabilité des nœuds Peu de modifications dans Past Inconvénient : Pics sur les nœuds de réputation forte (=> associer la réputation à la capacité de stockage)

20 GDS – 17/02/0620 Bénéfice d’une réputation élevée Capacité de stockage : –Quotas –Proportionnelle à la capacité offerte par les nœuds Meilleures QoS : donner une priorité plus importante aux messages issus de nœuds réputés –Difficile à mettre en œuvre (possibilité de tricherie)

21 GDS – 17/02/0621 Conclusions Evaluation du coût du nouveau protocole de join dans Pastis –Surcoût du monitoring, de la génération/transfert des certificats Implémentation de la réplication basé sur réplication Difficulté d’évaluer l’efficacité de l’incitation (nécessité d’avoir de nombreux utilisateurs « réels »)

22 GDS – 17/02/0622 Questions ?

23 GDS – 17/02/0623 Autre approche Placer les réplicats sur les nœuds les plus stables du leafset  Plus de contiguïté des réplicats dans l’anneau  Mise en place de pointeur (modification plus en profondeur de Past)