SERVICES D ADMINISTRATION D'APPLICATIONS REPARTIES

Transcription

1 UNIVERSITE JOSEPH FOURIER THESE pour obtenir le grade de DOCTEUR de l université Joseph Fourier de Grenoble Discipline : Informatique, Systèmes et Communication présentée et soutenue publiquement par DE PALMA NOËL Le 24 octobre 2001 SERVICES D ADMINISTRATION D'APPLICATIONS REPARTIES Directeur de thèse: Pr. Roland Balter JURY thèse) P. Y. Cunin, Professeur à l université Joseph Fourier (Président) J.M. Geib, Professeur à l université de Lille (Rapporteur) J. Bezivin, Professeur à l université de Nantes (Rapporteur) J. Estublier, Directeur de recherches au CNRS (Examinateur) R. Balter, Professeur à l université Joseph Fourier (Directeur de Thèse) L. Bellissard, maître de conférence à l INPG (Co-Directeur de

2

3 Remerciements Je tiens à remercier toutes les personnes qui ont rendu cette thèse possible par leurs aides et leurs contributions. Mes premiers remerciements sont adressés à Pierre-Yves Cunin, professeur à l université Joseph Fourier pour m avoir fait l honneur de présider ce jury. Je remercie Jean Bezivin, professeur à l Université de Nantes, et Jean-Marc Geib, professeur à l Université de Lille, pour avoir accepté d être rapporteurs de mon travail et d avoir apporté un jugement constructif. Je remercie également Jacky Estublier, directeur de recherches au CNRS pour avoir accepté d être examinateur de cette thèse. J adresse mes sincères remerciements à Roland Balter, professeur à l Université Joseph Fourier et à Luc Bellissard, Maître de conférence à l Institut National Polytechnique de Grenoble pour leur encadrement et leur soutien tout au long de ces trois années de thèse. Je remercie aussi l ensemble des membres de l équipe AAA pour leur aide, leur coopération et l élan qu ils ont su insuffler à mon travail. Merci donc à dédé, serge, david, nico, fred, xavier, philippe et à tous les nouveaux membres de l équipe. Je remercie aussi l ensemble des membres du projet Sirac, permanents, ingénieurs experts et thésards, pour l ambiance chaleureuse qui a régné au sein des divers bureaux du projet au cours de ma thèse. Je remercie l ensemble des joueurs de rugby du «jeudi midi» pour m avoir permis de vibrer à nouveau la balle à la main sur un terrain de rugby. Je remercie la bande des chevaliers ronds de la table buissarde pour leur savoir-vivre et pour les rêveries du samedi après midi. Merci donc à l africain, au tigre vert, à l homme chien,à olive, à patoux et à la musaraigne Enfin, je garde une place toute particulière pour ma famille qui a su me supporter et qui supporte encore mon caractère difficile. Pour finir, je remercie Pat sans qui je ne serais pas allé au bout de ce travail, pour tout son amour et son soutien infaillible dans les pires moments.

4

5 Table des matières I Introduction Qu est que l administration Les fonctions d administration Modèle de base d administration Les différents niveaux d administration Administration d applications réparties Caractéristiques des applications réparties Problèmes liés à l administration d application réparties Gestion de configuration d applications réparties Configuration de logiciels réparties Surveillance de logiciel répartie Reconfiguration de logiciels réparties Plan...21

6 Table des matières II Etude des solutions d administration Solutions Industrielles SNMP Architecture Protocole SNMP Structure de la MIB Conclusion JMX Architecture Instrumentation Mbean Standard Mbean dynamique Modèle de notification JMX Agent Conclusion Apport pour l administration d applications réparties Solutions académiques Patron d infrastructure d administration DCUP META MANDAS Langages de description d architecture POLYLITH DARWIN A3-OLAN WRIGHT RAPIDE Synthèse Modélisation des applications Classification des projets étudiés Discussion sur la modélisation des applications réparties Capacité de reconfiguration Les différents types de changement Classification des projets étudiés Discussion sur la reconfiguration des applications réparties... 84

7 Table des matières III La Méthode OLAN Contribution Vue d ensemble de la méthode OLAN Phase de conception Le langage OLAN Les outils d architecture Phase d administration Outil d administration Infrastructure d administration Extension du langage OLAN Liens entre le langage OLAN et l infrastructure d administration Composant primitif Composant composite Discussion L infrastructure d administration Contraintes de spécification Architecture Le niveau Instrumentation Composant administrable Interface d administration Déploiement Exemple Le niveau Contrôleur Contrôleur Interface d administration Déploiement du contrôleur Discussion...135

8 Table des matières IV Reconfiguration Dynamique Protocole de reconfiguration Problèmes généraux Cohérence locale Cohérence globale de l application Un protocole de reconfiguration Notion de calcul global Contraintes de reconfiguration Un algorithme de reconfiguration Une mise en oeuvre Discussion Déclinaison du protocole de reconfiguration Besoins pour l adaptation du protocole de reconfiguration Modélisation d un calcul distribué dans le cas AAA Mécanisme de passivation Algorithme de reconfiguration Discussion

