Combinaison de l'architecture et des domaines

Nous avons déni dans la section précédente les notions de domaine d'administration et d'administration fondée sur l'architecture des systèmes administrés. Nous expliquons dans les prochaines sections le processus à suivre pour combiner ces deux approches. Nous rap-pelons que l'objectif est d'administrer des ressources hétérogènes dans un contexte multi-échelles.

Fig. 5.2  Classication des domaines selon leur contenu

5.3.1 Processus d'administration fondée sur l'architecture

Nous commençons par les étapes à suivre pour extraire des représentations architectu-rales correspondant aux ressources existantes.

 Modélisation des ressources à administrer. La première étape de notre ap-proche consiste à modéliser les ressources à administrer. Cette étape permet d'iden-tier les informations et les éventuels évènements qu'on souhaite observer au niveau de la ressource à administrer. Le résultat de cette étape est un modèle abstrait de la ressource administrée.

 Instrumentation des ressources. Après avoir modélisé la ressource à administrer, il est indispensable d'instrumenter ces ressources an de pouvoir alimenter le modèle abstrait avec des données concrètes.

 Découverte des ressources et instanciation des représentations. Cette étape consiste à découvrir l'existence d'une ressource à administrer et à instancier les re-présentations correspondantes au niveau du système d'administration. La phase de découverte des ressources peut être eectuée à l'initiative de la ressource administrée, qui déclare son apparition ou disparition au système d'administration. Mais elle peut être également réalisée à l'initiative du système d'administration (ou l'administra-teur) qui peut initier une opération de recherche de ressources dans un périmètre bien spécique (une plage d'adresse IP ou l'URL d'un serveur MBean, par exemple). Elle peut être déclarative : l'administrateur ou une application d'administration ajoute alors une ressource directement.

5.3.2 Processus d'administration à base de domaines

L'objectif de cette section est de nous montrer les diérentes étapes à suivre an de mettre en place un domaine d'administration. Ces étapes sont résumées dans la gure 5.3.

Fig. 5.3  Processus d'administration à base de domaines

 Le choix des critères de découpage des domaines. Ce choix relève de la res-ponsabilité de l'administrateur et dépend de plusieurs caractéristiques du système à administrer. Parmi ces caractéristiques nous pouvons citer la distribution géo-graphique ou l'ampleur numérique du système administré. Nous présentons dans la section 5.5.1 les diérents critères de découpage des domaines.

 Le choix de la stratégie d'administration. Le choix de la stratégie d'adminis-tration adéquate est déterminant pour le passage à l'échelle de l'infrastructure de gestion. Ce choix dénit le modèle d'agencement des domaines et leur fonctions et périmètre d'administration. Plusieurs paramètres, tels le nombre des requêtes d'ad-ministration, le volume des données échangés ou la nature des requêtes échangées peuvent inuencer ce choix. Ces paramètres peuvent concerner aussi bien l'environ-nement matériel que l'environl'environ-nement logiciel ou réseau du système d'administration et du système à administrer. Nous présentons une classication de ces variables dans la section 5.5.4 de ce chapitre.

 Le déploiement et la composition des domaines. An de concrétiser la vue or-ganisationnelle résultante de l'étape précédente, des domaines d'administration sont instanciés et déployés, et dans certains cas composés. L'instanciation consiste à la création des domaines. Le déploiement correspond à leur copie dans leur environ-nement d'exécution matériel. Quant à la composition, elle désigne la possibilité de tisser des liens et des relations entre les domaines (hiérarchie, agrégation, etc.).  Le dimensionnement des domaines. Cette opération est indispensable pour le

sim-plié du domaine. Le dimensionnement permet d'extraire des opérations telles que le nombre maximum de requêtes supportées, le nombre maximum de ressources ad-ministrées, etc.

 Déploiement d'applications d'administration. Une fois le domaine déployé et dimensionné, nous pouvons déployer les applications d'administration. Ces applica-tions interagissent directement avec les domaines qui les intéressent an d'eectuer des opérations d'administration.

 L'approvisionnement en éléments administrés. La première opération que les applications d'administration peuvent eectuer est l'approvisionnement des domaines en ressources administrées. Cette opération d'approvisionnement consiste en la sé-lection et puis l'aectation des ressources administrées aux domaines. A l'issue de cette opération, des instances d'éléments administrés abstraits sont créées au niveau des domaines. Ces éléments sont des représentations architecturales des ressources administrées du monde réel.

 Le suivi et l'évolution de la stratégie d'administration. Au cours de l'exécu-tion, un suivi régulier de la plateforme d'administration doit être eectué. Ce suivi permet de planier l'évolution de la plateforme d'administration et d'anticiper des éventuelles défaillances. Quant à son évolution, elle est radicalement simpliée si on opte pour une approche à composants.

5.4 Administration fondée sur l'architecture des systèmes

ad-ministrés

5.4.1 Cycle de vie d'un élément administré

Chaque élément administré évolue selon un cycle de vie bien déni et illustré dans la gure 5.4. Les étapes du cycle de vie sont comme suit :

 Initialisé. Un élément administré est initialement instancié et par la suite initialisé avec des informations de gestion recueillies auprès de la ressource qu'il représente. Cette phase comprend par exemple la dénition des propriétés gérées et des ressources avec laquelle un élément administré interagit pour mettre à jour son état.

 En exécution. Un élément administré ne peut commencer à interagir avec les res-sources qu'il représente qu'à partir du moment où il est initialisé et lancé en exécution.  Migré. Cet état concerne les éléments administrés qui changent de domaine au cours de leur cycle de vie. Le domaine initial peut dans certaines situations avoir besoin d'informations concernant le devenir d'un élément administré qui a migré vers un autre domaine.

 Vérouillé. Un élément administré peut être verrouillé par une application d'admi-nistration an de pouvoir eectuer des opérations de mise à jour ou de contrôle par exemple.

 En attente. L'activité d'un élément administré peut être suspendue à la demande de l'administrateur du ME via les applications d'administration. Cet état peut servir par exemple à contrôler la charge d'activité au niveau des domaines. L'activité d'un ensemble de ME peut être suspendue an de libérer plus de ressources de calcul et éviter la défaillance du système d'administration suite à une surconsommation des ressources disponibles.

 Eacé. Un élément administré eacé n'existe plus dans le système d'administration. C'est l'étape nale du cycle de vie d'un élément administré.

Fig. 5.4  Cycle de vie d'un élément géré

5.4.2 Mise à jour des éléments administrés

Un élément administré interagit régulièrement avec les ressources qu'il représente an de mettre à jour son état. Cette interaction peut suivre trois modèles :

 Pull. Un élément administré interagit avec la ressource gérée à l'initiative de l'ad-ministrateur ou de l'élément administré lui-même. (voir le mode 1 de la gure 5.5)  Pooling. Ce modèle d'interaction est similaire au modèle précédent sauf que les

re-quêtes sont exécutées à une fréquence régulière et prédénie à l'initiative de l'élément administré correspondant. Un scheduler est donc positionné au niveau de l'élément administré. Il gère la fréquence d'activation des requêtes. Ce mode requiert donc une conguration de l'élément administré an de gérer l'alternance entre l'activation et la mise en attente de l'élément administré (voir mode 2 de la gure 5.5).

 Push. Selon ce modèle d'interaction, une ressource prend l'initiative d'informer un élément administré de chaque éventuel changement d'état. Le mode 3 de la gure 5.5 montre un exemple de ce mode d'interaction. Avec cette approche, nous pouvons éco-nomiser certaines interactions par rapport au modèle précédent. Cette économie est matérialisée dans la réduction des ux de données sur le réseau et du temps de trai-tement au niveau des infrastructures de gestion. La mise en ÷uvre de cette approche requiert une instrumentation de la ressource administrée pour qu'elle puisse prendre l'initiative et envoyer l'information sélectionnée à l'entité administrative concernée.