Soutenance mémoire
Les défis de l’administration d’applications réparties
Les systèmes informatiques modernes intègrent un nombre croissant de processeurs hétérogènes interconnectés par des réseaux aux caractéristiques diverses comme les réseaux locaux, les satellites ou le réseau téléphonique commuté. Cette diversification des équipements engendre une complexification des applications réparties modernes. Celles-ci sont aujourd’hui constituées d’un grand nombre de composants logiciels développés de façon indépendante. Les environnements actuels sont également caractérisés par un dynamisme croissant, qu’il soit des utilisateurs, de leurs besoins ou encore des caractéristiques physiques du système sur lequel est déployée l’application. Pour faire face à cette évolution des systèmes informatiques, il est primordial de développer des systèmes d’administration prenant en charge différentes fonctions.
– Configuration et déploiement : la première tâche de l’administration consiste à configurer et à déployer le système. Cela veut dire choisir et assembler les composants du système et les placer sur des sites physiques. Le système de déploiement doit gérer le code des composants depuis la phase d’empaquetage jusqu’au chargement et à l’instanciation des composants. Il doit également fournir des mécanismes pour la mise à jour de code.
– Réparation des pannes : l’occurrence d’une panne (machine, réseau ou logicielle) peut faire basculer l’application dans un état d’erreur et la rendre indisponible pour les besoins des usagers. L’application n’est alors plus à même d’assurer le minimum de qualité de service requis par ses utilisateurs. Il est donc important de réparer le système de façon à le ramener à la configuration qu’il avait avant la panne.
– Gestion des variations de performances : les systèmes doivent assurer une certaine qualité de service. Ils doivent, par conséquent, être adaptés aux différentes variations de performances et aux pics de charge.
– Gestion des ressources : les ressources utilisées dans un système, comme les processeurs, les systèmes de stockage, les E/S et la bande passante des réseaux peuvent être partagées par plusieurs applications. La gestion des ressources qui a un impact important sur les performances doit tenir compte de la qualité de service et des priorités de chaque application.
– Gestion de la sécurité : un système informatique doit résister aux attaques malveillantes. Par conséquent, les acteurs impliqués dans un système (utilisateurs, administrateurs) doivent agir sous une ou plusieurs autorités. La mise en œuvre de ces fonctions d’administration est une tâche complexe. En effet, elle nécessite la prise en compte de différents facteurs.
– Complexité des systèmes administrés : les systèmes administrés doivent fournir à l’administrateur des interfaces permettant de les observer et de les adapter. Néanmoins, plusieurs systèmes, notamment les systèmes patrimoniaux dont la conception n’a pas pris en compte les besoins d’administration, ne facilitent pas la mise en œuvre de certaines reconfigurations. Il est nécessaire que le système d’administration crée des méta-niveaux et des abstractions exposant une vue plus exploitable du système administré.
– Distribution et passage à l’échelle : les systèmes distribués à grande échelle nécessitent des infrastructures adéquates pour permettre à l’administrateur d’accéder aux différentes parties du système. Pour satisfaire cette contrainte, les systèmes d’administration sont, aujourd’hui, des applications réparties à part entière pouvant être complexes. Ces systèmes d’administration nécessitent d’être configurés, déployés et adaptés aux événements extérieurs, au même titre que les systèmes administrés.
– Diminution du rôle de l’être humain : avec la complexité croissante des systèmes distribués modernes, les compétences des administrateurs humains montrent leurs limitations. De plus, le coût de l’administration devient de plus en plus important. Il devient donc nécessaire d’automatiser les fonctions de l’administration qui peuvent l’être. L’administration des couches basses (système d’exploitation, réseaux) a suscité beaucoup d’attention par le passé. En particulier, les travaux menés ont abouti à la création d’un standard largement utilisé, appelé SNMP(Simple Network Management Protocol). Dans cette thèse, nous nous intéressons à l’administration des intergiciels qui a fait l’objet de moins de travaux. Notre contribution se décompose en deux parties. D’une part, nous proposons une technique de construction de systèmes administrables. Un système administrable est un système sur lequel il est possible d’effectuer dynamiquement des opérations de gestion de configuration. D’autre part, nous proposons un système d’administration automatisant certaines fonctions de l’administration comme le déploiement, la mise à jour de code et la réparation des pannes. Ce système d’administration base ses actions sur une connaissance de l’architecture du système administré. Il est ainsi développé suivant le principe récemment proposé d’administration fondée sur l’architecture [DvdHT02]. Dans le cadre de nos expérimentations, nous avons appliqué les principes de l’administration fondée sur l’architecture aux serveurs d’applications J2EE. Ce choix a été motivé par deux raisons.
Administration de JonasALaCarte
Les outils de configuration et de déploiement utilisés dans les serveurs d’applications J2EE « libres », comme JOnAS [jon], JBoss [LF] et Geronimo [Mul04] sont généralement restreints à des scripts ad hoc. Ceci peut induire l’occurrence d’erreurs de configuration et nécessiter un temps considérable pour l’administrateur, notamment dans des environnements distribués de type grappe. Nous avons intégré dans JonasALaCarte le système d’administration introduit dans la section précédente. Ce système permet d’automatiser un grand nombre de fonctions d’administrations liées à la tolérance aux pannes et au redimensionnement du serveur. Il permet notamment de superviser de façon autonome le serveur J2EE grâce à l’utilisation de boucles de commande semblables à celles utilisées dans la théorie de la commande [Oga97]. L’architecture à composants du système d’administation permet d’intégrer des politiques d’administration sophistiquées sous la forme de composants.
Le modèle agent-gestionnaire et ses limitations
L’approche actuelle pour l’administration des systèmes et des réseaux s’inspire des standards définis entre 1988 et 1990 : le protocole SNMP (Simple Network Management Protocol) pour le monde Internet et les protocoles CMIS/CMIP (Common Management Information Services and Protocols) spécifiés par les organisations ISO et ITU principalement pour le domaine des Télécommunications. Ces standards permettent l’inter-opérabilité entre les différents vendeurs. Ils sont basés sur un même modèle générique, appelé modèle agent-gestionnaire. Les éléments de ce modèle sont présentés sur la figure 2.3. Le modèle repose sur les entités suivantes :
– Le gestionnaire agit en tant qu’interface pour l’administrateur humain. Il est généralement installé sur une machine dédiée à l’administration. Un gestionnaire peut intéragir avec un ou plusieurs agents.
– L’agent réside sur une machine administrée. Il est le délégué local du gestionnaire pour les objets administrés dont il consulte ou modifie l’état.
– La MIB (Management Information Base) définit l’organisation des objets administrés, ainsi que le modèle de données qui permet d’accéder à ces objets. Elle est utilisée à la fois par le gestionnaire et par les agents.
– Le protocole d’administration de gestion définit les interactions entre le gestionnaire et les agents. Le principe du modèle agent-gestionnaire est de séparer le système d’administration des entités administrées. Il a été spécifié pour satisfaire plusieurs fonctions de l’administration telles que la configuration, la sécurité, la tolérance aux fautes et l’observation. Le lecteur intéressé pourra se référer à [JPMF] pour avoir une liste plus détaillée sur ces systèmes d’administration. Par ailleurs, dans [SPMF] sont listées les perspectives sur l’évolution des technologies d’administration spécifiques à Internet. Une implantation typique de ce modèle est le standard SNMP (Simple Network Management Protocol) qui a été l’un des premiers protocoles permettant d’administrer des réseaux. Ses principaux avantages sont liés à sa simplicité. Les constructeurs de matériels peuvent superviser leurs appareils avec un minimum d’effort. SNMP permet d’effectuer les tâches 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 fait que le protocole SNMP s’est trés largement répandu et continue d’être utilisé intensivement. Néanmoins, le protocole SNMP présente plusieurs inconvénients. SNMP 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 tâches 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’administration doivent être mises en œuvre à la main. Le développement des agents SNMP et la cohérence des opérations d’administration sont laissés à la charge du programmeur. Le langage utilisé pour modéliser les ressources administrées, ASN1, n’est pas adapté à la modélisation d’applications 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 modélisation est orientée vers la spécification des protocoles de communication et non sur la spécification des applications réparties. De plus, les administrateurs n’ont pas à leur disposition une vision de la structure de l’application en cours d’exécution. Les défauts de SNMP peuvent être généralisés au modèle agent-gestionnaire. Ce modèle se base sur une architecture centralisée qui ne passe pas à l’échelle pour supporter la charge et pour résister aux fautes. Sa structure statique manque de flexibilité et ne peut donc s’adapter à la complexité ni à la dynamicité des applications réparties. De nouvelles tendances apparaissent au delà de ce modèle telles que l’administration basée sur l’architecture et l’administration autonome que nous décrivons dans les sections suivantes.
L’administration fondée sur l’architecture
L’architecture d’un système informatique décrit ce système en tant qu’assemblage de composants. Cette description se base en général sur un modèle servant à définir l’organisation du système et son fonctionnement. Le modèle d’un système sert à mieux le comprendre, à prédire son comportement et sert également à sa conception et à son implantation. La notion d’architecture des systèmes a été surtout exploitée pour la conception des systèmes et ce n’est que récemment qu’on s’est rendu compte qu’elle pourrait servir de base pour l’administration. En particulier, les parties identifiées du système peuvent être des unités de déploiement, d’isolation de faute et de reconfiguration. La notion d’administration fondée sur l’architecture traduit l’idée que les modèles d’architecture peuvent servir de base pour la construction des fonctions d’administration. Ce principe est de plus en plus utilisé grâce aux efforts récents pour développer des architectures dirigées par les modèles (model-driven architecture) [omg].
Nix
Nix [DJa04] est un canevas offrant plusieurs mécanismes de déploiement qui peuvent être utilisés afin de mettre en place des politiques de déploiement différentes. Ce canevas a été développé à l’université d’Utrecht. La principale contribution de Nix est un modèle pour un déploiement sûr et flexible, basé sur une analyse des dépendances entre les composants à déployer. La sûreté veut dire que toutes les dépendances sont satisfaites et la flexibilité veut dire la possibilité d’introduire un ensemble de politiques sans grande contrainte ainsi que la capacité du système à tolérer la coexistence de plusieurs versions d’un même composant. Au départ, il s’agit surtout de remédier aux problèmes de cohérence et d’incompatibilité de versions rencontrés par des outils d’installation centralisée de logiciel, tels que RPM. Ceci a conduit à une analyse rigoureuse du processus d’installation, et à des propositions novatrices pour sa mise en œuvre. L’approche proposée se base sur une analogie entre le déploiement de composants et la gestion de la mémoire [DVdJb04]. Deux problèmes majeurs sont identifiés.
– Les dépendances non résolues. A dépend de B (noté A->B) si le bon fonctionnement de A nécessite la présence de B. La fermeture d’un composant 2 de A (closure) est la fermeture transitive de la relation ->, issue de A, c’est à dire l’ensemble de composants dont A dépend (transitivement). Une dépendance n’est pas résolue lorsqu’un composant est déployé sans sa fermeture complète.
– Les conflits. Ceci fait référence au cas où deux versions différentes d’un même composant ne peuvent pas cohabiter parce qu’ils occupent la même place dans le système de fichiers. Comme le présente la figure 2.9 la solution proposée est basée sur l’organisation d’un référentiel des composants sous la forme d’un espace d’adressage. Chaque objet répertorié possède un nom global unique appelé store path, similaire à un nom symbolique dans un système de fichiers hiérarchique. Un composant est typiquement représenté par un répertoire sous lequel sont stockés tous ses éléments comme le code source, le code binaire, les librairies, etc. Un store path identifie un composant d’une manière unique et inclut également un préfixe qui représente un hachage cryptographique de tous les éléments constituant le composant. Ainsi, une modification dans l’un des composants entraine la création d’un nouveau store path. Afin de définir des dépendances, et donc de permettre aux fermetures d’être calculées, la règle suivante est appliquée: si un objet A dépend d’un objet B alors A contient le store path de B. Par exemple, les flèches de la figure 2.9(a) montrent les dépendances du composant subversion. La valeur de la fermeture correspondante est montrée dans la figure 2.9(b) comme étant un objet à part. Les fermetures sont déterminées automatiquement en interprétant les valeurs de dérivation. Par exemple, la valeur de dérivation utilisée pour définir la fermeture de subversion est représentées dans le rectangle en haut de la figure 2.10. Notons qu’une valeur de dérivation inclut un descripteur de déploiement (contenant par exemple, des noms de composants, une description de la plate-forme cible) et le programme des tâches de déploiement (sous la forme de scripts shell appellés builders dans Nix). Une valeur de dérivation est interprétée par l’équivalent d’un programme qui construit les fermetures et exécute les actions spécifiées par les builders. La forme des valeurs de dérivation telle que présentée dans les figures précedentes est en fait cachée aux clients en utilisant divers mécanismes. En effet, les valeurs de dérivation ne sont pas conçues pour être écrites à la main. Elles sont générées à partir d’un langage de plus haut niveau. Par ailleurs, le déploiement d’un composant suit un modèle fonctionnel (au sens des langages fonctionnels).
– Le résultat d’une opération ne dépend que de ses paramètres (si on recommence avec les mêmes paramètres, on a le même résultat). Par conséquent tous les paramètres sont explicites et il n’existe pas de dépendances cachées.
– Une fois le résultat obtenu, il ne change pas. Les opérations de déploiement sont exprimées sous forme fonctionnelle comme des « expressions Nix » (derivation expressions) dans un langage développé à cet effet. Une description complète du langage (syntaxe et sémantique) se trouve dans [Dol05].
|
Table des matières
Résumé
Abstract
Remerciements
1 Introduction
1.1 Les défis de l’administration d’applications réparties
1.2 Construction d’intergiciels administrables
1.2.1 Principe
1.2.2 JonasALaCarte : un serveur d’applications J2EE administrable
1.3 Construction de systèmes d’administration
1.3.1 Principe
1.3.2 Administration de JonasALaCarte
1.4 Évaluation
1.5 Organisation du document
2 L’administration des intergiciels
2.1 Introduction
2.2 Fonctions de l’administration
2.2.1 Configuration et déploiement
2.2.2 Observation
2.2.3 Reconfiguration
2.2.4 Gestion des ressources
2.2.5 Tolérance aux fautes
2.2.6 Sécurité
2.3 Les défis de l’administration et les solutions existantes
2.3.1 Le modèle agent-gestionnaire et ses limitations
2.3.2 L’administration fondée sur l’architecture
2.3.3 Vers une administration autonome
2.3.4 Synthèse
2.4 Systèmes d’administration fondés sur l’architecture
2.4.1 Rainbow
2.4.2 SmartFrog
2.4.3 Nix
2.5 Synthèse
3 Modèles de composants pour la construction de systèmes administrables
3.1 Quelle architecture adopter pour la construction de systèmes administrables?
3.2 Les EJB
3.3 CCM
3.4 OSGi
3.5 DCUP
3.6 Fractal
3.7 Synthèse
4 Administration de serveurs J2EE
4.1 Le standard J2EE
4.1.1 Le serveur HTTP
4.1.2 Le conteneur Web
4.1.3 Le conteneur d’EJB
4.1.4 La base de données
4.1.5 Synthèse
4.2 Architecture de serveurs d’applications J2EE
4.2.1 Configuration centralisée
4.2.2 Configuration distribuée
4.3 Les standards de l’administration de plates-formes J2EE
4.3.1 JMX
4.3.2 JSR77
4.3.3 JSR88
4.3.4 Synthèse
4.4 Administration des serveurs d’applications J2EE « libres »
4.4.1 JBoss
4.4.2 Geronimo
4.4.3 JOnAS
4.4.4 Synthèse
4.5 Les défis de l’administration de serveurs J2EE
4.6 Synthèse
5 Présentation de la contribution
5.1 Synthèse de l’état de l’art
5.1.1 Administration fondée sur l’architecture
5.1.2 Construction de systèmes administrables
5.1.3 Étude de cas : administration des serveurs d’applications J2EE
5.2 Présentation de la contribution
5.2.1 Construction de systèmes administrables
5.2.2 Système d’administration
5.2.3 Évaluation
5.3 Organisation des chapitres de la contribution
6 Construction de systèmes administrables : cas des serveurs d’applications patrimoniaux
6.1 Architecture de JOnAS
6.2 Réingénierie de JOnAS
6.2.1 Identification des parties à modifier dans JOnAS
6.2.2 « Fractalisation »de JOnAS
6.2.3 Empaquetage et chargement des classes des services
6.3 Mise en œuvre de la « fractalisation »
6.4 Généralisation de notre approche
6.5 Synthèse
7 Système d’administration fondée sur l’architecture
7.1 Besoins de l’administration des serveurs J2EE
7.1.1 Déploiement de l’intergiciel J2EE
7.1.2 Reconfiguration
7.2 Jade : un canevas réflexif pour l’administration fondée sur l’architecture
7.2.1 Architecture
7.2.2 Outils pour l’administration
7.3 Système de déploiement et de reconfiguration
7.3.1 Extension du composant SR
7.3.2 Système de déploiement
7.3.3 Reconfiguration
7.3.4 Synthèse
7.4 Administration dans JonasALaCarte
7.4.1 Déploiement d’une grappe J2EE
7.4.2 Mise à jour dynamique de code
7.4.3 Réparation automatique des pannes
7.5 Synthèse
8 Évaluation
8.1 Aspects qualitatifs
8.1.1 Compatibilité avec les standards
8.1.2 Pertinence du redémarrage partiel
8.1.3 Comparaison avec les travaux de l’état de l’art
8.2 Aspects quantitatifs
8.2.1 Point de vue du développeur JOnAS
8.2.2 Point de vue de l’administrateur
8.2.3 Évaluation des performances
8.3 Synthèse
9 Conclusion
9.1 Rappel de la problématique
9.2 Principaux apports
9.2.1 Construction de systèmes administrables
9.2.2 Construction de systèmes d’administration
9.3 Perspectives
9.3.1 Application de l’approche à un grain plus fin
9.3.2 Implantation d’autres politiques d’administration
9.3.3 Administration à grande échelle
Bibliographie
Télécharger le rapport complet
