Revue d article : Dynamic Replica Placement for Scalable Content Delivery

Transcription

1 Revue d article : Dynamic Replica Placement for Scalable Content Delivery Marc Riner - INSA Lyon - DEA DISIC Introduction Cet article [1] présente une technique innovante de placement de réplicats et de maintien de leur consistance par rapport à la source. Basé sur les contraintes coté serveur et client, cette approche permet un placement dynamique,efficace et de manière distribuée des réplicats pour les CDNs 1. Pour présenter et commenter cet article nous considérerons tout d abord un résumé, puis des discussions sur le contexte de l article, l approche présentée et finalement sur les expérimentations menées. 1 Résumé Après avoir exposé la problématique, l article commence par effectuer un bref état de l art, puis décrit quelles contributions sont apportées. 1.1 Introduction Le problème peut s écrire : comment placer, où placer, et comment maintenir la cohérence des réplicats dans un réseau de distribution de contenu? Actuellement une grande partie des CDN (Akamai, Digital Island) utilisent la redirection des requêtes clientes par DNS, mais cette technique, par son approche centralisée, manque d extensibilité. D autre part, le problème de la dissémination des updates reste entier puisque le multicast IP fonctionne mal entre différents domaines et le mutlicast au niveau application (ALM 2 ) n est pas, pour l heure, très extensible (approche centralisée sur la racine de l arbre). L article propose donc une technique qui permet : de placer dynamiquement (en fonction de la charge des serveurs et de la latence des clients) un nombre restreints de réplicats. de construire et maintenir un arbre (au niveau application) pour maintenir la cohérence des réplicats en utilisant un minimum de bande passante et un délai faible. d effectuer les deux points précédents de manière distribuée. 1 Content Distribution Network 2 Application Level Multicast

2 1.2 Formulation du problème Les auteurs choisissent ici de considérer le problème comme il suit : pour rendre le système de réalisation plus efficace, il suffit de minimiser le nombre de réplicat de sorte à ce que la latence de clients et la charge des serveurs soient bornés. Ils supposent ces bornes préalablement définies. Ce choix est expliqué par le fait que le coût principal est le coût de réplication des données. 1.3 Tapestry On a remarqué que les techniques actuelles manquaient d extensibilité, pour palier à cela, l article propose d organiser les différents nœuds du réseau sur le réseau Tapestry [5]. Tapestry est un réseau overlay qui permet de situer des objets (par un chemin court) dans le réseau de manière distribuée. Un réseau Tapestry permet de router des message d un nœud vers n importe quel autre de manière distribuée. Le routage utilise, dans une version plus évoluée, le principe du hashed-suffix routing présenté originellement par Plaxton, Rajaraman et Richa. Une caractéristique intéressante d un réseau overlay du type tapestry est la capacité de trouver un objet dans le réseau de manière efficace (en terme de nombre de saut de routage). Il a été montré, de plus, que, dans le cas d un objet répliqué, une requête était menée au réplicat le plus proche de l émetteur de cette requête. Tapestry apparaît donc comme un système très intéressant (par sa nature distribuée) pour les échanges de messages d updates entre serveurs ou des requêtes des clients. 1.4 D-tree protocole L article présente, à ce stade, les algorithmes qui construisent et maintiennent le Dissemination tree (d-tree). L approche des auteurs est d organiser les réplicats en un arbre, au dessus de Tapestry ; avec comme racine la source des données. Puis ils donnent une méthode pour maintenir dynamiquement cet arbre. Deux approches sont proposées pour organiser l arbre : naive et smart. naive : Lorsqu un client c envoie une requete pour l objet o qui est routée par Tapestry jusqu au premier serveur s. Soit s peut satisfaire, si sa charge n est pas trop importante, les contraintes de latence du client, dans ce cas il répond à la requête. Soit ces contraintes ne sont pas satisfaite (serveur surchargé ou latence trop longue), s va alors placer un réplicat sur le chemin de c à s le plus proche de c. smart : Dans la même configuration le serveur s reçoit la requête. S va alors choisir le serveur le moins chargé parmi son père (dans l arbre), ses frères, et ses fils. Si ce serveur convient en termes de charge et de latence, il répondra à la requête de c. Sinon s place un réplicat sur le chemin qui mène à c le plus loin de c possible mais tout en respectant les contraintes. Dans cette section les auteurs présente quel serait la méthode idéale pour ce genre d algorithme en vue de comparer leur approche avec cette dernière. L approche idéale est basée sur la connaissance non seulement de la topologie globale du réseau (soit du réseau IP, soit du réseau overlay) mais aussi sur une connaissance des clients puisque les réplicats sont placés après avoir reçu les requêtes. Ne possédant aucune caractéristique dynamique cet algorithme sera appelé static. La dernière partie de l approche concerne le maintient dynamique de l arbre. On sup- 2