9 Table des matières V Exemple d utilisation L application de gestion distribuée de logs Principe d architecture Une architecture particulière Utilisation de la méthode OLAN Conception Administration Discussion Expérimentation VI 2.1 Evaluation des coûts de déploiement de base à l aide de A Hypothèses Rappel de l algorithme de déploiement Mesure Regroupement des notifications de déploiement Algorithme de déploiement Mesures Impact de la hiérarchie Hypothèses Algorithme de déploiement Mesures Discussion Conclusion VII Bibliographie...197

10

11 I Introduction

12 Chapitre I : Introduction Toutes les applications doivent évoluer au fil du temps pour satisfaire les besoins de leurs utilisateurs ou pour prendre en compte la modification de leur environnement d exécution. Le rôle d un administrateur est d intervenir sur les applications en cours d exploitation pour prendre en compte ces changements. A l aube de l informatique, beaucoup d applications étaient conçues pour s exécuter sur de gros ordinateurs centraux, les mainframe. Avec ce type d architecture, chaque application était construite sous la forme d un gros morceau de code qui s exécutait sur un unique calculateur. Les utilisateurs utilisaient ces applications au travers de terminaux directement reliés au calculateur. Dans le cas de ces applications, les opérations d administration étaient effectuées en arrêtant l application et en modifiant les fichiers de configuration de l application, ou à l extrême, le code source de l application. Un administrateur pouvait facilement opérer sur l application à administrer du fait de la présence centralisée sur le calculateur du code de l application. L étape suivante qui est apparue avec la généralisation des PC (Personnal Computer) et des réseaux locaux, fut la séparation entre le code du client et le code des bases de données servant au stockage d information. A ce stade une application était divisée en différentes pièces de code pouvant s exécuter sur des machines différentes. Une application n était plus construite sous la forme d un seul processus s exécutant sur une seule machine. Avec ce nouveau type d application, le travail des administrateurs s est complexifié. Ils devaient détecter quelle partie de l application devait être modifiée et administrée et sur quelle machine s exécutait le code correspondant. Les opérations d administration devinrent plus complexes du fait de la distance physique pouvant séparer les diverses machines hébergeant une partie de l application. Au bout du compte, cette complexité était encore gérable de manière plus ou moins ad hoc par les administrateurs. Puis vint la révolution des réseaux et de l Internet que l on connaît aujourd hui. Les applications actuelles sont de plus en plus distribuées, de plus en plus larges, de plus en plus complexes. Soudainement une simple application peut être composée de centaines voir de milliers de morceaux de codes dispersés sur le réseau, coopérant pour fournir à leurs clients le service qu ils requièrent. Ce type d application est aujourd hui devenu très complexe à administrer pour les administrateurs qui en ont la charge. Ces difficultés sont liées : A la grande dispersion géographique et structurelle des différentes parties constituant l application A la difficulté pour les administrateurs d obtenir une vision cohérente de la structure d une application en cours d exécution, à localiser quelle partie de l application pose problème et comment intervenir sur l application pour remédier au problème tout en entraînant un minimum de perturbation sur l application et les usagers. L administration d application répartie reste un problème ouvert pour lequel il n existe pas de solutions satisfaisantes. Beaucoup de travaux ont été menés ces dernières années pour fournir des solutions d administration de systèmes distribués (matériel réseaux et autres équipements) comme, par exemple, SNMP[Sfdc90]. Les ressources matérielles (routeur, pont ) sont instrumentées pour fournir des informations sur leur état et pour permettre aux administrateurs d agir dessus. Cependant, ces solutions d administration ne sont pas adaptées à l administration d applications réparties comme nous le verrons dans l état de l art qui été effectué dans le cadre de cette thèse. Au cours de ces dernières années, une approche novatrice pour la conception d applications a peu à peu vu le jour. Cette approche est fondée sur le concept de composant et sur une méthodologie de construction par assemblage de composants. Dans cette approche les applications réparties sont construites en assemblant des briques de bases appelées composants. Ces composants peuvent être soit des morceaux d applications pré-existantes soit du logiciel écrit à partir de rien. 12

13 Chapitre I : Introduction Avec cette approche le cycle de vie d une application répartie implique différents intervenants : Les architectes de l application doivent, en premier lieu, spécifier l application et identifier les composants (à divers niveaux de granularité). Les programmeurs ont la charge de réaliser les composants constituant les briques de bases de l application. Les intégrateurs, doivent pour leur part assembler l application à partir de divers composants de bases et en intégrant éventuellement des morceaux d applications pré-existantes. Les administrateurs doivent déployer l application et y apporter des modifications en cours d exécution pour satisfaire les besoins des utilisateurs finaux. Ces différents intervenants constituent des métiers différents et éventuellement des sociétés différentes. On comprend dés lors l importance d un modèle de conception fédérateur permettant à ces divers intervenants de coopérer. La figure suivante illustre le cycle de vie d une application : Figure 1: Cycle de vie d une application Pour pouvoir fournir les opérations de contrôle adaptées à l administration d applications réparties, les différents intervenants participant à la construction de l application doivent prévoir, dés la conception, l infrastructure de contrôle adaptées aux besoins de l application. Ceci requièrt une méthode permettant de prendre en compte la tache d administration tout au long du cycle de vie de l application. Cette méthode doit permettre de concevoir les applications en vue de leur administration et de les administrer une fois l application en cours d exploitation. L objectif du projet OLAN au sein du laboratoire SIRAC est de définir une telle méthode et de définir les outils correspondants. Le projet OLAN est issu des travaux menés par Luc Bellissard[Bel96] sur la programmation constructive, dénommée aussi programmation par composition de logiciels. Ce projet porte sur la construction, l exécution et l administration d applications réparties. Le fil directeur de ce travail est de profiter des avantages d'une architecture clairement explicitée pour cacher la complexité de programmation de telles applications et pour produire un modèle de l application permettant, entre 13

