Revue d'article: A NETWORK-AWARE DISTRIBUTED STORAGE CACHE FOR DATA INTENSIVE ENVIRONMENTS Auteurs: Brian L. TIERNEY, Jason LEE, Brian CROWLEY, Mason HOLDING Computing Sciences Directorate – Lawrence Berkley National Laboratory University of California, Berkley, CA, 94720 Tahiry RAZAFINDRALAMBO – DEA DISIC – 2003/2004 1 Introduction Cet article [1] présente une architecture de stockage basée sur des caches distribués à travers un réseau haut débit. Il décrit une implémentation d'un cache réseau et comment cette implémentation a été adaptée pour être "network-aware", c'est à dire comment les opérations de cette implémentation s'adaptent aux conditions du réseau. Cette implémentation à été mise en place pour les data intensive grid (grille de données intensives) 2 Résume de l'article 2.1 Problématique Les flux de données à grande vitesse résultant des opérations d'instruments tels que les systèmes d'imagerie médicale, les capteurs de d'expérience en physique sont le quotidien des scientifiques. L'avancé des réseaux à grande vitesse fournit de nouvelles approches pour la collection, l'organisation, l'analyse, la visualisation… des données fournies par de tels instruments. L'objectif étant de faire en sorte que les données et l'analyse soient aisément disponibles. Cet article décrit comment les grilles de données peuvent permettre de résoudre de tels problèmes et comment un cache réseau à grande vitesse est un composant particulièrement important dans l'architecture des grilles de données intensives. Les auteurs décrivent l'implémentation d'un cache réseau et comment ce cache réseau a été adapté pour être "network-aware" c'est à dire s'adapter en fonction des conditions du réseau. 2.2 Description de l'approche Du point de vue de l'application une grille est une collection de services middleware qui fournissent aux applications une vue uniforme des composants, des ressources distribuées, et des mécanismes pour les assembler en système. Du point de vue du système middleware, la grille est un ensemble standardisé de services basic fournissant ordonnancement, découverte de ressources, services de communications… Cependant du point de vue du concepteur de la grille, ces services résultent et doivent interagir avec un ensemble hétérogène de possibilités, et souvent impliquent de regarder dans les couches inférieures de calcul ou d'infrastructures de communications. ( utilisation des grilles pour résoudre ces problèmes) Notre modèle doit employer un cache de stockage de données distribué comme élément commun pour toutes les sources de données impliquées. Un cache signifie que le stockage est plus rapide que sur un disque local typique et qu’il est temporaire par nature. Dans les environnements de données intensives, un cache haut débit permet de fournir une interface standard de débit élevé pour les accès venant des sources de données, pour les accès dûs au traitement des données, pour le système de stockage de masse, et pour l’interface utilisateur. (architecture pour les données intensives). Pour utiliser efficacement les réseaux étendus haut débit, les applications doivent être « network-aware » c’est à dire que l’application essaie d’ajuster sa demande en fonction des changements de disponibilité des ressources réseaux. Les applications network-aware vont exiger un service qui fournit des informations sur le passé, le présent et le future état des liens du réseaux qu’elles voudraient utiliser. Un système de surveillance est la première étape pour fournir un tel service.(network aware application) 2.3 Implémentation 2.3.1 Le cache haut débit distribué L’implémentation du cache haut débit distribué mis en place par les auteurs est DPSS [2] Distributed-Parallel Storage System. Cette technologie a été testée ( projet DARPA MAGIC )avec succès pour fournir une architecture de cache, fortement scalable, distribuée, économique et de haute performance. L’implémentation typique d’un DPSS consiste en un grand nombre de station à bas prix comme serveur de block DPSS, chacun avec plusieurs contrôleurs de disque, et plusieurs disques sur chaque contrôleur. L’architecture interne d’un DPSS est la suivante : La requête d’un bloc de données est envoyée depuis une application client à un maître DPSS, qui trouve sur quels serveurs de blocs DPSS sont situés les blocs, puis le maître transmet les requêtes directement vers le client. Les serveurs peuvent être n’importe où sur le réseau. La performance d’un DPSS, mesurée par le débit, est optimisée pour un nombre relativement petit (quelques milliers) de fichier relativement grand (plus de 50MB). Les performances sont les même pour des fichiers de plus de 50 MB. Le DPSS est dynamiquement configurable, autorisant l’ajout ou le retrait de serveurs ou de disque à la volé. Ceci est fait en conservant les informations concernant les ressources hardware du DPSS dans une base de donnée formaté LDAP, qui peut être mise à jour dynamiquement. Des systèmes agents sont utilisés pour surveiller le réseau, les hôtes, et la disponibilité des disques, et stockent ces informations dans une base LDAP. Ces informations peuvent être utilisées pour la tolérance aux fautes, et l’équilibrage de charge. 2.3.2 L’équilibrage de charge Pour que le cache DPSS soit efficace dans un environnement de réseau étendu, il doit avoir une connaissance suffisante du réseau pour s’ajuster à un grand nombre de condition de performance du réseau, et qu’il soit capable de se reconfigurer automatiquement en face d’une congestion ou d’une défaillance matériel. La première étape pour l’équilibrage de charge est le monitoring du réseau. Les auteurs ont implémenté un système nommé Java Agent for Monitoring Managment (JAMM). Ces agents basés sur Java et RMI peuvent lancer une grande variété d’outils et de système de monitoring de réseau, en extraire les résultats, et les publier dans une base LDAP. Ces agents peuvent de manière sécurisée démarrer n’importe quel programme. Les agents exécutent par exemple netperf [3] ou ping pour le monitoring du réseau…, les résultats sont alors publiés dans une base LDAP à des intervalles réguliers (quelques minutes). Ces agents sont exécutés sur tous les hôtes du système distribué, incluant les clients et tous les serveurs. Le DPSS utilise TCP pour le transfert de données. Pour que TCP fonctionne bien sur des réseaux haut débit, il est important qu’il y ait un buffer assez grand pour que le contrôle de congestion fonctionne correctement. La taille du buffer dépend du produit délai-bande passante du réseau, mais le produit délai-bande passante peut avoir un ordre de grandeur de 4 ou 5 sur internet. Il est donc pratiquement impossible de configurer pour un hôte un paramètre de TCP qui soit optimal pour chaque connexion. Pour résoudre ce problème la librairie cliente DPSS détermine automatiquement le produit délai-bande passante pour chaque connexion à un serveur DPSS et met le buffer TCP à la taille optimal. La bande passante et le délai sont obtenus dans la base LDAP. Le DPSS peut exécuter un équilibrage de charge si des blocs de données sont répliqués sur plusieurs serveurs. Le DPSS master utilise les informations d’état dans la base LDAP pour déterminer comment expédier un requête cliente de bloc vers un serveur qui peut donner la réponse la plus rapide. Les auteurs abordent le problème du Load balancing comme un problème combinatoire, il y a un certain nombre de client et un certain nombre de serveur; chaque client doit être assigné à un ou plusieurs serveurs sans qu'aucun serveur ne soit surchargé. L'approche le l'algorithme à coût minimum de flots est une bonne méthode pour résoudre ce problème de type combinatoire. Le problème est que cet algorithme est off-line donc implique un prédictibilité au niveau de la demande de blocs par les clients, alors que les départs et les arrivées de clients sont aléatoires, les quantités de données demandées aussi… La solution proposée par les auteurs est d'exécuter l'algorithme chaque fois qu'une requête client arrive, l'algorithme lui même est assez rapide (1ms pour un modèle de graphe typique). Les auteurs ont modélisé l'équilibrage de charge de DPSS comme un problème de transport, le réseau est présenté comme un graphe bipartite avec des nœuds et chaque nœud est un client ou un serveur, et chaque arête est un chemin réseau du serveur vers le client. Chaque arête a un coût par blocs et une capacité maximum. L'algorithme trouve le flots de blocs du serveur vers le client qui minimise le coût total. Les coûts et les capacités sont assignés par rapport à la latence réseau qui est selon les auteurs le facteur dominant affectant les performances. Cette latence est divisée en trois latence, le délai du lien entre le client et le master, délai d'exécution du serveur et du master DPSS, et délai de transmission entre le serveur et le client. Ces délais sont obtenus dans la base LDAP. Le problème de cette approche est que les chiffres obtenus ne sont pas forcément à jour et que plusieurs arêtes peuvent partager le même lien, ce qui n'apparaît pas dans le graphe. La capacité des arêtes est la bande passante obtenu de la base LDAP. Cette capacité peut être réduite en fonction du degré des réplication des données. Quand des données sont chargées dans le DPSS, les blocs sont distribués à travers n serveurs, et chaque blocs est répliqué m fois (m<=n). Si nous supposons que les blocs sont uniformément distribués, il est peu probable qu'un serveur stocke plus de m/n pourcent des blocs demandés. La capacité assignée de l'arête est le minimum, soit de la bande passante soit de m/n pourcent des données demandées par le client. L'implémentaion du load balancing, maintient une structure de graphe de données qui est modifiée chaque fois qu'un client part ou arrive. Le coût des arêtes est recalculé toutes les 3 minutes d'après les données de la base LDAP. 2.4 Résultats Les expérimentations réalisées par les auteurs ont montrées que la réplication de données et le load balancing augmentent le débit en sortie du DPSS par un facteur de 2.17 comparé a l'utilisation sans réplication. En utilisant la réplication de données, le load balancing augmente de 33% le débit de sortie total par rapport à la "greedy strategy" employé jusqu'ici dans les systèmes DPSS. Les expériences ont été faites avec load balancing et réplication de données sur 4 configurations différentes, avec un réseau comme présenté dans le schéma suivant. Globalement, l'équilibrage de charge et la réplication de données, augmentent la bande passante délivrée aux applications. La réplication autorise l'utilisation de plusieurs serveurs par un clients, mais sans l'équilibrage de charge, les clients restent limités par la vitesse du serveur le plus lent. L'approche du flot à coût minimum pour l'équilibrage de charge augmente le débit total du système et s'adaptant à la demande client. 2.5 Future works Les travaux sur le DPSS sont encore nombreux et dans de nombreux domaines. Les auteurs prévoient de tester le DPSS dans une banc d'essai plus large, avec plus de clients. Ceci permettra de mieux évaluer l'approche du flot à coût minimum, et de mieux monter les impacts de l'équilibrage de charge. 2.6 Conclusions Les auteurs ont décrit une architecture de données pour les applications générant des flux intensifs de données, centrée sur l'utilisation d'un cache haut débit et network-aware. Les auteurs pensent que ce type de cache deviendra un composant essentiel pour les architectures de grilles de données. Les auteurs ont aussi montré que l'ajout d'un système prenant en compte l'état du réseau sur un système distribué peu largement augmenté les performances. Cependant plus de tests doivent être réalisés pour valider l'utilité de l'algorithme d'équilibrage de charge sur des environnements réseaux plus généraux. La réplication de données est aussi l'un des facteurs d'augmentation de performance sur un système DPSS. Malgré le fait que la réplication à un coût, elle permet aussi une meilleure tolérance aux fautes. 3 Evaluation Les résultats présentés dans cet article montre une architecture pour les applications de données intensives qui est centrée sur un cache haut débit et qui peut s'adapter aux conditions du réseau. Les auteurs pensent que ce type de cache sera un composant très important pour construire des grille de données intensives. Les résultats décrits après l'expérimentation montrent aussi que l'ajout de la composante permettant d'adapter les requêtes de la grilles aux conditions réseaux augmente considérablement les performances de l'architecture, de plus le load balancing effectué grâce a une réplication des données permet d'utiliser la grille et les serveurs de données de manière relativement optimal malgré le fait que la réplication ait un coût. Cet article est assez difficile à lire, le plan n'est pas très clair, les auteurs dans l'introduction propose de présenter un système de cache distribué qui soit network aware, et pourtant le gros de l'article se base sur l'optimisation de ce cache qu'il suppose comme acquis, toutes les expérimentations se basent sur l'optimisation de ce cache, les auteurs comparent les performances du cache avant et après optimisations. Il y a très peu de descriptions du système lui même, les auteurs en font seulement une description sommaire et renvoient pour plus de détails vers des références bibliographiques pour une description complète du système. Ceci est peut être dû à la longueur de l'article qui doit être restreinte. Les auteurs ne parlent pas non plus ou très peu pour ne pas dire pas du tout des systèmes concurrents aux leurs, et ne font aucune comparaison entre leur architecture et les architectures concurrentes. D'autres articles des mêmes auteurs concernant une implémentation du DPSS pour des applications telles que High Energy Physics (HEP) ont été publiées et ont permis aussi de voir d'autres résultats de test concernant le DPSS. Les derniers travaux des auteurs concernant le sujet se sont basés surtout sur les améliorations des performances de ce cache que ce soit au niveau de l'algorithme de load balancing, au niveau du monitoring du réseau lui même pour voir une vue assez proche de la réalité du réseau… BIBLIOGRAPHIE [1] B. Tierney, J. Lee, B. Crowley, M. Holding, J. Hylton, F. Drake, "A Network-Aware Distributed Storage Cache for Data Intensive Environments", Proc. of IEEE High Performance Distributed Computing Conference (HPDC-8), August 1999. [2] DPSS: http://www-didc.lbl.gov/DPSS [3] Netperf: http://www.netperf.org/