Modèle de suivi d’itinéraire de ProActive

La gestion du parcours des Destinations d’un itinéraire (génération des ordres de migration) et le lancement des fonctions à exécuter au cours du suivi de cet itinéraire est programmée dans une classe de ProActive, nommée Migration-StrategyManager, et une instance de cette classe est associée à l’objet. Lorsque l’itinéraire de migration est prêt, c’est-à-dire lorsque le gestionnaire du suivi de l’itinéraire a connaissance de tous les nœuds à visiter, alors le MigrationStra-tegyManager parcourt successivement chaque élément de cet itinéraire. Pour chaque élément il exécute l’appel de la méthode associée (voir section 4.3.2.1) en fonction du paramètre associé à la Destination, c’est-à-dire à l’arrivée sur le nœud (par exemple onArrival) ou au départ (par exemple onDeparture) du nœud ou la combinaison des deux. Ainsi, le MigrationStrategyManager décharge l’agent mobile du suivi de son propre itinéraire. Lorsque tous les éléments de l’itinéraire ont été passés en revue, la migration de l’agent mobile s’arrête.

La figure 4.9 présente un exemple d’itinéraire qu’un agent mobile peut exé-cuter en utilisant la bibliothèque ProActive. L’agent mobile part du nœud Thio pour se rendre successivement sur les nœuds Yate, Koumac et Noumea pour ef-fectuer la fonction onArrival (par exemple). En résumé, cet itinéraire consiste à réaliser dans l’ordre :

– Départ de la station d’origine

– Pour chaque nœud de l’itinéraire exécuter l’action onArrival, à l’arrivée sur celui-ci

– Passer au nœud suivant et recommencer

Agent Mobile Noeud Noeud Noeud Noeud Migration Koumac Noumea Thio Yate

Fig. 4.9 – Un itinéraire défini manuellement, construit avec la bibliothèque ProActive

Nous explicitons dans les sections suivantes comment nous avons utilisé le concept de Destination et les extensions que nous y avons apportées afin de pouvoir construire des itinéraires d’administration système et réseau.

4.4 Conception d’itinéraires pour

l’administra-tion

Un itinéraire d’administration est un itinéraire qui permet à un agent mobile d’effectuer des tâches à la place d’un administrateur. Nous regroupons dans le concept d’itinéraire d’administration les opérations qui peuvent être effectuées sur les systèmes d’exploitation via des nœuds de ProActive et les opérations d’administration réseau qui sont effectuées selon la technologie Client/Serveur SNMP.

Tout en restant fidèle au modèle de ProActive, nous avons étendu la définition de ce qu’est une Destination pour que cela inclut les équipements actifs du réseau pour lesquels une opération d’administration doit être effectuée. Cette opération est une opération qui doit être réalisée en utilisant le protocole SNMP afin d’accéder aux informations de la MIB de chaque agent SNMP.

4.4.1 Destinations

4.4.1.1 Les types d’intervention d’un agent mobile d’administration

Nous découpons les types d’intervention d’un agent mobile en quatre catégo-ries, identifiables par leur mode de fonctionnement.

1. L’agent mobile effectue une migration sur un nœud afin d’y effectuer une tâche (1^er cas sur la figure 4.10)

2. L’agent mobile doit se comporter comme un client d’un agent SNMP pour collecter des données de la MIB SNMP (2ème cas sur la figure 4.10)

3. L’agent mobile se rapproche au plus près de l’agent SNMP en effectuant au préalable une migration sur le site qui héberge l’agent SNMP. La communi-cation Client/Serveur utilise l’interface de bouclage (loopback ) de la couche IP (3ème cas sur la figure 4.10)

4. L’agent mobile se rapproche des agents SNMP en effectuant une migration sur un nœud appartenant au même réseau que ces agents. Toutes les re-quêtes Client/Serveur sont faites en utilisant le réseau local, plutôt que les liens inter-réseaux. Ainsi les requêtes peuvent se faire à la vitesse des liens locaux (4^ème cas sur la figure 4.10)