14 Chapitre I : Introduction autres, de représenter sa structure sous la forme des composants qui la constituent. Le projet OLAN définit une méthode globale constituée des éléments suivants : Un modèle d application à base de composants reposant sur un langage de description d architecture, l ADL OLAN. Les langages de définition d'architecture (Architectural Definition Languages, ADL) se distinguent des langages de programmation classiques par leur objectif premier qui est d'aider les concepteurs de systèmes à structurer et composer leurs éléments logiciels pour former des applications. Ces langages permettent de remonter de manière compréhensible et synthétique l architecture d'un système logiciel tout en ouvrant des portes à une certaine souplesse d'évolution des applications. Un ensemble d outils associés facilitant la construction et l administration des applications. Une infrastructure d administration à l exécution. L objectif de cette thèse est d apporter une contribution à cette méthode en appliquant les principes de la programmation par composition pour faciliter la construction des applications réparties et des infrastructures d administration correspondantes. L infrastructure d administration associée à une application est elle même une application répartie de grande complexité et de grande taille. Notre contribution doit permettre de faciliter la construction des applications réparties et de prévoir, dès la conception de l application, l infrastructure d administration adaptée aux besoins de l application. Mon travail a consisté à étendre les résultats du travail de Luc Bellissard pour prendre en compte l administration des applications. Ce travail se situe au niveau de l ADL OLAN et de l infrastructure à l exécution. L idée centrale est de définir un modèle de l application représentant les informations fondamentales qui sont partagées entre le développement de l application et les différents aspects de l administration effectués durant les phases du cycle de vie de l application. Le modèle est un point de transition, un pivot entre la construction d une application et son administration. Il permet d assurer une continuité entre la phase de construction de l application et son administration. Grâce à ce modèle, les concepteurs vont pouvoir dériver l infrastructure d administration adaptée au besoin de l application et les administrateurs vont pouvoir plus simplement prendre en compte la complexité des applications de grande taille et les administrer de façon cohérente au travers de l infrastructure d administration. La contribution de cette thèse porte plus particulièrement sur : Les extensions apportées au modèle d applications à base de composants pour prendre en compte la fonction d administration durant la phase de conception de l application. Ces extensions sont apportées au niveau de l ADL OLAN pour permettre de décrire d une part des composants administrables et d autres part des composants de contrôle (appelés contrôleur) formant l infrastructure d administration de l application. Les composants administrables forment l instrumentation de base de l application permettant son administration alors que les contrôleurs forment le niveau de contrôle renfermant la logique d administration de l application. La mise en œuvre de l infrastructure d administration correspondante à l exécution. On propose pour cela un modèle de composants administrables et de contrôleurs. On explicite le passage de la description de l architecture de l application à sa mise en œuvre sous la forme de composants administrables et de contrôleurs. On décrit les mécanismes de déploiement, de surveillance et de reconfiguration constituant l infrastructure d administration. 14

15 Chapitre I : Introduction La suite de ce chapitre est organisée de la manière suivante. Nous présentons tout d abord les différents paradigmes liés à l administration. Pour cela nous examinerons les différentes fonctions d administration telles qu elles sont définies dans CMIP[Sta93], le modèle d administration de l OSI (Open System Interconnexion). Enfin nous présenterons les différents niveaux d administration. Nous discuterons ensuite plus particulièrement de l administration d applications réparties. Pour cela nous étudierons les différentes caractéristiques des applications réparties et les problèmes d administration inhérents. Pour finir, nous préciserons la définition de la gestion de configuration de l OSI dans le contexte des applications réparties. 1 Qu est que l administration 1.1 Les fonctions d administration L administration est une vaste activité qui recouvre de nombreux aspects différents. Le modèle OSI [Kle88] tente de séparer la tache d administration en différentes fonctions administratives. Les principales fonctions définies par l OSI sont les suivantes : La gestion des performances Il est crucial, dans les systèmes actuels, de prendre en compte la qualité de service demandée par les utilisateurs et exigée pour les applications. Le rôle de la gestion des performances consiste à évaluer et à optimiser la qualité de service d un système pour permettre un fonctionnement acceptable. Des exemples de gestion de performances seraient le réglage du débit d un réseau ou le temps de réponse moyen d accès à une base de donnée. La gestion des pannes Durant la vie d un système, de nombreuses pannes peuvent survenir et porter atteinte à son fonctionnement. La fonction de gestion des pannes s occupe de la détection et de l identification des erreurs survenant dans un système. Idéalement, lorsqu une faute se produit, celle ci doit être détectée et confinée pour empêcher sa propagation. L erreur doit ensuite être traitée soit par le système soit par un administrateur. La gestion de la sécurité L ensemble des ressources d un système ne sont pas forcement mises à disposition de tous les utilisateurs. La sécurité dans les systèmes distribués a pour rôle de permettre l accès aux ressources du système aux seuls utilisateurs autorisés. La fonction de sécurité englobe l ensemble des mécanismes de sécurité au sein du système. Cela comprend des activités comme la surveillance des violations d accès, la gestion des informations d accès et des clés de cryptage. Audit et facturation Certaines des ressources ne sont pas accessibles gratuitement. Une fonction importante d administration est la gestion de la comptabilité. Cette activité a pour rôle de surveiller l utilisation des ressources du système et de facturer cette utilisation aux utilisateurs correspondants. Outre la facturation, cette activité permet de gérer une répartition équitable des ressources en fonction des utilisateurs et de leurs privilèges respectifs. 15

