Techniques d’obtention des éléments d’un itinéraire

Nous rappelons que nous sommes supposés effectuer de l’administration sys-tème et réseau sur plusieurs éléments. Tous ces éléments ne sont pas forcément dans le même sous-réseau, ce qui va nécessiter des techniques appropriées pour mettre l’information concernant les éléments du réseau à administrer à disposi-tion. Nous présentons ci-après les techniques que l’on pourrait utiliser pour la mise à disposition des listes d’éléments permettant de construire des itinéraires, et le modèle que nous avons choisi d’implémenter.

4.4.2.1 Serveur d’annuaire centralisé

L’itinéraire est construit à partir de la liste des éléments à visiter stockés dans un serveur d’annuaire (par exemple LDAP [44], cf. figure 4.13). Les informations décrivant les nœuds de la plate-forme ou les agents SNMP des équipements actifs doivent être enregistrées dans ce serveur d’annuaire. Il en est de même lorsque des changements de topologie interviennent au sein du réseau de l’entreprise, ou lors de l’apparition ou de la disparition de nœuds. Afin de savoir où aller, l’agent mobile consulte cet annuaire, récupère la liste des éléments à visiter, construit son itinéraire, et exécute la ou les fonctions d’administration programmées par l’administrateur.

AM Noeud

Serveur LDAP

Noeud

Interrogation du serveur LDAP Migration vers un autre noeud

Fig. 4.13 – Serveur d’annuaire contenant les éléments nécessaires à la création des itinéraires d’administration

Dans cette proposition, chaque agent mobile doit connaître la localisation du serveur d’annuaire dans le réseau de l’entreprise. Chaque nœud de la plate-forme à agents mobiles doit s’enregistrer automatiquement et se désenregister à la fin de son activité. Si un nœud vient à disparaître subitement, un élément de la plate-forme à agents mobiles doit assurer la cohérence des enregistrements de l’annuaire en effaçant l’enregistrement correspondant au nœud défaillant. Tou-tefois un avantage fourni par un serveur d’annuaire LDAP est la possibilité de réplication. Ainsi plusieurs annuaires peuvent être répartis sur l’ensemble du ré-seau, chacun étant responsable du sous-réseau dans lequel il fournit son service, mais pouvant servir d’annuaire de secours.

4.4.2.2 Distribution d’itinéraires par un object actif

La liste des éléments permettant de construire un itinéraire à la volée est mise à disposition par un objet actif que l’agent mobile interroge avant chaque migration. Cet objet actif sert d’interface entre les agents mobiles et un système quelconque permettant d’obtenir une liste d’éléments (par exemple une base de données, un fichier décrivant les éléments, etc). L’objet actif fournit à chaque

demande de l’agent mobile le prochain élément que l’agent mobile doit visiter. L’agent mobile doit connaître la référence de cet objet actif pour le localiser et l’interroger (cf. figure 4.14). Chacun des nœuds de la plate-forme doit être enregistré dans cet objet actif (ou sa référence annulée en cas de défaillance) afin d’être accessible pendant le suivi de l’itinéraire.

AM Noeud

Noeud

Objet Actif

Interrogation de l’objet actif Migration vers un autre noeud

Serveur DNS etc.

Interface

Fichiers descriptifs Base de données

Fig. 4.14 – Objet actif fournissant des itinéraires pas à pas

Cet objet peut agir comme un daemon de routage. Dans ce cas, cet objet sélectionne en fonction de la demande d’un agent mobile, le prochain site à visiter selon des critères pré-définis (charge réseau, charge machine, événement transmis par d’autres agents mobiles, etc..) afin que l’agent mobile puisse continuer sa tâche. De même, les agents SNMP des équipements actifs du réseau doivent être référencés si ceux-ci doivent être administrés par un agent mobile. En cas de nœud défaillant, l’agent mobile interroge de nouveau l’objet actif pour connaître le prochain site à visiter. Il en est de même si un agent SNMP ne peut être contacté par l’agent mobile.

Dans cette proposition, la création et la gestion de l’itinéraire sont délégués à l’objet actif. L’agent mobile est un client de l’objet actif qui lui fournit au fur et à mesure le prochain site qu’il doit prendre en compte. Il est indispensable d’assurer la fiabilité de cet objet actif puisqu’il est responsable de la fabrication de l’itinéraire et de la progression du suivi de l’itinéraire par l’agent mobile. Bien évidemment, chaque consultation de l’object actif, avant toute nouvelle migration de l’agent mobile, engendre un délai dans l’exécution globale de l’itinéraire d’ad-ministration. Toutefois, la proposition de l’objet actif présente un intérêt puisque elle rend inutile la mise en œuvre de nouveaux services sur le réseau (principale-ment pas de service d’annuaire à mettre en œuvre). L’objet actif peut être défini

dans le même langage de programmation que la plate-forme à agents mobiles et réagir rapidement sur l’itinéraire donné à l’agent mobile lorsque des nœuds sont défaillants. De plus, l’objet actif peut utiliser les informations sur le comporte-ment du réseau afin d’adapter les itinéraires qu’il donnera aux agents mobiles au moment de leur requête.

4.4.2.3 Critères de sélection

Les deux propositions présentées mettent en évidence des contraintes d’uti-lisation et de délai d’exécution. En effet la mise en œuvre d’un annuaire LDAP entraîne automatiquement une programmation statique de la localisation de cet annuaire sur le réseau (par exemple nom DNS du serveur qui héberge l’annuaire). Il en est de même pour l’object actif de la deuxième proposition. Nous pouvons dégager de ces deux propositions les propriétés suivantes qu’il est souhaitable de mettre en œuvre :

– répartir le service sur un ou plusieurs sous-réseaux – avoir des informations régulièrement mises à jour – éviter les références statiques pour l’accès à ces services

– diminuer le nombre de consultations du service fournissant les listes d’élé-ments

En prenant en compte ces besoins, nous avons donc implémenté notre propre service d’itinéraire.