l’administration système et réseau
8.2 Administration dans le contexte des appli- appli-cationsappli-cations
On peut souligner le fait que l’utilisation des agents mobiles dans un cadre d’administration de systèmes et de réseaux (au sens classique du métier d’ad-ministrateur système et réseau) peut s’avérer parfois trop coûteuse en temps d’installation et de mise en œuvre, surtout pour un administrateur de réseau qui ne serait pas au fait de la programmation et du déploiement d’applications en environnement réparti (un cadre d’administration tel celui que nous avons dé-veloppé constitue bien une application répartie et non triviale à déployer et à utiliser).
En revanche, une fois une telle difficulté maîtrisée, cette approche permet de tirer partie de la bonne connaissance du réseau et de fournir des techniques de ges-tion permettant d’automatiser la supervision d’un vaste ensemble hétérogène de machines et d’équipements, tel qu’illustré, par exemple, par des grilles de calcul. Par exemple, obtenir l’état (disponibilité) de tous les nœuds d’une grille de calcul, peut être entièrement délégué à un ensemble d’agents mobiles qui renseigneraient soit un ensemble d’administrateurs de la grille, soit des agents de calcul, sur l’état de la grille. De tels agents jouent alors le rôle de sonde (c’est pour cela qu’on les rend souvent stationnaires). En considérant qu’un tel système de supervision est mis à la disposition d’agents de calculs dans un premier temps, le système qui
les déploie s’adresse aux agents sondes et cela lui permet ensuite de décider de la machine d’accueil. Dans un deuxième temps, si les calculs sont mobiles on peut imaginer les agents qui les exécutent capables de migrer afin de mieux utiliser les ressources d’autres systèmes. En effet, un problème classique mais réel en ré-parti, est de décider où exécuter les calculs. Pour cela il faut avoir des moyens pour connaître la charge des systèmes et des réseaux, le nombre d’agents présents et le temps CPU qu’ils utilisent [32], le nombre de threads disponibles, etc.., tous les paramètres utiles à la prise de décision du placement des agents mobiles de calcul au moment de leur déploiement mais aussi pendant leur cycle de vie.
On voit bien dans cet exemple que les fonctionnalités de supervision (offertes notamment par NWS [103], un outil incontournable pour la grille) sont offertes à des couches applicatives (ici, le service de répartition de charge) qui, à l’instar d’un administrateur humain, ont à prendre des décisions.
De manière orthogonale, la complexité croissante des services et des applica-tions déployés sur les infrastructures réparties justifie la transposition des tech-niques standard d’administration, des systèmes et des réseaux à ce nouveau contexte. Un outil comme JMX (voir annexe 9.2) constitue un bel exemple d’ou-til qui permet de favoriser cette transposition. En effet, JMX permet d’ouvrir les composants applicatifs au monde de l’administration et notamment, à ses standards comme SNMP. Supposons un ensemble de composants applicatifs ad-ministrables via JMX, il devient nécessaire de concevoir des outils intégrés, donc des plates-formes d’administration pour superviser ces éléments logiciels (telles que par exemple James [83] (plate-forme d’administration à agents mobiles, elle-même administrable via JMX), Lira [21], projet OLAN [58], SmartFrog [40]). Les soucis d’automatisation, de facilité de programmation des fonctions d’adminis-tration, de performance, notamment sur des réseaux à faible débit, etc..., nous semblent à nouveau justifier l’emploi d’agents mobiles dans ces plates-formes. Nous pensons donc que le travail décrit dans cette thèse trouve son application. Nous allons essayer à présent d’illustrer cette éventuelle application.
Étant donné une application complexe s’exécutant sur le réseau que l’on désire administrer, en utilisant des agents mobiles d’administration suivant des itiné-raires dynamiques, nous proposons de considérer que les agents vont se déplacer, non pas sur un groupe d’éléments constituant un réseau, mais sur un groupe de composants de l’application constituant un groupe de services.
En effet, c’est pertinent de considérer que des applications et des services peuvent être regroupés par type de service fourni, et ce, même en se plaçant au niveau réseau. Par exemple, le service d’impression global d’un réseau est composé du service d’impression de chaque serveur d’impression et de chaque imprimante quelqu’en soit le type. Ainsi il est possible, en utilisant la technologie offerte par JMX, d’instrumenter chaque élément du groupe de service et des applications disponibles. Chaque application peut ainsi devenir administrable par un protocole tel SNMP en ayant au préalable défini la MIB SNMP associée.
Ensuite, il faut programmer les opérations d’administration de ces services au sein d’agents mobiles (ProActive), et ce, selon notre cadre de conception. Cela passe aussi par la définition de nouvelles Destinations qui permettront aux agents mobiles d’administration d’atteindre, peut être juste virtuellement, les agents JMX et d’y effectuer les opérations d’administration. A partir de telles Destinations, on pourra donc prévoir de nouveaux types d’itinéraires adaptés à ce type d’administration d’applications et les faire suivre à nos agents mobiles qui feront en sorte que les bonnes méthodes d’administration soient exécutées.
Cette technique appliquée unitairement sur chaque élément logiciel peut être utilisée à un niveau supérieur dans le sens où l’on voudrait pouvoir administrer un service indépendamment du nombre d’applications et de composants logiciels qui mettent en œuvre ce service. Par exemple, on peut considérer un groupe de services administrables par JMX que l’on aimerait superviser comme un tout, et ce de façon très simple, à partir d’un navigateur Web ou d’une plate-forme d’administration réseau standard. Pour cela, on associerait à un tel groupe les types d’agents mobiles capables d’administrer ces composants et leurs itinéraires. Ce même groupe de services serait à son tour rendu administrable à distance, soit en utilisant le protocole HTTP soit le protocole SNMP, grâce à l’instrumentation fournie par JMX. On pourrait dès lors déclencher les opérations d’administra-tion associées à chaque groupe de services, sans avoir à en connaître le mode de fonctionnement.