16 Chapitre I : Introduction La gestion de la configuration Dans le contexte de l ISO, la gestion de configuration a pour rôle d initialiser le système et de permettre la modification de l état des ressources composant le système. Dans le cas de ressource matérielle, cette fonction peut permettre, par exemple, de fixer la taille d un tampon réseau ou passer une imprimante d un état hors ligne à celui en ligne. Dans le cas de ressources logicielles comme une application répartie, la fonction de configuration doit permettre de manipuler sa structure interne et de modifier son état en cours d exécution. 1.2 Modèle de base d administration Les différentes fonctions d administration présentées auparavant sont fortement liées entre elles. L évaluation des performances d un réseau, par exemple, peut entraîner le changement de configuration d un routeur. Toutes ces fonctions d administration se basent sur une activité d observation du système à administrer. Le modèle de base d administration présenté par sloman[slo94] définit les notions de gestionnaire (manager) et d objets administrables (managed object). Un objet administrable est une ressource matérielle ou logicielle pouvant être administrée par un manager. Ces objets sont instrumentés pour pouvoir être surveillés et administrés. Ils doivent fournir une interface d administration permettant aux managers de les manipuler. Un objet administrable doit être spécifié comme tel lors de sa conception. Il est donc fondamental de prendre en compte les besoins d administration d un système lors de sa conception. Les managers, pour leur part, sont soit des administrateurs humains soit des contrôleurs logiciels contenant la logique requise pour effectuer des opérations d administration bien identifiées. Ils reçoivent des informations sur les objets administrables dont ils ont la charge via divers moyens de surveillance. A partir de ces informations, les managers peuvent prendre les décisions adéquates et effectuer des opérations de contrôle sur les objets administrables. Les managers et les objets administrables interagissent via un service de surveillance et de contrôle permettant au manager de recevoir des informations sur les objets administrables et de les administrer en conséquence. La figure suivante illustre ce cycle d administration ainsi que les relations entre manager et objet administrable. Manager Service de contrôle Service de surveillance Objet Administrable Figure 2 : Le cycle d administration 16

17 Chapitre I : Introduction 1.3 Les différents niveaux d administration On constate que les fonctions d administration sont utilisées pour gérer divers types de ressources. On identifie trois catégories de ressources correspondant à différents niveaux d administration : Le système d exploitation, l infrastructure réseau et les applications (ou service). L ensemble des fonctions d administration sont présentes aux différents niveaux d administration. Administration de système Ce type d administration manipule des abstractions de niveau système comme le système de fichiers, l ordonnanceur de tâche ou le mécanisme de pagination etc. Les administrateurs systèmes doivent gérer les utilisateurs, les sauvegardes, la facturation de l utilisation des diverses ressources du système et les performances globales du système Des exemples d administration sont le réglage des stratégies d allocation de la mémoire, du disque ou de l ordonnanceur (scheduler) des tâches. Administration réseau Les infrastructures d administration de niveau réseau s occupent principalement de la gestion des communications et du matériel intervenant dans les couches basses du réseau comme les ponts, les répéteurs ou les routeurs. Ces divers matériels sont instrumentés pour répondre aux requêtes d administration. Il s agit de régler les divers paramètres de ces dispositifs permettant une utilisation correcte et performante du réseau. Les tâches d administration communes de ce niveau sont, par exemple, de mesurer et de surveiller l activité IP, les connections TCP, de déterminer quel équipement réseau est opérationnel ou encore de produire une carte de la topologie des réseaux et des sous-réseaux. Administration d application Ce niveau d administration doit permettre d observer et d agir sur les applications. Les administrateurs doivent, par exemple, gérer l évolution des besoins des usagers, la disponibilité de l application, la cohérence des données manipulées etc. Les abstractions manipulées à ce niveau sont les diverses ressources logicielles qui composent l application. Ces ressources peuvent être de diverses granularités comme, par exemple, une base de donnée, un serveur WEB, un composant de filtrage dans un logiciel de pare-feu, etc. Les tâches d administration de ce niveau sont, par exemple, la mise à jour de la version d un logiciel, la migration de logiciel sur d autres sites d exécution ou bien l extension d une application pour lui permettre de prendre en compte de nouvelles fonctionnalités ou pour traiter de nouveaux types de données. L administration des applications diffère des autres types d administration par le fait qu elle implique de multiples intervenants ayant des rôles très différents dans la gestion du cycle de vie de l application. 2 Administration d applications réparties Notre travail a pour objectif de fournir des solutions pour la construction d une infrastructure d administration d application répartie. Cette thèse se focalise sur la fonction de gestion de configuration. Cette fonction a été définie initialement dans le contexte de l administration de réseau. Différents protocoles de gestion de configuration ont été développés pour l administration réseau. Cependant, comme nous le verrons, ces protocoles sont trop spécifiques à l administration réseau et les opérations de contrôle fournies sont trop limitées pour la configuration d applications réparties. Les administrateurs doivent disposer d opérations plus évoluées leur permettant de gérer facilement la 17

