GANAME Abdoul Karim DEA DISIC Monitoring Data Archive for Grid Environments Introduction Cet article cosigné par Jason Lee, Dan Gunter, Martin Stoufer et Brian Tierney (Lawrence Berkeley National Laboratory), présente un système de monitoring d’archives dans les environnements de Grid dont les pièces maîtresses sont Netlogger et GMA (Global Monitoring Architecture). Netlogger est un outil de monitoring d’applications distribuées et GMA une architecture dédiée au monitoring dans les grilles. Ce modèle a été développé pour palier à certaines insuffisances des systèmes de monitoring dans les grilles de calcul, notamment le non support de bursts de données sans engorgement du système, la non prise en compte des archives dans le monitoring ainsi que le passage à l’échelle. Synthèse de l’article Contexte 1. Monitoring de données dans un environnement distribué Le monitoring (surveillance) consiste en un processus de collecte et d’agrégation de données en vue d’une analyse de performance d’un réseau ou d’une application. Aucune norme n’est définit pour la conception des outils de monitoring; l’approche étudiée ici comporte quatre (4) éléments. Ce sont : Le générateur de données de monitoring (GDM), Le service d’activation de monitoring (SAM) qui lance le générateur de données de monitoring, collecte les événements et les envoie aux destinataires qui les ont demandé, Le receveur d’événements monitorés (REM) qui traite les données de monitoring, convertit les événements en records et les envoie dans un tampon disque, L’archiveur qui charge les records dans la base de données d’archivage d’événements. Le monitoring est nécessaire dans un environnement distribué en ce sens qu’il permet de détecter les points sensibles qui peuvent être à l’origine des goulots d’étranglements. Il permet aussi de détecter les éléments qui sont à l’origine d’une baisse de performance dans le réseau. La solution présentée dans cet article t’atèle à présenter le REM et l’archiveur, un travail précédent réalisé par ces mêmes auteurs ayant déjà traité du GDM et du SAM. 2. État de l’art L’état de l’art présente les architectures de grilles [1] ainsi que le monitoring des données dans ces environnements. Il donne également une vue globale de quelques outils de monitoring de Page 1 sur 7 GANAME Abdoul Karim DEA DISIC grilles et présente quelques approches utilisées telles que Pablo [2] et Snodgrass [3]. Un tour d’horizon sur la réplication des données dans les grilles y est fait [4] ainsi que des commentaires concernant les solutions de monitoring basés sur des bases de données relationnelles. Approche proposée L’approche proposée s’appuie sur deux (2) notions essentielles, à savoir Netlogger [5] et GMA. 1. Netlogger C’est un outil qui a été conçu pour monitorer le comportement de tous les éléments participant à la communication entre applications dans un système distribué, afin de déterminer exactement dans quels composants le temps est le plus perdu. Le monitoring se fait à l’aide de fichiers de logs d’événements produits à tous les points critiques du système distribué à monitorer. Les événements issus de chacun des composants sont ensuite corrélés, ce qui permet de caractériser la performance du système global. Netlogger est constitué de quatre composants, à savoir : Une API et une librairie de fonctions qui simplifie la génération des logs d’événements applicatifs, Un jeu d’outils pour la collecte et le tri des fichiers de log, Un système d’archivage des événements, Un outil d’analyse des logs et de visualisation. Il faut noter que, comme pour tout système de monitoring réseau, Netlogger nécessite une synchronisation d’horloge. Un trigger spécial appelé trigger d’activation offre la possibilité aux utilisateurs de changer dynamiquement le comportement de Netlogger sans avoir à le redémarrer. Une fonction de reconnexion intégrée permet à Netlogger d’être tolérant aux fautes. En effet, cette fonction de reconnexion permet de définir une destination de backup pour l’envoi des événements ainsi qu’un intervalle de reconnexion. Si d’aventure la connexion principale venait à être interrompue, la librairie écrit les données à l’emplacement de backup et une scrutation est faite pour savoir si la destination principale n’est pas rétablie (la scrutation est faite aux intervalles définis par l’utilisateur). Dès que la connexion principale est rétablie, Netlogger commence à écrire les données à cet emplacement après avoir optionnellement envoyé au préalable les données « backupées ». Tous ces avantages font de Netlogger un bon protocole de transport flexible pour GMA. 2. Le Grid Monitoring Architecture (GMA) C’est une architecture de monitoring de grilles développée pour répondre aux impératifs de passage à l’échelle tout en offrant des performances dynamiques. Il est constitué de trois éléments essentiels : Le Directory service (DS) : Il publie la liste des données d’événements disponibles ainsi que le producteur à contacter pour demander ces ressources. Le consommateur : demande et reçoit des données d’événements du producteur. Afin de rechercher un producteur qui offre les services qu’il sollicite, le consommateur peut interroger le DS. Il peut aussi s’enregistrer auprès du DS pour rendre disponible la liste des événements qu’il sollicitera. Page 2 sur 7 GANAME Abdoul Karim DEA DISIC Le producteur : Il répond aux requêtes des consommateurs en leur envoyant les données d’événements. Dans le but de trouver les consommateurs qui acceptent les événements qu’il produit, un producteur peut faire des recherches dans le DS. Il peut aussi s’enregistrer en vue de rendre disponible la liste des événements qu’il produit. Il est aussi possible de combiner un producteur et un consommateur pour former un « pipe producteur/consommateur » utilisé pour filtrer/agréger les données. Par exemple, un consommateur peut collecter des données d’un certain nombre de producteurs et utiliser ces données pour générer un nouveau type de données qui sera mis à la disposition de d’autres consommateurs. 3. Combinaison Netlogger / GMA L’approche GMA sépare les canaux de contrôle et de données dans le monitoring des archives de grilles. Le contrôle est assuré par des messages SOAP (Simple Object Access Protocol ) [6] tandis que Netlogger est utilisé pour la chaîne de données. Le contrôle inclut la souscription, le désabonnement ainsi que l’envoi des paramètres des requêtes. La séparation des canaux de données et de contrôle a des avantages indéniables tels que : La possibilité de positionner les options de faible latence dans TCP dans la chaîne de contrôle, La possibilité de positionner les options de haut débit dans la chaîne de données. 4. Utilisation de GMA dans le monitoring d’archives L’architecture GMA offre un cadre pour structurer les interactions entre l’utilisateur, le servie d’activation, le récepteur d’événements et les composants du service d’archivage. Au sens GMA, le service d’activation est un producteur, le récepteur d’événements est un consommateur et le service d’archivage est un producteur. Quand l’utilisateur demande l’activation du service d’archivage par exemple, il joue le rôle de consommateur. L’interface GMA offre des outils d’interactions nécessaires à l’activation, à l’archivage et à la recherche des données d’événements. 5. Le récepteur d’événements monitorés et l’archiveur Ces deux (2) éléments interviennent au niveau de l’archivage des données de monitoring. Le récepteur d’événements monitorés lit les événements de monitoring à partir du réseau et les écrit sur le disque sous forme de fichiers de logs. Quant à l’archiveur, il parse ces logs et les charge dans la base de données d’archivage. Contrairement à l’utilisation d’un composant unique utilisé pour la lecture des événements et l’archivage, cette configuration a les avantages suivants : Le récepteur d’événements est très rapide et léger, Page 3 sur 7 GANAME Abdoul Karim DEA DISIC Une défaillance partielle ou totale de la base de données n’affecte pas le récepteur aussi longtemps qu’il y aura assez d’espace disque pour buffériser les données d’événements. Finalement, le système est plus facile à maintenir car chaque composant peut être séparément upgradé et redémarré. Dans un souci d’efficacité, les données sont chargées dans la base de données par des batchs en utilisant les commandes de chargement SQL standards (ex bulkcopy) 6. Le modèle de données et les données d’archives. Le modèle de données utilisé par l’approche étudiée est basé sur les travaux de NWS [7]. Il décrit chaque événement par un nom, une valeur principale, une cible (adresse IP source et destination), le code à exécuter associé et un certain nombre de variables complémentaires (chaînes ou valeurs numériques). Le modèle de données utilisé est de type Entité/Association comme le montre la figure ci-dessous : Ainsi, ces entités peuvent être mises dans des tables indexées séparées pour permettre une recherche aisée des événements. Ce système peut s’interfacer avec n’importe quelle base de données relationnel supportant le langage SQL. Il faut aussi noter que les événements atomiques prévues dans la base de données ont la même structure que ceux générés par Netlogger, ce qui facilite leur parsing avant insertion dans la base. L’évaluation de la solution Plusieurs tests ont été effectués afin d’évaluer la puissance l’analyse des données de monitoring par la solution proposée. Nous présentons ici l’exemple des « trous inexpliquées dans la bande passante d’un réseau ». Etablissement d’une baseline préalable, Etablissement d’une requête SQL pour connaître la liste des événements qui se sont déroulés au moment où la bande passante était en dessous du seuil critique constaté, Calcul de la moyenne de tous les événements relatifs à la bande passante à travers tous les liens du réseau (par la fonction SQL AVG ()), SQL retourne tous les trous dans la période précisée et on fait une comparaison avec la baseline, Les résultas sont ensuite visualisés et interprétés avec l’outil de visualisation nlv intégré à Netlogger. Page 4 sur 7 GANAME Abdoul Karim DEA DISIC Analyse de l’article Pertinence À en juger par les dires des auteurs et le succès de Netlogger qui a été développé par ce même laboratoire, l’approche proposée dans l’article a été l’un des pionniers dans la prise en compte des archives dans le monitoring en environnement de grilles. De plus, la technique de bufférisation des données à tous les points critiques du système afin d’éviter les goulots d’étranglement (introduit par cette approche) a posé les jalons d’une nouvelle manière de penser les outils de monitoring dans les environnements distribués. L’état de l’art est bien détaillé. Les auteurs font référence à une panoplie de techniques de monitoring et de mesure de performances en environnement de grilles aussi pertinentes les unes que les autres. Points forts La clarté de l’article est assez remarquable. Sans information extérieure, le lecteur est en mesure de se faire une idée précise du monitoring des données archivées dans un environnement de grilles. L’approche est expliquée de façon structurée, progressive et informative. Par ailleurs, l’approche proposée est bien mise en valeur par des arguments convaincants qui font apparaître le sérieux du travail accompli. Les notions employées tout au long de l’article sont bien définies et illustrées. L’approche montre clairement que l’architecture proposée permet de gérer des bursts de données d’événements sans gripper le système. Ceci est un avantage indéniable en ce sens que la gestion de ces bursts de données n’a aucun impact sur le temps de requetage à la base de données. Points faibles Si les auteurs de l’article affirment que leur solution passe à l’échelle, il n’en demeure pas moins que l’argumentation effectuée n’est pas très convaincante. En effet, le passage à l’échelle a été évalué par l’envoi de 26000 événements/s au récepteur d’événements et ce, durant 1h (4.5 Go de données, 100 millions d’événements). Ceci ne prouve aucunement que le système passerait à l’échelle pour un débit ou un temps plus grand. En outre, le tuning système de la base de données d’archivage gagnerait à être pris en compte en plus du tuning développeur largement traité (indexation des tables,…). En effet, les 4.5 Go de données ont été insérées dans la base d’archivage en 4h de temps, ce qui est énorme. Quelques zones d’ombre subsistaient également et la fin de la lecture, la première question qui nous est venu à l’esprit a été la suivante : Comment les auteurs ont-ils pu oublier de traiter l’aspect sécurité alors que le modèle de données duquel dérive leur approche (NWS) n’offre aucun mécanisme de sécurité ? Quelques recherches sur le Web nous a alors permis d’avoir la réponse : La sécurisation est assurée par l’utilisation de clés publiques X.509 combiné avec le protocole SSL [8]. Page 5 sur 7 GANAME Abdoul Karim DEA DISIC Conclusion Cet article présente un système de monitoring de données archivées dans un environnement de grilles qui s’appuie sur une approche relationnelle. Il s’évertu à expliquer comment une base de données relationnelle avec historisation des données permet à partir d’une baseline de comprendre et expliquer les problèmes de performances dans un environnement de grilles. Cette approche s’appuie sur la puissance de requêtage du langage SQL et sur les fonctions de monitoring de Netlogger. Cet article montre aussi qu’une architecture de monitoring s’appuyant sur la norme GMA (Global Monitoring Architecture) peut passer à l’échelle dans un environnement de grilles, pourvu que le choix de la base de données d’archivage soit judicieux. L’article présente l’approche de façon très claire et synthétique, illustrant au besoin les notions par des exemples. Au final, le lecteur a une vision générale du monitoring des données dans les grilles et plus particulièrement des avantages de l’archivage des données dans une base de données relationnelle. La tolérance aux fautes mise en œuvre par la possibilité d’indiquer une destination de Backup en cas d’inaccessibilité de la destination principale achève de donner à cette architecture une flexibilité et une robustesse remarquables. Page 6 sur 7 GANAME Abdoul Karim DEA DISIC Réferences 1 Cancio, G., S. Fisher, T. Folkes, F. Giacomini, W. Hoschek, D. Kesley, B. Tierney. The DataGrid Architecture, Version 2 http://www-itg.lbl.gov/~hoschek/publications/edg-architecture.pdf 2 Ribler, R. J. Vetter, H Simitci, D. Reed. Autopilot : Adaptive Control of Distributed Applications. Proceedings of the 7th IEEE Symposium on High-Performance Distributed Computing, Chicago, IL; Jul 1998 http://www-pablo.cs.uiuc.edu/Publications/Presentations/HPDC7/ 3 Snodgrass, R., A Relational Approach for Monitoring Complex Systems, ACM Transactions on Computer Systems, Vol. 6, 1998 4 Chervenak, A, et al., Giggle : A Framework for Constructing Scalable Replica Location Services, Proceeding of the IEEE Supercomputing 2000 Conference, nov 2000 http://www.globus.org/research/papers/giggle.pdf 5 Brian Tierney and Dan Gunter, Netlogger : A Toolkit for Distributed System Performance Tuning and Debugging, Dec 1992 http://www-didc.lbl.gov/papers/NetLogger.overview.pdf 6 Simple Object Access Protocol (SOAP) http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ 7 Swany, M. and R. Wolski, Representing Dynamic Performance Information In Grid Environments with the Network Weather Service, Proceeding of the 2nd IEEE International Symposium on Cluster Computing and the Grid, Berlin,Germany, may 2002 http://pompone.cs.ucsb.edu/~rich/publications/nws-gis.pdf 8- A Grid Monitoring Architecture http://www-didc.lbl.gov/GGF-PERF/GMA-WG/papers/GWD-GP-16-1.pdf Page 7 sur 7