3 pose les noeuds de l arbre à peu près synchronisés grâce au Network Time Protocol, dans ces conditions, la racine de l arbre envoie périodiquement de messages (heartbeats) à ses fils. Un nœud ne recevant pas de message pendant une certaine période sait que un de ses père n est plus là, il commence donc une procédure de rattachement à l arbre. D autre part, les serveurs doivent aussi envoyer périodiquement un message de rafraichissement à leur père, sans cela le serveur père considère que son fils n est plus là. 1.5 Evaluation Pour évaluer leur travaux, les auteurs ont réalisé des simulations sur un réseau de 5000 nœuds des modèles GT-ITM. Sur ce réseau 500 serveurs d-tree (racines des arbres) sont placés, soit de manière aléatoire, soit proche du backbone. Pour placer les réplicats, quatre méthodes sont adoptée en vue de le comparer : les deux algorithmes dynamiques smart et naive présentés ci dessus, qui fonctionne sur Tapestry (resp. od smart et od naive), l algorithme static avec connaissance globale du réseau overlay (overlay s) et l algorithme static avec une connaissance globale du réseau IP (IP s). La comparaison est basée sur trois facteurs : 1. Qualité du placement Prend en compte le nombre de réplicats créés et le rapport de la déviation standard par rapport à la moyenne du nombre de client par réplicat. La distribution étant la meilleur quand ce rapport est le plus faible. 2. Performance Muticast Prend en compte la bande passante utilisée globalement et le RDP Trafic pour la construction de l arbre Prend en compte le nombre de messages (niveau application) échanges et la bande passante associée utilisée pour ces messages. Les résultats montrent que l approche od smart est la plus proche de IP s dans la majorité des cas, sauf pour la construction du message, la complexité de l algorithme induisant un overhead conséquent. Les auteurs remarquent cependant que la fréquence à laquelle l arbre est reconstruit est nettement inférieure à celle des updates ou de l accès des données. L approche od naive quand à elle a des performances situées bien en decà de od smart. La conclusion est donc que l approche od smart est très intéressante puisque ses performances permettent de placer un nombre restreint de réplicats qui satisfont les contraintes client et serveur et que par sa nature décentralisée elle supporte facilement le passage à l échelle. 2 Discussion Maintenant que nous avons vu ce que l article [1] présente nous pouvons nous questionner sur un certains nombre de points. Tout d abord mettre l article en perspective en dégageant son contexte. Puis en discutant l approche proposée ainsi que les expériences menées. 3 Relative Delay Penalty 3