18 Chapitre I : Introduction complexité de l application administrée et la faire évoluer correctement. Les paragraphes suivants présentent les caractéristiques propres aux applications réparties ainsi que les problèmes liés à l administration d applications réparties. Enfin, nous préciserons la définition de la gestion de configuration de l OSI dans le contexte des applications réparties. 2.1 Caractéristiques des applications réparties Ce paragraphe présente les caractéristiques liées aux applications réparties. Ces applications sont construites à l aide de composants logiciels qui coopèrent au travers d un réseau. Ces différents composants logiciels peuvent s exécuter sur des machines très hétérogènes comme des PC ou des PDA (personnal digital assistant) et utiliser des réseaux issus de diverses technologies comme les réseaux locaux, les satellites ou, tout simplement, le réseau téléphonique commuté. L utilisation de médiums de communication non fiables et non sécurisés rend ces applications très sensibles aux pannes et aux attaques. L occurrence d une panne machine ou réseau peut faire basculer l application dans un état d erreur et la rendre indisponible pour les besoins des usagers. Ce point est crucial car les applications réparties doivent souvent assurer un minimum de qualité de service pour ses multiples utilisateurs. Ces dernières années, le succès d Internet a encouragé le développement d applications réparties de plus en plus large. Les ordres de grandeur pour ces applications peuvent atteindre des centaines de milliers de composants logiciel et matériel. Ceci a eu pour incidence de complexifier l architecture de ces applications et d accroître leur nombre d utilisateurs. On constate, de plus, que ces applications sont construites en utilisant des composants programmés à l aide de diverses technologies. Cette hétérogénéité des logiciels rend ces applications difficiles à concevoir à cause de l effort d intégration requis pour assembler les composants. De plus, pour de nombreuses d applications réparties, l usager devient une entité mobile en se déplaçant avec son outil de travail ou en requérant les services de l application à divers emplacements géographiques. 2.2 Problèmes liés à l administration d application réparties L administration d application répartie est une activité complexe par rapport au contrôle d une application centralisé. Ceci est lié aux caractéristiques des applications réparties présentées au paragraphe précèdent. On constate que l infrastructure d administration nécessaire au contrôle d une application répartie est elle même une application répartie. C est pourquoi, l application d administration hérite des même contraintes que celles liées aux applications réparties. Vulnérabilité aux pannes Toutes les applications sont sujettes aux pannes. Dans le cas des applications réparties cette vulnérabilité est accrue par le problème de fiabilité et d hétérogénéité des réseaux. La distribution géographique rend le recouvrement des erreurs difficile. L infrastructure d administration est sujette aux pannes réseau du fait qu elle utilise ce médium de communication pour contrôler les ressources distantes. Elle a donc les mêmes problèmes de tolérance aux fautes qu une application répartie normale et doit préserver la cohérence de l application malgré l occurrence de pannes pendant une opération d administration. Par conséquent, l infrastructure d administration doit assurer la fiabilité des opérations d administration et proposer des opérations permettant de défaire les modifications effectuées. 18

19 Chapitre I : Introduction Hétérogénéité des machines, des réseaux, des logiciels Une application répartie peut être construite à partir de plusieurs applications préexistantes (réparties ou non) développées indépendamment les unes des autres à l aide de diverses technologies. L infrastructure d administration doit pouvoir contrôler et coordonner les divers composants à administrer malgré les divers modes de communication utilisés et les différents types de matériel et réseau mis en jeu. Il est donc crucial pour l infrastructure d administration de prendre en compte l hétérogénéité des machines et des réseaux ainsi que celle des composants logiciels à administrer. Ceci implique que l infrastructure d administration doit être capable de gérer des composants construits avec diverses technologies et s exécutant sur divers matériels ou réseau. Dimension des applications Les progrès technologiques effectués dans le domaine des réseaux encouragent les entreprises à construire de plus en plus d application réparties. La complexité des services requis par les utilisateurs nécessite des applications faisant coopérer un grand nombre de composants logiciels et de machines. Les infrastructures de contrôle associées sont elles même des applications réparties à grande échelle. La dimension des applications implique qu elles soient administrées par de nombreux administrateurs simultanément coopérant pour accomplir certaines tâches administratives. L infrastructure d administration doit assurer la concurrence de nombreuses opérations de contrôle et doit toujours être disponible pour les administrateurs. Dans certains cas, le nombre d événements se produisant dans une application est trop important pour pouvoir être traiter uniquement par des administrateurs humains. Il est crucial pour l infrastructure d administration de pouvoir détecter des événements bien identifiés et d y réagir automatiquement en reconfigurant l application. L infrastructure d administration doit pouvoir passer à l échelle et être disponible pour les administrateurs. Elle doit permettre aussi la construction d applications auto-adaptables. L ensemble des opérations d administration doivent donc être pilotées interactivement par des administrateurs ou automatisées par l application. Administrer une application répartie de grande taille requièrt une infrastructure d administration adéquate. Cette infrastructure d administration est elle même une application répartie de grande taille, complexe à mettre en œuvre. Cohérence des applications Les applications réparties actuelles ont souvent une architecture complexe composée de nombreuses briques logicielles interopérantes. Cette complexité rend difficile la construction d une vision cohérente de l application en cours d exécution. De plus, il est très difficile d assurer et de vérifier que les opérations de contrôle maintiennent l application dans un état cohérent. L infrastructure d administration doit avoir accès à une vision de l architecture de l application et doit maintenir cette vison en fonction des changements effectués sur l application. De plus, les opérations d administration ne doivent pas violer la cohérence de l application administrée. Ceci implique de définir des abstractions permettant de modéliser une application et de la faire évoluer. De notre point de vue, assurer la cohérence du logiciel lors d une opération d administration est l aspect de l administration le plus difficile à prendre en compte. Sécurité Les opérations d administration donnent des pouvoirs importants aux administrateurs. L ensemble de ces opérations ne doivent pas être disponibles à des personnes non autorisées 19

