Dans cette section, nous nous intéressons aux systèmes d'administration fondée sur l'architecture des systèmes administrés. Nous étudions dans un premier temps le canevas Rainbow [CHSS04], dont l'objectif est la gestion autonome des systèmes. Ensuite, nous présentons le canevas SmartFrog [GGL+03] qui a pour mission la gestion des applications dans un contexte de grilles.
3.4.1 Rainbow
Rainbow [CHSS04] est un canevas conçu pour la construction de systèmes auto-adaptables. Le point focal dans ce travail est la réalisation de la boucle de commande [OM03] telle qu'elle a été introduite dans les travaux de recherche sur les systèmes autonomes par IBM. Pour ce faire, il s'appuie sur une architecture orientée composants et une approche orientée ar-chitecture. Nous détaillons dans le reste de cette section le modèle à composants adopté et l'architecture d'administration résultante.
3.4.1.1 Le modèle à composants de Rainbow
Le modèle de composants utilisé dans ce travail est le modèle à composants spéci que au projet Rainbow [CHSS04]. Il s'agit d'un modèle qui permet de représenter le système administré d'une manière hiérarchique. Les liaisons entre les composants sont représentées sous forme de connecteurs. Dans le cas de composants composites (hiérarchiques), ces liaisons permettent d'exposer des interfaces internes au niveau d'un composant composite (parent).
Le principe de la gestion orientée par les composants consiste à modéliser d'une fa-çon abstraite les ressources à administrer sous forme de composants Rainbow. Le modèle abstrait est ensuite utilisé pendant la conception du système à l'aide d'un chier ADL (Ar-chitecture Description Langage). L'ADL est également consulté à l'exécution pour procéder à l'adaptation du système.
3.4.1.2 Architecture d'administration
De point de vue architecture, Rainbow distingue la couche d'administration de la couche du système administré pour permettre l'intégration de politiques d'administration indé-pendamment des mécanismes (e.g. sondes, canaux d'observation). Cette séparation permet également de réutiliser des parties de la couche d'administration pour diérents types de systèmes. La gure 3.5 résume les principaux éléments qui composent cette architecture.
Infrastructure de la couche système. A ce niveau, des interfaces d'accès sont implantées. Des sondes (probes) observent et mesurent les diérents états du système et des actionneurs (eectors) permettent la mise en place des modi cations souhaités par l'administrateur. De plus, un service de découverte peut être sollicité pour allouer des ressources à administrer suivant le type des ressources ou d'autres critères bien dé nis.
Infrastructure de la couche d'architecture. Des jauges (gauges) permettent d'agréger les informations envoyées par les sondes et de mettre à jour les propriétés appropriées dans le modèle d'architecture. Un gestionnaire de modèle (model ma-nager) traite les informations et accède au modèle d'information. Un évaluateur de contraintes (constraint evaluator) véri e périodiquement le modèle et détecte le be-soin d'une adaptation si une contrainte est violée. Une machine d'adaptation (adapta-tion engine) détermine l'ac(adapta-tion à eectuer et met à jour l'adapta(adapta-tion correspondante. Infrastructure de traduction. Cette couche établit la correspondance entre le mo-dèle et le système d'administration. Un dépôt dans l'infrastructure maintient la liste de correspondance entre la représentation en composants et l'implantation système. Par exemple, le système peut faire correspondre l'identi cateur d'un composant à une adresse IP.
Fig. 3.5 Architecture interne de Rainbow [CHSS04]
3.4.1.3 Synthèse
Rainbow est un canevas conçu pour la construction des systèmes auto-adaptables. Pour ce faire, il s'appuie sur une architecture basée sur les composants et une approche de gestion orientée architecture. Ce travail propose une vision avancée de la boucle de commande telle
qu'elle a été proposée dans les travaux menés par IBM dans le domaine de l'autonomic computing.
L'architecture d'administration proposée fait bien la distinction entre la couche qui englobe l'intelligence de l'administration (couche d'architecture) et les couches qui gèrent les mécanismes d'interaction avec les ressources réelles administrées (couche de traduction et couche système).
Néanmoins, Rainbow présente quelques limitations. En eet, le canevas se focalise sur l'automatisation de l'adaptation et n'exploite pas, par exemple, l'ADL pour le déploiement des systèmes distribués. De plus, la partie instrumentation et la création des actionneurs se font d'une manière ad hoc. Le modèle de composants est exploité pour la représentation du système administré et non pas pour la construction du système d'administration lui-même. Certes l'automatisation des décisions d'administration est indispensable dans un contexte large échelle. Toutefois, avec un modèle de gestion centralisé, l'e cacité du moteur de décisions dans un contexte large échelle risque d'être faible.
3.4.2 SmartFrog
SmartFrog (Smart Framework for Object Groups) [GGL+03] est un canevas d'adminis-tration dédié à la description, le déploiement, la con guration et la gestion d'applications Java distribuées. Il a été développé par HP Labs et a été exploité en production. En par-ticulier, SmartFrog a été exploité pour l'administration des grilles de calcul.
Nous présentons dans cette section le modèle à composants sur le quel s'appuie ce travail et nous étudions les fonctions d'administration qu'il propose ainsi que les possibilités de passage à l'échelle qu'il ore.
3.4.2.1 Le modèle à composants SmartFrog
A n d'êtrer gérées par SmartFrog, les applications à déployer doivent respecter un modèle de composants spéci que. Ces composants étendent une classe Java, ce qui leur confère un cycle de vie commun. De plus, chaque composant fournit deux types d'interfaces : les interfaces fonctionnelles et les interfaces de gestion. Par ailleurs, il y a deux types de composants, primitifs et composites. De point de vue implémentation un composant primitif est un objet Java qui implémente les interfaces de gestion et des interfaces fonctionnelles SmartFrog. Un composant composite regroupe un ensemble de composants primitifs.
Pour décrire la structure et les interactions de ses composants, SmartFrog fournit un langage de description qui permet de dé nir une description du système à déployer d'une manière déclarative. Une description d'un composant est une collection ordonnée d'attri-buts. Un attribut a la forme d'une paire (nom, valeur). Il existe trois types de valeurs :
des valeurs simples (entiers, chaînes de caractères, etc.), une référence vers un autre attribut,
une autre description de composant.
Le dernier cas permet de dé nir une relation d'inclusion (hiérarchie) entre composants. SmartFrog fournit un ensemble de services pour faciliter le déploiement et l'administration de ces composants. Parmi ces services on peut citer le service de désignation de noms ou
de celui de la découverte dynamique des ressources.
Nous nous focalisons dans cette section sur la fonction la plus importante fournie par SmartFrog, à savoir la gestion du déploiement.
3.4.2.2 Gestion du déploiement
La principale fonction d'administration remplie par SmartFrog est la gestion du dé-ploiement. Pour ce faire, SmartFrog dispose d'un descripteur de déploiement basé sur un langage propriétaire et un gestionnaire qui se base sur les descriptions des composants pour orchestrer les diérentes tâches liées au déploiement. Le gestionnaire est un système distribué et les diérentes parties de ce système se coordonnent entre elles pour accomplir les tâches de déploiement. Ces tâches utilisent les interfaces de gestion fournies par les composants. Par ailleurs, le gestionnaire reste actif pendant l'exécution de l'application et se charge d'un certain nombre d'opérations telles que l'observation du système, la ré-action aux fautes et l'arrêt des applications. De plus, pour palier les éventuels problèmes de sécurité, SmartForg ore un canevas de gestion de sécurité qui organise les diérentes machines cibles sous la forme de domaines de sécurité, ce qui permet une répartition des responsabilités. De plus, la communication entre les n÷uds est sécurisée.
3.4.2.3 Gestion à large échelle
Les infrastructures et les applications SmartFrog sont la plupart du temps réparties. Typiquement, elles peuvent être installées sur des dizaines ou des centaines de machines, d'où le besoin d'administrer cette infrastructure fortement répartie. JMX peut être utilisé a n d'administrer à la fois l'infrastructure et les applications SmartFrog. Toutefois, les implémentations actuelles de JMX ne permettent pas gérer des milliers de MBeans dé-ployés sur une centaine de machines. La combinaison de JMX et de SmartFrog pourrait permettre à la fois l'administration des infrastructures SmartFrog et aussi la gestion des con gurations JMX à large échelle. sfJMX (SmartFrog -JMX) est une extension de JMX qui matérialise cette combinaison [Gui02]. Elle permet la gestion des infrastructures et des applications SmartFrog en orant une instrumentation transparente et peut intrusive dans l'infrastructure et les applications SmartFrog. D'autre part, sfJMX permet la gestion des installations JMX à large échelle en orant les moyens de descrir, con gurer et déployer des installations JMX réparties.
Chaque élément de l'infrastructure JMX (Mbean, Agent, etc.) peut être décrit avec le langage de description d'architecture fourni par SmartFrog. C'est ainsi qu'on peut décrire des topologies de déploiement avancées qui répondent aux besoins des applications d'ad-ministration. De telles topologies peuvent contenir plusieurs niveaux de hiérarchie. Elles peuvent également englober des interactions entres les Agents JMX. La gure 3.6 [Gui02] illustre un exemple de déploiement complexe des infrastructures JMX avec SmartFrog. Le MBean Deployer est un MBean sfJMX qui assure la gestion et découverte des agents JMX distants.
Fig. 3.6 cfJMX : Déploiement des infrastructures JMX avec SmartFrog
3.4.2.4 Synthèse
SmartFrog est un canevas logiciel conçu pour la gestion de déploiement des applica-tions réparties. Pour ce faire, il s'appuie sur un modèle à composants et un langage de description de déploiement. Le système est donc modélisé sous la forme d'un ensemble de composants interconnectés et imbriqués. Cette encapsulation dans des composants suivant le modèle SmartFrog permet aux applications patrimoniales d'être intégrées dans Smart-Frog. Pour déployer ces composants, SmartFrog se base sur un gestionnaire dé nissant les diérentes tâches de déploiement et un ensemble de services comme le service de découverte et d'adressage. SmartFrog a été utilisé dans un environnement industriel durant plusieurs années. Il a été utilisé, en particulier, dans le contexte de gestion des grilles de calcul.
Toutefois, ce canevas présente quelques limitations. Il suppose l'existence d'un envi-ronnement d'exécution déjà déployé sur les machines cibles. D'autre part, les fonctions de recon guration sont très limitées et sont restreintes au cycle de vie d'un composant. En n, le système d'administration est faiblement recon gurable et ne pro te pas, par exemple, du modèle à composants pour la gestion de son cycle de vie.
A n de pallier ces limitations, des travaux récents [Gui02] ont mis en place un système d'administration qui combine la capacité d'administration d'une manière e cace, transpa-rent et peu intrusive avec JMX et la faculté de déploiement à large échelle de SmartFrog.