Introduction

GANAME Abdoul Karim DEA DISIC
Page 1 sur 7
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

GANAME Abdoul Karim DEA DISIC
Page 2 sur 7
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.

GANAME Abdoul Karim DEA DISIC
Page 3 sur 7
 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,

GANAME Abdoul Karim DEA DISIC
Page 4 sur 7
 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.

GANAME Abdoul Karim DEA DISIC
Page 5 sur 7
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].