Ces différents types d’intervention seront entièrement définis dans l’itinéraire d’administration qui sera fourni à l’agent mobile. On trouve donc dans les itiné-raires d’administration des mécanismes permettant la migration pour les agents

Fig. 4.10 – Types d’intervention d’un agent mobile d’administration

mobiles (en particulier la définition des nœuds d’accueil) et des mécanismes per-mettant d’interroger des agents SNMP du réseau.

4.4.1.2 Extension de la notion de Destination

Pour prendre en compte dans nos itinéraires les éléments compatibles SNMP, nous avons défini une Destination particulière dénommée SNMPDestination con-forme au modèle des Destinations de ProActive. Une SNMPDestination contient l’ensemble des informations nécessaires pour effectuer une administration à dis-tance (Client/Serveur) entre le nœud sur lequel est situé l’agent mobile et l’agent SNMP cible. On y mémorise le nom logique de l’agent SNMP cible (par exemple rt-nat-192 ou à défaut son adresse IP), le nom de la communauté en lecture, le nom de la communauté en lecture/écriture et le port UDP de l’agent SNMP. Une

SNMPDestination contient donc toutes les informations nécessaires pour dialo-guer avec un équipement actif. Toutefois, une SNMPDestination ne permet pas à un agent mobile de migrer vers l’élément du réseau concerné puisque, les équi-pements actifs n’intègrent pas de nœuds Java pour accueillir des agents mobiles.

SNMPDestination NodeDestination Destination

Fig. 4.11 – Hiérarchie de classes issue de la classe Destination

Par héritage de la classe Destination (cf. figure 4.11), on pourrait facile-ment décrire un nouveau type de Destination, comme par exemple la destination SNMPV3Destination pour supporter le protocole SNMP V3 ou une destination pour le protocole CMIP [104]. Pour effectuer des tâches en parallèle sur des éléments constituant le réseau, la création d’agents mobiles effectuant la même fonction peut s’avérer nécessaire (cf. section 3.3.3). Un agent mobile père créérait des agents mobiles fils, et attendrait la synchronisation de ses fils pour collecter le compte rendu de l’exécution de la fonction. Ce type d’itinéraire peut être mis en œuvre par un nouveau type de destination (par exemple CloneDestination) qui clônerait un agent mobile et qui permettrait la synchronisation de tous les agents mobiles fils après la collecte de l’information (par exemple RendezVous-Destination pour la synchronisation à la fin des tâches).

La figure 4.12 montre un itinéraire d’administration générique réalisé avec notre extension de ProActive. Il fonctionne comme suit :

– Contacter un serveur afin de récupérer un itinéraire contenant la liste des éléments à visiter

– Pour chaque élément de l’itinéraire faire – Cas de

– NodeDestination alors migrer et exécuter l’action onArrival en tant que fonction d’administration

– SNMPDestination alors contacter l’agent SNMP et effectuer l’opération d’administration réseau (en mode Client/Serveur local ou distant) – Fin de Cas

– Fin Pour

La table 4.5 rappelle brièvement les actions à mener en fonction du type de Destinations que nous venons de décrire.

En utilisant ces nouvelles définitions, les itinéraires d’administration pourront être constitués d’éléments de type NodeDestination, de type SNMPDestination, selon le type d’administration que l’on veut faire exécuter à un agent mobile d’administration.

Agent Mobile Noeud Noeud Noeud Agent SNMP Noeud Migration Interrogation obtenir un itineraire Client/Serveur SNMP

Fig. 4.12 – Un itinéraire dynamique construit selon le modèle des Destinations

Destination Action

NodeDestination Migration et exécution de l’appel d’une méthode SNMPDestination Appel de méthode

pour un accès en Client/Serveur SNMP Tab. 4.5 – Actions menées selon les types de Destination