RENPAR’16 / CFSE’4 / SympAAA’2005 / Journées Composants Le Croisic, France, 5 au 8 avril 2005
LeWYS : un canevas logiciel à composants
pour construire des applications de supervision
Emmanuel Cecchet1, Oussama Layaida1, Vivien Quéma2
1INRIA Rhône-Alpes
2Institut National Polytechnique de Grenoble 655, Avenue de l’Europe
F-38334 Saint-Ismier Cedex, France {prenom.nom}@inrialpes.fr
Résumé
La conception d’une application autonome nécessite plusieurs fonctionnalités. Parmi elles, la fonction de supervision (monitoring) permet la réification de l’état des ressources du système (processeur, mémoire, etc.) ainsi que celui de l’application. Différents travaux ont été menés dans le but de fournir des outils de supervision. Néanmoins, les solutions proposées sont souvent ad-hoc et difficilement exploitables par les développeurs d’applications autonomes. Dans cet article, nous décrivons LeWYS, un canevas logiciel à composants permettant la construction d’applications de supervision. LeWYS permet de construire des applications de supervision pour des besoins variés. Nous présentons les différents composants du canevas, et l’évaluons.
Mots-clés : applications de supervision, composants, fractal
1. Introduction
Pour faire face à la complexité croissante des systèmes informatiques, de nombreux travaux de recherche portent sur la construction de systèmes autonomes. Ces systèmes nécessitent la mise en place de boucles de contrôles composées de composants de supervision dont le rôle est d’observer l’état de fonctionne- ment du système, de composants d’analyse responsables de prendre des décisions de reconfiguration, et de composants de reconfiguration pour opérer les changements [7].
L’état de fonctionnement du système regroupe l’état des ressources du système (consommation CPU, état du réseau, consommation mémoire, etc) et l’état de l’application. Actuellement, les développeurs de systèmes autonomes sont souvent contraints de développer des outils de supervision ad-hoc pour collecter ces informations. En effet, chaque système a ses propres besoins, et il existe rarement une ap- plication de supervision qui correpondent à ces besoins.
Ce qui manque, c’est un canevas générique permettant de construire des applications de supervision adaptées aux différents besoins. Pour que ce canevas soit utile, il doit avoir les caractéristiques sui- vantes :
– adaptation à différentes échelles de systèmes : de systèmes centralisés à des systèmes distribués à grande échelle de type Grilles, potentiellement hétérogènes.
– possibilité de remonter divers indicateurs : outre les indicateurs “standards” (i.e. CPU, mémoire, ré- seau, disques, etc.), une application de supervision doit laisser la possibilité à l’administrateur de développer de façon simple ses propres collecteurs.
– possibilité de construire des chaînes arbitrairement complexes de traitement et de propagation de l’information collectée. Il faut qu’il soit possible de filtrer l’information, de composer plusieurs évé- nements, de corréler certains indicateurs, etc. Par ailleurs, il est nécessaire de pouvoir insérer ces traitements à divers endroits en fonction de l’architecture du système observé et du traitement effec- tué : par exemple, le filtrage des données se fait au plus près de la source, alors que la corrélation multi-sites peut se faire sur différents noeuds.
– possibilité de configurer dynamiquement les divers paramètres de l’application de manière à pouvoir changer les indicateurs collectés, les traitements effectués sur ces indicateurs, les site sur lesquels ils sont acheminés, etc.
– par ailleurs, un aspect fondamental, et orthogonal à tous les précédents, est la non-intrusivité de la solution. Il est impératif que l’application de supervision ne perturbe que très peu les performances du système observé.
Contribution
Dans cet article, nous présentons LeWYS1, un canevas logiciel à composants pour la construction de systèmes de supervision qui répond aux besoins précédents. LeWYS fournit une bibliothèque de com- posants, implémentés à l’aide du modèle de composants FRACTAL, qui peuvent être assemblés pour construire des applications de supervision adaptés aux besoins de l’administrateur. Le traitement et l’acheminement des données est effectué par des canaux à événements dynamiques construits à l’aide de l’intergiciel DREAM. Ainsi, LeWYS permet de construire des applications de supervision aux caractéris- tiques très variées : d’une simple console locale affichant périodiquement la consommation CPU d’une machine, à des systèmes de supervision de Grille utilisant un intergiciel à publications/abonnements pour le transfert des données.
Le reste de l’article est structuré de la façon suivante : nous présentons le modèle de composants FRAC-
TALdans la section 2. La section 3 est une présentation générale du canevas LeWYS. Les sections 4, 5 et 6 sont consacrés aux composants du canevas. Une évaluation de qualitative et quantitative de LeWYS est fournie dans la section 7. Enfin, la section 8 présente les travaux connexes, avant de conclure en section 9.
2. Le modèle de composants FRACTAL
Le modèle FRACTAL[8] est dédié à la construction et la configuration dynamique de systèmes. FRACTAL
est un modèle général qui n’est pas dédié à un langage ou à un environnement d’exécution particulier.
Dans le cadre de cet article, nous nous limiterons à la description de l’implantation Java du modèle.
FRACTALdistingue deux types de composants : lescomposants primitifssont essentiellement des classes Java standards avec quelques conventions de codage. Lescomposants compositesencapsulent un groupe de composants primitifs et/ou composites. Un composant est constitué de deux parties : la partie de contrôle— qui expose les interfaces du composant et comporte des objets contrôleurs et intercepteurs
—, et lapartie fonctionnelle— qui peut être soit une classe Java (pour les composants primitifs), soit des sous-composants (pour les composants composites).
Les interfaces d’un composant correspondent à ses points d’accès. On distingue deux types d’inter- faces : lesinterfaces serveurs sont des points d’accès acceptant des appels de méthodes entrants. Elles correspondent donc aux services fournis par le composant. Lesinterfaces clientssont des points d’accès permettant des appels de méthodes sortants. Elles correspondent aux services requis par le composant.
Par ailleurs, le modèle définit une interface client particulière, appeléeinterface client de collection, qui peut être liée à plusieurs interfaces serveurs. Pour que deux composants communiquent, il faut que leurs interfaces soient liées.
La figure 1 représente un exemple de composant FRACTAL. Les composants sont représentés par des carrés. Le tour gris du carré correspond à la partie de contrôle du composant. L’intérieur du carré corres- pond à la partie fonctionnelle du composant. Les flèches correspondent aux liaisons entre composants.
Les interfaces sont représentées par des “T” (verts pour les interfaces clients ; rouges pour les interfaces serveurs). Les interfaces externes apparaissant au sommet des composants représentent les interfaces de contrôle du composant.
3. Une brève présentation de LeWYS
LeWYS est un canevas à composants dédié à la construction de systèmes d’observations. Un exemple typique de système développé avec LeWYS est représenté sur la figure 2. L’application observée est
1 LeWYS est un projet open-source développé au sein du consortium ObjectWeb. Il est téléchargeable à l’URL suivante : http ://lewys.objectweb.org
sous-composant
contenu interface externe
interface interne contrôleur
liaison
FIG. 1 – Exemple de composant FRACTAL
déployée sur trois sites. Sur chacun de ces sites est déployé un composant, appelépompe, dont le rôle est de générer les informations de supervision pour le site. Ces différentes informations sont fournies par dessondes. Les informations générés au niveau de chaque site sont véhiculés auprès d’observateurs à l’aide decanaux à événementsdynamiques construits en utilisant DREAM [12]. LeWYS ne fait pas d’hypothèse sur les systèmes observés. Si les seuls indicateurs observés sont les ressource physiques (CPU, disque, mémoire, etc.), LeWYS n’impose aucune modification aux applications s’exécutant sur les sites observés. En revanche, s’il est nécessaire d’observer des données propres à une application, il est nécessaire de développer des sondes appropriées, collaborant avec l’application pour fournir les données requises.
pompe sonde
CPU sonde disques multi- plexeur
pompe sonde
CPU sonde mémoire multi-
plexeur
DREAM pompe
multi- plexeur sonde
CPU sonde réseau
observateur
entrepôt de monitoring
observateur
observateur
observateur canaux à événements
DREAM
FIG. 2 – Exemple d’application de supervision construite avec LeWYS.
L’objectif de LeWYS n’est pas de fournir des implantations d’observateurs, néanmoins, nous sommes actuellement en train de développer un observateur particulier, appeléentrepôt de monitoring, qui est un composant permettant le stockage (dans une base de donnée) de l’ensemble des informations de supervision générées, ainsi que des fonctions manipulant ces données (affichage et correlation).
Les sections suivantes décrivent les différents composants du canevas LeWYS : la section 4 est consacrée à la pompe ; les différentes sondes sont présentées dans la section 5. Enfin, la section 6 décrit les canaux à événements.
4. La pompe
Une pompe est déployée sur chacun des sites sur lesquels l’application à observer est déployée. Le rôle d’une pompe est de générer périodiquement des informations de supervision, et de les transmettre aux observateurs intéressés. L’architecture de la pompe est représentée sur la figure 3.
multiplexeur sonde
canal 1 sonde
gestionnaire de sondes
gestionnaire de canaux
horloge sonde
cache
canal 2 gestionnaire de pompe
pompe
FIG. 3 – Architecture de la pompe.
Le composant principal de la pompe est lemultiplexeur. Ce composant possède deux interfaces clients de collection : la première interfacePull(représentée par un triangle blanc) est reliée à un ensemble de composants sondes. Cette interface définit une méthodeMessage pull()par l’intermédiaire duquel le multiplexeur peut récupérer un message produit par une des sondes. La deuxième interfacePush (représentée par un triangle bleu) est reliée à un ensemble de canaux de communications. Elle définit une méthodevoid push(Message m)permettant au multiplexeur de transmettre un message à l’un des canaux.
Le fonctionnement du multiplexeur est le suivant : il possède un thread qui, périodiquement, “pull” un (ou plusieurs) message(s) sur une (ou plusieurs) de ses interfacesPull, et “push” ce(s) message(s) sur une (ou plusieurs) de ses interfacesPush. Nous avons fait le choix d’implanter un multiplexeur car ce composant possède un seul thread, ce qui limite l’intrusivité de la pompe. Le multiplexeur estampille les messages qu’il envoie à l’aide du composanthorloge. Notons que ce composant peut également être utilisé par des composants cachesdans le cas où les sondes sont coûteuses. Le rôle d’un composant cache est de conserver la dernière valeur collectée pendant un laps de temps configurable.
Les sondes sont déployées par un composant appelégestionnaire de sondes. Celui-ci implémente une interface serveurProbeManagerpermettant de déployer une sonde et de la lier au multiplexeur.
Les canaux sont enregistrés en utilisant legestionnaire de canaux. Contrairement, aux sondes qui sont crées par le gestionnaire de sondes, le rôle du gestionnaire de canaux consiste uniquement à insérer un composant canal donné dans le compositepompe, et à lier ce composant au multiplexeur.
Enfin, legestionnaire de pompepermet aux utilisateurs d’intéragir avec le multiplexeur : celui-ci im- plémente une interface qui permet de souscrire aux informations de supervision d’une ou plusieurs pompes et permet de spécifier un ensemble de canaux auxquels cette information doit être envoyée, ainsi que la fréquence à laquelle cette information doit être délivrée. Par exemple, l’utilisateur peut de- mander à ce que les données concernant le CPU et la mémoire soient envoyées toutes les 200 ms aux canaux1et3.
5. Les sondes
LeWYS fournit différentes sondes permettant de réifier un vaste spectre de données provenant du sys- tème d’exploitation et des applications en cours d’exécution. Il est, de plus, facile de développer ses propres sondes. La seule exigence sur les sondes est qu’elles implémentent l’interfacePullqui est utili- sée par le multiplexeur pour collecter les données. Dans la suite de cette section, nous allons décrire les
différentes sondes fournies dans LeWYS.
5.1. Les sondes du système d’exploitation 5.1.1. Les sondes Linux
Linux, comme d’autres systèmes d’exploitation UNIX, réifie l’état du noyau à travers un système de fichiers virtuel, généralement monté sous l’entrée/proc. [14] décrit plusieurs optimisations permettant de collecter de façon efficace des données depuis ce système de fichiers. Toutes les sondes Linux de LeWYS ont le même comportement : lors de son déploiement, une sonde analyse le fichier approprié afin de déterminer l’ensemble desressourcesdisponibles et de calculer des numéros d’indices correspon- dants. Ceci permet ensuite d’appliquer plusieurs optimisations comme : (i) garder le même descripteur de fichier pour toutes les lectures (ii) collecter les informations en un seul bloc (les valeurs sont géné- rées pour chaque lectures) et (iii) accéder aux données à l’aide des indices pre-calculés, évitant ainsi des conversions intermédiaires.
Suivant ce modèle, LeWYS fournit les sondes nécessaires pour observer la consommation CPU, l’uti- lisation de la mémoire (totale, libre, disponible, partagée, en cache, etc.), l’utilisation des disque durs (nombre de lectures et d’écritures, nombre d’opérations fusionnées, débit des opérations de lec- tures/écritures, etc.), les performances du réseau (nombre de connexions actives, débits entrant/sortant, taux de pertes de paquets, etc.) et les informations du noyau (nombre de processus, nombre d’interrup- tions, etc.).
5.2. Les sondes Windows
Windows fournit une infrastructure d’observation permettant aux applications d’accéder aux perfor- mances du système sous-jacent. Ces informations concernent : (i) les composants matériels tels que la mémoire et le processeur, (ii) les composants systèmes tels que les processus, les interruptions et (iii) les composants applicatifs utilisant les services Windows pour exposer leurs performances. Quelque soit le type du composant observé, les données sont structurées en trois niveaux hiérarchiques :objet,instance etcompteur:
– un objet désigne une ressource observable présente dans le système, qui peut donc concerner les trois précédents types de ressources.
– une instance représente un sous-ensemble d’un objet. Par exemple, un objet “réseau” peut avoir plu- sieurs instances relatives aux différentes interfaces réseau présentes dans le système.
– un objet (ou une instance) définit plusieurs compteurs reflétant les métriques mesurées de cet objet.
Une instance réseau par exemple, définit les compteurs relatifs au : débit de transmission, débit de réception, nombre de paquets perdus, nombre de connexion active, etc.
Registry Interface PDH Perfmon Custom
App 1
RegQueryValueEx HKEY_PERFORMANCE_DATA
PerfLib Network
Custom App 2
Performance monitoring applications
Performance monitoring interfaces
Performance monitoring components Enum, select,
query, etc.
System Performance Components
Performance Extension Components LeWYS LIB
Network Memory
Processor
…..
Service 1 Service 2
Service 3
…..
CPU Probe
Memory Probe
Network Probe
Disk Probe
Battery Probe
LeWYS
Kernel WIN32 API
….
JNI
FIG. 4 – Les structures Windows d’accès aux métriques du système.
Comme le montre la figure 4, plusieurs composants se chargent de mesurer les performances des diffé- rents composants observables. Ces données sont accessibles aux applications à travers la base de registre (sous la cléHKEY_PERFORMANCE_DATA). Les données ne sont pas stockées dans le registre lui-même, mais l’accès à cette clé provoque leur collecte à partir des composants appropriés. Nous avons développé une librairie native qui permet aux sondes LeWYS de récupérer ces données de manière efficace.
5.3. Les sondes applicatives
LeWYS fournit actuellement des sondes JMX [5] dont le but est de collecter des informations applicatives dans les environnements Java. L’architecture JMX fait intervenir les trois niveaux suivants (figure 5) : – le niveauinstrumentationest composé d’un ensemble deMBeans. Les MBeans sont déployés au sein
de l’application observée. Ils permettent de collecter des informations sur l’application.
– le niveauserveur de MBeanspermet de gérer les MBeans déployés.
– le niveauprotocolefournit un ensemble de connecteurs permettant d’interagir avec les différents MBeans déployés.
Application
MBeans MBeans
MBean server Sonde LeWYS
RMI
instrumentation serveur de MBeans protocole
FIG. 5 – L’architecture JMX.
Les sondes JMX de LeWYS utilisent le niveau protocol pour interroger les MBeans déployés. Chaque sonde est associée à un serveur de MBeans. Durant son initialisation, elle s’informe sur tous les MBeans enregistrés, ainsi que leurs attributs. La communication avec le serveur est basée sur RMI, ce qui fait que les sondes peuvent être déployées localement sur la même machine que le serveur, aussi bien que sur une machine distante.
6. Canaux à événements
Les canaux à événements sont construits à l’aide de DREAM [12], un canevas à base de composants FRACTALpermettant de construire des intergiciels orientés-messages. DREAMfournit une bibliothèque de composants comprenant des files de messages, des composants encapsulant des sockets Java, des implémentations de protocoles (diffusion atomique fiable, diffusion probabiliste), une implantation de la spécification JMS [2], etc. Les intérêts de l’utilisation de DREAMsont multiples :
– DREAMest un canevas ouvert et extensible : le développeur d’application de supervision peut dé- velopper son propre canal à événements en s’aidant des composants présents dans la bilbiothèque DREAM.
– DREAMpermet de construire des canaux à événements dynamiquement reconfigurables. Cela permet, par exemple, d’insérer dynamiquement un composant de filtrage où d’aggrégation de données.
– DREAM fournit des composants de gestion de ressources qui permettent de construire des canaux à événements performants, ce qui est nécessaire pour garantir la non-intrusivité de l’application de supervision.
– DREAMest développé à l’aide du même modèle de composants, ce qui simplifie son intégration dans LeWYS.
7. Evaluation
Dans cette section, nous présentons une évaluation qualitative et quantitative de LeWYS.
7.1. Evaluation qualitative
Reprenons les différentes caractéristiques que nous mentionnons dans l’introduction comme nécessaires pour qu’une application de supervision soit utilisable dans de nombreux contextes :
– adaptation à différentes échelles de systèmes: en permettant de déployer dans la pompe des canaux de communication arbitraires, LeWYS permet de construire des applications de supervision adaptées à différentes tailles de systèmes. Par exemple, il est très simple de construire une console “locale”
de supervision qui affiche périodiquement un certain nombres d’indicateurs. Pour ce faire, il suffit d’enregistrer comme canal un composant qui ne fait qu’afficher les messages qu’il reçoit. Le système d’observation ainsi construit a uniquement pour but de donner périodiquement des informations sur la machine sur laquelle il est déployé. Il est également possible de construire des systèmes de propagation d’événements à grande échelle en utilisant les protocoles fournis dans la bibliothèque DREAM. Par exemple, DREAM fournit une implantation du protocole de diffusion probabilistique décrit dans [10]. Ce protocole peut être utilisé pour disséminer des informations collectées pour des systèmes comprenant des milliers de nœuds.
– possibilité de remonter divers indicateurs: l’architecture à base de composants de LeWYS a été conçue de façon à ce qu’il soit aisé de déployer des sondes spécifiques à un système donné. Le développeur n’a qu’à développer les classes de ses sondes et à les enregister dans un fichier de configuration du gestionnaire de sondes qui sera ainsi capable de les déployer. A l’heure actuelle, LeWYS fournit des sondes permettant de collecter divers indicateurs physiques (CPU, mémoire, disque, etc.) de machines exécutant des systèmes d’exploitation Windows 2000 & XP, Linux, et Solaris. Par ailleurs, nous avons développé des sondes applicatives permettant d’observer le comportement de l’intergiciel C-JDBC [9].
Nous sommes actuellement en train de développer des sondes pour les différents tiers d’un serveur J2EE, ainsi que des sondes de détection de fautes.
– possibilité de construire des chaînes arbitrairement complexes de traitement et de propagation de l’information collectée: l’utilisation de canaux à événements DREAM permet de construire des chaînes de propa- gation des données de supervision arbitrairement complexes. En effet, il est aussi bien possible de construire de systèmes de dissémination simplistes (sockets TCP/IP) que des systèmes de traitement de l’information basés sur des règles “événement→réaction” en utilisant l’implantation DREAMde l’intergiciel ScalAgent [12].
– possibilité de configurer dynamiquement les divers paramètres de l’application de supervision: l’utilisation du modèle de composants FRACTALpermet de modifier dynamiquement l’architecture de l’application de supervision. Des exemples de reconfigurations dynamiques sont : l’ajout d’une sonde, la modifi- cation de la fréquence de collecte d’une sonde, l’ajout d’un composantcachepour limiter l’intrusivité de la sonde, l’ajout d’un canal de dissémination des données, etc.
– non-intrusivité: l’architecture de la pompe a été conçue de manière à minimiser les ressources consom- mées par l’application de supervision : un seul thread est utilisé par le multiplexeur. Par ailleurs, des caches permettent de limiter l’intrusivité des sondes les plus coûteuses.
7.2. Evaluation quantitative 7.2.1. Sondes Linux
Le tableau 1 présente les performances des différentes sondes Linux : pour chacune d’elles, nous éva- luons le temps moyen de collecte des informations de supervision. Les mesures ont été effectuées sur des Pentium IV 4 Ghz, avec 512 Mo de mémoire, un disque IDE de 40 GO avec 6 partitions. La machine utilise un noyau Linux 2.4.20 et la JVM Sun 1.4.2.
Le coût dominant dans chaque mesure est celui de l’accès au système de fichier/proc. La sonde mé- moire a des performances moindres du fait qu’elle requiert des accès à deux fichiers/procdifférents.
Néanmoins le coût reste négligeable et prouve qu’il est possible de construire des applications de super- vision peu intrusives.
Sonde Temps moyen de col- lecte
CPU 23.4µs
Mémoire 40.7µs Disques 31.5µs Réseau 27.8µs Noyau 23.0µs
TAB. 1 – Performances des sondes Linux.
7.2.2. Sondes Windows
Le tableau 2 présente les temps moyen de collecte des sondes Windows. Ces résultats ont été obtenus Pentium IV 4 Ghz, avec 512 Mo de mémoire, un disque IDE de 40 GO avec 6 partitions. La machine utilise Windows 2000 et la JVM Sun 1.4.2.
Sonde Temps moyen de col- lecte
CPU 0.72 ms
Mémoire 0.35 ms Disques 1.9 ms Réseau 12 ms Noyau 1.2 ms
TAB. 2 – Performances des sondes Windows.
Le temps moyen de collecte des informations de supervision est au minimum de 0.35 ms. Ce coût, relativement élevé, est principalement imputable aux appels JNI, ainsi qu’à l’accès à la base de registre du système. On constate également une forte variation entre les différentes sondes (de 0.35 ms à 12,2 ms), qui n’est explicable que par le fait que certains composants d’observations du système sont coûteux en termes de besoins mémoires et de traitement (e.g. composants réseau).
8. Travaux connexes
Plusieurs travaux se sont intéressés aux systèmes de supervision, notamment dans le contexte des grappes de machines. Parmi eux, on distingue deux types de travaux : ceux qui se focalisent sur le supervision des applications [4, 1, 3], et ceux qui fournissent des plateformes de supervision plus géné- rales. Notre étude de l’état de l’art s’intéresse à cette deuxième catégorie.
Ganglia [13] est un système dédié à l’observation de grappes et de grilles de machines. Il repose sur l’utilisation de deux types de démons systèmes :gmondetgmetadcommunicant via un protocole d’an- nonce/écoute en multicast. Un gmond s’exécute sur chaque nœud observé et se charge de collecter un ensemble d’informations sur le système. Celles-ci sont envoyées périodiquement à un gmetad qui se charge de leur collecte et leur traitement. Outre le fait qu’il offre plus de fonctionnalités, LeWYS tire profit de l’architecture DREAM en offrant plus de flexibilité dans le placement et la construction des traitements des données observées (filtrage, agrégation, etc.). Par ailleurs, l’emploi d’un protocole d’an- nonce/écoute en multicast rend Ganglia peut apte à l’observation de systèmes à grande échelle.
L’architecture JAMM [15] définit une plateforme à agents automatisant le déploiement de sondes d’ob- servations et la collecte des événements correspondants. Il serait possible de construire un système ana- logue avec LeWYS en utilisant les composants “événements/réaction” de la bibliothèque DREAM. Ces composants permettent de déployer un ensemble de serveurs hébergeant des agents s’exécutant suivant
le modèle d’acteurs [6]. L’avantage de l’utilisation de DREAMest que la plate-forme à agents construite est plus flexible : il est par exemple aiser de modifier dynamiquement les propriétés de l’exécution des agents (ordonancement des messages, atomicité de leurs réactions, persistences, etc.) [12].
WatchTower [11] est un système de supervision spécifique aux environnements Windows. Il est basé sur l’interface PDH (Performance Data Helper), une interface de programmation qui masque la complexité de la base de registres de Windows. Bien que cette interface donne accès à tous les indicateurs de perfor- mances, elle est coûteuse car elle requiert un accès à la base de registre pour chaque valeur collectée.
Dans LeWYS, ceci est optimisé du fait qu’un seul accès est nécessaire pour récupérer les différents in- dicateurs de performance d’une sonde. Par ailleurs, le canevas LeWYS étant implanté en Java, il est indépendant de la plate-forme d’exécution : il est uniquement nécessaire de développer les sondes adé- quates.
Enfin, citons NWS (Network Weather Service) [16] un système de supervision qui permet de faire des pré- visions sur les performances à court-terme du réseau. NWS utilise différent composants écrits en C et utilisant des sockets TCP/IP pour la communication des données. L’accent a été porté sur la minimi- sation de l’intrusivité du système. LeWYS est un système de supervision plus général et de plus haut niveau : la possibilité de s’abonner à différents canaux d’événements permet notamment de construire des chaînes de traitement de l’information complexes, ce qui n’est pas le but de NWS. Il est néanmoins possible de fournir les mêmes fonctionnalités que NWS. Pour ce faire, il suffit de construire des canaux à événements DREAMutilisant de simples sockets TCP/IP.
9. Conclusion
Dans cet article, nous avons présenté LeWYS, un canevas logiciel à composants dédié à la construction d’applications de supervision. Les objectifs de LeWYS sont multiples : permettre la construction d’appli- cations de supervision pour des systèmes de tailles variables ; permettre au développeur de construire des collecteurs ad-hoc pour générer les informations de supervision dont il a besoin ; permettre un ache- minement et un traitement des informations arbitrairement complexes. Par ailleurs, l’architecture de LeWYS a été conçue de manière à minimiser l’instrusivité des applications de supervision.
Nous avons décrit les différents composants de LeWYS et présenté une évaluation des sondes Linux et Windows qui n’est pas en contradiction avec l’objectif de non-intrusivité. Nous sommes actuellement en train d’évaluer l’intrusivité des canaux à événements. Concernant les travaux futurs, nous souhai- tons utiliser LeWYS dans le cadre des applications de commerce electronique J2EE. Notre objectif à long terme est de construire un système autonome dans lequel LeWYS fournira les informations de supervi- sion.
Bibliographie
1. Scalable Performance Tools (Pablo Toolkit), June 1999. Department of Compu- ter Science, University of Illinois at Urbana-Champaign, USA, http ://www- pablo.cs.uiuc.edu/Project/Pablo/ScalPerfToolsOverview.htm.
2. Java Message Service Specification Final Release 1.1, Mars 2002. Sun Microsystems, http ://java.sun.com/products/jms/docs.html.
3. Remos : Resource Monitoring for Network-Aware Applications, April 2002. http ://www- 2.cs.cmu.edu/˜cmcl/remulac/remos.html.
4. The NetLogger Toolkit : End-to-End Monitoring and Analysis of Distributed Systems, June 2002.
DIDC, Lawrence Berkley National Laboratory, http ://www-didc.lbl.gov/NetLogger/.
5. Java Management Extensions (JMX) specification version 1.2, Mars 2004. Sun Microsystems, http ://java.sun.com/products/JavaManagement/.
6. Agha (G. A.). – Actors : A Model of Concurrent Computation in Distributed Systems.In : The MIT Press, ISBN 0-262-01092-5. – Cambridge, MA, 1986.
7. Bouchenak (Sara), Boyer (Fabienne), Cecchet (Emmanuel), Jean (Sébastien), Schmitt (Alan) et Stefani (Jean-Bernard). – A component-based approach to distributed system management - a use case with self-manageable j2ee clusters.In : 11th ACM SIGOPS European Workshop. – Leuven, Belgium, septembre 2004.
8. Bruneton (Eric), Coupaye (Thierry), Leclercq (Matthieu), Quéma (Vivien) et Stefani (Jean-Bernard).
– An Open Component Model and its Support in Java.In : Proceedings of the International Symposium on Component-based Software Engineering (CBSE’2004). – Edinburgh, Scotland, 2004.
9. Cecchet (E.), Marguerite (J.) et Zwaenepoel (W.). – C-JDBC : Flexible Database Clustering Middle- ware.In : Proceedings of Freenix. – 2004.
10. Eugster (P.), Guerraoui (R.), Handurukande (S.), Kermarrec (A.-M.) et Kouznetsov (P.). – Light- weight Probabilistic Broadcast.ACM Transactions on Computer Systems, vol. 25, n3, 2003.
11. Knop (M.), Schopf (J.) et Dinda (P.). – Windows Performance Monitoring and Data Reduction Using WatchTower. In : Proceedings of the Workshop on Self-Healing, Adaptive and self-MANaged Systems (SHAMAN). – New York City, 2002.
12. Leclercq (Matthieu), Quéma (Vivien) et Stefani (Jean-Bernard). – DREAM : un Canevas Logiciel à Composants pour la Construction d’Intergiciels Orientés Messages Configurables.In : Proceedings of the 4th Conférence Française sur les Systèmes d’Exploitation (CFSE’2005). – Le Croisic, France, April 2005.
13. Matthew (M.), Brent (C.) et David (C.). – The Ganglia Distributed Monitoring System : Design, Implementation, and Experience. – September. Submitted for publication
http ://ganglia.sourceforge.net/talks/parallel_computing/ganglia-twocol.pdf.
14. Smith (C.) et Henry (D.). – High-Performance Linux Cluster Monitoring Using Java.In : Proceedings of the 3rd Linux Cluster International Conference. – 2002.
15. Tierney (B.), Crowley (B.), Gunter (D.), Holding (M.), Lee (J.) et Thompson (M.). – A Monitoring Sensor Management System for Grid Environments. In : Proceedings of the 9th IEEE International Symposium on High Performance Distributed Computing (HPDC’00), p. 97. – Pittsburgh, USA, August 2000.
16. Wolski (Rich), Spring (Neil T.) et Hayes (Jim). – The network weather service : a distributed resource performance forecasting service for metacomputing.Future Generation Computer Systems, vol. 15, n 5-6, 1999, pp. 757–768.