20 Chapitre I : Introduction sous peine de compromettre la sécurité et l intégrité des applications. De plus, l ensemble des administrateurs n ont certainement pas tous les même droits de contrôle sur une application. Par conséquent, les utilisateurs d un service d administration doivent être sujets à authentification et autorisation. 2.3 Gestion de configuration d applications réparties La gestion de configuration au niveau applicatif reste un problème ouvert pour lequel il n existe pas de solutions satisfaisantes. Cette thèse se focalise sur la fonction de gestion de configuration. Cette fonction a été définie initialement par l OSI dans le contexte de l administration de réseau. Nous définissons la gestion de configuration dans le cadre des applications réparties comme étant l activité de configurer initialement le logiciel, à le surveiller puis à le reconfigurer. La configuration est l action d instancier les divers composants de l application, de les initialiser et de démarrer l application. La surveillance consiste à espionner l état des composants, leurs communications et leur performance. La reconfiguration, pour sa part, doit permettre de manipuler la structure interne et de modifier l état d une application en cours d exécution Configuration de logiciels réparties La configuration de logiciel consiste à fournir un modèle initial de l application, de le déployer et de démarrer l application. Le modèle de l application doit fournir suffisamment d informations sur les composants participant à l application et sur leur état initial pour permettre leur déploiement. On appelle déploiement l action d installer, d instancier et d initialiser les divers composants de l application puis de démarrer leur exécution. Le déploiement nécessite en particulier des informations sur le placement des différents composants sur leurs sites d exécution Surveillance de logiciel répartie Le service de surveillance est une brique importante dans l infrastructure d administration. Il est utilisé dans le cadre de toutes les fonctions d administration définies par l OSI. Dans le cadre de la gestion de configuration, ce service fournit des informations pertinentes sur les différents composants de l application, leurs communications et sur tout événement en rapport avec la configuration de l application. A partir de ces informations, l infrastructure d administration peut entraîner une reconfiguration de l application. L activité de surveillance d une application répartie, décrite dans [Mms96], comporte les quatre tâches suivantes : Génération Il s agit de la production des informations relatives à l état des composants de l application et de leurs communications. Collecte et traitement Cette tâche a pour rôle de filtrer et de stoker les informations produites. Délivrance Les informations produites par le service de surveillance sont acheminées à leur destinataire (utilisateurs ou agents administratifs). 20

21 Chapitre I : Introduction Présentation Les informations sont affichées aux utilisateurs finaux suivant le format demandé (représentation textuelle, graphes, diagrammes temporels) Reconfiguration de logiciels réparties La reconfiguration est une activité fondamentale pour l administration car elle donne le pouvoir aux administrateurs d agir sur les applications. Une opération de reconfiguration consiste à adapter une application pour prendre en compte de nouveaux besoins ou de nouvelles contraintes. Ceci permet de faire passer une application d une configuration i à une configuration i+1. Une reconfiguration peut être initiée soit par un administrateur, soit par l application elle-même en réaction à des événements de surveillance. On définit deux types de reconfiguration : la reconfiguration statique et dynamique. La reconfiguration statique Une opération de reconfiguration est dite «statique» quand elle nécessite l arrêt de l application pour pouvoir être appliquée. Ce type de reconfiguration n est pas forcement adapté à toutes les applications réparties. Certaines applications sont difficiles à arrêter de manière cohérente et doivent être perturbées le moins possible lors d une opération de reconfiguration. L arrêt d une application pour la reconfigurer affecte grandement sa disponibilité. La reconfiguration dynamique Une opération de reconfiguration est dite «dynamique» lorsqu elle peut être effectuée en cours d exécution, sans arrêter l application. On peut définir la reconfiguration dynamique comme étant l ensemble des changements que l on peut appliquer à une application en cours d exécution. Une opération de reconfiguration doit permettre d effectuer des changements sur les parties d application concernées sans perturber la totalité du système. Ceci fait de la reconfiguration dynamique une brique de base pour l administration étant donné que certaines opérations d administration nécessitent d être effectuées en cours d exécution. Au cours de nos travaux nous avons privilégié les opérations de reconfiguration dynamique étant donné qu elles englobent l ensemble des problèmes liés à la reconfiguration. De plus, la reconfiguration statique n est pas suffisante pour satisfaire l ensemble des besoins requis pour la gestion de configuration d applications réparties. 3 Plan Ce chapitre a introduit les notions fondamentales d administration et a motivé les besoins de gestion de configuration pour les applications réparties. Nous avons présenté les caractéristiques des applications réparties et les problèmes d administration associés. Pour finir, nous avons précisé la définition de l OSI en définissant la gestion de configuration d une application répartie comme étant une activité consistant à configurer initialement le logiciel, à surveiller son exécution et à le reconfigurer. Le chapitre 2 présente un état de l art sur les solutions d administration actuelles. Le chapitre 3 brosse un aperçu général de la méthode OLAN puis présente en détail les extensions apportées au langage de description OLAN dans le cadre de l administration ainsi que l infrastructure de contrôle associée. On montrera la correspondance entre les notions décrites à l aide du langage de 21

