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

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

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

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

GDS – 17/02/065 Placement des répliques (PAST) 04F2 3A B BB2 AC78 C52A E25A 73AB 8971 put( 8959, block ) 0-root 2-root 1-root Facteur de réplication k = 3 Clef = 8959

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

GDS – 17/02/067 Test de la volatilité dans Pastis console devgdx002 netgdx router Modelnet gdx [1-5] gdx [9-13] … Pastry/Past/Pastis contrôleur noeuds DHT gdx

GDS – 17/02/068 Test de la volatilité dans Pastis console devgdx002 netgdx router Modelnet contrôleur noeuds DHT gdx gdx [1-5] gdx [9-13] … Pastry/Past/Pastis

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)

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)

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

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

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

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

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

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

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

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

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 Stockage = 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)

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)

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

GDS – 17/02/0622 Questions ?

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)