Réplication adaptative sur les réseaux pair à pair 10 mars 2006
1 Introduction 2 Réseaux pair à pair et tables de hachage distribuées 3 Le protocole app-cache 4 Le protocole LAR 5 Tests de performance du protocole LAR 6 Conclusion
Introduction Réseaux pair à pair Réseaux décentralisés : nœuds égalitaires. Échange de ressources (fichiers par exemple). Non-homogénéité de la popularité des ressources Certaines ressources plus demandées que d autres. Protocoles app-cache, LAR : gestion de la non-homogénéité de la popularité par réplication. Informations à répliquer Ressources (fichiers) Information de routage
Acheminement de requêtes sur un réseau pair à pair Recherche sur un serveur d annuaire Centralisation des informations de localisation des ressources sur un serveur d annuaire. Avantage : gestion de la réplication aisée. Inconvénients : dépendance du réseau du serveur central, problèmes légaux. Recherche par inondation (Gnutella) Propagation des requêtes sur un réseau non-organisés. Mécanismes de TTL et de mémorisation de derniers messages pour éviter les boucles. Avantage : aucune organisation du réseau. Inconvénients : latence élevée de satisfaction des requêtes, surcharge du réseau par les requêtes.
Tables de hachage distribuées Principe Maintien d un index (identifiant de ressources, localisation) distribué pour le traitement des requêtes de recherche. Chaque nœud possède un identifiant et est chargé de la maintenance d une portion de l index dépendant de celui-ci.
Tables de hachage distribuées Qualités d un système de hachage distribué Répartition homogène des identifiants de nœuds et de ressources équilibrage de charge. Complexité de routage, d insertion et de suppression de nœud supportant le passage à l échelle. Adaptabilité à la défaillance de nœuds (départs non-signalé), résistances aux fautes byzantines mécanismes de redondances nécessaires (par exemple, utilisation en parallèle de plusieurs tables).
Quelques systèmes de tables de hachage distribuées CAN (Content Adressable Network) : utilisation d un espace vectoriel cartésien multi-dimensionnel. Table de routage contenant l adresse des nœuds connexes. Chord : organisation des nœuds en anneau. Routage en temps logarithmique. Pastry. Tapestry. Skipnet.
Présentation de Chord : nœuds organisés en anneau Insertion d un nœud sur l anneau Attribution d un identifiant unique (fonction de hachage cryptographique) aux nœuds et ressources. Insertion du nœud n sur l anneau : récupération d une partie de l espace géré par son successeur s n, gestion des clés entre p n et n 1. Table de routage d un nœud Entrée i de la table : adresse du nœud s (n+2 i 1 ) mod 2 t. Routage d une requête Choix du prochain saut : nœud d identifiant inférieur le plus proche de la ressource. A chaque saut : distance à la destination divisée par 2. Routage en temps logarithmique.
Exemple de routage sur un réseau Chord 13349 13876 14025... 2035... 5066...... 5066 12078...... 14097 2035 7035 12745... 12745 12078 Anneau Chord 5066... 11365... 7037 11365 10568 11342... 12078... 14097... 6453 6789 7001 Index de ressource Fingerlist Figure: Exemple d anneau Chord
Réplication classique de contenu Réplication par le demandeur d une ressource Le demandeur d une ressource la télécharge et la met à disposition (à la fin ou en cours de téléchargement) création de réplicat partiel ou total. Incitation à la réplication : lutter contre le freeriding Instauration de mécanisme donnant-donnant instantané : tit for tat (BitTorrent),... Utilisation de scores de réputation : Eigentrust,...
Réplication classique de contenu (2) Mécanismes de découpage de ressource Pour la mise à disposition partielle de réplicats, nécessite de découpage de ressources de taille importante : Découpage linéaire en paquets de taille fixe (BitTorrent) : problème de rareté de certains paquets. Découpage par network coding : combinaison linéaire de paquets. Nécessité de résoudre un système linéaire pour reconstituer la ressource (coûteux en calcul). Utilisé par Avalanche.
Le protocole app-cache Un nœud n 0 demande une ressource r : 1 Routage de la requête r sur le réseau : parcours des nœuds n 1,..., n k. 2 n k dispose de la ressource : envoi à n 0. 3 Création de réplicats de la ressource r sur les nœuds n 0,..., n k 1. Création agressive de réplicats. Pas de considération de la charge. Original Network. Network with app-cache.
Objectifs de LAR Gestion du phénomène de foules Gestion de la surcharge induite par un phénomène de foule. Adaptabilité rapide à la montée en popularité soudaine d une ressource (création et suppression au moment adéquat de réplicats). Équilibrage de charge Trois intervalles de charge l max configurable (débit des requêtes) : 1 0 l < l faible : charge faible récupérer la charge d un autre serveur. 2 l faible l < l forte : charge équilibrée objectif recherché. 3 l forte l < l max : redistribuer la charge à un autre serveur (de préférence de charge faible).
Objectifs de LAR (2) Décision locale Prise de décision (création, suppression de réplicat) réalisées sur la base d information disponibles localement moins de trafic de contrôle.
Création de réplicats par mesure de charge Le nœud n j demande la ressource r au nœud n i. n j envoie à n i la ressource r. n j communique sa charge courante l j à n i. n i décide de créer un ou plusieurs réplicats sur n j (pour équilibrage de charge) en considérant si un des critères suivants est satisfait : l(n i ) > l i forte et l(n i) l(n j ) > K (K constante prédéfinie). l i faible l(n i) < l max et l i l j l i faible équilibrage de charge entre les nœuds du réseau (réduction de la variance de la charge).
Destruction de réplicats Espace disque consacré au stockage des réplicats sur chaque nœud. Suppression des réplicats si l espace alloué est dépassé par politique Least-Recently-Used : le réplicat le plus anciennement accédé (heuristiquement le moins populaire actuellement) est supprimé.
Cache de pointeurs vers les réplicats Notification par n j des nœuds sur le chemin de la requête de la création de réplicat sur n i. Maintien de plusieurs pointeurs pour une même ressource. Messages d annonce avec les réplicats les plus récemment créés. Politique de fusion dans le cache? Réponse plus rapide aux requêtes suivantes sur la requête : si la requête atteint un nœud avec un pointeur vers un réplicat, suivi du pointeur plutôt que poursuite de l acheminement de la requête.
Cache de pointeurs vers les réplicats Cache de pointeurs maintenu selon une politique LRU. Non avertissement des nœuds abritant des pointeurs de la suppression d un réplicat (application politique LRU ou départ inopiné d un nœud) possibilité d existence de pointeurs obsolètes. Résolution du problème des pointeurs obsolètes en menant en parallèle de la vérification de l existence de réplicat un routage classique.
Routage Chord avec LAR 13349, 13876, 14025...,2035,...,5066,.. 14097..., 11365,... Data Fingerlist Replicated Fingerlist 12745 2035 Fingerlist..., 5066,12078,... 12078 11365 Data 10568, 11342 12078,..., 14097,... FingerList 7037 5066 Fingerlist..., 7037(14097), 12745,... 6453, 6789, 7001 Data..., 11365,... Fingerlist Figure 5. LAR routing and replication in Chord Figure: Routage Chord en utilisant la réplication LAR
Paramètres de la simulation Utilisation d un simulateur Chord modifiés. Paramètres utilisés : 1000 nœuds. 32767 ressources hébergées. l max = 10 requêtes / seconde, file de traitement de capacité 32. Fréquence de mise à jour de la charge : 0, 5 Hz Latence de saut : 25 ms. Débit de requêtes : 500 / s Longueur moyenne du chemin d une requête : 5 sauts. Répartition uniforme des sources des requêtes. Contribution égale pour la charge et la congestion des messages de contrôle et de données. Si l > l max (et file pleine), les messages sont rejetés.
Effet de biais sur la distribution des requêtes Number of queries dropped 250 200 150 100 50 0 Uniform query stream 0 50 100 150 200 250 300 350 400 450 500 time (in sec) chord app-cache LAR 200 180 160 140 120 100 80 60 40 20 0 90% queries to 10% data-items chord app-cache LAR 0 50 100 150 200 250 300 350 400 450 500 time (in sec) 250 200 150 100 50 0 90% queries to 1% data-items chord app-cache LAR 0 50 100 150 200 250 300 350 400 450 500 time (in sec) 5000 4500 4000 3500 3000 2500 2000 1500 1000 500 0 90% queries to 1 data-item chord app-cache LAR 0 50 100 150 200 250 300 350 400 450 500 time (in sec) Figure: Nombre de requêtes rejetées pour différentes distribution de requêtes
Distribution uniforme des requêtes Number of queries dropped 250 200 150 100 50 Uniform query stream 0 0 50 100 150 200 250 300 350 400 450 500 time (in sec) chord app-cache LAR Inutilité de la réplication. app-cache créé inutilement un nombre important de réplicats (1 millions). Réplication plus parcimonieuse pour LAR : moins de 1% de requêtes rejetées.
90% des requêtes sur 10% des ressources 200 180 160 140 120 100 80 60 40 20 0 90% queries to 10% data-items chord app-cache LAR 0 50 100 150 200 250 300 350 400 450 500 time (in sec) Mauvaise performance de app-cache, taux de rejet négligeable sans réplication ou avec LAR.
90% des requêtes sur 1% des ressources 250 200 150 90% queries to 1% data-items chord app-cache LAR 100 50 0 0 50 100 150 200 250 300 350 400 450 500 time (in sec) Phase de réplication intense de app-cache : taux de rejet fort, au-délà : taux de rejet faible. Réplication graduelle selon la charge pour LAR : rejet négligeable.
Phénomène de foule extrême : 90% des requêtes sur une ressource 5000 4500 4000 3500 3000 2500 2000 1500 1000 500 0 90% queries to 1 data-item chord app-cache LAR 0 50 100 150 200 250 300 350 400 450 500 time (in sec) Sans système de réplication, satisfaction de 29% des requêtes. Pour app-cache et LAR, phase de réplication : taux élevé de rejet, puis chute du taux de rejet (plus rapide pour app-cache. A considérer : intérêt de la réplication dans Chord de la fingerlist du prédécesseur.
Influence des coûts de transfert Simulation initiale réalisée avec coût de transfert identique pour les messages de contrôle et de données. Pour un coût de transfert de données x10 (distribution 90/10), taux global de rejet de requêtes : app-cache : 2% 42% LAR : 0% 10%
Influence de la charge Sensibilité de app-cache à la variation de charge moyenne : réponse à 83% des requêtes sous une charge de 50%. Meilleure résistance de LAR à la montée en charge : réponse à 97% des requêtes sous une charge de 50%.
Adaptabilité au changement de ressources populaires Number of queries dropped 5000 4500 4000 3500 3000 2500 2000 1500 1000 500 0 0 100 200 300 400 500 600 700 800 900 time (in sec) Figure: Nombre de requêtes rejetées sur 900 secondes pour une distribution de 90% de requêtes sur une ressource, avec changements brusques
Passage à l échelle Fraction of queries dropped 0.09 0.08 0.07 0.06 0.05 0.04 0.03 0.02 0.01 4000 servers 2000 servers 1000 servers 500 servers 0 0 50 100 150 200 time (in sec) Figure: Fraction des requêtes rejetées pour différents nombre de nœuds sur le réseau (charge moyenne de 25% sur chaque nœud, distribution des requêtes 90/10)
Conclusion Réplication adaptative sur charge LAR plus avantageuse que app-cache. Nouveauté : prise en compte de la charge pour la réplication. Efficacité de LAR pour la réplication de données de taille importante? Simulation sur un réseau dynamique (insertion et départ inopiné de nœuds) LAR ne gère pas la disparition de réplicats? Adaptation du protocole pour des ressources mutables? A explorer : network coding ou découpage linéaire utilisé avec LAR.
Références [1] Chord simulator. URL http://www.pdos.lcs.mit.edu/chord/. [] Bram Cohen. Système pair à pair BitTorrent. URL http://www.bittorrent.com/. [] Bram Cohen. Incentives build robustness in BitTorrent, 2003. URL citeseer.ist.psu.edu/cohen03incentives.html. [] Christos Gkantsidis and Pablo Rodriguez. Network coding for large scale content distribution. Technical report, Microsoft Research, 2004. URL http://research.microsoft.com/ pablo/avalanche.aspx. [] V. Gopalakrishnan, B. Silaghi, B. Bhattacharjee, and P. Keleher. Adaptive replication in peer-to-peer systems, 2003. URL citeseer.ist.psu.edu/article/ gopalakrishnan03adaptive.html. [] Nicholas Harvey, Michael B. Jones, Stefan Saroiu, Marvin Theimer, and Alec Wolman. Skipnet: A scalable overlay network with practical locality properties. In In proceedings of the 4th USENIX Symposium on Internet Technologies and Systems (USITS 03), Seattle, WA, March 2003. URL citeseer.ist.psu.edu/harvey03skipnet.html. [] Antony Rowstron and Peter Druschel. Pastry: Scalable, decentralized object location, and routing for large-scale peer-to-peer systems. Lecture Notes in Computer Science, 2218: 329??, 2001. URL citeseer.ist.psu.edu/rowstron01pastry.html. [] Ion Stoica, Robert Morris, David Karger, Frans Kaashoek, and Hari Balakrishnan. Chord: A scalable Peer-To-Peer lookup service for internet applications. In Proceedings of the 2001 ACM SIGCOMM Conference, pages 149 160, 2001. URL citeseer.ist.psu.edu/stoica01chord.html. [] B. Y. Zhao, J. D. Kubiatowicz, and A. D. Joseph. Tapestry: An infrastructure for fault-tolerant wide-area location and routing. Technical Report UCB/CSD-01-1141, UC Berkeley, April 2001. URL citeseer.ist.psu.edu/zhao01tapestry.html.