22 Chapitre I : Introduction description d architecture et l infrastructure à l exécution. Nous expliciterons dans ce chapitre l impact de notre solution d administration sur la programmation des applications réparties. Dans cette section nous verrons comment dériver l infrastructure d administration du modèle de l application. Le chapitre 4 sera entièrement consacré aux algorithmes de reconfiguration d applications réparties. Un des problèmes majeurs liés à la reconfiguration est d assurer la cohérence de l application vis à vis de la reconfiguration tout en minimisant l impact de cette reconfiguration sur les performances de l application. Dans cette section, nous définissons la notion de cohérence d une application, nous identifions précisément les problèmes pouvant rendre une application incohérente suite à sa reconfiguration et enfin nous proposons des algorithmes permettant de reconfigurer de manière cohérente une application. Nous verrons comment il est possible de prévoir les opérations de reconfiguration dés la conception de l application. Le chapitre 5 fournit des scénarios d utilisation de l infrastructure d administration. Ces scénarios montreront les intérêts et les inconvénients de notre solution. Nous finirons ce chapitre par une évaluation et une analyse critique de notre solution. Le chapitre 6 conclut le rapport. 22

23 II Etude des solutions d administration

24 Chapitre II : Etat de l art L'objectif de ce chapitre est de brosser un aperçu des différentes solutions d administration actuelles. L administration est une étape importante dans le cycle de vie d une application. Elle permet de modifier une application en cours d exécution ou d effectuer des opérations de maintenance pour satisfaire les besoins de leurs utilisateurs ou pour prendre en compte la modification de leur environnement d exécution. L administration d application permet d effectuer les divers réglages et mise au point sur une application qui sont requis en cours d exploitation. Cette phase d administration est effectuée par des administrateurs au travers d une infrastructure de contrôle. Dans le cas de l administration d application cette infrastructure est elle même une application répartie de complexité significative. Il est nécessaire de prévoir des la conception de l application les opérations d administration qui seront disponibles aux administrateurs. L administration d application met en jeu de multiples intervenants qui participent au cycle de vie de l application. Chacun de ces intervenants va devoir prévoir à son niveau la fonction d administration. L état de l art que nous avons effectué est divisé en 2 parties : La première partie présente les solutions d administration en vigueur dans les milieux industriels. A ce titre, nous étudierons SNMP et JMX. Bien que SNMP ne soit pas conçu pour l administration d applications réparties, son étude est importante du fait qu il est exploité depuis longtemps dans le cadre de l administration d équipement. Cette expérience ne peut être que bénéfique pour l administration d applications réparties. Puis nous étudierons JMX (Java Management Extension). JMX est un premier pas vers l administration d application car il présente les différents intervenants participant au cycle de vie des applications et identifie leur rôle respectif vis à vis de l administration. Cependant il reste des problèmes que nous allons détailler au cours de cette étude. Ensuite nous allons présenter des patrons d objets administrables. Ces patrons permettent de spécialiser une infrastructure d administration standard pour répondre aux besoins spécifiques de chaque application mais présentent quelques lacunes dans la modélisations des applications. Enfin nous étudierons des langages de description d applications distribuées qui se prêtent à la modélisation de ces applications. Pour finir nous ferons une synthèse de cet état de l art, nous discuterons de l intérêt d une approche mixte mêlant un patron d objet administrable et un langage de description d application puis nous en tirerons des conclusions. 1 Solutions Industrielles On présente ici les solutions d administration issues des milieux industriels. On examine plus particulièrement SNMP permettant l administration de systèmes distribués et JMX permettant l administration d applications et de réseaux. Nous ne présenterons pas le protocole CMIP de l OSI étant donné qu il est proche de SNMP et qu il est largement moins utilisé que ce dernier. 1.1 SNMP A partir de 1970, les réseaux d ordinateurs ont commencé à grandir considérablement. Des réseaux qui étaient jusqu alors séparés se sont regroupés dans un réseau de plus en plus large ; l Internet. Face à la croissance de ce réseau, il est devenu évident qu une solution de gestion de réseaux devait être développé. Dans la suite, nous présentons SNMP (Simple Network Management Protocol) qui a été le premier protocole utilisé pour administrer des systèmes distribués à large échelle. Ce standard permet de manipuler des appareils réseaux à distance (comme des ponts, des routeurs ). Pour cela, SNMP requièrt que ces appareils soient modélisés sous la forme d objets administrables. Un appareil du réseau est donc vu comme un ensemble de variables qui peuvent être lues (supervision) et/ou modifiées (contrôle). Un administrateur peut surveiller et modifier ces différents attributs au travers d une station d administration. D autre part lorsqu un événement important se produit, un objet administré peut avertir la station de management. 24