4 2.1 Contexte Une caractéristique principale de cet article est sa taille, il est court, il est donc nécessaire de se reporter à de nombreux autres articles pour le comprendre, cette démarche à permit de mieux comprendre dans quel contexte cet article a été écrit. Deux des auteurs de cet article travaillent sur le projet Oceanstore [4] qui utilise Tapestry comme infrastructure de localisation des objets et les d-tree pour les updates. De plus des travaux comme Bayeux[6] présente déja le même argumentaire en ce qui concerne l utilisation de Tapestry par rapport à des techniques de dissémination classique. Cet article se situe donc dans la continuité des travaux de Kubiatovicz sur Tapestry. Yan Chen, quand à lui, s intéresse plus particulièrement aux techniques de mise en place de réplicats. Cet article peut aussi être considéré comme un premier jet pour SCAN[2]. En effet, ce dernier article présente les même techniques de placement de réplicats avec cependant une partie expérimentation plus développée au sein d une description d architecture plus complète. Concernant le contexte du problème lui-même, on peut regretter que la courte partie réservée à l état de l art ne soit pas plus développée. D autre part cette partie discute de l existant (Akamai), des problèmes de dissémination des updates (IP muticast ou autres) mais pas des différentes techniques de réplications dynamique dans d autres domaines. Il est intéressant de mettre cet article en rapport avec les travaux de Karlsson et Mahalingam [3] sur l utilité des algorithme de placement de réplicats. Même si ces travaux ne concluent pas a une l inutilité de telles approches, on peut regretter le fait que les auteurs n aient pas pris soin de mieux défendre leur problème. Le manque de place peut sans doute expliquer cela. 2.2 Approche En considérant l approche utilisée, on remarque tout d abord que la formulation du problème, dont découle l approche est relativement courte et ainsi, les auteurs arrivent à la conclusion qu il faut minimiser le nombre de réplicats alors que cela n est forcement très clair. Dans quelle mesure ce nombre est-t-il ce qu il y a de plus important? D autre part l approche proposée est basée sur l utilisation de Tapestry, à se sujet on peut remarqué que ce choix n est que peu justifié. Il existe bien d autre type de réseaux overlay dont on ne sait s ils ne pourraient pas offrir des location services meilleurs que Tapestry (Pastry, Chord...). Enfin, toujours en ce qui concerne le manque d explications, on peut se questionner sur la validité des contraintes client et serveur proposée. En effet l article prend en compte seulement la capacité su serveur et la latence du client alors que de nombreux autres facteurs pourraient sembler importants (Capacité des liens, le fait que l on puisse toujours atteindre un objet, consistance des réplicats). Concernant le fonctionnement lui-même, la seule remarque que l on puisse faire est la suivante : Que se passe-t-il, si le serveur racine tombe en panne? Cette possibilité semble n avoir pas été remarquée dans l article, pourtant en suivant le protocole de maintenance de l arbre, si la source tombe, c est tout l arbre qui s écroule. Cette remarque étant, bien sur, à relativiser par rapport à une utilisation réelle de ce système. Cependant l approche est clairement présentée, les algorithmes décrits sont facilement compris et l intérêt de l approche apparaît assez clairement. 4

5 2.3 Expérientations Les expériences menées par les auteurs semblent prouver les performances de l algorithme smart mais dans quelle mesure sont-t-elles assez générale pour étendre cette conclusion sur des systèmes réels? Tout d abord, il n est dit nul part si les résultats présentés sont issus de statistiques sur un ensemble de simulation ou s ils résultent d une seule simulation. Mais ce qui parait plus important c est le principe de la comparaison elle-même, en effet les algorithmes comparés sont tous issus des mêmes auteurs. On peut de plus se demander de la validité de la supposition qui suppose l algorithme static comme étant proche de l optimum. En outre, il est intéressant de remarqué que les auteurs citent une comparaison entre leur algorithme et un algorithme utilisant pour base une redirection DNS des client. Or cet comparaison n est détaillée nulle part. Seuls les résultats sont présentés. Néanmoins on peut considérer ces expériences comme intéressantes pour une première approche, d ailleurs les expérimentations proposées dans SCAN[2] sont plus poussées. Conclusion Cet article présente une approche qui, à défaut d être complètement nouvelle, l est dans le contexte du placement des réplicats pour les CDN. De part sa longueure limitée, il y a beaucoup à dire sur le manque de précision et le manque de discussion. Néanmoins la contribution principale de cet article est d introduire des techniques Peerto-peer dans ce domaine. Références [1] Y. Chen, R. Katz, and J. Kubiatowicz. Dynamic replica placement for scalable content delivery. In International Workshop on Peer-to-Peer Systems, [2] Yan Chen, Randy H. Katz, and John D. Kubiatowicz. Scan : A dynamic, scalable, and efficient content distribution network. [3] Magnus Karlsson and Mallik Mahalingam. Do we need replica placement algorithms in content delivery networks. In 7th International Workshop on Web Content Caching and Distribution (WCW), August [4] John Kubiatowicz, David Bindel, Yan Chen, Patrick Eaton, Dennis Geels, Ramakrishna Gummadi, Sean Rhea, Hakim Weatherspoon, Westly Weimer, Christopher Wells, and Ben Zhao. Oceanstore : An architecture for global-scale persistent storage. In Proceedings of ACM ASPLOS. ACM, November [5] 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 , UC Berkeley, April [6] S. Zhuang, B. Zhao, A. Joseph, R. Katz, and J. Kubiatowicz. Bayeux : An architecture for scalable and fault-tolerant widearea data dissemination,