25 Chapitre II : Etat de l art Architecture L architecture d administration proposée par SNMP est composée des éléments suivants : Une station d administration qui contient les applications administratives (traitement d erreur ). Un agent d administration sur chaque appareil réseau (hub, switch, routeur ) ou/et sur chaque station du travail. Un agent a pour charge de répondre aux requêtes envoyées par la station d administration et de gérer les événements exceptionnels pouvant se produire sur l appareil réseau qu il contrôle. Une base de donnée administrative (MIB) par station administrée (donc par agent). La MIB décrit l ensemble des objets et leur attributs représentant les appareils administrés qui résident sur cette station. Un protocole de communication entre la station d administration et les agents. Ce protocole définit le dialogue entre la station d administration et un agent pour connaître l état d un appareil, le configurer, effectuer des mesures ou bien encore gérer certains événements exceptionnels. La figure suivante illustre l architecture de SNMP : Figure 3 : L architecture SNMP Protocole SNMP Le protocole SNMP est basé sur l échange de messages entre l appareil à surveiller et la station d administration. La station d administration peut émettre des messages vers un agent pour lire ou modifier les valeurs des appareils associés. Inversement, un agent peut envoyer un message vers la station d administration pour lui notifier l occurrence d un événement exceptionnel. Les messages, appelés Process Data Unit (PDU), sont transmis via le protocole de transport UDP. Par conséquent, les PDUs échangés entre la station d administration et l agent sont des datagrammes sans garantie d arrivée. Si une réponse à une requête tarde, la station d administration doit ré-émettre sa requête. 25

26 Chapitre II : Etat de l art Le protocole SNMP définit 5 types de messages : Get-request Requête de lecture d un attribut. L agent SNMP concerné va retourner à la station d administration un message de type get-response contenant la valeur de l attribut. Get-next-request Permet d inspecter le nom des attributs des objets présents dans la MIB. Set-request Cette requête permet de modifier la valeur d un attribut et donc le comportement de l appareil associé. Get-response Ce message correspond à une réponse de l agent aux requêtes précédentes. Trap Ce message est émis par un agent vers la station d administration lorsqu un événement se produit sur un des appareils gérés par l agent. L événement est identifié par un code de type entier Structure de la MIB Dans SNMP, les appareils réseaux sont modélisés sous la forme d objets administrés. Ces objets décrivent principalement l ensemble des variables d état accessible sur un appareil. Ils sont décrits en utilisant la notation ASN.1[Kal91] qui est un langage formel spécifié par le CCITT et l ISO. Chaque appareil administré maintient une base de donnée, appelé MIB, qui contient les définitions et les valeurs des objets administrés correspondants. Une MIB SNMP est organisée sous la forme d un arbre de manière similaire à un système de gestion de fichiers. SNMP définit une MIB standard dans le rfc Cette MIB doit être supportée par tous les appareils réseaux administrés par SNMP. Cette MIB définit notamment des objets permettant de mesurer et de surveiller l activité d IP, de TCP, d UDP, des interfaces matérielles. La MIB standard est généralement étendue par les constructeurs d équipement pour prendre en compte leurs besoins spécifiques. Chaque objet de la MIB possède un identificateur, un type et une valeur. L identificateur d un objet est unique pour une machine donnée. Il est construit sous la forme d une séquence d entier obtenu en ajoutant un entier à l identificateur de l objet supérieur dans la hiérarchie. Ainsi l objet associé à l activité du protocole IP a pour identificateur

27 Chapitre II : Etat de l art La figure suivante montre les premiers niveaux de la hiérarchie de la MIB : Figure 4 : Organisation de la MIB de SNMP Conclusion SNMP a été un des premiers protocoles permettant d administrer des réseaux. Ces principaux avantages sont liés à sa simplicité. Les constructeurs de matériels peuvent instrumenter leurs appareils avec un minimum d effort. D autre part, les administrateurs peuvent très rapidement prendre en main ce protocole. SNMP permet d effectuer les taches de base d administration en perturbant très peu les appareils et les réseaux administrés. Les ressources nécessaires pour mettre en place une infrastructure d administration basée sur SNMP sont peu importantes. Ceci a fait que le protocole SNMP s est très largement répandu et continue d être utilisé intensivement. La plupart des constructeurs de matériel réseau conçoivent leur matériel pour qu ils supportent SNMP. Malheureusement la simplicité du protocole SNMP implique aussi des inconvénients. Une déficience importante de SNMP est la sécurité. Il existe des trous de sécurité permettant à un intrus d accéder aux informations transitant sur le réseau et aux fonctions d administration des appareils. Une autres déficience de SNMP concerne son manque d automatisation. En effet les opérations d administration doivent être déclenchées manuellement par un administrateur. SNMP ne définit pas de méthodes permettant d automatiser certaines taches bien identifiées. Ceci est problématique pour les administrateurs devant contrôler des réseaux étendus composés de nombreux appareils. Par ailleurs SNMP ne propose pas d algorithme de déploiement et de reconfiguration. Les opérations d administrations doivent être mises en œuvre à la main. Le développement des agents SNMP et la cohérence de ces opérations d administration sont laissé à la charge du programmeur. Le langage ASN1, utilisé pour modéliser les ressources administrées, n est pas adapté à la modélisation d application réparties. Avec ce type de modélisation les administrateurs ont du mal à appréhender la structure complexe des applications réparties en cours d exécution. Cette 27