Agents Mobiles : itinéraires pour l’administration
système et réseau
Emmanuel Reuter
To cite this version:
Emmanuel Reuter. Agents Mobiles : itinéraires pour l’administration système et réseau. Réseaux et
télécommunications [cs.NI]. Université Nice Sophia Antipolis, 2004. Français. �tel-00207934�
HAL Id: tel-00207934
https://tel.archives-ouvertes.fr/tel-00207934
Submitted on 18 Jan 2008
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d’enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.
Université de Nice Sophia Antipolis
UFR SCIENCES
École Doctorale : STIC
THÈSE
Présentée pour obtenir le titre de :
Docteur en SCIENCES
de l’Université de Nice Sophia Antipolis
Spécialité : Informatique
par
Emmanuel Reuter
Équipe d’accueil : OASIS - INRIA Sophia Antipolis
Titre de la thèse :
Agents Mobiles :
Itinéraires pour l’administration système et réseau
Thèse dirigée par Françoise BAUDE
Soutenue le 28 Mai 2004
Président
M. :
Rapporteurs
MM. :
Examinateurs
MM. :
Michel
Riveill
Univ. Nice Sophia Antipolis
Olivier
Serge
Festor
Chaumette
INRIA Lorraine
Univ. Bordeaux 1
Françoise
Jean-Luc
Baude
Ernandez
Univ. Nice Sophia Antipolis
Ingénieur ATOS Origin
Je remercie avant tout Françoise Baude qui m’a encadré durant ces quatre
dernières années et sans qui cette thèse n’aurait pas pu se faire. Elle a su me
guider par ses nombreux conseils, les encouragements mentionnés à chaque fin
d’emails et pendant les nombreux repas de travail que nous nous sommes fixés
avec une certaine régularité.
L’accueil qui m’a été réservé dans l’équipe OASIS a été à la fois chaleureux
et enrichissant scientifiquement et m’a permis de m’ouvrir à de nouveaux sujets.
J’ai beaucoup apprécié les échanges entre Julien Vassière, Fabrice Huet, Romain
Quilici, membres de l’équipe Oasis, qui m’ont permis d’avancer dans mon travail
de recherche tout en occupant un poste à l’IUFM de l’académie de Nice.
Je tiens à remercier bien entendu les membres du jury : Michel Riveill qui a
accepté de présider ce jury, Olivier Festor, Serge Chaumettre pour avoir accepté
d’être rapporteurs et enfin Jean-Luc Ernandez pour avoir accepté d’être un examinateur de cette thèse.
Je tiens à remercier les deux directeurs de l’IUFM, François Rocca et René
Lozi, qui m’ont autorisé successivement à continuer ma thèse en parallèle du
travail d’ingénieur d’études que j’exerce au sein de cet établissement. Plus particulièrement François Rocca qui a été pour moi l’étincelle de départ de cette
grande aventure.
Une pensée particulière est adressée à Richard MANAS, Ingénieur de Recherche au Centre Informatique de l’Université de Nice Sophia Antipolis, pour
son aide et les discussions que nous avons eues pendant ces quatres années.
Je n’oublie pas le personnel de l’informatique de l’IUFM qui a su m’aider dans
mes démarches de tests et qui a parfois supporté mes absences pendant que je
voguais vers d’autres cieux, ceux de la recherche bien sûr.
A mon pays, la Nouvelle-Calédonie.
Table des matières
1 Introduction
1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Contribution et organisation du manuscrit . . . . . . . . . . . . .
11
11
11
13
2 L’administration des systèmes et des réseaux
2.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Définition de l’administration des systèmes et des réseaux .
2.2.1 Gestion des performances . . . . . . . . . . . . . . .
2.2.2 Gestion des fautes . . . . . . . . . . . . . . . . . . .
2.2.3 Gestion de la configuration . . . . . . . . . . . . . . .
2.2.4 Gestion des informations comptables . . . . . . . . .
2.2.5 Gestion de la sécurité . . . . . . . . . . . . . . . . . .
2.3 Le kit de survie de l’administrateur réseau . . . . . . . . . .
2.3.1 La couche physique . . . . . . . . . . . . . . . . . . .
2.3.2 La couche liaison de données . . . . . . . . . . . . .
2.3.3 La couche réseau . . . . . . . . . . . . . . . . . . . .
2.4 L’administration de réseau . . . . . . . . . . . . . . . . . .
2.4.1 Le protocole d’administration de réseau : SNMP . . .
2.4.2 Le protocole CMIP . . . . . . . . . . . . . . . . . .
2.4.3 Administration répartie . . . . . . . . . . . . . . . .
2.5 Quelques outils incontournables pour l’administration . . . .
2.5.1 Des outils élémentaires . . . . . . . . . . . . . . . .
2.5.2 Plates-formes d’administration centralisée . . . . . .
2.5.3 Des plates-formes d’administration basées sur le Web
2.6 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
15
16
16
17
18
18
18
19
19
20
22
24
24
33
33
36
36
37
41
41
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Les plates-formes à agents mobiles pour l’administration
tème et réseau : État de l’art
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 État de l’art des plates-formes à agents mobiles . . . . . . . .
3.2.1 Principe de l’administration par delegation . . . . . . .
3.2.2 Plates-formes tournées vers l’administration . . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
sys.
.
.
.
.
.
.
.
43
43
44
44
45
2
Table des matières
3.3
3.4
3.5
4
5
3.2.3 Installation des plates-formes . . . . . . . . .
3.2.4 Programmation des agents . . . . . . . . . . .
3.2.5 Communication entre agents mobiles . . . . .
3.2.6 Accès aux données de la MIB SNMP . . . . .
Itinéraires . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Motivation . . . . . . . . . . . . . . . . . . . .
3.3.2 Structuration d’un itinéraire de visite . . . . .
3.3.3 Autres structurations d’un itinéraire . . . . .
La topologie du réseau . . . . . . . . . . . . . . . . .
3.4.1 Motivation : besoin de découverte automatisée
3.4.2 Techniques de découverte de la topologie . . .
3.4.3 Topologie de niveau 2 . . . . . . . . . . . . .
Bilan . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Conception d’un mécanisme d’itinéraires dynamiques pour l’administration système et réseau
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Les agents mobiles dans ProActive . . . . . . . . . . . . . . . . .
4.2.1 ProActive : objets actifs asynchrones communicants . . . .
4.2.2 Modèle de base . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3 Création des objects actifs . . . . . . . . . . . . . . . . . .
4.2.4 Activités, contrôle explicite et abstractions . . . . . . . . .
4.3 Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Migration Faible . . . . . . . . . . . . . . . . . . . . . . .
4.3.2 Abstractions pour la mobilité . . . . . . . . . . . . . . . .
4.3.3 Modèle de suivi d’itinéraire de ProActive . . . . . . . . . .
4.4 Conception d’itinéraires pour l’administration . . . . . . . . . . .
4.4.1 Destinations . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.2 Techniques d’obtention des éléments d’un itinéraire . . . .
4.4.3 Le modèle de service d’itinéraire proposé . . . . . . . . . .
4.4.4 Construction et gestion de l’itinéraire . . . . . . . . . . . .
4.4.5 Utilisation d’itinéraires . . . . . . . . . . . . . . . . . . . .
4.5 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
48
54
56
57
57
57
59
62
62
64
67
68
71
71
72
72
73
73
75
76
76
78
82
83
83
86
89
95
97
98
Conception et implantation d’une plate-forme d’administration
système et réseau
101
5.1 Architecture générale : principe de conception . . . . . . . . . . . 101
5.2 Les services de la plate-forme . . . . . . . . . . . . . . . . . . . . 102
5.2.1 Service de collecte et d’analyse . . . . . . . . . . . . . . . 102
5.2.2 Service de mise à disposition des informations collectées et
analysées . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.2.3 Service de supervision de la plate-forme . . . . . . . . . . . 103
5.3 Architecture générale : mise en œuvre . . . . . . . . . . . . . . . . 103
Table des matières
5.4
5.5
5.6
3
5.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2 Connaissance du réseau . . . . . . . . . . . . . . . . . . .
5.3.3 Service de mise à disposition des informations découvertes
5.3.4 Service de supervision . . . . . . . . . . . . . . . . . . . .
5.3.5 Récapitulatif . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.6 Interface graphique . . . . . . . . . . . . . . . . . . . . . .
Principes et implantation de l’algorithme de découverte de la topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.2 Phase de détection des éléments . . . . . . . . . . . . . . .
5.4.3 Phase de connexion des éléments . . . . . . . . . . . . . .
Mise en œuvre du service de découverte de la topologie . . . . . .
5.5.1 Le service de localisation des nœuds ProActive . . . . . . .
5.5.2 Le service de découverte . . . . . . . . . . . . . . . . . . .
5.5.3 Interaction avec le serveur d’itinéraires . . . . . . . . . . .
5.5.4 Topologie de réseaux virtuels . . . . . . . . . . . . . . . .
5.5.5 Evaluation du temps de construction . . . . . . . . . . . .
5.5.6 Extension de l’agorithme pour le protocole SNMP V3 . . .
Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
103
104
107
108
109
110
114
114
115
117
122
122
123
123
123
124
126
127
6 Programmation d’agents mobiles pour l’administration système
et réseau
129
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6.2 Fabrication et suivi d’itinéraires . . . . . . . . . . . . . . . . . . . 130
6.2.1 Architecture générale . . . . . . . . . . . . . . . . . . . . . 130
6.2.2 Fabrication de l’itinéraire . . . . . . . . . . . . . . . . . . . 131
6.2.3 Suivi de l’itinéraire . . . . . . . . . . . . . . . . . . . . . . 134
6.3 Code d’administration . . . . . . . . . . . . . . . . . . . . . . . . 135
6.3.1 Les opérations de base . . . . . . . . . . . . . . . . . . . . 135
6.3.2 Utilisation des opérations de base dans le code de l’agent . 138
6.4 Extensibilité du modèle de développement . . . . . . . . . . . . . 141
6.4.1 Modalités de l’extension . . . . . . . . . . . . . . . . . . . 141
6.4.2 Exemple : prise en compte d’un nouveau type de destination142
6.4.3 Exemple : fabrication d’un nouveau type d’itinéraire parallèle145
6.5 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
7 Performances et évaluation des agents mobiles pour
tration système et réseau
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Analyse des performances . . . . . . . . . . . . . . . .
7.2.1 Expériences sur un réseau local . . . . . . . . .
7.2.2 Expériences sur un réseau WLAN . . . . . . . .
7.3 Exemples d’utilisation des agents mobiles . . . . . . . .
l’adminis153
. . . . . . 153
. . . . . . 154
. . . . . . 154
. . . . . . 161
. . . . . . 165
4
Table des matières
7.3.1
7.4
Quelques exemples simples exploitant la propriété d’autonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
7.3.2 Exemple : Autoconfiguration des VLANs dans un réseau . 167
Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
8 Conclusion
169
8.1 Bilan, contribution . . . . . . . . . . . . . . . . . . . . . . . . . . 169
8.2 Administration dans le contexte des applications . . . . . . . . . 171
9 Annexes
9.1 La technologie Jini . . . . . . . . . . . . . . . . .
9.1.1 Les services enregistrés . . . . . . . . . . .
9.1.2 L’enregistrement d’un service . . . . . . .
9.1.3 La localisation d’un service . . . . . . . . .
9.1.4 Utilisation de Jini dans notre plate-forme .
9.2 Java Management Extension . . . . . . . . . . . .
9.2.1 Les niveaux dans JMX . . . . . . . . . . .
9.3 Wifi . . . . . . . . . . . . . . . . . . . . . . . . .
9.3.1 Les réseaux sans fil en mode Infrastructure
9.3.2 Les réseaux sans fil en mode ad hoc . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
175
175
175
176
176
176
177
177
178
178
180
Bibliographie
180
Résumé
189
Table des figures
2.1
2.2
2.3
2.4
2.5
2.12
2.13
Réseau Ethernet non segmenté . . . . . . . . . . . . . . . . . . . .
Réseau Ethernet segmenté . . . . . . . . . . . . . . . . . . . . . .
Exemple d’une topologie en bus . . . . . . . . . . . . . . . . . . .
Exemple d’une topologie en étoile . . . . . . . . . . . . . . . . . .
Architecture Client/Serveur sur laquelle se base l’utilisation d’un
protocole d’administration dans un réseau . . . . . . . . . . . . .
Structure d’indexation des données dans la MIB-2 SNMP . . . . .
Les groupes d’objets de la MIB-2 . . . . . . . . . . . . . . . . . .
Délégation à un gestionnaire intermédiaire des opérations d’administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Plate-forme de supervision du trafic réseau instantané . . . . . . .
Plate-forme d’administration de réseaux centralisée . . . . . . . .
Capture d’écran de la topologie réseau obtenue par la plate-forme
HP Network Node Manager . . . . . . . . . . . . . . . . . . . . .
Capture du segment 8 . . . . . . . . . . . . . . . . . . . . . . . .
Principe du Web-Based Management . . . . . . . . . . . . . . . .
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
Architecture de MAD . . . . . . . . . . . .
Classe générique d’un agent mobile . . . .
Classe HelloAgent de la plate-forme Ajanta
Classe d’un agent mobile dans MAP . . .
Classe d’un agent mobile dans SOMA . . .
Modèle des domaines de SOMA . . . . . .
Les itinéraires dans MobileSpaces . . . . .
Les Patterns de migration dans Ajanta . .
Une portion de l’Internet . . . . . . . . . .
Topologie de niveau 2 . . . . . . . . . . . .
2.6
2.7
2.8
2.9
2.10
2.11
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
26
28
34
37
39
40
40
41
.
.
.
.
.
.
.
.
.
.
45
51
51
52
55
58
59
61
65
68
4.1 Création des objects actifs : Instanciation-, Object-based . . . . .
4.2 Création d’un objet actif avec une politique de service RunActive
4.3 Création d’un objet actif dans la JVM en cours, à distance ou par
co-allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 Programmation explicite du contrôle . . . . . . . . . . . . . . . .
74
74
5
.
.
.
.
.
.
.
.
.
.
17
17
21
21
75
75
6
Table des figures
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.19
4.20
4.21
4.22
4.23
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
5.14
SimpleAgent : exemple d’un objet actif mobile . . . . . . . . . .
Localisation avec répéteurs . . . . . . . . . . . . . . . . . . . . . .
Exécution automatique de méthodes et itinéraires . . . . . . . . .
Modèle générique d’activité d’un agent mobile . . . . . . . . . . .
Un itinéraire défini manuellement, construit avec la bibliothèque
ProActive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Types d’intervention d’un agent mobile d’administration . . . . .
Hiérarchie de classes issue de la classe Destination . . . . . . . . .
Un itinéraire dynamique construit selon le modèle des Destinations
Serveur d’annuaire contenant les éléments nécessaires à la création
des itinéraires d’administration . . . . . . . . . . . . . . . . . . .
Objet actif fournissant des itinéraires pas à pas . . . . . . . . . .
Objet actif fournissant des itinéraires en une seule fois . . . . . . .
Le service d’itinéraire . . . . . . . . . . . . . . . . . . . . . . . . .
Extension de notre hiérarchie des Destinations, incluant la notion
de service d’itinéraire . . . . . . . . . . . . . . . . . . . . . . . . .
Extension de la hiérarchie des destinations, pour les destinations
de type parallèle . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exemple d’intégration de CloneDestinations et de RendezVousDestinations dans un itinéraire de type parallèle . . . . . . . . .
Hiérarchie de classes issue de la classe ItineraryManager . . . . .
Hiérarchie de la classe ItineraryManager étendue pour les itinéraires parallèles . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Algorithme du MigrationStrategyManager . . . . . . . . . . . . .
Fonctionnement de la création et du suivi d’un itinéraire . . . . .
77
78
80
81
82
84
85
86
87
88
90
92
92
93
94
96
97
98
100
Hiérarchie des descriptifs des sous-réseaux . . . . . . . . . . . . . 105
Interface pour la saisie du descriptif d’un sous-réseau . . . . . . . 106
Interface pour la sélection du constructeur de la Destination . . 107
Interface pour la saisie d’une Destination . . . . . . . . . . . . 107
Les services de la plate-forme vus par IC2D . . . . . . . . . . . . 109
Répartition des services de la plate-forme sur deux nœuds différents109
Le récapitulatif des services de notre plate-forme à agents mobiles
pour l’administration système et réseau . . . . . . . . . . . . . . . 110
Interface de visualisation de la topologie . . . . . . . . . . . . . . 112
Onglet de visualisation des informations d’un élément . . . . . . . 113
Les services de la plate-forme et des agents mobiles d’administration vus par IC2D . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Lancement d’un agent mobile d’administration . . . . . . . . . . . 114
Interrogation à distance de l’agent mobile via la GUI . . . . . . . 115
AgentMonitoringFrame : Supervision des ressources système d’un
élément . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Onglet de visualisation de la charge réseau d’un équipement actif 116
Table des figures
5.15 Schéma d’un réseau quelconque . . .
5.16 Topologie obtenue par l’algorithme .
5.17 Schéma d’une migration automatique
du sous-réseau . . . . . . . . . . . . .
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
6.12
6.13
6.14
6.15
6.16
6.17
6.18
6.19
6.20
7.1
7.2
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7
. .
. .
des
. .
. . . . . . . . . . . . . . 118
. . . . . . . . . . . . . . 121
services au plus proche
. . . . . . . . . . . . . . 124
Interaction entre l’agent mobile, l’ItineraryServer et l’ItineraryManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Les méthodes publiques de la classe de l’ItineraryManager . . . 132
Les méthodes privées ou protégées de la classe de l’ItineraryManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Un ItineraryManager pour la collecte de données sur des imprimantes du sous-réseau représenté par un ItineraryServer . . . . . 134
Itinéraire couvrant tout le réseau : ItineraryManagerWholeNetwork 135
Classe MgtMigrationStrategyManagerImpl . . . . . . . . . . . . 136
Exemple de code inspiré par la gestion des traps de AdventNet
pour instancier un agent mobile de gestion de traps . . . . . . . . 137
Un agent générique permettant de gérer une trap SNMP . . . . . 137
Classe abstraite de l’Agent . . . . . . . . . . . . . . . . . . . . . . 139
Un agent mixte, récupérant les ressources du système sur chaque
nœud et la table ARP de chaque Agent SNMP . . . . . . . . . . . 140
Code du lanceur de l’AgentMix . . . . . . . . . . . . . . . . . . . 141
L’AgentSnmpV3 qui dialogue en SNMP V3 avec des équipements
actifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
La définition d’une destination pour le protocole SNMP V3 . . . . 143
Un exemple d’un ItineraryManager pour des destinations du type
SNMP V3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Principe de sécurisation . . . . . . . . . . . . . . . . . . . . . . . 145
Classe de l’ItineraryManagerParalleleWholeNetwork . . . . . . 146
Classe de la CloneDestination . . . . . . . . . . . . . . . . . . . 147
Classe de la RendezVousDestination . . . . . . . . . . . . . . . . 149
Classe abstraite de l’AgentGeneric - agent secondaire . . . . . . . 150
Classe de l’AgentClone . . . . . . . . . . . . . . . . . . . . . . . . 151
Schéma du réseau d’évaluation avec un débit modifiable sur le lien
inter-réseau (via la machine bourail) . . . . . . . . . . . . . . . .
Collecte du groupe System (100Kbps-200Kbps) . . . . . . . . . .
Collecte du groupe System (1Mbps-5Mbps) . . . . . . . . . . . . .
Collecte de la table de Routage (100Kbps-200Kbps) . . . . . . . .
Collecte de la table de Routage (1Mbps-5Mbps) . . . . . . . . . .
Collecte de la table ARP (100Kbps-200Kbps) . . . . . . . . . . .
Collecte de la table ARP (1Mbps-5Mbps) . . . . . . . . . . . . . .
Comparatif des fonctions par débits . . . . . . . . . . . . . . . . .
Schéma de la configuration d’évaluation avec un réseau sans fil . .
155
156
157
158
158
159
160
160
161
8
Table des figures
7.10 Interrogation des agents SNMP en Client/Serveur et avec
mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.11 Retour systématique à la station de départ . . . . . . . . .
7.12 Estimation du vidage de l’agent mobile . . . . . . . . . . .
7.13 Schéma d’un réseau Wifi fonctionnant en mode ad hoc . .
7.14 Schéma du réseau pour l’autoconfiguration des VLANs . .
agent
. . . .
. . . .
. . . .
. . . .
. . . .
163
164
164
166
168
9.1
9.2
9.3
9.4
.
.
.
.
176
177
180
180
Jini du côté serveur . . . . . . . .
Jini du côté du client . . . . . . .
Accès Wifi en mode infrastructure
Accès Wifi en mode ad hoc . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Liste des tableaux
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
Exemple de résultat de la commande ping . . . . . . . . . . . . .
Exemple de résultat de la commande arp . . . . . . . . . . . . . .
Exemple de résultat de la commande traceroute . . . . . . . . . .
Exemple de résultat de la commande nmap -sT 192.168.80.0 . . .
Informations principales de la MIB-2 SNMP . . . . . . . . . . . .
Opérations définies par le protocole SNMP . . . . . . . . . . . . .
Exemple d’une table de routage obtenue en SNMP . . . . . . . .
Exemple d’une table ARP obtenue en SNMP . . . . . . . . . . . .
Exemple d’utilisation de la commande snmpset sur un commutateur
22
23
23
24
27
29
30
30
31
4.1
4.2
4.3
Routines de service . . . . . . . . . . . . . . . . . . . . . . . . . .
Primitives de migration (méthodes statiques) . . . . . . . . . . . .
API d’exécution automatique de méthode, notamment sur départ
et arrivée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
API d’utilisation d’un itinéraire . . . . . . . . . . . . . . . . . . .
Actions menées selon les types de Destination . . . . . . . . . . .
Actions menées selon les types de Destination, version étendue . .
76
77
4.4
4.5
4.6
5.1
5.2
5.3
5.4
5.5
5.6
5.7
Explication des Tags du service de description d’un sous-réseau .
Extrait de la MIB BRIDGE dot1dTpFdb . . . . . . . . . . . . . .
Liste résultante de l’énumération des chemins . . . . . . . . . . .
Liste résultante de l’énumération des chemins sans connexion impossible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Liste résultante de l’énumération des chemins sans connexion impossible et indirecte . . . . . . . . . . . . . . . . . . . . . . . . . .
Liste résultante pour la construction de la topologie . . . . . . . .
Répartition par catégories d’éléments sur un réseau . . . . . . . .
9
79
80
86
99
105
118
118
119
119
120
125
10
Liste des tableaux
Chapitre 1
Introduction
1.1
Contexte
De nos jours, toutes les entreprises sont équipées au minimum d’un réseau
local, et pour les plus importantes d’entre elles de réseaux longue distance (Wide
Area Network). L’administration de réseaux est devenue un point critique dans
toutes ces entreprises par l’hétérogénéité même des éléments composant le réseau.
Du fait de cette hétérogénéité, il devient indispensable de surveiller en permanence les éléments-clefs du réseau, afin que les utilisateurs ne soient pas affectés
par des incidents de fonctionnement et que la perte d’exploitation soit la plus
faible possible en cas d’incident. Pour cela, les entreprises investissent dans des
outils d’administration de réseau très onéreux [35, 37] et qui ne sont pas nécessairement adaptés à chacune d’entre elles.
Un système d’administration de réseau, qui fournit des mécanismes de surveillance, est composé d’une ou plusieurs stations de supervision qui communiquent entre elles et avec les éléments du réseau par un protocole d’administration de réseau, les plus connus étant SNMP [87] et CMIP [104]. Il est nécessaire
d’arriver à le répartir dans les sous-réseaux de l’entreprise pour diminuer l’utilisation de la bande passante sur les liens inter-réseaux, d’améliorer la réactivité
du système d’administration en le distribuant sur chaque sous-réseaux de l’entreprise.
1.2
Motivation
Il y a de plus en plus d’éléments dans les réseaux des entreprises qu’un administrateur doit surveiller. Pour cela il dispose, normalement, d’outils pour analyser
son réseau, surveiller son système, mais une plate-forme à agents mobiles peut
apporter une aide substantielle à un administrateur. En effet, certaines tâches
routinières, comme par exemple l’effacement de fichiers temporaires ou le déploiement de logiciels, peuvent être directement effectuées par des agents mobiles
11
12
Introduction
et relativement autonomes. La programmation de tels agents mobiles peut être
simplifiée dès lors qu’un cadre d’administration de systèmes et de réseaux fournissant les outils appropriés est disponible. Par exemple, l’inventaire automatisé
du parc informatique est une opération facilement réalisable avec une technique
à agents mobiles par laquelle on déploit un ou plusieurs agents autonomes. Le
mécanisme de migration fourni dans les plates-formes à agents mobiles permet de
faire déplacer sans souci les agents mobiles et de faire exécuter automatiquement
une tâche pré-programmée adaptée à une opération d’administration localement
sur chaque élément. Il est à présent admis que les agents mobiles dans un cadre
d’administration système et réseau permettent la réduction du temps de traitement des messages échangés entre des éléments du réseau, permettent de limiter
la bande passante nécessaire aux opérations d’administration distantes, et enfin
le traitement local des informations permet de réagir plus rapidement aux changements dans le réseau [64]. Par ailleurs, la technologie des agents mobiles semble
aussi adaptée à l’administration des réseaux en émergence que sont les active networks, notamment en facilitant le déploiement des tâches d’administrations dans
ce nouveau type de réseau [75].
Pour utiliser des agents mobiles dans un cadre d’administration système et
réseau, la mise en œuvre d’itinéraires permettant l’exécution de tâches d’administration est un besoin pour rendre complètement autonomes ces agents mobiles
pendant l’exécution des tâches pré-programmées. Idéalement, un itinéraire dynamiquement créé par la connaissance automatique de l’infrastructure du réseau,
serait adapté pour suivre l’évolution des réseaux et des services que ces réseaux
peuvent fournir et pour déployer dynamiquement, en parallèle si nécessaire, les
agents mobiles d’administration ayant en charge la supervision de tels réseaux.
Un tel concept d’itinéraire dynamique et intelligent pour son suivi, offrirait plus
d’avantages qu’un itinéraire statique, qui plus est défini manuellement : l’itinéraire
serait toujours à jour, et son suivi serait adapté aux conditions réseaux environnantes, c’est-à-dire prenant en compte des pannes dans le réseau, les nouveaux
éléments, et ce de manière complètement transparente à l’administrateur.
Donnons un exemple d’itinéraire que l’on peut appliquer au genre humain.
Imaginons un voyageur partant de Nice à destination de Nouméa, pour aller
s’installer en Nouvelle-Calédonie. Décrivons plus précisément son itinéraire de
voyage. A l’aéroport de Nice-Côte d’Azur, notre voyageur se rend au comptoir de
la compagnie afin de récupérer son titre de transport. Il prend son premier avion
à destination de Paris, départs Internationaux. A l’aéroport de Roissy, il récupère
des présents pour ses amis néo-calédoniens et les emportent avec lui dans l’avion
qui l’amène à Osaka, aéroport de transit. Profitant de la baisse du cours du Yen,
notre voyageur acquiert un appareil photo de bonne qualité afin de ramener des
souvenirs de son voyage. Arrivé à destination, notre voyageur offre les présents à
ses amis sur le territoire. Néanmoins, notre voyageur n’oubliera pas de rester en
contact avec sa ville de départ.
Revenons à notre agent mobile. En se basant sur le descriptif de l’itinéraire de
Contribution et organisation du manuscrit
13
voyage, notre agent mobile se rend de sa station de départ (Nice) vers la station
Roissy, premier point d’arrêt. Sur la station Roissy, il exécute une première collecte de données avant de reprendre son chemin vers la station Osaka. Deuxième
point d’arrêt, pour lequel l’agent mobile prend une image de l’état du système.
L’agent mobile se dirige ensuite vers sa station d’arrivée, Nouméa, où il termine
son itinéraire. Même à distance, lui et sa station d’origine peuvent rester en communication et ainsi notre agent mobile peut transmettre les informations qu’il a
collectées pendant son itinéraire.
Pour généraliser une telle solution, un administrateur doit être en mesure de
fournir un itinéraire d’administration aux agents mobiles. La création de ces itinéraires peut être statique, c’est-à-dire des itinéraires définis manuellement réseau
par réseau. Une solution généralisable qui donnerait des itinéraires dynamiques et
adaptables selon les réseaux et les éléments qui y sont connectés est plus appropriée, à cause des changements incessants qui surviennent dans les réseaux. Pour
ce faire, la connaissance de l’infrastructure interconnectant les éléments entre
eux est nécessaire, typiquement la topologie des différents réseaux constituant le
réseau de l’entreprise.
1.3
Contribution et organisation du manuscrit
Dans un premier temps nous détaillons le métier de l’administration des systèmes et de réseaux afin de mieux cerner l’intérêt et les difficultés d’un tel métier
au sein des entreprises (chapitre 2).
L’émergence des plates-formes à agents mobiles et leur intégration possible
dans le monde de l’administration système et réseau permettent d’envisager des
solutions pour aider un administrateur dans le métier qu’il exerce jour après
jour, afin de satisfaire aux contraintes d’exploitation des systèmes et des réseaux
dont il a la charge. Une analyse comparative détaillée de telles plates-formes est
présentée dans le chapitre 3. Elle permet de mettre en évidence l’intérêt que
pourrait avoir le fait de disposer d’itinéraires d’administration qui puissent être
construits dynamiquement plutôt que statiquement.
Ce travail de thèse consiste donc à proposer la définition d’un mécanisme
de fabrication puis d’utilisation d’itinéraires dynamiques pour l’administration
système et réseau. Ces itinéraires, définis dynamiquement, et dans un premier
temps sous-réseau par sous-réseau, sont des itinéraires locaux qui sont par la
suite combinés dynamiquement entre eux de sorte à pouvoir prendre en considération l’intégralité de l’architecture à superviser. Nous validons cette définition
en fournissant une plate-forme complète ainsi qu’un cadre de programmation
d’agents mobiles d’administration système et réseau. Pour ce faire, nous nous
basons sur la bibliothèque ProActive pour le calcul parallèle, réparti et mobile.
En nous basant sur le modèle de programmation d’agents mobiles qu’offre la
14
Introduction
bibliothèque ProActive, nous décrivons quelles extensions nous y avons apportées
dans le but de définir un mécanisme d’itinéraires pour l’administration système
et réseau (chapitre 4).
La conception d’une plate-forme d’administration à base d’agents mobiles
ProActive mettant en œuvre des itinéraires d’administration est décrite en termes
de services qu’il est nécessaire de mettre en place (chapitre 5). Une présentation
détaillée d’un algorithme de découverte de la topologie est ensuite donnée. Cet
algorithme a pour objectif de fournir à la plate-forme d’administration développée
des listes d’éléments découverts, afin de permettre la programmation aisée d’itinéraires d’administration pour des agents mobiles d’administration système et
réseau.
Une fois une telle plate-forme disponible, nous sommes en mesure d’expliciter
en détails comment programmer aisément des agents mobiles d’administration
système et réseau (chapitre 6).
Le chapitre 7 a comme intérêt de valider cette plate-forme et son applicabilité.
On fournit des exemples réels d’implantation d’agents d’administration et des
mesures et des analyses de performances comparatives avec de l’administration
classique SNMP centralisée, et ce pour une large gamme de configuration de
réseau.
Nous concluons par un récapitulatif de la contribution que nous avons apportée quant à la mise en œuvre des itinéraires d’administration, et donnons les
perspectives associées à une telle mise en œuvre : supervision d’une plate-forme
à agents mobiles, supervision et aide à la répartition des agents mobiles sur une
grille de calculs, en sont des perspectives possibles.
Chapitre 2
L’administration des systèmes et
des réseaux
2.1
Motivation
L’évolution des moyens de communication mis à la disposition des entreprises,
l’hétérogénéité de l’infrastructure des réseaux et des éléments qui les composent,
la quantité d’informations dont veulent disposer les entreprises, tout cet ensemble
nécessite d’apporter une cohérence dans le fonctionnement de l’infrastructure de
communication.
Pour ce faire, et malgré la diversité des éléments constituant le cœur du réseau
(par exemple les équipements actifs) proposés par les constructeurs, l’administration des systèmes et des réseaux repose fondamentalement sur la connaissance
de l’infrastructure des réseaux et sur celle du fonctionnement des systèmes informatiques entrant en jeu. Le fonctionnement de ces systèmes doit être assuré
par un ou plusieurs administrateurs, en fonction du nombre d’éléments qui interviennent au sein de l’infrastructure de communication. Ces administrateurs
peuvent travailler de concert pour assurer la maintenance des différents matériels, la mise-à-jour des logiciels, la préparation et l’évolution des infrastructures
et la mise en service des nouveaux équipements. La connaissance du fonctionnement des réseaux permet aux administrateurs de choisir le type de techniques
adaptées afin d’en assurer la pérennité (par exemple doublage des équipements
actifs, liens de secours, liens hertziens, etc..).
Pour obtenir un fonctionnement quasi-permanent des systèmes et des réseaux,
les administrateurs doivent pouvoir récupérer à tout instant un rapport sur l’état
du fonctionnement du réseau et de celui des systèmes qui y sont connectés. Cela
implique une collecte des informations disponibles dans le réseau pour déterminer
son état. Les administrateurs peuvent déterminer, par la collecte des informations,
les défaillances possibles et les surcharges pouvant amener à un dysfonctionnement. Comme la quantité d’informations recueillie est importante, il va de soi que
15
16
L’administration des systèmes et des réseaux
cette tâche doit être automatisée pour que l’administrateur n’ait que de l’information utile pour effectuer son travail. C’est dans cette optique que les stations
et les logiciels d’administration ont été créés. Ces logiciels donnent une vue complète du réseau et ils permettent à l’administrateur (ou aux administrateurs) une
intervention rapide et efficace.
Dans la section 2.2 nous décrirons les tâches des administrateurs et les couches
du modèle OSI entrant en jeu dans un système d’administration de réseau. Le
kit de survie de l’administrateur réseau, c’est-à-dire les outils de base utiles à un
administrateur, sera présenté dans la section 2.3
Par la suite nous définirons dans la section 2.4 les protocoles d’administration de réseau et les outils les plus usités pour réaliser des tâches d’administration. Toutefois, les outils les plus usités dans le métier de l’administration réseau
fournissent des informations qui ne peuvent malheureusement pas être prises en
compte automatiquement par d’autres outils ou plates-formes que l’administrateur souhaiterait mettre en œuvre.
2.2
Définition de l’administration des systèmes
et des réseaux
L’administration des systèmes et des réseaux consiste à contrôler, coordonner
et surveiller les différentes ressources mises en œuvre afin de fournir des services
opérationnels aux utilisateurs : ces ressources sont les équipements, le réseau, les
services sont ceux offerts par les différents serveurs, les applications, Internet,
etc... Par exemple, ces services peuvent être :
– l’accès aux données et aux ressources informatiques partagées (base de données, annuaires, etc)
– la consultation des sites Internet ; l’accès au réseau informatique
Toute entreprise possédant un grand nombre d’ordinateurs, emploie des administrateurs de réseau et de systèmes pour assurer la qualité et la continuité du
service.
Le modèle de l’administration de réseau selon la classification SMFA (Specific
Management Functional Areas [29]) consiste en 5 domaines de compétence : la
gestion des performances, la gestion des fautes, la gestion de la configuration, la
gestion des informations comptables, la gestion de la sécurité.
2.2.1
Gestion des performances
Un administrateur réseau a comme responsabilité la mise en place, le suivi
et l’évolution des moyens de communication. Compte tenu de l’augmentation
régulière du trafic sur un réseau local, par exemple, un administrateur doit envisager le changement de l’infrastructure réseau afin d’améliorer le débit offert aux
utilisateurs. En fonction de la charge du réseau qu’un administrateur supervise,
Définition de l’administration des systèmes et des réseaux
17
il peut prévoir le changement de la structure de communication du réseau (cf.
figure 2.1) en introduisant une segmentation du trafic par l’ajout d’un nouvel
équipement actif (par exemple, un commutateur). La conséquence directe sera
l’amélioration du trafic dans le cœur du réseau et une meilleure segmentation du
trafic (cf. figure 2.2) dans chaque sous-réseau connecté.
Pour superviser les moyens de communication, l’administrateur peut disposer
d’outils d’analyse (par exemple Multi Router Traffic Grapher [56], HP Network
Node Manager [35]) afin de suivre en temps réel les différents flux qui circulent sur
les réseaux dont il a la charge. De tels outils d’analyse permettent d’effectuer des
prospectives d’évolution de l’infrastructure physique tant sur le point de vue du
changement de débit que sur le type de liaison utilisée (par exemple : une liaison
spécialisée plutôt qu’une liaison point-à-point Numéris active à la demande).
Hub
Hub
Ether 10/100
Ether 10/100
COL
12 345 678 100
1012 36 12255080
! Power
COL
12 345678 100
101236 12255080
! Power
Fig. 2.1 – Réseau Ethernet non segmenté
Commutateur
Hub
Ether 10/100
COL
12 345 678 100
1012 36 12255080
! Power
Ethernet
Switch
Hub
Ether 10/100
COL
12 345678 100
101236 12255080
! Power
Fig. 2.2 – Réseau Ethernet segmenté
2.2.2
Gestion des fautes
Quels que soient les systèmes informatique dont l’administrateur a la charge,
chacun de ces systèmes ne peut être exempt d’erreurs. Le travail de l’administrateur consiste à assurer le fonctionnement de ces systèmes. Par exemple, la
panne d’un commutateur dans le réseau est un événement rare mais très important dont l’administrateur doit tenir compte dans ses procédures de gestion des
incidents. L’administrateur doit être en mesure de pouvoir prendre les décisions
nécessaires afin de corriger dans un temps très bref la défaillance de son système.
Les procédures mises en place pour assurer la continuité de service ou un fonctionnement en mode dégradé sont des éléments nécessaires pour que les usagers
de l’infrastructure de communication soient le moins pénalisés par des pannes sur
le réseau.
18
2.2.3
L’administration des systèmes et des réseaux
Gestion de la configuration
Un administrateur de systèmes informatique a pour tâche l’installation, la
mise en route de services réseaux et la maintenance de ces différents systèmes.
L’administrateur assure aussi la configuration, la mise à niveau des équipements
actifs de l’infrastructure du réseau et il se trouve en mesure de prévoir les différentes opérations de maintenance nécessaires. Par exemple, le changement de la
version d’un système d’exploitation sur un commutateur faisant suite à un avis
du constructeur de l’équipement actif est une tâche qui lui incombe et qu’il doit
mettre en œuvre.
L’administrateur est responsable de l’adressage des machines sur le réseau,
il suit l’évolution du parc de machines connectées et il organise, si nécessaire, le
redéploiement des systèmes sur son infrastructure de communication.
Pour être aidé dans sa tâche de gestion, l’administrateur peut disposer en fonction du type du système d’exploitation de ses systèmes, d’outils divers et variés
mais dont l’usage reste souvent propriétaire à un type de plate-forme (WinNT,
Solaris, etc..). Par exemple, Webmin [16] fonctionnant sous Linux permet à un
administrateur d’effectuer de la maintenance ou de la configuration de son système.
2.2.4
Gestion des informations comptables
Un administrateur peut fournir aux instances dirigeantes de son entreprise les
coûts engendrés par telle ou telle application. Pour cela, l’administrateur réalise
des calculs de coûts en fonction des débits réseaux utilisés, de la charge des machines sur lesquelles tournent les applications. L’administrateur doit disposer pour
cela d’outils pour mesurer le trafic, calculer le taux de charge des applications. Par
exemple, les applications Internet payantes (http://link.springer.de) sont à
la charge de l’administrateur qui doit assurer pour son entreprise la comptabilisation des accès aux services fournis et permettre l’ouverture de nouveaux accès
à ces mêmes services.
2.2.5
Gestion de la sécurité
Un administrateur système et un administrateur réseau doivent travailler de
concert pour la mise en œuvre de nouveaux services. Les administrateurs doivent
assurer la sécurité des informations et la sécurité des accès. Par exemple, un annuaire d’entreprise doit pouvoir être consulté mais il convient de s’assurer que la
population ayant accès à ces informations soit une population limitée : un Internaute quelconque ne bénéficierait pas des mêmes droits d’accès qu’un employé de
l’entreprise hébergeant ce service. Il s’agit donc d’avoir des procédures de mise
en route de nouveaux services tout en préservant la sécurité et la fonctionnalité
des services déjà existant.
Le kit de survie de l’administrateur réseau
2.3
19
Le kit de survie de l’administrateur réseau
L’objectif de cette section est de présenter les couches du modèle OSI qui
sont directement liées au métier de l’administrateur réseau : la couche physique,
la couche liaison de données et la couche réseau, toutes les trois intervenant dans
le fonctionnement d’un réseau. Nous donnerons les détails des concepts et des
outils qu’il est nécessaire de connaître afin de pouvoir comprendre le métier de
l’administrateur de réseau.
Définition 1 Équipements actifs : Le terme équipements actifs, sous entend dans
ce manuscrit, les éléments qui sont connectés sur un réseau, qui participent à son
fonctionnement et qui sont administrables, c’est-à-dire équipés d’un agent SNMP.
Définition 2 Réseau : Le réseau est l’ensemble de voies de communication, conducteurs électriques, etc., qui desservent une même unité géographique, dépendant
de la même entreprise. Nous nous baserons sur cette définition pour nous rapprocher plus précisement du réseau que nous utilisons tous les jours, c’est-à-dire un
moyen de communication et d’échange entre différentes entités.
Ainsi, le réseau en tant qu’entité communiquante est la partie principale de
notre préoccupation puisque celle-ci se situe au cœur de tout le trafic qui y circule.
Il va de soi qu’il faut donc une architecture physique afin de relier les entités le
constituant et des protocoles de communication pour permettre à ces différentes
entités de dialoguer entre elles. Pour définir les différents niveaux permettant à
ces entités de dialoguer entre elles, l’ISO (organisation internationale de normalisation) a donc défini un modèle en sept couches appelé modèle de référence
(modèle OSI : Open Systems Interconnection). Ce modèle en sept couches est
défini comme suit : Physique, Liaison, Réseau, Transport, Session, Présentation,
Application.
Dans ce modèle et en rapport avec l’administration des systèmes et des réseaux, nous nous préoccuperons principalement de deux couches du modèle OSI :
la couche liaison et la couche réseau [91]. Effectivement, ces deux couches ont
une très grande importance puisqu’elles relèvent activement du fonctionnement
du réseau, et qu’il est nécessaire d’assurer leur disponibilité et leur fiabilité.
2.3.1
La couche physique
C’est la couche qui s’occupe de la transmission des bits d’information de façon
à ce que le récepteur des données recueille une information non altérée par le canal
de communication.
La partie physique d’une architecture réseau dépend de la qualité de service
que l’on souhaite obtenir. Plusieurs types de couche physique existent, comme
la partie en câble coaxial (10Base-2 ou 10Base-5 [1]), le câble téléphonique à
20
L’administration des systèmes et des réseaux
paires torsadées (10BaseT ou 100BaseT [1]), les connexions en fibre optique, les
connexions par voie hertzienne, etc.., tout ce qui permet de faire circuler de l’information. La qualité de l’installation de cette couche est primordiale puisqu’elle a
une incidence sur le fonctionnement même du réseau. Par exemple, un connecteur
RJ45 mal serti engendrerait des perturbations sur le réseau (collision, tentative
pour trouver la vitesse du média, etc..).
Le contrôle de la qualité de cette liaison peut se faire par exemple dans le cas
d’un réseau 10Base-T, par l’utilisation d’un testeur de câbles. Cette technique
permet de se rendre compte des problèmes de connectivité électrique sur le média
utilisé.
2.3.2
La couche liaison de données
La tâche principale de cette couche est de prendre un moyen de communication brut et de le transformer en une liaison qui paraît exempte d’erreurs de
transmission à la couche réseau (on parle de trames). Quelques types de protocoles
sont utilisés pour assurer le fonctionnement du canal de communication comme le
protocole CSMA/CD [60], l’anneau à jeton [61], ou de façon plus évoluée l’ATM
(Asynchronous Transfert Mode [5]).
Pour vérifier la qualité du canal de communication offerte par la couche de
liaison dans le cas d’une topologie réseau en étoile, une technique simpliste mais
assez efficace consiste à utiliser deux ordinateurs connectés sur un concentrateur
(Hub) ou un commutateur (Switch) et d’appliquer un outil client/serveur qui
émet des trames depuis un poste à destination de l’autre. Si dans ce cas les trames
émises sont reçues par l’autre ordinateur, alors le canal de communication peut
être considéré comme fiable.
Nous allons détailler les réseaux de type Ethernet [1]. Ces réseaux sont les plus
courants et la technologie Ethernet a permis une large diffusion de ces réseaux
dans les entreprises. Dans ce type de réseau, les stations partagent le même
canal de communication et elles échangent entre elles des trames. Le protocole
CSMA/CD a été défini pour l’accès partagé à ce média de communication.
Les premiers réseaux de type Ethernet utilisaient une technologie de type câble
coaxial pour fonctionner selon une topologie en bus (cf. figure 2.3). Ces réseaux
fonctionnaient sans équipement actif intermédiaire. L’évolution des technologies a
permis d’abandonner ce type de technologie et de passer à des réseaux construits
sur une topologie en étoile. Le cœur de ces réseaux est composé d’équipements
actifs intelligents (par exemple pour une meilleure gestion du trafic). Nous étudierons plus précisément les réseaux Ethernet en étoile puisque ceux-ci nécessitent
la présence d’équipements actifs pour fonctionner. En effet, la construction de la
topologie en étoile nécessite du matériel actif pour connecter le cœur du réseau
et les autres éléments (PC, Imprimantes, équipements actifs , etc..). La figure
2.4 présente un exemple de réseau typique sur lequel nous avons conduit nos
expérimentations.
Le kit de survie de l’administrateur réseau
21
Postes de travail sur le réseau, PC, Mac, Serveurs d’’impressions, etc...
Fig. 2.3 – Exemple d’une topologie en bus
Vers l’Internet ou un autre réseau de l’entreprise
Routeur
Ether 10/100
Commutateur, coeur du réseau
COL
1 2 3 4 5 6 7 8 100
10 1 2 3 6 12255080
Commutateur
Power
Serveur Web, Messagerie
Proxy, Annuaire
Station de supervision
Modem
Pont Ethernet
Concentrateur
Commutateur
Ether 10/100
COL
1 2 3 4 5 6 7 8 100
10 1 2 3 6 12255080
Commutateur
Power
Postes de travail sur le réseau, PC, Mac, Serveurs d’impression, etc...
Fig. 2.4 – Exemple d’une topologie en étoile
Avec l’évolution des techniques relatives à la couche de liaison de données,
plusieurs équipements actifs existent sur le marché informatique, dont principalement :
– les ponts Ethernet (Bridges) : ces équipements actifs ne font que répéter le
signal du canal de communication à destination des autres interfaces qu’ils
possèdent,
– les concentrateurs (Hubs) : ces équipements actifs répètent le signal reçu
sur tous les ports de sortie excepté celui par lequel est arrivée l’information,
– les commutateurs (Switches) : ces équipements actifs répètent le signal sur
le port de sortie qui correspond à l’adresse MAC (Medium Access Control)
du destinataire ou sur tous les ports si le port de destination est inconnu
(retransmission en mode de diffusion),
– les routeurs : ces équipements actifs transportent les paquets IP d’un réseau
vers un autre réseau de destination.
L’avantage d’une topologie en étoile par rapport à une topologie en bus est que
lorsque une connexion du réseau devient défaillante sauf sur le cœur du réseau,
les communications sur le réseau perdurent à l’exception du brin défaillant, sauf
si tous les services du réseau sont concernés par cette défaillance. Il s’agit là
effectivement d’une meilleure sécurité pour assurer une qualité de service plus
importante aux usagers.
22
L’administration des systèmes et des réseaux
2.3.3
La couche réseau
Cette couche permet de gérer la façon par laquelle les informations (ici paquets) sont acheminées depuis l’émetteur jusqu’au destinataire, et de s’assurer
que l’information sera récupérée dans le même ordre qu’elle a été émise. Le protocole réseau le plus usité de nos jours reste le protocole IP [39], avec les deux
couches de transport : UDP [96] et TCP [93]. Pour avoir un aperçu du fonctionnement d’un réseau, nous allons présenter quelques outils qui servent dans le
suivi et l’observation de la couche réseau. Nous ne détaillerons pas les protocoles
associés.
Ping-Pong Pour vérifier la connectivité entre deux ordinateurs possédant une
adresse IP, le protocole ICMP (Internet Control Message Protocol) [38] est utilisé. Son fonctionnement de base est le suivant : émission d’un datagramme vers
une machine de destination (ICMP Echo-Request), qui demande à la machine de
destination de répondre par un datagramme vers l’émetteur (ICMP Echo-Reply).
Son fonctionnement est relativement simple, mais l’utilisation de ce protocole permet de déterminer rapidement la panne d’un équipement actif du réseau. Il s’agit
ici d’utiliser une des nombreuses fonctionnalités de ce protocole. La commande
système associée la plus utilisée est la commande ping (cf. table 2.1 par exemple).
Ping de pacifique.iufm.unice.fr vers
Réponse de www.unice.fr
www.unice.fr
octets=32 temps <10 ms TTL=128
Tab. 2.1 – Exemple de résultat de la commande ping
La table 2.1 donne le compte rendu de l’exécution de la commande ping. La
machine www.unice.fr a répondu avec un temps inférieur à 32 ms. Le paquet IP
de retour a une durée de vie de 128 (Time To Live, le délai de vie du paquet sur
le réseau IP).
Résolution des Adresses
Quel que soit l’emplacement de la connexion
physique des ordinateurs (Local Area Network (LAN) ou Wide Area Network
(WAN)), un autre protocole entre en jeu afin d’effectuer le lien entre la couche
réseau et la couche liaison de données. Ce protocole, appelé ARP (Address Resolution Protocol) [65] , permet de faire l’association de l’adresse IP de l’équipement
avec l’adresse physique de la carte réseau de l’équipement. Si deux machines sont
sur le même réseau local, le protocole ARP associera l’adresse IP de la machine
avec l’adresse Ethernet de la carte réseau (cf. table 2.2). Ce protocole permettra
à la couche réseau de joindre la machine destinataire et de lui transmettre la
ou les trames de données. Si les deux machines ne sont pas sur le même réseau
local (cas du WAN), un appel à ce protocole est également réalisé. La machine
utilisera tout d’abord sa table de routage pour trouver le routeur intermédiaire,
Le kit de survie de l’administrateur réseau
23
recherchera son adresse Ethernet, et transmettra donc le message à ce routeur
pour que celui-ci soit acheminé. La commande système qui est associée est la
commande arp.
arp -a
Adresse Internet (IP)
192.168.80.30
Adresse physique (MAC)
00 :04 :76 :97 :86 :46
Méthode d’apprentissage
dynamique
Tab. 2.2 – Exemple de résultat de la commande arp
La méthode d’apprentissage des adresses Ethernet par le protocole ARP est
de deux types :
– Statique : les entrées dans cette table sont faites de manière manuelle (faites
par l’administrateur)
– Dynamique : l’adresse Ethernet de l’hôte distant est apprise par le protocole,
mise en cache pour être réutilisée ultérieurement. Il existe un délai de garde
à partir duquel l’adresse sera effacée du cache (en général 5 minutes).
Suivi des trames IP Un autre outil qui utilise le protocole ICMP pour avoir le
chemin parcouru par les paquets IP entre deux stations distinctes est traceroute.
La table 2.3 donne le chemin parcouru par un paquet IP entre une station du
réseau 134.59.80.0 et la station d’adresse 134.59.1.71 (www.unice.fr). Cet outil
utilise la spécification de la durée de vie d’un paquet IP dans le réseau (champ
TTL du paquet IP) pour découvrir le chemin parcouru entre l’émetteur et le
destinataire.
traceroute
1 <10 ms <10 ms <10 ms
2 <10 ms <10 ms <10 ms
3 <10 ms <10 ms <10 ms
www.unice.fr
gw-80.iufm.unice.fr [134.59.80.254]
router-priv [172.16.250.1]
www.unice.fr [134.59.1.71]
Tab. 2.3 – Exemple de résultat de la commande traceroute
Les trois commandes présentées ci-dessus (ping, arp et traceroute) sont des
commandes fournies en standard dans les systèmes d’exploitation. Ces commandes donnent un diagnostic primaire d’une perte de connectivité entre deux
éléments du réseau (soit sur un LAN, voire même dans le cas d’un WAN). Toutefois, leurs possibilités limitées de diagnostic ont ouvert la voie vers des outils
d’administration de systèmes et de réseaux par l’utilisation de protocoles d’administration de réseau comme décrit dans la section suivante.
24
L’administration des systèmes et des réseaux
Scan d’un réseau Un outil du domaine public, nmap [102], permet de scanner
un réseau cible afin d’y trouver les services existants ainsi que de prédire le type de
système d’exploitation par adresse IP découverte. Le résultat obtenu par cet outil
de scan peut être utilisé pour définir de façon très approximative la topologie du
réseau cible. En effet, les routeurs, les commutateurs sont détectés par cet outil,
ce qui donne cette approximation.
Il fonctionne comme suit : par exemple, la commande nmap -sT 192.168.80.0
cherchera tous les éléments du réseau et leurs services associés en partant de
l’adresse IP 192.168.80.1 jusqu’à l’adresse 192.168.80.255. Le résultat (voir
un extrait table 2.4) de cet outil ne sera pas directement exploitable, mais celui-ci
permet de connaître les éléments du réseau actif et leurs services.
nmap -sT 192.168.80.0
Interesting ports on rtlocal (192.168.80.222) :
Port
State Service
79/tcp
open finger
514/tcp
open shell
2001/tcp open dc
6001/tcp open X11 :1
TCP Sequence Prediction : Class=random positive increments
Difficulty=2198 (Medium)
Remote operating system guess :
Cisco Router/Switch with IOS 11.2
Tab. 2.4 – Exemple de résultat de la commande nmap -sT 192.168.80.0
2.4
L’administration de réseau
Un outil typique destiné à l’administration de réseaux consiste en un outil qui
fonctionne en mode Client/Serveur, associant une station d’administration de réseau (NMS) et les équipements actifs du réseau (cf. figure 2.5). Pour fonctionner,
ces outils utilisent soit le protocole SNMP (voir section 2.4.1) dans le monde des
réseaux IP ou le protocole CMIP (voir section 2.4.2) dans le monde des télécommunications. Nous parlerons plus précisément du protocole SNMP puisque
notre travail de recherche s’est illustré plus spécifiquement dans le contexte de
l’administration des réseaux IP et des réseaux locaux (LAN).
2.4.1
Le protocole d’administration de réseau : SNMP
SNMP (Simple Network Management Protocol) [86] est un protocole d’administration de réseau qui se veut simple dans son utilisation. Afin de pouvoir l’utili-
L’administration de réseau
25
ser, il est nécessaire que les équipements actifs du réseau soient équipés d’un agent
SNMP. Partant de cette hypothèse, il est possible de les interroger en utilisant
le protocole SNMP. L’information qu’un administrateur réseau pourra recueillir
dans un agent SNMP se trouve regroupée dans la MIB (Management Information
Base) décrite ci-après. Ce protocole étant basé sur un modèle Client/Serveur (cf.
figure 2.5), la station d’administration émet un paquet UDP représentant une
requête SNMP à destination de l’équipement actif du réseau à administrer. Cette
requête doit contenir le nom de la communauté SNMP de lecture (respectivement le nom de la communauté de lecture/écriture) pour accéder en lecture aux
variables de la MIB SNMP (respectivement en lecture/écriture).
Station d’administration
Plate−forme
d’administration
Hote
Hote
Agent
d’admin
Agent
d’admin
Agent
d’admin
Protocole
d’administration
Routeur
Fig. 2.5 – Architecture Client/Serveur sur laquelle se base l’utilisation d’un protocole d’administration dans un réseau
Lorsque l’agent SNMP est en mesure de répondre, il retourne, dans un paquet
UDP vers l’émetteur, les valeurs des variables SNMP demandées.
2.4.1.1
MIB-2 SNMP
Chaque agent SNMP met à la disposition de la station d’administration des
objets (appelés aussi variables) qui sont structurés dans une MIB (Management
Information Base) [104] définie par la RFC-1213 [87]. Ces objets sont réunis dans
des groupes (le groupe system décrit l’équipement actif, et par exemple la valeur
de la variable system.sysDescr.0 peut être la chaîne de caractères suivante : Linux
olddell.iufm.unice.fr 2.4.18-6mdk).
Chaque objet est identifié dans la MIB SNMP par un oid (Object IDentifier,
voir la figure 2.6) qui définit sa position au sein de la structure arborescente de
la MIB. En suivant l’arbre présenté par la figure 2.6 depuis la racine jusqu’à une
feuille, on forme l’oid. Cet oid est constitué d’une suite d’étiquettes numériques
séparées par des points.
Par exemple, l’oid 1.3.6.1.2.1.1.1.0 (cf. figure 2.7) correspond à la variable
systemDescr du groupe system de la MIB. La valeur 0 à la fin de l’oid correspond
26
L’administration des systèmes et des réseaux
iso(1)
org(3)
dod(6)
internet(1)
directory(1) mgmt(2)
experimental(3) private(4)
mib−2(1)
objets de la MIB
Fig. 2.6 – Structure d’indexation des données dans la MIB-2 SNMP
au fait que la variable recherchée est un objet simple (system.systemDescr.0 ). Par
contre si la variable est une table on trouvera oid.<valeur index 1>....<valeur
index n> (par exemple interfaces.ifTable.ifEntry.1 jusqu’à la valeur interfaces.ifTable.ifEntry.n).
Les groupes les plus utilisés dans la MIB-2 SNMP sont regroupés dans la table
2.5 et une partie de la structure de la MIB SNMP est présentée par la figure 2.7.
Un exemple : le groupe IP de la MIB-2 SNMP Le protocole IP est
un protocole qui délivre des datagrammes (mode non connecté) sur le réseau.
Le groupe IP fournit les informations relatives au fonctionnement du protocole
IP (oid de base du groupe IP = 1.3.6.1.2.1.4, c’est-à-dire iso.org.dod.internet.mgmt.mib-2.ip) sur l’équipement actif. On y trouve, par exemple, la table de
routage (ipRouteTable), la table ARP par interfaces de l’équipement actif (ipNetToMediaTable) et une autre table qui donne les informations des adresses IP
de l’équipement actif par numéro d’interface (ipAddrTable).
2.4.1.2
Fonctionnement du protocole
Le protocole SNMP définit 5 types de messages (Protocol Data Unit) (voir la
table 2.6). Les messages de type Get-Request, Get-Next-Request sont des messages
L’administration de réseau
Nom de la MIB-2 SNMP
System
Interfaces
Ip
Icmp
Tcp
Udp
Egp
Transmission
Snmp
27
Utilité
Nom, emplacement et description de l’équipement
et notamment le type de service fourni par l’équipement
(hub, switch, router,..)
Interfaces réseau et les données liées au trafic mesuré
Par exemple : Type et nombre d’interfaces réseau
Statistiques sur le trafic IP, table de routage,
table ARP, . . . (...)
Statistiques sur le trafic ICMP
Paramètres et statistiques du trafic TCP,
par exemple : la table des connexions TCP
Paramètres et statistiques du trafic UDP
Informations sur la mise en œuvre du protocole EGP
(External Gateway Protocol)
Informations au sujet des moyens de transmission et des
protocoles d’accès aux interfaces de l’équipement
Paramètres et statistiques du trafic SNMP
Tab. 2.5 – Informations principales de la MIB-2 SNMP
utilisés pour de la collecte d’informations d’administration sur un agent SNMP.
Le message de type Get-Request est émis depuis un outil de supervision vers
un agent SNMP. L’agent SNMP répond par un message de type Get-Response
contenant la valeur des variables demandées.
Le message particulier Get-Next-Request est un message qui demande à l’agent
SNMP la variable suivante dans la MIB SNMP. Par exemple, un message GetNext-Request 1.3.6.1.2.1.1.1.0 (system.systemDescr.0 ) vers un agent SNMP sera
suivi d’un message de type Get-Response contenant la valeur de l’objet d’Oid
1.3.6.1.2.1.1.2.0 correspondant à l’objet system.sysObjectID. Par un échange de
messages de type Get-Next-Request et Get-Response entre l’outil de supervision
et un agent SNMP, il est possible d’obtenir toute la MIB de l’agent SNMP.
Un message de type Set-Request émis par l’outil de supervision à destination
de l’agent SNMP permet la mise-à-jour d’une ou plusieurs variables. La réponse
en retour est soit la liste des variables mises à jour soit un message d’erreur
rapportant une incohérence dans la mise à jour (cf. table 2.9).
Un message de type Trap peut être émis depuis l’équipement actif vers la
station d’administration, message non sollicité, afin de prévenir la station d’administration d’un événement pour lequel l’agent SNMP a été programmé. Par
exemple, une trap SNMP peut être émise lors du changement d’état d’une interface réseau (ex : passage du statut linkUp au statut linkDown). L’administrateur
configure l’agent SNMP pour que celui-ci émette une alerte, en spécifiant le type
28
L’administration des systèmes et des réseaux
iso(1)
org(3)
dod(6)
internet(1)
directory(1)
mgmt(2)
mib−2(1)
system(1)
interfaces(2)
at(3) deprecated
ip(4)
icmp(3)
tcp(6)
sysDescr(1)
sysObjectID(2)
sysUpTime(3)
sysContact(4)
sysName(5)
sysLocation(6)
sysServices(7)
udp(7)
egp(8)
transmission(10)
snmp(11)
experimental(3)
private(4)
enterprises(1)
Fig. 2.7 – Les groupes d’objets de la MIB-2
d’alerte et l’adresse IP de la station d’administration de réseau.
2.4.1.3
Quelques exemples d’informations stockées dans la MIB-2
SNMP
Les commandes que nous avons présentées dans la section 2.3.3 permettent
d’obtenir des informations sur le fonctionnement du réseau, mais ces mêmes informations peuvent être obtenues en collectant des données dans la MIB d’un agent
SNMP. Pour cela, nous allons présenter le groupe system, et quelques tables du
groupe ip donnant des informations sur la table ARP et la table de routage de
l’élément.
2.4.1.4
Groupe system
Pour déterminer les types de services fournis par l’équipement actif sur lequel
nous collectons des données, nous utilisons les informations contenues dans le
groupe System.sysServices de la MIB.
La liste ci-dessous donne un exemple des valeurs de cette variable en fonction
des services fournis par un équipement actif. Le niveau de fonctionnalité est :
– 1 physical (par exemple répéteur ou concentrateur)
L’administration de réseau
Emetteur
Station
Station
Message
GetRequest
GetNextRequest
Station
Agent SNMP
Agent SNMP
SetRequest
GetResponse
Trap
29
Fonctionnalité
obtenir une variable
obtenir variable suivante
(si existante, sinon retour d’erreur)
modifier la valeur d’une variable
retour de la réponse
message d’alerte de l’agent SNMP
vers la station d’administration
Tab. 2.6 – Opérations définies par le protocole SNMP
–
–
–
–
2 datalink/subnetwork (par exemple commutateur)
3 internet (par exemple passerelle IP, routeur)
4 end-to-end (par exemple élément du réseau, PC)
7 application (par exemple un relais de messagerie, une imprimante en
réseau)
Par exemple, pour un concentrateur exécutant des fonctions de répéteurs avec
un agent SNMP, la valeur de la variable system.sysServices sera 1. Un élément
n’effectuant que des tâches de routage de trafic aura comme valeur de la variable
system.sysServices la valeur 4. Un élément effectuant des fonctions de niveau 2 et
de niveau 3 aura comme valeur pour la variable system.sysServices la valeur 6. La
technique pour connaître le type de service fourni est d’utiliser la décomposition
de la valeur de la variable suivant la somme de 2N iveau−1 , c’est-à-dire l’utilisation
d’un masque binaire, comme définie dans la RFC-1213 [87], où chaque niveau
correspond à la couche OSI.
2.4.1.5
Groupe ip : la table de routage
La table de routage d’un réseau local nous donne le chemin parcouru par les
paquets IP entre le réseau local et le réseau extérieur. Pour obtenir ces informations par le biais de l’agent SNMP, nous collectons la table ip.ipRouteTable.
Chaque ligne de la table 2.7 est une entrée de la table ip.ipRouteTable.
2.4.1.6
Groupe ip : la table ARP
Sur les équipements actifs du réseau local (par exemple un routeur ou un
commutateur), une collecte de la table ip.ipNetToMediaTable permet d’avoir les
mêmes informations que celles obtenues par la commande Unix arp -a (voir section 2.3.3). La table 2.8 en donne un aperçu.
30
L’administration des systèmes et des réseaux
SNMP : IpRouteTable
ipRouteDest
255.255.255.255
192.168.81.0
192.168.80.0
192.168.1.0
192.168.82.0
192.168.11.0
192.168.10.0
127.0.0.0
0.0.0.0
ipRouteNextHop
0.0.0.0
192.168.80.253
0.0.0.0
192.168.80.244
192.168.80.253
192.168.80.244
192.168.80.244
0.0.0.0
192.168.80.253
ipRouteMask
255.255.255.255
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.0.0.0
0.0.0.0
ipRouteIfIndex
2
2
2
2
2
2
2
2
2
Tab. 2.7 – Exemple d’une table de routage obtenue en SNMP
Address IP
(ipNetToMediaNetAddress)
192.168.80.30
192.168.80.241
192.168.80.10
192.168.80.245
192.168.80.244
192.168.80.7
Address Physique
(ipNetToMediaPhysAddress)
00 :04 :76 :97 :86 :46
00 :06 :5B :D1 :50 :5B
00 :30 :05 :08 :23 :39
00 :02 :16 :57 :43 :00
00 :10 :7B :3A :20 :B5
00 :D0 :B7 :7E :73 :AD
Interface
(ipNetToMediaIfIndex)
2
2
2
2
2
2
Tab. 2.8 – Exemple d’une table ARP obtenue en SNMP
L’administration de réseau
2.4.1.7
31
Gestion des interfaces
Nous présentons ici la commande Unix snmpset qui permet de modifier une
valeur dans la MIB-2 SNMP. L’exemple de la table 2.9 permet de changer le
statut d’une interface d’un commutateur de Up (valeur 1) à Down (valeur 2).
Le protocole SNMP retourne la valeur qui a été affectée par l’opération SET du
protocole.
Commande
Résultat
Commande
Résultat
snmpset -v1 -c private 192.168.80.246
interfaces.ifTable.ifEntry.ifAdminStatus.4 integer 2 (down)
interfaces.ifTable.ifEntry.ifAdminStatus.4 = down(2)
snmpset -v1 -c private 192.168.80.246
interfaces.ifTable.ifEntry.ifAdminStatus.4 integer 4 (Valeur incorrecte)
Error in packet.
Reason : (badValue) The value given has the wrong type or length.
Tab. 2.9 – Exemple d’utilisation de la commande snmpset sur un commutateur
2.4.1.8
Evolution du protocole SNMP
Le nouveau standard : le SNMP V3 Les fonctionnalités de base du protocole SNMP V1 (mais aussi SNMP V2, non détaillé ici, voir [19]) que nous venons
de décrire, n’offrent pas de mécanisme de sécurité permettant d’authentifier la
source d’un message, ni de fournir un quelconque cryptage des données. Pour
cela, le protocole SNMP V3 [20] a été défini pour palier aux insuffisances des
deux versions précédentes du protocole.
Ce protocole vise essentiellement à inclure la sécurité des transactions, notamment l’identification des parties et la confidentialité. Le protocole SNMP V3
se veut modulaire dans son implémentation :
– Transport : module responsable du transport. Il se présente sous la forme
d’un module et non pas dans le moteur SNMP pour rendre indépendante
la description SNMP V3 de UDP.
– Module de traitement : module responsable d’encoder et décoder les paquets
SNMP en respectant le numéro de version du standard (V1, V2 ou V3). On
a fait de cette tâche un module externe au moteur pour permettre l’adaptation aux prochaines versions de SNMP. Plusieurs modules de traitements
peuvent fonctionner simultanément. Il est donc possible pour un moteur
SNMP de traiter des messages de différentes versions en même temps.
– Sécurité : la sécurité concerne l’authentification, l’encryption et la vérification du temps écoulé entre l’échange de deux paquets afin que la capture
d’un paquet ne permette pas son utilisation ultérieure à des fins de deni de
service.
32
L’administration des systèmes et des réseaux
– Applications : il s’agit des processus qui interagissent avec le moteur SNMP
en utilisant des messages qui peuvent être définis dans le protocole ou des
messages décrits par une mise en œuvre spécifique du moteur. Les applications sont développées pour effectuer des opérations de gestion spécifiques.
Les objectifs peuvent être très variés d’une application à une autre mais
elles utilisent en commun le même moteur SNMP pour effectuer les opérations de gestion. Selon les applications, l’entité peut jouer le rôle de superviseur et converser avec un autre superviseur en échangeant des requêtes
d’informations. Cela permet un échange d’informations sur le système d’administration qui n’existait pas dans les versions précédentes du protocole.
– Contrôle d’accès : le module du contrôle d’accès doit décider si une requête
est permise et si une réponse peut être envoyée ou l’ignorer si une personne
non autorisée a fait la requête.
La sécurité dans le protocole SNMP V3 peut aller de l’authentification d’un
utilisateur (plus sécurisé que le nom de la communauté SNMP en V1 et V2), à
l’authentification de l’émetteur des messages et au cryptage des paquets échangés.
Les aspects liés à la sécurité du protocole SNMP V3, contenues dans le User
Security Module sont décrites ci-dessous.
Authentification : l’authentification a pour but d’assurer que le paquet n’a
pas subi de modification en cours de route et que le mot de passe de l’entité
émettrice est valide. Elle utilise les fonctions de hachage à une direction (MD5 et
SHA-1). Les données obtenues et le code de hachage sont transmis sur le réseau.
Avec cette technique, le mot de passe est validé sans qu’il ait été transmis sur le
réseau.
Localisation des mots de passe : ce mécanisme permet que la sécurité d’un
domaine d’administration soit garantie même si la sécurité d’un des agents SNMP
du domaine a été compromise. SNMPv3 préconise l’utilisation d’un seul mot
de passe, pour tous les échanges avec les agents SNMP, mais ajoute une étape
de localisation. Un mot de passe localisé ne fonctionne qu’avec un seul agent.
Pour localiser, une chaîne de caractères unique est déterminée pour chaque agent.
SNMPv3 utilise le ContextEngineID 1 . Cette chaîne de caractères est générée par
un ensemble de données relatif à l’agent : adresse MAC de la carte ethernet,
adresse IP, etc.. Le ContextEngineID est groupé avec le mot de passe et le résultat
est transmis à une fonction de hachage à une direction où il sera vérifié comme
dans l’étape d’authentification.
Encryption : l’encryption empêche de lire les informations de gestion contenues dans un paquet SNMPv3. SNMPv3 utilise pour l’encryption un deuxième
1
Un agent SNMP V3 peut contenir plusieurs agents SNMP, cette chaîne permet donc de
converser avec le bon agent SNMP
L’administration de réseau
33
mot de passe partagé entre la station de gestion et l’agent. SNMPv3 se base sur
DES (Data Encryption Standard) pour effectuer l’encryption.
Estampillage du temps : ce mécanisme vise à empêcher la réutilisation d’un
paquet SNMPv3 valide déjà transmis. Le temps est estampillé sur chaque paquet.
Quand le paquet est reçu, le temps actuel est comparé avec le temps indiqué sur
le paquet. Si la différence est supérieure à 150 secondes, le paquet est ignoré.
2.4.2
Le protocole CMIP
Le protocole CMIP [104] est un protocole d’administration de réseau, qui supporte l’échange d’informations entre l’application d’administration et les agents
d’administration.
SNMP a été développé comme solution de transition plus simple de CMIP/CMIS
en attendant que le support logiciel de CMIP/CMIS soit suffisant. SNMP avait
pour objectif de disparaître dès la généralisation de CMIP/CMIS.
L’information d’administration échangée entre l’application et les agents est
faite par le biais d’objets (CMIP/CMIS), qui représentent l’entité à administrer2 .
Ces objets peuvent être modifiés ou contrôlés et ils peuvent être utilisés pour
effectuer des tâches sur l’agent administré.
Le protocole CMIP est un protocole largement utilisé dans le domaine des
télécommunications. Cependant, ce protocole consomme beaucoup de ressources
sur le système administré, ce qui fait que ce protocole n’est pas très largement
diffusé. De plus, le protocole CMIP est défini pour fonctionner sur la pile du
protocole OSI. Cependant, le standard utilisé de nos jours dans la majorité des
environnements de réseaux locaux (LAN) est le protocole TCP/IP3 . Pour preuve
du succès plus important de SNMP, c’est que la plupart des équipements actifs
n’implémentent que le protocole SNMP 4 .
2.4.3
Administration répartie
Ce que nous venons de décrire, aussi bien en terme d’outils permettant la détection des incidents du réseau, ou en terme d’utilisation d’un protocole d’administration de réseau (SNMP) sont des techniques centralisées. Nous allons maintenant présenter quelques évolutions vers l’administration de réseau distribuée,
en présentant l’évolution des MIBs SNMP pour intégrer de l’administration de
réseau répartie, proposée par le groupe de l’IETF DISMAN (pour Distributed
2
L’objet est l’encapsulation des données qui sont associées à la ressource, combiné à la partie
logicielle adaptée à la ressource, qui implémente les opérations qui peuvent être faites sur les
données.
3
TCP/IP ne calque pas complètement sur les couches OSI.
4
Une implémentation de CMIP sur TCP/IP existe et elle s’appelle CMOT [24] : CMIP over
TCP.
34
L’administration des systèmes et des réseaux
Management). L’engorgement de plus en plus important des stations d’administration a incité les fondateurs à proposer une amélioration de la MIB SNMP
permettant une administration répartie. Deux propositions ont été faites, l’approche par scripts et l’approche par MIB.
Dans cette extension de SNMP, on définit les tâches du gestionnaire ainsi
que les tâches qui sont déléguées par tout gestionnaire au gestionnaire de niveau
intermédiaire. Le choix des gestionnaires intermédiaires se base sur la notion de
proximité (voir figure 2.8), c’est-à-dire au plus proche des équipements actifs du
réseau.
Gestionnaire Principal
GI
EA
EA
GI
EA
GI
EA
EA
EA
GI : Gestionnaire Intermediaire
EA : Equipement Actif
Delegation des fonctions d’administration
Dialogue Client / Serveur SNMP
Fig. 2.8 – Délégation à un gestionnaire intermédiaire des opérations d’administration
2.4.3.1
Approche par Script
L’approche par Scripts est de permettre la mise en œuvre d’opérations d’administration les plus proches possible des équipements actifs du réseau, face à
l’augmentation croissante du nombre d’éléments à administrer. Les deux MIBs
décrites ci-dessous peuvent travailler de concert afin de réaliser automatiquement
des tâches d’administration.
MIB Script Une telle solution, comme décrite par Pras dans [66], fonctionne
selon un principe de délégation des méthodes d’administration. Le fonctionnement est relativement simple : la station d’administration du réseau transfert
L’administration de réseau
35
les scripts vers les stations d’administration intermédiaires afin que celles-ci exécutent le code des scripts [80]. Plusieurs langages peuvent être utilisés pour l’exécution des scripts, comme tcl/tck, shells Unix, etc...
MIB schedule Il s’agit de positionner une valeur donnée à une période définie dans un objet de la MIB. La période peut être unique, dans le sens où la
valeur sera positionnée une seule fois, périodique ou datée. En utilisant cette
MIB [45], certaines tâches très périodiques que doit exécuter un administrateur
peuvent être programmées et l’équipement actif a la responsabilité d’effectuer les
modifications demandées. Par exemple, ouvrir administrativement certains accès
réseau en changeant la valeur du statut d’administration d’une interface réseau
(interfaces.ifTable.ifEntry.ifAdminStatus).
2.4.3.2
Approche par MIB
Nous allons détailler les MIBs SNMP qui ont été définies par le groupe de
travail du DISMAN pour distribuer les opérations d’administration dans les gestionnaires intermédiaires du réseau.
Les opérations SNMP déportées L’utilisation de la MIB DISMAN remote
operation [100] permet au gestionnaire de lancer à distance les programmes ping,
traceroute et lookup 5 depuis un gestionnaire intermédiaire. Le résultat de ces
diverses commandes est enregistré dans des tables, chacune étant dédiée à une
commande. Il est possible d’avoir simultanément le résultat des trois commandes
en consultant les tables associées depuis la station de supervision.
MIB log notifications Il s’agit de la définition d’une MIB qui permet de
sauvegarder les alertes émises par les autres éléments du réseau évitant ainsi
toute perte sur la station d’administration [43]. L’enregistrement des événements
peut être associé à la mise en place d’un filtre qui permet de n’enregistrer que
les événements importants. Les informations concernant les événements qui sont
enregistrés sont : l’oid de l’objet qui a généré cette alerte, et l’adresse IP de
l’émetteur. Toutefois, s’il s’agit du protocole SNMP V3, en plus des informations
précédentes, l’entité et le nom du contexte sont enregistrés. Une donnée supplémentaire correspondant à l’heure d’enregistrement de l’alerte est associée afin
que la station d’administration puisse reconstituer le déroulement des alertes.
Par exemple, la notification du changement du statut d’une interface (link-up ou
link-down) peut être enregistrée dans cette MIB, ce qui peut être d’autant plus
pertinent si l’équipement actif se trouve sur un réseau distant.
5
La commande lookup permet de connaître les informations de nommages des éléments dans
le réseau, comme explicité par les commandes système du type nslookup [26].
36
L’administration des systèmes et des réseaux
MIB event Cette MIB permet de mettre en œuvre un mécanisme de déclenchement selon le résultat de l’évaluation d’une condition [41]. Cette MIB est
programmée à l’avance depuis la station d’administration, et la surveillance de
l’évaluation des conditions programmées permet le déclenchement automatique
par l’agent SNMP de l’événement associé.
MIB expression Il s’agit de faire évaluer en utilisant cette MIB [42] des expressions selon des critères définis par l’administrateur du réseau. Le résultat de
l’évaluation est enregistré dans une table de cette MIB qui peut être consulté
a posteriori par l’administrateur. L’évaluation se fait au moment où l’administrateur fait une requête de lecture de l’expression. Celle-ci est automatiquement
évaluée et le résultat stocké dans la table associée.
2.4.3.3
SNMP centralisé versus DISMAN
Les MIBs définies par le groupe DISMAN de l’IETF donnent une approche
différente de l’administration réseau traditionnelle, où toutes les données sont
analysées par une station centralisée. Il y a une utilisation des possibilités de
calcul des équipements actifs du réseau, ce qui permet de déléguer certaines tâches
d’administration. Cependant, l’utilisation des MIBs succinctement décrites dans
cette section est consommatrice en terme de ressources de calcul et de stockage des
résultats. Toutefois, cette approche va dans le sens d’une plus grande autonomie
de gestion au niveau des équipements actifs.
2.5
Quelques outils incontournables pour l’administration
Il existe sur le marché différents types d’outils pour effectuer des tâches d’administration de systèmes et de réseaux. Nous décrirons les outils minimaux qui
sont utilisés pour visualiser le trafic qui circule sur les réseaux dans la section
2.5.1. Une présentation succincte d’un outil commercial sera faite dans la section
2.5.2, et nous terminerons en présentant les autres méthodes pour effectuer de
l’administration d’équipements actifs.
2.5.1
Des outils élémentaires
Il existe un nombre important d’outils destinés à l’administration des réseaux.
Les plus simples d’utilisation d’entre eux sont des outils du domaine public. Par
contre ces outils ne sont pas conçus pour être intégrés les uns avec les autres.
Nous pouvons citer, à titre d’exemple, les outils suivants :
– tcpdump : trace des trames Ethernet que reçoit l’interface réseau du système
Quelques outils incontournables pour l’administration
37
– MultiRouter Traffic Grapher [56] : permet d’obtenir des graphiques sur
l’activité des équipements actifs du réseau
– etherape [27] : est une visualisation de ce que l’on peut obtenir par tcpdump
(cf. figure 2.9)
– etc..
Fig. 2.9 – Plate-forme de supervision du trafic réseau instantané
Un nombre important de tels outils existent effectivement, mais ces outils
présentent les mêmes lacunes d’intégration que ceux cités ci-dessus, c’est-à-dire
qu’il est impossible d’utiliser les informations d’un outil automatiquement dans
un autre outil par manque de standard dans les échanges d’information.
2.5.2
Plates-formes d’administration centralisée
2.5.2.1
Quelques exemples de plates-formes
Il se trouve que les plates-formes en exploitation sont des outils commerciaux.
Les solutions proposées comme Network Node Manager [35], Tivoli [95] ou Cisco
Works [23] sont des outils très performants pour effectuer le travail de supervision et d’administration de réseau. Ces outils propriétaires ont des possibilités
étendues concernant la gestion de leur propre matériel (ex : Hp Network Node
Manager avec des imprimantes réseaux HP), mais nettement moins concernant
les équipements actifs des autres constructeurs.
38
L’administration des systèmes et des réseaux
Ces outils commerciaux permettent de suivre en temps réel l’activité des équipements actifs qui composent les réseaux de l’entreprise. Ces outils offrent la possibilité d’avoir la topologie du réseau (cf. figure 2.11), les liens entre les différents
équipements composant le réseau de l’entreprise. Ces outils offrent aux administrateurs les possibilités de programmation des alertes, la gestion des fautes qui
peuvent survenir au sein de l’infrastructure du réseau.
2.5.2.2
Architecture des plates-formes d’administration de réseau centralisée
La figure 2.10 présente le schéma traditionnel d’une plate-forme d’administration de réseau, avec d’un côté la station d’administration qui supporte les
fonctionnalités d’administration : enregistrement des informations liées aux équipements actifs, protocole d’interrogation des équipements actifs, interface d’administration (GUI), noyau de l’application d’administration, c’est-à-dire tous les
outils permettant à l’administrateur d’être au courant du fonctionnement du système.
De l’autre côté, on retrouve les agents d’administration (agents SNMP) avec
leurs différentes implémentations de la MIB SNMP en accord avec leur fonctionnalité (routeur, commutateur, concentrateur, etc...)
La station d’administration gère la communication avec tous les équipements
actifs (selon le protocole d’administration choisi, en général SNMP) et fournit le
support d’une décision centralisée quant à l’administration du réseau. Une telle
approche n’est plus forcement utilisable dans les réseaux actuels, à cause de l’augmentation de la taille des réseaux d’une part, et de leur organisation de plus en
plus complexe, comprenant des sous-parties plus autonomes. Une administration
répartie semble mieux passer à l’échelle, est plus robuste et plus réactive sur le
temps d’exécution des fonctions d’administration [12, 49]. En effet, le nombre
d’équipements actifs devenant important, la station d’administration centralisée
devient donc le point faible de tout le système d’administration, tant par la charge
réseau induite que par la quantité d’informations à collecter et à mémoriser. Il
convient de noter que l’administrateur du réseau doit se trouver physiquement sur
la station d’administration afin d’être en mesure de traiter les incidents provenant
du réseau.
A titre d’exemple nous allons présenter HP Network Node Manager car c’est
un outil complet et représentatif des plates-formes d’administration de réseau.
Cette plate-forme permet à plusieurs administrateurs de se connecter à distance,
via un navigateur Internet, sur la plate-forme d’administration. Ces administrateurs suivent donc les alertes et les incidents qui peuvent survenir sur le réseau à
partir d’un ordinateur distant.
Afin d’avoir un aperçu général de la plate-forme HP Network Node Manager,
nous avons installé et fait tourner cette plate-forme sur un réseau de production
(sur le réseau illustré par la figure 2.4). Nous récupérons donc de la plate-forme
Quelques outils incontournables pour l’administration
39
Applications d’Administration
Noyau
BD
Protocole d’Administration
Sauvegarde de l’Information
Agent d’Administration
MIB
Agent d’Administration
MIB
Protocole d’administration
Echange entre les modules
du systeme d’administration
Fig. 2.10 – Plate-forme d’administration de réseaux centralisée
des informations visuelles de ce réseau.
La figure 2.11 présente une capture d’écran de la topologie du réseau présentée
sur la figure 2.4. On y trouve les différents segments détectés par l’outil d’administration connectés sur le commutateur central du réseau local. Chaque segment
est localisé par rapport à l’interface du commutateur qui le relie au reste du réseau (par exemple l’interface FastEthernet 0/9 pour le segment 8) et on trouve
sur la figure les équipements actifs du réseau facilement détectables par un tel
système d’administration : les routeurs et les commutateurs. Ils sont représentés
par des figures en losange indiquant le fait qu’ils participent à la gestion du trafic
du ou des segments du réseau. Sur la figure 2.11 présentée, deux routeurs Cisco
ont été détectés (cisco2520 et gw-80) et ceux-ci sont connectés sur le commutateur central. Les brins qui relient les différents segments au commutateur central
permettent d’avoir leur inter-connexion sur les interfaces du commutateur central
(ici sur les interfaces de type FastEthernet : Fa0/9 et Fa0/24).
Afin d’avoir une vue plus détaillée d’un des segments du réseau, il suffit de
le sélectionner dans la GUI de l’outil. Ansi la figure 2.12 montre les éléments
découverts appartenant au segment 8 (PC, imprimantes, routeur Cisco 2520 et
évidemment le commutateur central).
40
L’administration des systèmes et des réseaux
Icone d’un commutateur
Icone d’un routeur
Icone d’un segment du reseau connecte sur
une interface du commutateur
Fig. 2.11 – Capture d’écran de la topologie réseau obtenue par la plate-forme
HP Network Node Manager
Fig. 2.12 – Capture du segment 8
Bilan
2.5.3
41
Des plates-formes d’administration basées sur le Web
Étant donné que le protocole HTTP est devenu omniprésent, les constructeurs
ont intégré un serveur HTTP au sein des équipements actifs du réseau. Les fonctionnalités fournies sont celles que le constructeur a bien voulu offrir, mais elles
ont l’avantage de permettre une administration des équipements actifs via un
navigateur. Cette technique d’administration à distance s’appelle le Web-Based
Management [99]. La méthode utilisée pour la configuration se déroule entre le
navigateur du poste Client et le Serveur de l’élément du réseau de la manière
suivante :
– Le client crée une connexion TCP avec le serveur,
– Le client transmet une requête HTTP, typiquement un GET ou un POST
au serveur,
– Le serveur retourne une entête HTTP suivie, éventuellement, d’une applet
Java qui sert à établir le lien entre le poste client et le poste serveur,
– Le client rompt la connexion HTTP et l’applet Java prend le relais pour
transmettre les ordres d’administration à l’équipement actif.
Ether 10/100
COL
12 345 678 100
1012 36 12255080
! Power
Station de supervision
Commutateur
Connexion par le protocole HTTP
Echange de donnees via l’applet Java
Fig. 2.13 – Principe du Web-Based Management
Toutefois cette méthode est une solution qui ne permet d’administrer les équipements actifs que un par un, alors que les réseaux sont composés de dizaines
d’équipements actifs et qu’il faut parfois s’occuper de plus d’un équipement actif
simultanément.
2.6
Bilan
Dans ce chapitre, nous avons détaillé les outils qui permettent d’effectuer
des opérations simples d’administration, comme en utilisant les commandes Unix
ping, arp, traceroute, etc.., commandes qui donnent des informations sensibles à
l’administrateur du réseau sur la connectivité des réseaux et des éléments entre
42
L’administration des systèmes et des réseaux
eux. Pour obtenir de plus amples informations, un administrateur peut utiliser le
protocole SNMP (ou HTTP) pour communiquer avec des équipements actifs qui
composent le réseau qu’il gère, afin de prendre des décisions efficaces quant à la
mise en œuvre de services du réseau. Des outils plus ou moins intégrés dans des
plates-formes existent pour l’aider dans son métier, que ceux-ci soient libres de
droits ou commerciaux.
Cependant la difficulté voire l’impossibilité d’étendre les fonctionnalités offertes par les plates-formes d’administration et notamment les commerciales, justifie d’envisager d’autres solutions. Les plates-formes à agents mobiles présentent
en général la propriété de permettre à l’administrateur de programmer de nouvelles fonctions. Par ailleurs ces plates-formes offrant le concept d’agents mobiles
permettent d’introduire plus d’autonomie dans la réalisation des fonctions d’administration et donc de décharger d’autant le travail de l’administrateur.
Le chapitre 3 présente l’état de l’art des plates-formes à agents mobiles qui
sont utilisées dans ce contexte.
Chapitre 3
Les plates-formes à agents
mobiles pour l’administration
système et réseau : État de l’art
3.1
Introduction
Depuis quelques années, la communauté d’administration de systèmes et de
réseaux a reconnu le fort potentiel qu’offrent les systèmes basés sur des agents
et en particulier, sur des agents mobiles, pour effectuer des tâches d’administration [11] : décentralisation du contrôle, répartition des tâches de calculs liées à
l’administration, autonomie, possiblilité de gain en bande passante, etc.
La popularité du langage Java [51] et en particulier, le fait qu’il masque l’hétérogénéité des systèmes, qu’il permet aisément la mobilité de code et qu’il propose
des outils permettant d’appréhender les problèmes relevant de la sécurité, a plus
précisément focalisé l’intérêt de cette communauté sur des systèmes à agents mobiles écrits en Java. Dans le contexte de l’intégration des agents mobiles pour
l’administration système et réseau, nous avons étudié les plates-formes qui sont
bâties au dessus d’une architecture en Java. Les plates-formes à agents mobiles
sélectionnées, dans ce chapitre, ont pour objectif de fournir des outils d’administration de systèmes et de réseaux par le biais des agents mobiles. Pour utiliser ces
agents mobiles dans ce contexte, il est souhaitable d’offrir la notion d’itinéraires
construits et obtenus dynamiquement afin d’arriver à un degré élevé d’automatisation des tâches. Cependant, dans la majorité des plates-formes étudiées, les
itinéraires sont obtenus de façon statique (via par exemple un fichier), et ce sera
l’objet principal de ce travail de thèse de lever ce type de contraintes. Comme
pour construire des itinéraires dynamiques il faut une connaissance tant qu’à faire
automatique du réseau à administrer, nous étudierons dans ce chapitre l’état de
l’art concernant un autre aspect : la construction dynamique de topologie du
réseau.
43
44 Les plates-formes à agents mobiles pour l’administration système et réseau : État de l’art
En effet, les améliorations fournies par les équipementiers et la diminution
des coûts des matériels actifs des réseaux (commutateurs, routeurs, concentrateurs équipés d’agents SNMP) permettent désormais de collecter de plus en plus
d’informations du réseau. Il n’est plus nécessaire de collecter les informations
de trafic directement sur les éléments (PC, Serveurs, etc..) car le cœur du réseau
offre à son niveau l’équivalent. Il devient donc possible d’interroger uniquement les
équipements actifs le constituant afin d’avoir une vue très fine de l’état général du
réseau. Grâce à ces techniques et aux services inclus dans les équipements actifs, il
a de même été possible de concevoir des algorithmes permettant la détermination
fine de la topologie du réseau, c’est-à-dire de localiser le plus précisément possible
les éléments (PC, Serveurs, etc..), le reste de l’architecture du réseau et leur
connectivité.
Nous présenterons dans la section 3.2 les plates-formes à agents mobiles et la
façon de les utiliser, puis dans la section 3.3 les itinéraires que l’on peut appliquer
à des agents mobiles. Les études qui ont été faites pour déterminer la topologie
des réseaux sont présentées dans la section 3.4 et nous conclurons ce chapitre
dans la section 3.5 en donnant une orientation pour appliquer les agents mobiles
dans un contexte d’administration système et réseau.
3.2
État de l’art des plates-formes à agents mobiles
A notre connaissance, il existe depuis le début des années 1990, c’est-à-dire
depuis les premiers travaux du Management by Delegation [30] qui ouvraient la
voie des plates-formes dans le cadre de l’administration système et réseau, un
certain nombre de plates-formes à agents mobiles pour l’administration système
et réseau, qui se révèlent être incontournables. Notre présentation décrit les principes de l’administration par délégation, puis nous présenterons les plates-formes
à agents mobiles tournées vers l’administration système et réseau.
3.2.1
Principe de l’administration par delegation
L’approche introduite par MAD [30] présente la première les concepts de la
délégation des tâches d’administration de la station centralisée vers des éléments
intermédiaires, qui a leur tour deviennent des stations d’administration agissant
comme des proxies. L’architecture de MAD, repose sur des possibilités de déporter
les fonctions d’administration de la station centralisée vers ces proxy, appelés
MAD agent.
Le composant central de l’architecture proposée par MAD est le MAD agent
(voir figure 3.1). C’est une combinaison entre le modèle hiérarchique de supervision et d’un agent proxy (le MAD Agent) qui fournit un ensemble de services
nécessaire pour effectuer la supervision, et le contrôle des éléments gérés. Le MAD
État de l’art des plates-formes à agents mobiles
Manager
45
Script delegue
MAD Agent
Equipement
gere
Fig. 3.1 – Architecture de MAD
Agent fournit un ensemble de services qui peuvent être invoqués depuis la station
d’administration, ou depuis autre MAD Agent.
Le processus de délégation est engendré par la station d’administration sur
laquelle ont été décrites les fonctions d’administration qui seront transmises à
un MAD Agent. Ce processus permet de charger à la volée de nouvelles fonctions d’administration dans le proxy intermédiaire, ou de supprimer une fonction
devenue inutile, tout cela pendant la durée de vie du MAD Agent. Dans l’architecture distribuée de MAD, un MAD Agent peut devenir à son tour le gestionnaire
d’autres MAD Agents, et la station maître d’administration devenir un agent
proxy. Tout cela grâce aux possibilités de l’architecture qui permet de rajouter
ou de supprimer des fonctions dans ses nœuds.
Dans cette architecture, il existe trois types de fonctions possibles : la fonction
autonome qui a son thread d’exécution et ses données privées, la fonction exécutée
à la volée et qui retourne son résultat et la fonction qui est un objet à l’écoute
des demandes de services, accessible par tous les composants de l’architecture.
Le language de programmation de ces fonctions peut être le langage C ou tout
autre language.
3.2.2
Plates-formes tournées vers l’administration
Suite aux travaux menés par MAD, un certain nombre de plates-formes à
agents mobiles pour l’administration système et réseau, qui se révèlent être incontournables ont vu le jour et nous allons en détailler quelques unes, en présentant
les points les plus originaux :
– MIAMI, projet européen basé au dessus de Grasshopper [50] : Grasshopper [94] est la première plate-forme à agents mobiles qui est compatible
avec les standards industriels supportant des agents mobiles et leur gestion
(OMG MASIF [14]). MIAMI regroupe plusieurs entités différentes, comme
des entreprises, sous la forme d’un Place-Oriented Virtual Private Network,
afin de pouvoir administrer des nœuds situés à différents endroits en appliquant, par exemple, la même politique de sécurité à tous ces nœuds.
Cette approche permet de déléguer la gestion de ce PO VPN à une entité
46 Les plates-formes à agents mobiles pour l’administration système et réseau : État de l’art
extérieure à des fins d’administration.
– MAP [68] : Università di Catania, Italie.
MAP sécurise en deux niveaux l’accès des agents mobiles sur les nœuds.
Dans un premier temps lorsque les agents mobiles entrent dans un nouveau
domaine (collection de nœuds regroupés sous la même autorité d’administration) ils obtiennent des droits d’accès sur les nœuds qui composent le
domaine. De plus, une restriction peut être appliquée sur chaque nœud du
domaine en fonction des exigences de sécurité mises en place par de l’administrateur.
– MAGENTA [76] : IRISA, Campus Universitaire de Beaulieu, France.
La particularité de MAGENTA est de prendre en compte la déconnexion
de la station d’administration. En effet, si l’administrateur utilise un ordinateur portable, il se peut qu’il soit déconnecté ou que le lien SLIP/PPP
qui le relie au réseau soit très lent. Ainsi, lorsque les agents mobiles doivent
revenir à la station d’administration, ils vérifient qu’ils ont la possibilité
d’y revenir. Dans le cas contraire, l’agent mobile attend la reconnexion de
la station avant d’y revenir. Pendant cette période d’attente, il stationnera
sur un nœud de la plate-forme en attendant cet événement.
– SOMA [10] : Università di Bologna, Italie.
Le point fort de SOMA est la supervision des agents mobiles et des nœuds
d’accueil, et au passage des systèmes d’exploitation sous-jacents. Pour ce
faire, on dispose d’une API permettant d’accéder, par exemple aux ressources suivantes : CPU, charge réseau, consommation de mémoire. En
utilisant cette API, chaque nœud de la plate-forme peut être supervisé par
un agent mobile dédié à cette tâche.
– James [84] : University of Coimbra, Portugal. Ce travail introduit la possibilité de superviser la plate-forme d’administration elle-même, c’est-à-dire
James, en utilisant le protocole SNMP et l’instrumentation JMX pour tous
les objets de la plate-forme (cf. annexe JMX 9.2). Pour cela la MIB-JAMES
a été définie. Grâce à cette MIB, la plate-forme à agents mobiles peut aussi
être supervisée par une plate-forme d’administration réseau classique (par
exemple HP Network Node Manager).
– MobileSpaces [77] : National Institue of Informatics / Japan Science and
Technology corporation, Japon. Cette plate-forme fournit des agents mobiles transporteurs d’agents mobiles. Ces agents mobiles transporteurs assurent les opérations de migration des agents qu’ils transportent dans un
sous-réseau donné. Un ensemble d’itinéraires adaptés pour le sous-réseau
est défini et mis à la disposition des agents mobiles transporteurs. La politique de migration, dans un sous-réseau donné, est dépendante des fonctions
d’administration que doivent exécuter les agents mobiles. Ainsi, l’agent
transporteur aura l’itinéraire associé à la fonction d’administration. Une
extension possible de ces agents transporteurs est de les utiliser pour faire
traverser un pare-feu aux agents mobiles d’administration, diminuant ainsi
État de l’art des plates-formes à agents mobiles
47
les contraintes de sécurité qui sont mises en œuvre.
Nous avons listé des plates-formes à agents mobiles bâties uniquement au
dessus du language Java. Mais il existe d’autres types de plates-formes à agents
mobiles tournées vers l’administration système et réseau où les tâches à réaliser
sont définies par d’autres languages, comme Tcl/Tk [92], qui permettent d’effectuer des opérations d’administration par l’utilisation de scripts, comme par
exemple AgentTcl [31], AGNI [71], qui utilisent l’interpréteur de scripts pour distribuer le code dans les nœuds d’accueil et lancer des opérations d’administration
à distance. Toutefois, un désavantage quant à l’utilisation des scripts repose sur
la nécessité de l’interprétation du script, ce qui induit un temps d’exécution plus
long, plutôt que d’utiliser un language compilé comme l’est Java.
Au lieu de faire un état de l’art qui décrirait chaque plate-forme d’administration à base d’agents mobiles l’une après l’autre, nous avons préféré organiser
cette description en considérant tour à tour différent aspects d’importance :
– Installation de la plate-forme
– Programmation d’agents
– Communication entre agents
– Accès aux informations de la MIB SNMP
La notion d’itinéraire pour un agent mobile est si fondamentale que nous en avons
fait l’objet d’une section à part (section 3.3).
3.2.3
Installation des plates-formes
Dans cette section nous aborderons le problème du déploiement des platesformes à agents mobiles, qui se base sur la mise en route des nœuds et sur des
techniques pour l’enregistrement de ces nœuds.
Lorsqu’il s’agit de travailler avec une plate-forme à agents mobiles, on introduit le concept de nœud. Un nœud dans une plate-forme à agents mobiles
est une entité logicielle qui permet la réception, le départ et l’exécution d’un
agent mobile. Ce nœud est une partie intégrante de la plate-forme. Pour cela le
nœud fonctionne comme un daemon ou un service. Le nœud peut être mis en
route systématiquement pendant la phase de démarrage du système (au boot).
Le nœud peut être aussi démarré mais aussi ultérieurement arrêté à la demande
de l’utilisateur, soit par des scripts automatiques de connexion, en utilisant des
commandes à distance (par exemple rsh), ou encore en utilisant le plannificateur
de tâches (ou le crontab) fourni dans le système d’exploitation.
Plutôt que d’utiliser des commandes systèmes pour démarrer ou arrêter les
JVMs hébergeant les nœuds de la plate-forme, une solution intégrée à la plateforme peut être plus adaptée. En effet, le problème de l’arrêt des nœuds à distance
peut se révéler fastidieux s’il est fait manuellement et parfois problématique, car il
faut en particulier identifier tous les processus système faisant tourner les JVMs.
48 Les plates-formes à agents mobiles pour l’administration système et réseau : État de l’art
Pour faciliter cela, il est possible de démarrer en tant que daemon du système une
JVM, et de demander à cette JVM de créer une JVM en tant que processus fils
qui elle hébergera un nœud de la plate-forme. L’intérêt c’est de pouvoir déléguer
à ces JVMs daemon le problème du démarrage, de l’enregistrement et de l’arrêt
des nœuds de la plate-forme. Cette technique, particulièrement intéressante dans
le cas du redémarrage des nœuds est mise en œuvre dans James [81], la JVM
daemon exécutant une classe s’appelant Jrexec.
Certaines contraintes dans le domaine de l’administration des systèmes et
des réseaux sont importantes à considérer, même si elles n’ont pas fait l’objet
de recherche au cours de cette thèse : il s’agit essentiellement de la sécurité. En
effet, en fonction des droits de l’utilisateur démarrant le nœud, les agents mobiles ultérieurement hébergés par ce nœud auront plus ou moins de droits sur le
système. Un nœud accessible à tout agent mobile de n’importe quel utilisateur,
mais démarré avec les droits de l’administrateur (typiquement root) pose des
problèmes de sécurité du système hôte. Néanmoins, vu que l’on veut faire de
l’administration, il faut que les agents mobiles aient des droits correspondant
à ceux de l’administrateur. Pour ce faire, une technique d’authentification de
chaque agent mobile est souhaitable afin de les autoriser à effectuer des accès au
système (commandes particulières sur le système).
Une fois les nœuds de la plate-forme à agents mobiles instanciés, il convient
de trouver une méthode pour les localiser afin que ceux-ci soient accessibles aux
utilisateurs. Selon les plates-formes, certains nœuds s’enregistrent automatiquement au moment de leur démarrage, comme dans le cas de MAP [69], en se
connectant directement sur le nœud maître de la plate-forme. Cette solution a
l’inconvénient d’introduire des références statiques entre les nœuds déployés. Une
autre idée est de ne pas enregistrer les nœuds de la plate-forme mais de rendre
ceux-ci accessibles par le biais de fichiers référençant les nœuds (méthode statique
de mise à jour) comme c’est le cas dans James [82], ou en utilisant un bus à objet
(par exemple CORBA) [9] pour l’enregistrement des nœuds en tant que service du
réseau. C’est cette dernière idée qui offre le plus de souplesse car elle évite toute
référence statique liée au déploiement de la plate-forme d’une part, et d’autre
part elle laisse toute autonomie aux programmeurs pour enregistrer et localiser
les nœuds de la plate-forme à agents mobiles.
3.2.4
Programmation des agents
3.2.4.1
Patterns de fonctions d’administration système et réseau à
base d’agents mobiles
Plusieurs types d’agents mobiles peuvent exister. Ils sont à regrouper en fonction des tâches génériques qu’ils sont en mesure d’exécuter. Ils ont des possibilités
de communication, entre eux ainsi qu’avec les autres éléments de la plate-forme,
État de l’art des plates-formes à agents mobiles
49
de migration, de duplication, etc.. Nous détaillons ci-dessous les principaux types
d’agents mobiles que nous avons rencontrés dans la littérature.
Statique : Un agent statique est un agent mobile qui n’exécute en général
qu’une seule migration. Cette migration s’effectue depuis la station de départ
vers un nœud bien défini au lancement. A l’arrivée sur le nœud, l’agent mobile ne
migre plus mais exécute une tâche prédéfinie. Il peut s’agir d’un calcul de longue
durée (par exemple vérifier périodiquement le nombre de requêtes exécutées sur
une base de données), de la supervision de l’interface réseau (ce que fait par
exemple le Daemon Agent de la plate-forme MAP [69]), de la supervision de
l’espace disque du système hôte. Une autre utilisation d’un agent mobile statique
serait de fournir une ou plusieurs listes d’éléments qui correspondraient à des
itinéraires pour les agents mobiles de la plate-forme. Cette proposition est utilisée
dans James [78] par le biais de l’Agent Pool. Un tel agent est aussi appelé un agent
stationnaire car il ne migre plus pendant sa durée de vie.
Visiteur : Un agent visiteur est un agent mobile qui visite successivement les
différents nœuds de la plate-forme afin d’y appliquer la même fonction d’administration. Il peut s’agir d’un agent mobile allant, par exemple, effacer sur chaque
système les fichiers temporaires ou collecter les espaces disques utilisés, etc..
Le Verifier Agent [69] de MAP est un agent visiteur, dont l’utilisation peut
faciliter les tâches de l’administrateur du réseau, par exemple, en récupérant les
versions des systèmes d’exploitation installées sur les éléments du réseau.
Collecteur de données : Un agent collectant les données est un agent mobile
qui nécessite un point de rendez-vous avec un ou plusieurs autres agents mobiles pour les décharger des données que ces derniers ont collectées. Cet agent de
collecte peut toutefois récupérer des données qui ont été laissées à sa disposition
sur les différents systèmes par d’autres agents mobiles. Après la collecte, cet agent
transporte les données jusqu’à un système défini à l’avance.
Transporteur : Un agent transporteur est un agent qui transporte des agents
mobiles d’un réseau à un autre, ou qui transporte les agents mobiles dans un
sous-réseau. Il permet d’éviter la multiplication des procédures d’identification
des agents mobiles lors du passage d’un réseau à un autre (par exemple si les
contraintes de sécurité imposées aux agents mobiles diffèrent). Lorsque le transporteur agit uniquement dans un sous-réseau, celui-ci transporte un ou plusieurs
agents mobiles qui ont les mêmes déplacement prévus (mêmes nœuds à visiter)
(par exemple le Navigator Agent de MobileSpaces [78]).
Suivi d’incident : Un agent de suivi d’incident est un agent qui est programmé
pour réagir aux données qu’il analyse. Il peut analyser les fichiers d’incidents ou
50 Les plates-formes à agents mobiles pour l’administration système et réseau : État de l’art
de fonctionnement d’un système (par exemple les logs Unix) et se déplacer, si
nécessaire, sur un autre système (par exemple, détecté dans les logs) qui aurait
été compromis.
Communication et synchronisation : Lorsque l’on veut utiliser un ensemble
d’agents mobiles pour accomplir une tâche particulière (par exemple pour connaître l’état général d’un cluster), des techniques de communication et de synchronisation doivent souvent être mises en œuvre. En effet, les agents mobiles
ont besoin de communiquer entre eux pour échanger leur état, leurs données,
leur localisation si nécessaire afin de pouvoir mener à bien leur tâche. Plusieurs
schémas existent :
– communication directe d’agent à agent (par exemple l’échange de la charge
CPU d’un système)
– communication d’information d’un agent à une boîte postale (par exemple
délestage des données transportées dans une base de données afin de pouvoir
venir les récupérer ultérieurement)
– synchronisation entre agents (point de rendez-vous après l’exécution d’une
tâche effectuée en parallèle)
3.2.4.2
Déploiement d’un agent
Nous avons décrit dans la section 3.2.3 de quelle manière sont lancés les nœuds
d’une plate-forme à agents mobiles. Voyons maintenant quelle est la méthode
"générique" qui permet de démarrer l’exécution d’un agent mobile sur de tels
nœuds : Agent monAgent = lanceAgent("Agent","nom du nœud").
Chaque plate-forme propose son propre son nom pour la méthode lanceAgent.
Cependant, la mise en œuvre de cette méthode consiste toujours à instancier la
classe "Agent" selon les modalités du noyau d’exécution.
3.2.4.3
Programmation d’un agent mobile
Pour faciliter la création d’agents mobiles dans une plate-forme donnée, on
dispose en général d’un agent générique qu’il suffit de personnaliser puis d’instancier pour créer de nouveaux agents de ce nouveau type. Une classe (que l’on
appelle Agent dans l’exemple de code figure 3.2) fournit le cadre général de l’utilisation des fonctionnalités attendues d’un agent mobile dont notamment la
possibilité de migration.
Dans une telle classe, on trouve en général une primitive (go) qui permet
de faire migrer l’agent mobile de sa position actuelle vers un autre nœud de la
plate-forme. Une primitive (dénommée par exemple myWork sur la figure 3.2)
correspond à la fonction déclenchée automatiquement à l’arrivée sur un nouveau
nœud. L’activité de l’agent mobile est matérialisée par une primitive (dénommée
run sur la figure 3.2), qui est en fait celle exécutée par le thread qui "donne vie"
État de l’art des plates-formes à agents mobiles
public class Agent{
public void myWork() {
}
public void go(String new_Node) {
public void run() {
// la vie de l’agent mobile
}
}
51
}
Fig. 3.2 – Classe générique d’un agent mobile
et donc l’autonomie à l’agent mobile. L’utilisation de ce découpage en méthodes
distinctes pour les opérations qui sont réalisées par un agent mobile est une
approche utilisée dans Ajanta [3]. L’exemple de la figure 3.3 montre comment
pourrait être personnalisé un agent générique.
public class HelloAgent extends Agent {
public HelloAgent(Credentials credential) {
super(credential);
}
public void run() {
System.out.println("Agent"+credential.name+" says Hello to "+host.getHostURN());
go("another_host_URN");
}
public void arrive() {
}
public void depart() {
}
}
Fig. 3.3 – Classe HelloAgent de la plate-forme Ajanta
On y trouve une primitive arrive correspondant à la méthode à exécuter lors
de l’arrivée sur le nœud, ainsi qu’une primitive depart qui est appelée avant le
départ d’un nœud. L’appel de la méthode go est effectué dans la méthode run
exécutée par le thread associé à l’agent mobile. Les itinéraires d’Ajanta sont des
itinéraires typiquement construits manuellement et transmis à l’agent mobile au
moment de sa création.
Un autre cadre de programmation est proposé par la plate-forme MAP [69].
Dans MAP, la programmation d’un nouvel agent mobile se fait par l’extension
de la classe Agent. La méthode exec est la méthode qui est appelée après chaque
opération de migration, méthode qui sera exécutée par le thread associé à l’agent
mobile. Le programmeur doit implémenter sa fonction d’administration à partir
du corps de la méthode exec (cf. figure 3.4). Dans cette méthode, l’appel de
la méthode go permet de lancer le processus de migration de l’agent mobile.
L’itinéraire qui est donné à l’agent mobile est contenu dans une variable globale,
appelée Locations, qui contient la liste des nœuds à visiter et qui doit être mise à
jour par retrait de la destination vers laquelle on va migrer pour éviter de boucler
sur la même destination. Dans MAP, l’itinéraire est récupéré par la réception d’un
52 Les plates-formes à agents mobiles pour l’administration système et réseau : État de l’art
message émis depuis la station d’administration (méthode receiveSyncMessage)
et entièrement suivi par l’agent mobile.
public class CirculateAgent extends Agent {
Vector addressVector;
public CirculateAgent()
{
addressVector = null;
}
// l’agent va de site en site tant que la liste adressVector contient des éléments
public void exec()
{
while( addressVector == null ); // l’agent attend un itinéraire
System.out.println( "************************************" );
System.out.print( "
PARCOURS A EFFECTUER BIEN RECU:
" );
Vector locations = loc.getAll();
for( int i = 0; i < locations.size(); ++i )
{
System.out.println();
System.out.print( ( ( URL ) locations.elementAt( i ) ).toString() );
}
System.out.println( " * mi trovo qui" ); // je suis là
System.out.println( "************************************" );
if( addressVector.size() != 0 ) //jusqu’à ce que ce soit fini
{
URL remoteURL = ( URL ) addressVector.remove( 0 );
go( remoteURL );
}
}
public Message receiveSyncMessage( Message m )
{
addressVector = ( Vector ) m.content;
return m;
}
}
Fig. 3.4 – Classe d’un agent mobile dans MAP
Suite à l’exposé de ces exemples (Ajanta et MAP), on peut constater que
l’agent mobile gère lui-même son processus de migration, dans le sens où l’ordre
de migration vient du code de l’agent mobile (c’est lui qui invoque la primitive
go). Une approche différente et complémentaire, comme celle adoptée dans MobileSpaces [78] ou dans ProActive [8] est de pouvoir aussi déclencher la migration
de l’extérieur de l’agent mobile. Cette possibilité permet, si besoin, de décharger
les programmeurs du pilotage de la migration d’un agent. Ainsi, de se concentrer
sur le développement du code de la tâche d’administration à réaliser.
3.2.4.4
Mécanisme de construction d’itinéraire
Fournir un itinéraire prêt à l’emploi pour un agent mobile pose le problème de
la collecte des éléments qui font parties de l’itinéraire. Nous avons mis en évidence
différentes méthodes pour obtenir des itinéraires qui sont utilisés par des agents
mobiles.
État de l’art des plates-formes à agents mobiles
53
Statique : Un itinéraire construit statiquement est un itinéraire qui est obtenu
à partir d’un fichier décrivant un itinéraire. Ce type de construction est assez
rigide et impose à l’administrateur de la plate-forme à agents mobiles de mettre
à jour régulièrement cet itinéraire statique en fonction des nouveaux nœuds actifs
de la plate-forme. Il s’agit ici de la solution la plus contraignante.
Endroit centralisé plus ou moins à jour : Il s’agit d’enregistrer automatiquement les nœuds de la plate-forme dans un nœud maître (Gavalas [63]). Cette
technique permet de centraliser tous les éléments qui seront donnés pour les itinéraires en un seul lieu. Mais la défaillance d’un nœud n’est pas prise en compte
parce qu’il n’y a pas de rétroactivité entre le nœud maître et les nœuds qui se
sont enregistrés.
Au fur et à mesure du parcours : L’itinéraire obtenu est un itinéraire
qui est construit à la volée. Il est découpé en portions et enrichi au fur et à
mesure que l’agent mobile change de domaine. Ici le terme de domaine peut être
un domaine logique regroupant certains nœuds de la plate-forme en fonction de
besoins pouvant être très variés (par exemple, les machines d’une équipe, localisée
sur plusieurs bâtiments), ou un domaine physique comme par exemple un sousréseau. Ainsi à chaque changement de domaine, l’agent mobile devra enrichir son
itinéraire avec les éléments à visiter sur le nouveau domaine. C’est une approche
similaire qui est utilisée par MobileSpaces, car chaque agent mobile qui change de
domaine est pris en charge par un agent mobile particulier qui pourra lui indiquer
l’itinéraire à suivre dans le nouveau domaine.
3.2.4.5
Programmation de l’aspect fonctionnel
Conformément au schéma général d’un agent mobile (voir section 3.2.4.3), on
s’intéresse à présent plus précisément à la programmation de la tâche d’administration qu’un agent devra exécuter en lieu et place d’un administrateur. Précédemment, nous avons vu que la primitive go définit la méthode (par exemple
arrive) qui sera exécutée à l’arrivée sur le nouveau nœud. Pour permettre l’exécution de tâches d’administration, il est nécessaire de programmer cette fonction
avec la tâche d’administration que l’on souhaite voir appliquée sur le nœud ou à
partir de ce nœud. Il existe deux types de tâches d’administration que l’on veut
voir réalisées par des agents mobiles : les tâches d’administration des systèmes
(par exemple avoir la charge CPU) ; les tâches d’administration réseau (utilisation
d’un protocole d’administration de réseau, SNMP en l’occurrence).
Fonctions d’administration de système : Les fonctions de ce type sont
des fonctions qui font des appels systèmes afin de collecter, modifier ou installer
des données ou des programmes. Dans un cadre de développement en Java, ces
fonctions feront appel à l’interface native de Java, le JNI.
54 Les plates-formes à agents mobiles pour l’administration système et réseau : État de l’art
Par exemple, en utilisant le JNI, pour connaître la charge CPU d’un système
quelconque, il faudra déterminer le type de système afin d’adapter le code du
programme. En effet, la charge CPU est obtenue de manière différente en fonction
des systèmes d’exploitation. Sous Linux, en lisant le fichier /proc/loadavg tandis
que sous les environnements Windows, il faudra développer la bibliothèque (une
DLL, dynamic link library) fournissant cette information.
Fonctions d’administration réseau : Pour écrire des fonctions d’administration réseau, il faudra utiliser le protocole SNMP, car c’est le protocole d’administration de réseau le plus répandu. L’implémentation du protocole SNMP
existe, par exemple proposée par AdventNet [2] dans sa bibliothèque Java, afin
de faciliter l’écriture de ces fonctions. Une fois que le protocole est disponible,
n’importe quelle fonction d’administration réseau peut être écrite, comme par
exemple obtenir le nombre et le type des interfaces réseau d’un système.
A titre de récapitulatif, nous donnons le cadre de programmation de SOMA [9]
(cf. figure 3.5) : la primitive run pour définir l’activité principale de l’agent mobile,
goNode pour déclencher le processus de migration et la primitive verifyNode qui
est la fonction d’administration système à exécuter sur le nœud d’arrivée. Dans
cet exemple, la fonction verifyNode permet de récupérer l’état du système au
passage de l’agent mobile. En suivant son itinéraire, l’agent mobile pourra ainsi
collecter l’état de tous les systèmes visités. On remarque un aspect intéressant
qui est le fait de pouvoir associer le nom du nœud à visiter et le nom d’une
méthode qui doit être exécutée à l’arrivée sur ce nœud. Ce nom de méthode est
ici quelconque, contrairement à ce que l’on avait pu observer par exemple dans
le code de la figure 3.3 (méthode de nom arrive) ou dans celui de la figure 3.4
(méthode de nom Exec).
3.2.5
Communication entre agents mobiles
Il est essentiel que les agents mobiles puissent avoir un moyen de communiquer
entre eux ou avec l’extérieur, sans avoir à se préoccuper de leur localisation. Les
plates-formes évoquées au début de ce chapitre, sont reprises ici en fonction des
moyens de communication qui sont fournis aux agents mobiles.
– MIAMI : Une définition d’une boite aux lettres sert de moyen de réception des communications entre les agents mobiles s’envoyant des messages
ayant pour adresse : [email protected] Domaine est le domaine où se situe
actuellement l’agent destinataire du message. L’agent mobile ne changeant
pas forcément de domaine lors de la migration. Les agents mobiles peuvent
tout de même se localiser entre eux, puisque les facilités requises par MASIF
[14] en terme de localisation des agents mobiles (service d’enregistrement
utilisant le Bus Corba, RMI, etc..), sont implémentées en standard dans la
plate-forme Grasshopper.
État de l’art des plates-formes à agents mobiles
55
void run() { // starting method for every Agent
// Asking to AgentSystem the list of Nodes in this Domain
Node = AgentSystem.getAllDomain();
CurrNode=0;
// Looking for the first active Node
for (;CurrNode<Node.length;CurrNode++)
if (AgentSystem.isActive(Node.Name)) goNode();
.. // Error: no active nodes
}
void goNode() {
try {
this.go(Node[CurrNode].Name,"VerifyNode");
}
catch(Exception e) { //Can’t go, System or Security exception
... goHome(); // Back home with failure status
}
}
void verifyNode() { // Restart method specified by goNode()
try {
CPUload[CurrNode]=Monitor.getCPULoad();
}
catch(Exception e) { // action not allowed
... // Actions for exception handling
}
CurrNode++;
for (;CurrNode<Node.length;CurrNode++)
if (AgentSystem.isActive(Node.Name)) goNode();
goHome();
}
Fig. 3.5 – Classe d’un agent mobile dans SOMA
– MAP : les messages sont échangés en connaissant le lieu et le port TCP du
MAP Server (nœud de la plate-forme), et si l’agent n’est pas sur le nœud,
alors le message n’est pas réacheminé. Le système utilise une liste des MAP
Servers pour essayer de localiser l’agent. En cas d’échec, le message ne peut
pas être retransmis.
– MAGENTA : Lorsque deux agents ont besoin de communiquer, ils se fixent
un rendez-vous sur le même site, et s’échangent des messages pour communiquer. Lorsque la station d’administration veut communiquer avec les
agents mobiles elle utilise un service de localisation inclues dans la plateforme.
– SOMA : Dans le cadre de cette plate-forme, les agents mobiles s’échangent
des messages pour communiquer entre eux. Pour se localiser dans le domaine
de SOMA, un agent mobile utilise les facilités offertes par MAFFinder [14],
une sorte de service d’enregistrement que les agents mobiles interrogent afin
de pouvoir se localiser. Chacun des nœuds de la plate-forme enregistrant
au fur et à mesure les agents mobiles qu’ils hébergent.
– James : Inter-agent communication avec le JavaSpaces, où tous les agents
56 Les plates-formes à agents mobiles pour l’administration système et réseau : État de l’art
s’enregistrent afin de pouvoir communiquer entre eux. Une autre méthode
pour fournir des communications entre les agents mobiles et d’utiliser le
nœud maître de la plate-forme qui possède la liste de tous les agents mobiles en activité dans la plate-forme. Par ce biais, un agent mobile localise
indirectement l’agent mobile avec lequel il souhaite communiquer.
– MobileSpace : Chaque agent maintient une file de requêtes de messages
et il s’enregistre auprès des autres agents avec lesquels il doit converser
(donc défini statiquement). Lorsqu’un agent doit bouger, il laisse derriere
lui un agent forwarder, qui permet à tous autres agents mobiles visitant
le nœud, de savoir le recontacter par le bias des forwarders. Ces agents
mobiles utiliseront le forwarder agent pour migrer à la même localisation
que l’agent mobile avec lequel ils doivent communiquer, et pourront ensuite
dialoguer avec lui.
Les mécanismes de localisation et de communication entre les agents mobiles
doivent être transparents aux agents mobiles et c’est le rôle de la plate-forme
de fournir de tels mécanismes. Comme nous verrons par la suite, la plate-forme
ProActive a le mérite de fournir ces mécanismes de manière que l’on peut qualifier
d’idéale !
3.2.6
Accès aux données de la MIB SNMP
Afin de pouvoir accéder aux informations de la MIB SNMP, il est utile que
les agents mobiles puissent converser avec les agents SNMP.
Certaines plates-formes ont intégré dans leur distribution des classes permettant de converser en SNMP. Cela implique que lorsqu’un agent mobile arrive sur
un nœud sur lequel il doit exécuter une fonction d’administration requérant le
protocole SNMP, il n’a pas besoin de télécharger les classes. Ces classes mettent
en œuvre une API qui, pour masquer la complexité de l’utilisation du protocole SNMP, prédéfinit un ensemble de fonctions d’administration (par exemple,
l’obtention de statistiques sur des interfaces réseaux). L’inconvénient évident est
que certaines requêtes SNMP ne pourront pas être réalisées. Cette solution est
mise en œuvre, par exemple par SOMA [10], qui intègre une interface (nommée
Monitoring Application Programming Interface), permettant de fournir une agrégation des résultats des indicateurs de surveillance. Ainsi l’agent mobile arrive et
collecte directement la ou les valeurs des indicateurs.
Une autre méthode est celle qui consiste à associer le code de l’agent mobile
avec une API indépendante de la plate-forme qui donne accès à toute la pile
du protocole SNMP (méthodes, fonctions, encodages, décodages, etc..), comme
par exemple AdventNet [2]. En utilisant cette technique, l’agent mobile est libre
d’accéder à n’importe quelle information contenue dans la MIB de l’agent SNMP.
L’agent mobile va devoir télécharger les classes utiles pour réaliser sa fonction
d’administration SNMP, ce qui peut être pénalisant en terme de performance si
le lien réseau entre l’hôte de départ et l’hôte d’arrivée est de faible débit.
Itinéraires
3.3
Itinéraires
3.3.1
Motivation
57
Pour caractériser le concept d’itinéraire [4, 89], nous dirons que l’itinéraire
d’un agent mobile est l’union d’opérations composées d’un déplacement (communément appelée une migration) et d’une action que l’agent mobile doit exécuter à
chaque point de passage de cet itinéraire. Un itinéraire est un concept important
qui permet de décharger l’agent mobile de la gestion explicite des opérations de
migration, et lui permettre de se concentrer uniquement sur son objectif principal : exécuter la ou les tâches en lieu et place d’un administrateur.
3.3.2
Structuration d’un itinéraire de visite
Comme on vient de le voir (cf. section 3.2.4.4), les éléments d’un itinéraire
peuvent être collectés de manière statique par l’administrateur de la plate-forme
à agents mobiles (liste d’éléments pré-définis pour un itinéraire), de manière automatique (enregistrement automatique des nœuds au démarrage de la plateforme), ou par un système autonome qui collectera les éléments à indiquer dans
l’itinéraire.
Quelque soit le moyen utilisé pour mettre ces éléments à disposition, on peut
remarquer qu’un itinéraire peut être structuré de différentes manières : plate ou
par domaine (virtuel ou physique) à visiter.
3.3.2.1
Structure plate
C’est la structure la plus simple d’un itinéraire couvrant tous les éléments
au sein du réseau d’entreprise, par exemple, et ce sans aucune organisation quelconque liée à la localisation de ces éléments.
3.3.2.2
Structuration virtuelle
C’est une structuration possible d’un itinéraire dans lequel les éléments sont
regroupés virtuellement (dans ce que l’on peut appeler un domaine). On entend
par virtuel, le fait que des éléments regroupés n’appartiennent pas tous au même
réseau, ou au même sous-réseau, mais dont les fonctionnalités permettent de les
regrouper dans une entité administrable logiquement. Par exemple, un itinéraire
couvrant certains éléments pris dans chaque sous-réseau d’une entreprise pourra
donner lieu à un itinéraire structuré virtuellement et donc définissant un domaine
dans le réseau. Il sera donc possible d’avoir plusieurs itinéraires de ce type sachant
qu’il est possible de créer plusieurs domaines virtuels d’éléments dans un réseau.
SOMA [9] propose une telle solution (cf. figure 3.6) dans le but de gérer les
droits et les déplacements des agents mobiles au sein de la plate-forme, grâce à
des regroupements virtuels d’éléments. Chaque nœud de la plate-forme est créé
58 Les plates-formes à agents mobiles pour l’administration système et réseau : État de l’art
avec comme référence le nœud maître du domaine dans lequel il fait partie. Un
domaine peut être défini comme étant un sous-réseau entier, mais aussi englober
des nœuds appartenant à un autre sous-réseau. Dans cette approche, les domaines
sont sous la responsabilité d’un ou plusieurs administrateurs. Le déplacement des
agents mobiles d’un domaine à l’autre se fait obligatoirement en passant par une
entité de contrôle (nœud maître) qui alloue automatiquement les nouveaux droits
aux agents mobiles requis pour accéder au domaine visé.
Fig. 3.6 – Modèle des domaines de SOMA
3.3.2.3
Structuration physique
C’est la mise à disposition d’un itinéraire couvrant les éléments connus appartenant au même sous-réseau. Il existera donc plusieurs itinéraires de ce type
dans le réseau d’une entreprise, par exemple, si celui-ci est composé de plusieurs
sous-réseaux.
Une approche par sous-réseau est une approche qui colle à la réalité de l’administration. Lorsqu’un agent mobile doit changer de réseau, il contactera le
service d’itinéraire présent sur le réseau cible. Il existe deux variantes de cette
solution : la première masque les itinéraires aux agents mobiles ce qui introduit
la présence d’un agent mobile de "transport" (voir section 3.2.4.1) pour fonctionner ; la deuxième fournit directement aux agents mobiles des itinéraires ce qui
donne la possibilité aux agents mobiles de gérer eux-mêmes le déroulement de
leur itinéraire, voire de le modifier si nécessaire.
L’approche par agent mobile transporteur est présente dans MobileSpaces [78]
sous la forme d’un Agent Pool et d’un Navigator Agent (cf. figure 3.7). L’Agent
Pool est un système qui est initialisé avec tous les itinéraires du sous-réseau et
qui les modifie en fonction des conditions rencontrées par les agents mobiles (par
exemple, mise à jour en cas de nœud défaillant). Chaque Navigator Agent possède
un itinéraire pré-déterminé par l’Agent Pool et il est à disposition des Task Agent
(agents mobiles exécutant des fonctions d’administration), afin de les transporter
Itinéraires
59
sur le sous-réseau. Le Navigator Agent transporte un ou plusieurs Task Agent, il
gère tout le processus de la migration, de l’exécution des ordres de migration. Le
Navigator Agent met à jour à son retour la liste des éléments qui sont devenus
inaccessibles sur le sous-réseau, détenue au sein de l’Agent Pool.
Fig. 3.7 – Les itinéraires dans MobileSpaces
3.3.2.4
Composition
Pour donner plus de souplesse aux itinéraires, une solution de composition
de ces éléments peut apporter un avantage pour l’autonomie et la réactivité des
agents mobiles. En effet, il est possible d’imaginer des itinéraires globaux (section
3.3.2.1) ; des itinéraires structurés par domaine (section 3.3.2.2) ; des itinéraires
structurés par sous-réseaux (section 3.3.2.3). Avec une telle composition, il sera
possible de fournir des itinéraires couvrant tout le domaine d’administration,
un sous-réseau ou un ensemble d’éléments répartis sur plusieurs sous-réseaux de
l’entreprise.
3.3.3
Autres structurations d’un itinéraire
Jusqu’à présent, nous avons décrit des itinéraires qui sont des itinéraires non
structurés dans le sens où il s’agit de parcourir séquentiellement les éléments les
uns après les autres. On constate toutefois que nous avons besoin d’itinéraires plus
sophistiqués plutôt qu’un simple parcours. Il faut pouvoir donner des schémas de
migration afin d’adapter le comportement des agents mobiles en fonction des
conditions qu’ils rencontrent pendant leur phase de migration. Les itinéraires
sophistiqués sont des itinéraires qui peuvent prendre en compte les événements
qui surviennent dans le fonctionnement général d’un réseau : coupure d’électricité,
panne réseau, lien défaillant, panne système, redémarrage d’un élément, surcharge
du CPU système, surcharge de l’interface réseau, en sont des exemples concrets.
Il faut aussi prendre en compte les tâches qui peuvent être effectuées en parallèle
60 Les plates-formes à agents mobiles pour l’administration système et réseau : État de l’art
sur différents systèmes. Ce parallélisme introduit des notions de synchronisation
entre les différents composants.
3.3.3.1
Sélection de la Destination
La sélection de la destination parmi un ensemble de destinations peut être vue
comme un itinéraire particulier intégrant une notion de sélection. Cette sélection
ou ce choix entre les différents éléments à visiter est basée sur des critères de
charge CPU des éléments, de la charge du réseau, par exemple. Autre exemple,
la visite d’un élément d’un cluster de PCs peut suffire à obtenir l’information
recherchée, sans avoir à visiter chacun des éléments du cluster.
3.3.3.2
Visite au hasard
Un tel type d’itinéraire consiste en la visite au hasard de l’ensemble des éléments appartenant à ce type d’itinéraire. Il n’y a pas de priorité assignée à chaque
élément de l’ensemble, mais chaque élément doit être visité. Le critère de choix
de la destination dans cette visite au hasard, peut être basé, par exemple, sur le
plus court chemin à parcourir pour y arriver, la puissance de l’hôte, etc... Il s’agit,
par exemple, de surveiller l’espace disque disponible sur un ensemble d’éléments
du réseau sans qu’il y ait un caractère d’urgence. Ici, l’ordre de visite n’apporte
rien de plus puisque seul le résultat compte.
3.3.3.3
Parallélisme
Il s’agit d’utiliser des notions de parallélisme pour faire exécuter la même tâche
à des agents mobiles en parallèle. Ce mode de fonctionnement peut imposer des
types de synchronisation pour la collecte des informations en retour :
– attente d’au moins un agent mobile pour continuer le parcours de l’itinéraire
principal
– attente de tous les agents mobiles pour continuer le parcours de l’itinéraire
principal
On peut, par exemple, utiliser cette notion de parallélisme dans le cas d’un
réseau sans fil (Wifi). Nous savons pertinemment que la bande passante d’un
réseau Wifi est faible par rapport aux réseaux câblés. Pour effectuer une tâche
d’administration nécessitant un délai d’exécution court, un itinéraire parallèle est
approprié dans ce cas là. En effet, la même tâche pourra être faite en parallèle
sur chacun des ordinateurs connectés au réseau sans fil, et le temps d’exécution
de la fonction globale sur l’ensemble des ordinateurs sera inférieur à une fonction
exécutée séquentiellement sur chacun des ordinateurs les uns après les autres. De
plus, on peut espérer profiter d’un recouvrement calcul/communication : pendant qu’une des tâches a déjà commencé à s’exécuter, les agents mobiles peuvent
continuer à transiter sur le réseau sans fil pour atteindre le nœud de destination.
Itinéraires
3.3.3.4
61
Un exemple de mise en œuvre de la composition de destinations dans un itinéraire
Le mécanisme d’itinéraires mis en œuvre dans Ajanta [3] consiste en une composition sophistiquée d’actions et de migrations. Chaque élément de l’itinéraire
est constitué par ce qui est appelé un pattern de migration. Un itinéraire est
une séquence de tels patterns. Chaque pattern est associé avec une action que
l’agent mobile devra effectuer lorsque l’agent mobile arrivera sur un nouvel hôte,
dont le descriptif est dans l’itinéraire (par exemple, appeler la fonction de nom
justOnTime).
Pattern
ItinEntry
Sequence
PatternCollection
Selection
Key
Set
SplitJoin
Class
Abstract
Class
Split
SplitJoinAll
SplitJoinAny
Fig. 3.8 – Les Patterns de migration dans Ajanta
Les patterns de migration de Ajanta sont les suivants (cf. figure 3.8) :
– Pattern : Élement abstrait de base d’un itinéraire
– ItinEntry : La définition d’un hôte à visiter et l’appel de la fonction
– PatternCollection : Une agrégation de pattern de migration
– Sequence : L’agent mobile visite la liste des hôtes de façon séquentielle
– Selection : L’agent mobile visite un hôte des hôtes de la liste des serveurs
– Set : L’agent mobile visite la liste des hôtes au hasard
– Split : L’agent mobile peut créer des agents mobiles fils qui feront le travail
à sa place, en parallèle
– SplitJoin : L’agent mobile père attend le retour de tous les agents mobiles
fils et il se synchronise avec leur résultat
– SplitJoinAll : L’agent mobile père attend tous ses agents mobiles fils dans
un état de rendez-vous
– SplitJoinAny : L’agent mobile père attend le retour d’un seul de ses agents
mobiles fils
En effectuant une combinaison des éléments du schéma proposé par Ajanta,
on peut obtenir un itinéraire d’administration évolué. Les possibilités offertes par
le parallélisme et les points de rendez-vous, permettent de réaliser des tâches à
grande échelle avec le même type d’agent mobile.
62 Les plates-formes à agents mobiles pour l’administration système et réseau : État de l’art
3.4
3.4.1
La topologie du réseau
Motivation : besoin de découverte automatisée
Il s’agit d’étudier les outils qui permettent de découvrir la topologie d’un
réseau, que ce soit au sein d’un réseau local, ou dans un réseau plus étendu
comme un réseau d’entreprise, métropolitain ou longue distance.
Breitbart et al. [13] remarquent qu’il est difficile de conserver la topologie du
réseau manuellement et que ce travail devient vite frustrant. En effet, un ajout
de routeur ou d’un commutateur entraîne un changement dans le fonctionnement global du réseau et une cartographie automatique permet de faire aisément
gagner du temps à l’administrateur. Le travail de Schonwalder [79] propose de
déterminer la topologie du réseau au niveau 3 parce que le protocole IP est le
protocole le plus répandu. C’est d’autant plus facile à réaliser parce qu’il existe
des outils dans la pile du protocole IP (par exemple le drapeau ICMP dans un
paquet IP). Ainsi, il est aisé de déterminer la topologie d’un réseau de niveau
3, car tous les équipements actifs intervenant savent naturellement dialoguer en
utilisant le protocole IP. On trouve dans la littérature des algorithmes permettant
la construction de la topologie de niveau 3 et récemment grâce à l’amélioration
des équipements actifs (commutateurs, concentrateurs intelligents), on trouve des
algorithmes pour construire la topologie de niveau 2 pour les réseaux locaux.
3.4.1.1
Définition de la notion de topologie
La topologie de niveau 3 est la cartographie d’un réseau qui répond au
protocole IP. Les équipements actifs intervenant dans cette topologie sont des
équipements capables d’effectuer du routage de paquets IP (par exemple un routeur). Les autres équipements sur le chemin, tels que les commutateurs et les
concentrateurs ne peuvent pas être répertoriés puisqu’ils ne participent pas à la
gestion du trafic IP.
La topologie de niveau 2 est la cartographie d’un réseau local (LAN) prenant en compte tous les équipements actifs intervenant dans le fonctionnement
et la transmission d’information. On rappelle qu’un équipement actif de niveau
2 ne participe pas au cheminement de paquets IP dans le réseau (pas de routage, par exemple). Il n’est pas trivial de détecter simplement des équipements
actifs de niveau 2. Un équipement actif de niveau 2 peut être détecté, s’il possède
un agent SNMP actif, lors de la construction de la topologie. Les services que
l’équipement actif fournit, sont définis dans le descriptif du système de la MIB2 SNMP (mib-2.system.sysServices). Par contre, un équipement simple, tel un
concentrateur ou un commutateur sans agent SNMP, ne pourra pas être détecté.
C’est en posant quelques hypothèses et en faisant quelques regroupements d’information, que l’on espère justes, que l’on pourra les intégrer dans la topologie
La topologie du réseau
63
construite (par exemple, si plus d’une adresse Ethernet est détectée sur un port
d’un commutateur, alors on peut considérer qu’il y a un concentrateur connecté
sur ce port du commutateur).
En synthétisant les différentes définitions de ce qu’est la topologie, on peut dire
que la topologie du réseau est une vue de l’ensemble des éléments du réseau (LAN,
MAN, WAN) qui entrent en jeu dans le fonctionnement des services qui sont
fournis par le biais du réseau. Par le biais de cette topologie, les administrateurs
réseau peuvent avoir une vue globale des équipements actifs qui fonctionnent (les
équipements actifs défaillants seront détectés par des alarmes provenant de ceux
opérationnels) et qui permettent de fournir un service : l’accès au Web, l’accès
aux services de messagerie, en sont des exemples.
3.4.1.2
Exemples d’applications liées à la connaissance de la topologie
Pour compléter la motivation de disposer de la cartographie du réseau, nous
donnons ci-dessous quelques exemples concrets où cette topologie s’avère intéressante.
Surveillance des liens L’apparition des applications réparties pose de plus en
plus de problèmes aux administrateurs, tant par les besoins de qualité de services
induits que par la bande passante réseau qui est utilisée par ces applications.
La localisation des serveurs d’application peut être répartie sur tout le réseau de
l’entreprise ce qui peut induire des surcharges locales sur certains brins du réseau.
La bonne connaissance de la topologie permet à l’administrateur de redimensionner le débit de son réseau ou de délocaliser certains serveurs d’applications en
fonction de la plus forte demande.
PathFinder [33] propose de connaître la topologie dans le but de savoir comment circulent les flux sur le réseau, de quel poste client vers quel poste serveur,
etc.., sachant que tout poste client joue de plus en plus souvent aussi le rôle d’un
serveur d’information ou de calcul du réseau. Les possibilités de partage de données ou la puissance de calcul des postes de travail actuels permettent en effet à
tout poste "Client" de devenir un poste "Serveur" sur le réseau.
Filtre pour les alarmes du réseau Pour améliorer la qualité des alarmes
qui remontent du réseau, une bonne connaissance de la topologie du réseau peut
s’avérer nécessaire. Chaque élément du réseau peut renvoyer une alarme après
avoir détecté une faute du réseau, ce qui face à l’augmentation croissante des
éléments (commutateurs, PCs, etc..) peut engendrer beaucoup d’alarmes. L’utilisation de la connaissance de cette topologie permettrait de filtrer les alarmes
pour n’obtenir que quelques alarmes permettant à l’administrateur de prendre
une décision rapide.
Ainsi Breitbart [13] propose de définir un algorithme pour construire une
topologie de réseau physique de niveau 2 permettant de filtrer les alarmes (sup-
64 Les plates-formes à agents mobiles pour l’administration système et réseau : État de l’art
pression des alarmes redondantes provenant de différents éléments ayant détectés
une panne). Avec cette technique, l’administrateur pourra focaliser son attention
sur l’élément du réseau (en général un équipement actif) qui est devenu défaillant.
Observation des performances du réseau Lorsqu’un réseau Ethernet est
segmenté en utilisant des commutateurs, chaque commutateur obtient une vision
du segment qu’il gère. Sur chaque segment, l’administrateur peut collecter sa
charge en utilisant les informations du commutateur. Avec la corrélation des
vues de tous les équipements actifs, l’administrateur peut détecter les endroits
de son réseau consommant le plus de bande passante, voire même saturant les
segments. Par cette correlation, l’administrateur peut intervenir afin d’améliorer
les conditions générales du réseau, soit en déplaçant physiquement les serveurs
d’application, soit en gérant mieux le trafic de chaque segment (utilisation de
seuil par exemple pour limiter la bande passante de certaines applications).
Une approche proposée par REMOS [46] et par Fontanini [28], est d’utiliser
la topologie du réseau afin d’essayer d’anticiper des problèmes de charge sur le
réseau pendant des phases critiques mais aussi de pouvoir analyser le réseau en
mode de fonctionnement normal.
3.4.2
Techniques de découverte de la topologie
Dans cette section nous présenterons les techniques utilisées pour déterminer
la topologie des réseaux de niveau 3 (IP) et dans la section suivante celle de niveau
2 (Ethernet). Nous commencerons notre présentation par les outils commerciaux
qui utilisent ces techniques et nous montrerons quelles ont été les recherches
effectuées sur les deux niveaux par la suite.
3.4.2.1
Les outils disponibles dans les plates-formes d’administration
commerciales
De plus en plus d’outils commerciaux se sont penchés sur l’obtention de la
topologie du réseau. Les premières topologies de réseaux construites ont été faites
au niveau de la couche réseau (niveau IP). Les principaux outils qui relèvent de
ce type de construction de la topologie du réseau sont évidemment Hp Network
Node Manager [35] et IBM Tivoli [95]. Ces deux outils commerciaux ont utilisé
les informations qu’il est possible de trouver dans les MIBs SNMP des routeurs
pour construire leur topologie. Avec la diminution des coûts de la bande passante
et l’amélioration du cœur du réseau (matériel actif plus performant comme par
exemple des commutateurs), on trouve désormais des outils commerciaux pour
avoir une topologie de niveau liaison de données (niveau Ethernet, ATM, etc..). Le
principal outil commercial réalisant une telle tâche est l’outil Hp Network Node
Manager extended Topology [35] qui fournit via le même outil une topologie de
niveau 3 et une topologie de niveau 2. Dans les sections suivantes nous parlerons
La topologie du réseau
65
des outils de construction de la topologie dont l’algorithme est disponible, parce
que dans les outils commerciaux il n’est pas possible d’avoir la ou les méthodes
permettant de construire la topologie du réseau.
3.4.2.2
Topologie de Niveau 3
La topologie de niveau 3 permet de connaître la connectivité qui peut exister
entre les différents éléments du réseau de l’entreprise, même d’une portion d’Internet, et ce en utilisant les techniques traditionnelles disponibles dans les systèmes
d’exploitation actuels. Les principaux outils ont été énumérés dans le chapitre 2.
Il s’agit des outils de base comme Ping, Arp et Traceroute (voir la section 2.3.3).
Les équipements actifs composant le cœur du réseau n’interviennent pas dans le
routage du trafic et ne peuvent pas être mentionnés dans une topologie de Niveau
3.
Les premières recherches pour déterminer une topologie de niveau 3 ont été
effectuées par Siamwalla [70]. La technique utilisée permet d’avoir la topologie
d’un WAN, d’un MAN ou tout simplement d’un LAN en ne prenant en compte
que les routeurs.
Fig. 3.9 – Une portion de l’Internet
L’algorithme proposé par Siamwalla [70] (voir topologie résultante figure 3.9)
est une combinaison des techniques vues dans la section 2.3.3. Il s’agit d’utiliser
les informations du protocole IP (Ping et Traceroute), de rajouter la possibilité
66 Les plates-formes à agents mobiles pour l’administration système et réseau : État de l’art
d’interrogation des serveurs DNS [26] (DNS Zone Transfert : permet d’obtenir
la liste de toutes les machines enregistrées dans le serveur DNS) pour construire
la topologie désirée. Celle-ci est effectivement trouvée avec plus ou moins de
rapidité (dépend du nombre d’hôtes dans la classe d’adresse IP) car l’outil doit
tout d’abord déterminer le masque du réseau associé à chaque sous-réseau qui
doit être analysé. En effet, la recherche des adresses IP est résolue en diminuant
le nombre de bits du masque du réseau (de 31 à 7, c’est-à-dire couvrant les classes
d’adresse IP C, B et A), puis en envoyant des paquets ICMP en broadcast sur le
réseau. Les éléments qui répondent permettent de déterminer le masque de réseau
associé aux adresses IP. Chaque élément qui répond est répertorié en utilisant les
principes du système de fichier Unix, c’est-à-dire la classification arborescente des
répertoires et des fichiers. Chaque élément est enregistré dans le répertoire dont
le nom est défini par l’adresse IP du réseau. Ainsi avec cette technique, Siamwalla
[70] obtient la représentation d’une topologie sous forme arborescente. Seuls les
éléments de types routeurs sont présentés sur le graphique (cf. figure 3.9) de la
topologie obtenue.
Les techniques utilisées dans la proposition de Schonwalder [79] sont d’utiliser
la combinaison du protocole ICMP pour déterminer la connectivité des éléments
appartenant à la topologie finale et les outils comme traceroute pour déterminer les routeurs intervenant entre les réseaux ciblés. Une fois ceux-ci détectés,
l’adresse des réseaux est obtenue en utilisant le ICMP mask request. Le protocole ICMP permet de demander au routeur gérant le sous-réseau de retourner
l’adresse du réseau et le masque d’adresse associé. L’utilisation du masque de
réseau permet de regrouper les éléments découverts dans le même sous-réseau
dessiné graphiquement.
Une extension des techniques de Schonwalder [79] est proposée par Lin [34].
Lorsque les éléments ont été détectés, Lin [34] utilise les informations des agents
SNMP.
Ainsi, ceci permet de borner simplement l’étendue de la découverte de topologie de niveau 3. En effet, la découverte se fonde sur la possibilité d’interroger
les agents SNMP des équipements actifs. Dès lors que l’on n’a pas accès aux informations des MIB-2 SNMP (car elles seraient sous la responsabilité d’un autre
administrateur de réseau), la découverte s’arrête d’elle-même. En plus cette méthode permet d’améliorer sensiblement le temps de construction de la topologie
par rapport à [79], parce qu’il est possible d’avoir puis d’exploiter les informations
des tables de routage.
Une approche différente est d’essayer d’utiliser une plates-formes à agents mobiles pour construire la topologie du réseau IP. Par exemple, un agent capable
de se déplacer sur le réseau distant effectue la collecte des adresses IP du dit
réseau, revient à la station d’administration principale et repart, si nécessaire
vers un nouveau sous-réseau à découvrir. Une telle approche, mettant en évidence
l’intérêt de la mobilité est présentée par la plate-forme AGNI [71], montrant que
l’effect de délocalisation permet d’améliorer de près de 30 % le temps global de
La topologie du réseau
67
la construction de la topologie en utilisant les agents de AGNI, par rapport à la
solution centralisée.
3.4.3
Topologie de niveau 2
3.4.3.1
Introduction
Avec la somme d’information disponible de fait dans certains équipements
actifs du réseau (niveau 2), il devient possible de découvrir la topologie de niveau
2 en allant tout simplement collecter ces informations dans les équipements actifs.
Après cette collecte, une corrélation des données est nécessaire pour obtenir la
topologie du réseau local. Tous les algorithmes de découverte de la topologie de
niveau 2 sont de ce fait assez similaires.
3.4.3.2
Point commun des algorithmes de découverte de la topologie
L’objectif est d’avoir, à partir de l’information minimale du réseau (données
d’un commutateur par exemple), une topologie représentant tous les éléments
qui entrent en jeu dans le fonctionnement du réseau local. Il peut s’agir des
commutateurs, des serveurs, des serveurs d’impression, des postes de travail, en
définitive de tout élément connecté sur le réseau local. La topologie obtenue permet d’avoir le positionnement de ces éléments par rapport à chaque commutateur,
par exemple, dans l’architecture générale du réseau.
Ces algorithmes ([34], [46], [13]) utilisent tous le protocole SNMP pour collecter des informations dans les MIBs SNMP et notamment les informations contenues dans la MIB-2 Bridge qui donnent les associations port/adresse Ethernet
des éléments connectés (cf. pour exemple la figure 3.10), appelée communément la
matrice de commutation (Forwarding Database). En effet, la MIB Bridge contient
les informations nécessaires à la commutation des trames Ethernet sur le réseau.
Une utilisation des informations de la MIB Bridge est présentée plus en détail
dans la section 5.4 pour la construction de la topologie d’un réseau local. En
corrélant ces données, c’est-à-dire en associant les adresses Ethernet des éléments
du réseau, celles découvertes dans la MIB Bridge, on peut arriver à positionner
les éléments dans la topologie du réseau. Toutefois, lorsque le réseau fonctionne
avec des équipements actifs non SNMP, une partie de la topologie ne peut être
construite. En effet, la MIB Bridge pourra avoir enregistrée, par exemple, 30
adresses Ethernet sur le port du commutateur sans pouvoir fournir suffisamment
d’information pour déterminer la topologie réelle. Dans ce cas précis, on supposera la présence d’un équipement actif (concentrateur par exemple) connectant
les différents éléments.
En conclusion, cela motive le fait que tout équipement actif devrait avoir un
agent SNMP. C’est d’ailleurs la tendance générale (un tel agent est présent en
standard dans les commutateurs Cisco, commutateurs de plus en plus utilisés).
68 Les plates-formes à agents mobiles pour l’administration système et réseau : État de l’art
Fig. 3.10 – Topologie de niveau 2
Avec les informations collectées de plus en plus nombreuses, la topologie résultante aura une chance d’être de plus en plus précise. Cependant, il est intéressant
d’avoir toute cette quantité d’information, mais il demeure néanmoins que la
partie la plus importante et la plus délicate de l’algorithme de construction de la
topologie reste la corrélation des données.
Nous avons été obligé d’écrire notre propre algorithme de découverte et de
construction de la topologie (voir chapitre 5) parce que les algorithmes décrits
précédemment ne sont pas disponibles dans le domaine public.
3.5
Bilan
Dans ce chapitre nous avons pu mettre en évidence les techniques utilisées
pour déployer une plate-forme à agents mobiles : démarrage des nœuds, arrêt, redémarrage, nommage des nœuds et les techniques de localisation de ceux-ci. Après
avoir évoqué les différents types d’agents mobiles qu’il est possible de mettre en
œuvre, chacun ayant une fonctionnalité bien définie (agent visiteur, agent trans-
Bilan
69
porteur, etc.), nous nous sommes penchés sur le problème de la programmation
des agents mobiles dans ces plates-formes. Différentes techniques sont mises en
œuvre dans les plates-formes, et nous avons vu que le schéma général reste le
même : instanciation d’un agent mobile générique pour les fonctionnalités générales de l’agent mobile, puis gestion des ordres de migration de ceux-ci. Soit d’une
manière manuelle (primitivie go), soit de manière transparente à l’agent mobile
par le biais d’un système de poursuite de l’itinéraire.
Nous avons décrit les différents types d’itinéraires pouvant exister mais aussi
les schémas de composition permettant d’aller au delà d’un itinéraire "séquentiel"
et d’avoir des itinéraires plus structurés. Ces itinéraires permettent d’avoir des
itinéraires d’administration plus évolués que le mode séquentiel.
En fin de chapitre, les outils de construction de la topologie de niveau 3 et
de niveau 2 ont été vus pour mettre en évidence l’intérêt d’avoir la topologie du
réseau construite automatiquement. Il s’agira d’en tirer profit pour la construction
d’itinéraires d’administration système et réseau dynamique.
Nous présenterons dans le chapitre suivant la solution que nous avons mise
en œuvre au dessus de la plate-forme ProActive pour fournir des itinéraires liés
à l’administration système et réseau en utilisant des agents mobiles.
70 Les plates-formes à agents mobiles pour l’administration système et réseau : État de l’art
Chapitre 4
Conception d’un mécanisme
d’itinéraires dynamiques pour
l’administration système et
réseau
4.1
Introduction
Nous voulons fournir un système d’itinéraires pour effectuer des tâches d’administration système et réseau. Comme étudié dans le chapitre précédent, les platesformes à agents mobiles se fondent en général sur des itinéraires d’administration
qui sont statiques (liste d’éléments dans un fichier texte par exemple) ; l’objectif
est de se détacher de cette contrainte en fournissant des itinéraires dynamiques
bâtis grâce à la découverte de la topologie sous-jacente du réseau à administrer.
Le mécanisme d’itinéraire dynamique que nous proposons dans cette thèse est
un système permettant la migration des agents mobiles en vue de l’exécution
des opérations d’administration sur les différents hôtes ou éléments réseau, qui
est basé sur la composition d’itinéraires dynamiques correspondant à chacun des
sous-réseaux locaux constituant le domaine de l’entreprise. Nous ne fournissons
pas d’itinéraires en rapport avec l’Internet ou une portion de cet Internet. En effet, il n’est pas nécessaire de prendre en compte le réseau de l’opérateur qui relie
les différents sous-réseaux que nous souhaitons administrer avec la technologie
des agents mobiles, parce que nous souhaitons mettre en œuvre des itinéraires
d’administration dans les réseaux locaux du domaine à administrer. Ainsi, le réseau extérieur ne relève pas de notre compétence. Et donc, la topologie, même
partielle du réseau IP, n’est pas prise en compte dans le cadre de notre recherche.
La section 5.4 expliquera en détail le principe et l’implantation du mécanisme
de découverte de la topologie réseau du domaine à administrer.
Pour cela, nous avons utilisé la bibliothèque à agents mobiles ProActive [67] et
71
72 Conception d’un mécanisme d’itinéraires dynamiques pour l’administration système et réseau
étendu le système existant d’itinéraire de migration pour l’adapter à un environnement d’administration système et réseau. Dans la section 4.2 nous décrirons les
fonctionnalités de la plate-forme ProActive. Dans la section 4.3 nous détaillerons
plus précisément le modèle de cette plate-forme dans le contexte de la migration.
Les extensions apportées, sans modification du modèle de ProActive, seront présentées dans la section 4.4. Il est important de remarquer que ces extensions ont
pu être faites sans modification du modèle de suivi d’itinéraire de la bibliothèque
de ProActive.
4.2
Les agents mobiles dans ProActive
Les modèles à objets actifs proviennent de l’unification des notions d’objet
et d’activité, de la même manière que le concept d’objet lui-même provient de
l’unification des notions de structure de données et de procédure. Un objet actif
se conforme donc à la règle des trois unités : unité de données (objets), unité de
code (classes) et unité d’activité (threads).
Le concept d’agent mobile résulte de la rencontre entre les techniques de programmation distribuée à objets et les techniques de code mobile. Dans son acception la plus courante, la notion d’agent mobile désigne une entité logicielle
autonome qui se déplace de machine en machine afin de remplir une tâche.
Même si diverses plates-formes d’agents mobiles ont été proposées (dans le
cadre du langage Java, Aglets [97] et Voyager [98] pour les plus célèbres), aucune
n’intègre de façon réellement transparente les aspects objets actifs communicants
d’une part, mobilité d’autre part, comme réussit à le faire ProActive.
4.2.1
ProActive : objets actifs asynchrones communicants
Dans un souci de portabilité, la bibliothèque ProActive s’interdit toute modification du langage Java et de sa machine virtuelle. Nous sommes donc en présence
d’une simple bibliothèque, qui utilise les outils standards (javac et JVM). Pour
des raisons de déverminage des programmes (problème exacerbé en l’occurrence
car ils sont répartis et parallèles), ProActive s’interdit également la modification
du code source écrit par l’utilisateur (pas de pré-traitement). De plus, la bibliothèque est elle-même écrite entièrement en Java, ce qui autorise l’utilisation de
n’importe quelle plate-forme Java et des outils associés, en particulier le fonctionnement dans un environnement ouvert et dynamique avec télé-chargement
dynamique de code ; ProActive utilise le mini-serveur http de la plate-forme Java
pour transférer dynamiquement le bytecode nécessaire.
Les agents mobiles dans ProActive
4.2.2
73
Modèle de base
ProActive offre un modèle de programmation parallèle et répartie que l’on
peut qualifier de “à objets actifs” [15] (par opposition à des approches où les
activités sont orthogonales aux objets), et de “hétérogène” dans le sens où tous
les objets ne sont pas actifs. Un des objectifs est de faciliter la programmation
répartie, en particulier par le biais de la réutilisation [18].
En bref, le modèle de ProActive présente les caractéristiques suivantes :
– des objets actifs et accessibles à distance,
– la séquentialité des activités (processus purement séquentiels),
– une communication par appel de méthode standard,
– des appels systématiquement asynchrones vers les objets actifs,
– un mécanisme d’attente par nécessité (futur transparent),
– les continuations automatiques (un mécanisme transparent de délégation),
– l’absence d’objets partagés,
– une programmation des activités qui est centralisée et explicite par défaut,
– du polymorphisme entre objets standards et objets actifs distants.
Un appel asynchrone permet de ne pas se bloquer lors d’une communication. Cependant, toute communication se base sur une phase de rendez-vous (l’émetteur
est bloqué jusqu’à ce que l’appel de méthode ait atteint la file des requêtes en
attente de l’objet récepteur).
Un futur est alors un objet résultat d’un appel asynchrone : initialement il
n’a pas encore de valeur. D’une façon duale, l’attente par nécessité permet de
se bloquer automatiquement si l’on tente d’utiliser le résultat non encore revenu
d’un appel asynchrone. Un futur est transparent dans le sens où le programmeur
n’a pas besoin d’ajouter du code pour obtenir ce type de synchronisation.
Par rapport à RMI 1 , ProActive se caractérise par la création d’activités à
distance, par des objets distants générés à partir de classes ou d’objets (et non pas
uniquement d’interfaces), par les appels asynchrones et les futurs transparents,
par un contrôle fin de l’activité (file d’attente de requêtes paramétrable) des
objets actifs et bien sûr la migration.
Nous allons maintenant présenter succinctement les principales caractéristiques de ProActive (pour plus de détails voir [17]).
4.2.3
Création des objects actifs
La bibliothèque a pour objectif de permettre la création d’un object actif
distant le plus simplement possible, à partir de code (donc d’une classe 2 ) initialement local et séquentiel. Un objet Java standard, créé par une instruction :
A a = new A ("foo", 7);
1
Remote Method Invocation, bibliothèque standard de Java
Si le code de la classe n’est pas disponible dans la JVM, il sera dynamiquement téléchargé
depuis un serveur HTTP, indiqué au lancement de la JVM.
2
74 Conception d’un mécanisme d’itinéraires dynamiques pour l’administration système et réseau
a) Instanciation-based :
A a = (A) ProActive.newActive ("A", params, Node);
b) Object-based :
a = (A) ProActive.turnActive (a, node);
Fig. 4.1 – Création des objects actifs : Instanciation-, Object-based
peut être transformé en un objet actif distant de deux manières différentes (Exemple
figure 4.1).
Du plus statique au plus dynamique, a) Instanciation-based passe par la
création d’une nouvelle classe ou d’une interface qui sera instanciée avec l’activité
FIFO par défault. Si cette classe ou interface implémente l’interface-marqueur
RunActive 3 , l’activité propre de l’objet actif sera définie par la méthode runActivity, en place de l’activité FIFO réalisée par défaut (cf. section 4.2.4). Le second
paramètre de cet appel statique (params) correspond aux paramètres effectifs à
passer au constructeur lors de la création distante. Dans notre exemple, il peut
être défini par :
Object[] params = {"foo", new Integer (7)};
Il est possible de redéfinir la politique de service sans que l’objet actif implémente
l’interface-marqueur RunActive en appelant une des méthodes newActive de la
bibliothèque, qui prend en paramètre une activité (cf. code figure 4.2).
A a = (A) ProActive.newActive("A",null,
"//lo.inria.fr/VM1", RunActive, null)
Fig. 4.2 – Création d’un objet actif avec une politique de service RunActive
Le dernier paramètre (node) spécifie la machine virtuelle où doit être placé
l’objet actif (c’est habituellement une URL, par exemple, de la forme //lo.inria.fr/VM1).
Dans le cas d’un node null, la création se fait dans la JVM en cours. Un autre
objet actif passé en paramètre à la place du paramètre node (newActive est surchargée) permet la co-allocation (même machine virtuelle) avec un objet actif
déjà existant (cf. figure 4.3).
Enfin, le dernier type de création, b) Object-based, est encore plus dynamique puisqu’il prend un objet déjà créé, et en fait un objet actif accessible à
distance. La sémantique est la suivante. Tout d’abord, si le code nécessaire à un
accès distant sur ce type d’objet n’existe pas encore, il est généré dynamiquement. Si node est la JVM en cours, les éléments nécessaires à la création d’un
3
Interface marqueur, RunActive comporte une routine qui permet de redéfinir la politique
de service
Les agents mobiles dans ProActive
75
A a0 = (A) ProActive.newActive("A",params,null) ; // JVM en cours
A a1 = (A) ProActive.newActive("A",params,"//lo.inria.fr/VM1") ;
A a2 = (A) ProActive.newActive("A",params,a1) ; // co-allocation
Fig. 4.3 – Création d’un objet actif dans la JVM en cours, à distance ou par
co-allocation
class BoundedBuffer extends FixedBuffer
implements RunActive {
runActivity (Body myBody) {
while (true) {
if (this.isFull()) myBody.serveOldest ("get");
else if (this.isEmpty()) myBody.serveOldest ("put");
else myBody.serveOldest();
myBody.waitForNewRequest ();
} } }
Fig. 4.4 – Programmation explicite du contrôle
objet actif sont ajoutés à l’objet en question (une activité propre, une file d’attente, etc.). Si node n’est pas la JVM en cours, une copie de l’objet en question
est transmise à la JVM node, et les éléments mentionnés ci-dessus sont ajoutés
dans la JVM de cette copie. Dans tous les cas, l’objet original passif reste en
place. Cette technique permet entre autre la répartition de code pour lequel on
ne dispose pas du source.
4.2.4
Activités, contrôle explicite et abstractions
Les appels distants étant asynchrones, ils sont mémorisés sous la forme de
requêtes dans une file d’attente du côté de l’appelé. Ultérieurement, nous dirons
que la requête est servie par l’objet actif. Jusqu’à présent, nous avons créé un
objet actif sans préciser son activité, et par défaut un service fifo des requêtes
était alors réalisé : exécution des requêtes dans l’ordre d’arrivée. Dans ce sens,
les objets actifs sont bien des processus purement séquentiels.
La création d’objets actifs de type a) Instanciation-based permet de donner
à un objet un comportement spécifique4 : activité propre (qui ne consiste pas
à servir des méthodes publiques), activité mixte (services et activité propre),
services purs mais de type non-fifo.
L’exemple 4.4 présente un simple tampon borné. La routine runActivity
permet à l’utilisateur de spécifier, sous la forme d’un thread explicite, l’activité
4
Un objet actif se situe toujours dans un continuum : Acteur pur – Agent – Serveur pur.
76 Conception d’un mécanisme d’itinéraires dynamiques pour l’administration système et réseau
void
void
void
void
void
serveOldest () ;
serveOldest (String S) ;
serveOldest (String S1, String S2) ;
serveOldestWithoutBlocking () ;
serveMostRecentFlush (String s) ;
void serveOldestTimed (int t) ;
void waitForNewRequest () ;
Sert la plus ancienne requête, bloquée
Sert la plus ancienne de nom S, bloquée
Sert la plus ancienne de nom S1,S2
Service non bloquant
Sert la plus ancienne de nom s,
et supprime les autres
Service bloquant pour au plus t ms
Attente non active d’une requête
Tab. 4.1 – Routines de service
de l’objet. Lorsque cette routine existe, elle remplace totalement le comportement
fifo fourni par défaut. Le paramètre myBody donne accès à tout un ensemble de
routines de services permettant de sélectionner la requête à servir. Dans l’exemple
4.4, la méthode serveOldest est utilisée, mais toute une bibliothèque est accessible
au programmeur (exemple 4.1). On y trouve des services bloquants, non-bloquants,
temporisés, etc. mais également des itérateurs sur la file d’attente permettant
d’étendre la bibliothèque si nécessaire. Notons waitForNewRequest qui permet de
programmer une attente non-active.
Nous sommes ici en présence d’une programmation de l’activité qui est explicite, avec service lui aussi explicite, sans non-déterminisme sur l’ordre des services ; dans l’exemple 4.4 si le tampon n’est ni plein ni vide, on impose de servir la
requête la plus ancienne. Ce type de programmation est fort utile si l’on souhaite
avoir un contrôle fin sur l’activité de l’objet.
Le fait que la programmation soit ouverte (contrôle du service des requêtes) se
révèle particulièrement important pour la construction d’un service de migration
puissant et flexible (voir section 4.3.2). Cet aspect de programmation ouvert,
permet aisément d’étendre le modèle de ProActive pour des besoins spécifiques.
4.3
4.3.1
Migration
Migration Faible
Il est bien connu qu’il est difficile d’implémenter (c.f. [90]) de façon complètement portable de la migration forte en Java de par l’absence de trois fonctionnalités : interruption préemptive, lecture et sérialisation du thread, écriture
(reconstruction) du thread sur la JVM cible. Par souci de portabilité ProActive
s’est interdit toute modification de la machine virtuelle, toute utilisation d’outils
tels qu’un préprocesseur de code source (ProActive agit donc uniquement à l’exécution) et finalement, en raison des problèmes de sécurité, toute modification des
classes (le bytecode) au chargement.
Migration
77
public class SimpleAgent implements RunActive,
Serializable {
public void moveToHost(String t) {
ProActive.migrateTo(t);
}
public void joinFriend(Object friend) {
ProActive.migrateTo(friend);
}
public ReturnType foo(CallType p) {
...
} }
Fig. 4.5 – SimpleAgent : exemple d’un objet actif mobile
4.3.1.1
Primitive
Il existe en fait une seule primitive implémentée dans la bibliothèque ProActive pour fournir la migration des objets actifs communicants : migrateTo() .
Cette primitive est surchargée en deux versions décrites dans la table 4.2.
static void migrateTo(URL)
static void migrateTo(Objet)
Permet la migration vers
un site référencé par une URL.
le site supposé d’un autre objet actif.
Tab. 4.2 – Primitives de migration (méthodes statiques)
Un objet voulant migrer appelle lui-même la méthode statique migrateTo()
qui se charge de toutes les opérations nécessaires à la migration, notamment la
sérialisation de tout le sous-système (un objet actif et tous ses objets passifs) et
sa reconstruction à l’arrivée sur le site distant. Il est possible soit de migrer vers
un nœud distant que l’on désigne explicitement, soit de migrer pour rejoindre un
autre agent, sans que l’on sache explicitement sur quel nœud il se trouve. Dans
ce dernier cas, il n’est toutefois pas possible de garantir que, une fois la migration
effectuée, les deux objets mobiles se trouveront sur le même nœud : il est possible
que l’agent que l’on cherche à rejoindre migre lui aussi de site en site.
Pour utiliser cette primitive, un objet actif peut implémenter une méthode
publique qui appellera la méthode statique ProActive.migrateTo(). Ainsi, la demande de migration pourra venir d’un objet tiers. Cependant, la décision de
migrer viendra in fine de l’objet mobile lui-même : lors du service d’une requête
portant sur une telle méthode publique. A noter que du fait de la migration faible,
tout code situé après ProActive.migrateTo() ne sera pas exécuté. L’exemple 4.5
illustre l’utilisation des méthodes de migration dans un objet actif.
78 Conception d’un mécanisme d’itinéraires dynamiques pour l’administration système et réseau
4.3.1.2
Localisation d’objets mobiles
Afin de pouvoir assurer la communication en présence de migration, il est
nécessaire de pouvoir localiser après un nombre quelconque de migrations un
objet actif. Pour être indépendant du système d’exploitation sous-jacent, la bibliothèque ProActive implémente le système de localisation dans sa couche applicative [8].
L’approche définie dans ProActive est une approche par répéteur. Plus précisément, la source d’un message n’a pas besoin de connaître la localisation exacte
de l’agent mobile, il lui suffit de savoir que tout message qu’elle envoie sera correctement acheminé à destination. Pour réaliser cela, l’agent mobile qui quitte
un nœud laisse derrière lui un objet répéteur qui sera chargé de faire suivre les
messages vers son nouveau site d’exécution présumé (cf. figure 4.6).
Site A
Repeteur
Source
4 - Mise a jour
1 - Envoi de la requete
2 - Suivi
Site B
3 - Suivi
Site C
Agent
Site D
Fig. 4.6 – Localisation avec répéteurs
Ce nouveau nœud peut lui-même abriter un répéteur, et ainsi de suite pour
chaque migration. On obtient ainsi une chaîne de répéteurs qui a pour dernier
maillon l’objet actif mobile. Le message sera donc transmis de nœud en nœud
jusqu’à l’agent. Pour améliorer la fiabilité d’un tel système de répéteurs, c’està-dire diminuer le risque que la chaîne des répéteurs soit brisée par une panne,
ProActive implémente un système diminuant la longueur de la chaîne des répéteurs, en mettant à jour dynamiquement les références vers la nouvelle position
de l’agent mobile : lorsqu’un appel de méthode atteint l’objet mobile, la localisation exacte de l’appelé est renvoyée à l’appelant. Cette mise à jour est facile
à réaliser, puisque toute communication ProActive ( à travers des répéteurs ou
directement) se base sur la phase de rendez-vous.
4.3.2
Abstractions pour la mobilité
Le modèle et les primitives introduits précédemment permettent de construire
des objets actifs mobiles en gérant explicitement les migrations. Mais il est éga-
Migration
79
lement possible de construire, au dessus des primitives de base, des méthodes
et des concepts de plus haut niveau afin de gérer la migration à différents niveaux d’abstraction. Cela permettra entre autre de faciliter la spécification de
comportements autonomes.
Dans la suite de cette section, nous allons présenter trois types d’abstractions
réutilisables : l’exécution automatique de méthodes lors du départ ou de l’arrivée sur un nouveau site, le suivi d’un itinéraire pré-établi, et un agent mobile
générique.
4.3.2.1
Exécution automatique de méthodes sur départ et arrivée
La migration d’un objet actif mobile comporte deux phases principales correspondant au déroulement nominal de la migration, ce sont le départ d’un site et
l’arrivée sur le site de destination. Une troisième phase existe en présence d’une
levée d’exception. ProActive permet de construire une abstraction qui va associer
à chacune de ces phases une méthode à exécuter. Cette association se fait en
appelant une des méthodes de la table 4.3 avec comme paramètre le nom de la
méthode à exécuter.
static void onDeparture(String s)
static void onArrival(String s)
static void onException(String s)
Méthode à exécuter
au départ
à l’arrivée
lors d’une exception
Tab. 4.3 – API d’exécution automatique de méthode, notamment sur départ et
arrivée
Des contraintes ont été imposées sur les méthodes susceptibles d’être exécutées
automatiquement. Elles ne doivent prendre aucun paramètre et ne doivent retourner aucun résultat. Cependant il est possible d’avoir des fonctions complexes en
utilisant les attributs de l’objet. Une utilisation typique de ces méthodes est la
suppression et la reconstruction automatique d’éléments non sérialisables qui ne
peuvent donc pas être déplacés avec l’objet, tels qu’une interface graphique (voir
exemple figure 4.7).
4.3.2.2
Itinéraire
L’autonomie d’un agent mobile provient notamment de sa capacité à aller
de site en site sans intervention extérieure. Dans le cadre de la bibliothèque
ProActive, un itinéraire est formé d’un ensemble de paires destination-méthode,
instance d’une classe appelée NodeDestination, représentant les sites à visiter
avec les actions à effectuer à l’arrivée sur chacun d’entre eux. Les hôtes à visiter
(destinations au sens courant du terme) sont définis soit par reférence directe, soit
80 Conception d’un mécanisme d’itinéraires dynamiques pour l’administration système et réseau
static
static
static
static
static
static
void
void
void
void
void
void
add(URL, String method)
travel()
requestFirst(Boolean)
itineraryStop()
itineraryResume()
itineraryRestart()
ajoute un site à visiter
démarre le suivi d’un itinéraire
service des requêtes avant migration
arrête un itinéraire
reprend le suivi d’un itinéraire
recommence l’itinéraire
Tab. 4.4 – API d’utilisation d’un itinéraire
public void deleteSwingInterface() { . . . }
public void rebuildSwingInterface() { . . . }
public void migrateTo(String dest) {
...
ProActive.migrateTo(dest);
}
public void runActivity(Body b) {
...
b.itinerary.add(new NodeDestination("//tuba.inria.fr/Node1",
"rebuildSwingInterface"));
b.itinerary.add(new NodeDestination("//oasis.inria.fr/Node2",
"rebuildSwingInterface"));
ProActive.onDeparture("deleteSwingInterface");
ProActive.requestFirst(true);
...
ProActive.travel();
}
Fig. 4.7 – Exécution automatique de méthodes et itinéraires
par leur nom symbolique, auquel cas les mécanismes de nommage de RMI sont
utilisés5 . Une méthode est désignée par son nom, et est exécutée par réflexion.
Cette abstraction associe à chaque objet actif un itinéraire courant qui est
suivi de manière séquentielle, et contrôlé par les méthodes de la table 4.4. Un
objet mobile démarre un itinéraire en appelant la méthode travel(). Il est possible
d’appeler la méthode requestFirst() pour spécifier le moment où doit intervenir le
traitement des requêtes. L’agent peut ainsi suivre un itinéraire qui sera prioritaire
sur le traitement des requêtes (elles seront ignorées jusqu’à la dernière destination
de l’itinéraire) ou bien traiter toutes celles en attente avant de poursuivre son
parcours. Il est possible de contrôler directement et dynamiquement un itinéraire
afin de construire un comportement adapté à une application particulière (voir
en particulier les méthodes Stop et Resume de la table 4.4).
5
Ce qui revient à associer à chaque site une URL du type rmi ://nomdusite/nomdelobjet
Migration
81
public class GenericAgent implements Serializable {
...
public void shareInformation() {
int max = agentList.size();
for (int j=0;j<max; j++) {
((GenericAgent)
agentList.elementAt(j)).informationFound(. . .);
} }
public void runActivity(Body myBody) {
while (. . . ) {
this.serveAllPendingRequests();
this.performOperation();
this.shareInformation();
ProActive.migrateTo(getNextDestination());
} } }
Fig. 4.8 – Modèle générique d’activité d’un agent mobile
4.3.2.3
Agent mobile générique
Beaucoup d’applications à base d’agents mobiles présentent les mêmes caractéristiques : un ou plusieurs agents se déplacent de site en site, effectuent sur
chaque site des opérations et partagent leurs résultats. Pour décrire le fonctionnement d’un agent mobile, nous présentons sur la figure 4.8 l’activité générique
d’un agent mobile qui va de site en site pour exécuter une tâche T et qui partage
l’information recueillie avec d’autres agents mobiles du même type. Cet agent
mobile générique est réalisé en utilisant la bibliothèque ProActive et montre succintement comment est fait l’implémentation de la migration et comment est
réalisé le partage d’information.
L’activité de l’objet (cf. figure 4.8), se décompose en plusieurs opérations.
L’agent sert d’abord toutes les requêtes en attente, puis il effectue une opération
(par exemple une recherche d’information). L’information est ensuite partagée
avec les autres objets mobiles. Le code nécessaire pour cette tâche est extrêmement simple puisqu’il consiste à appeler une méthode sur chacun des autres
objets, le moteur d’exécution ProActive se chargeant de transformer l’appel local
en appel distant quelque soit le site sur lequel se trouve le destinataire.
Il suffit de redéfinir la méthode performOperation() afin de programmer les
fonctions précises de l’agent. Il est aussi possible d’avoir une politique de sélection
de site (méthode getNextDestination()) totalement aléatoire ou bien dépendante
des informations déjà recueillies.
82 Conception d’un mécanisme d’itinéraires dynamiques pour l’administration système et réseau
4.3.3
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 MigrationStrategyManager, 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 MigrationStrategyManager 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 effectuer 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
Noeud
Yate
Agent
Mobile
Noeud
Noeud
Koumac
Thio
Noeud
Migration
Noumea
Fig. 4.9 – Un itinéraire défini manuellement, construit avec la bibliothèque
ProActive
Conception d’itinéraires pour l’administration
83
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’administration
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égories, identifiables par leur mode de fonctionnement.
1. L’agent mobile effectue une migration sur un nœud afin d’y effectuer une
tâche (1er 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 communication 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 requê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
84 Conception d’un mécanisme d’itinéraires dynamiques pour l’administration système et réseau
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 permettant 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 conforme au modèle des Destinations de ProActive. Une SNMPDestination contient
l’ensemble des informations nécessaires pour effectuer une administration à distance (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
Conception d’itinéraires pour l’administration
85
SNMPDestination contient donc toutes les informations nécessaires pour dialoguer 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 équipements actifs n’intègrent pas de nœuds Java pour accueillir des agents mobiles.
Destination
NodeDestination
SNMPDestination
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 facilement 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 RendezVousDestination 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.
86 Conception d’un mécanisme d’itinéraires dynamiques pour l’administration système et réseau
obtenir un itineraire
Noeud
Agent
Mobile
Noeud
Noeud
Agent SNMP
Migration
Client/Serveur SNMP
Noeud
Interrogation
Fig. 4.12 – Un itinéraire dynamique construit selon le modèle des Destinations
Destination
NodeDestination
SNMPDestination
Action
Migration et exécution
de l’appel d’une méthode
Appel de méthode
pour un accès en Client/Serveur SNMP
Tab. 4.5 – Actions menées selon les types de Destination
4.4.2
Techniques d’obtention des éléments d’un itinéraire
Nous rappelons que nous sommes supposés effectuer de l’administration systè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 à disposition. 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.
Conception d’itinéraires pour l’administration
4.4.2.1
87
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
Interrogation du serveur LDAP
Noeud
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. Toutefois 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
88 Conception d’un mécanisme d’itinéraires dynamiques pour l’administration système et réseau
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.
Interface
Base de données
AM
Noeud
Fichiers descriptifs
Objet Actif
Serveur DNS
etc.
Noeud
Interrogation de l’objet actif
Migration vers un autre noeud
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’administration. 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 (principalement pas de service d’annuaire à mettre en œuvre). L’objet actif peut être défini
Conception d’itinéraires pour l’administration
89
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 comportement 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’utilisation 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.
4.4.3
Le modèle de service d’itinéraire proposé
4.4.3.1
Présentation globale
Ainsi, nous avons choisi d’implémenter un modèle qui est une variante des
deux solutions proposées précédemment. Dans le modèle adapté (cf. figure 4.15),
nous faisons transporter à l’agent mobile toutes les données qui lui sont nécessaires. L’objet actif, qui fournit la liste des éléments, est consulté une fois avant
que l’agent mobile démarre son itinéraire. L’objet actif a la charge de fournir des
informations les plus à jour possible aux agents mobiles, en collectant les données
obtenues par un algorithme de découverte de la topologie (voir la section 5.4 pour
les détails). L’objet actif est construit dans le même language de programmation
que la plate-forme à agents mobiles ce qui favorise la compatibilité entre les objets
de la plate-forme.
En donnant des listes d’éléments complètes aux agents mobiles un gain de
temps appréciable est réalisé pour le déroulement du suivi de l’itinéraire. Cependant, si un des nœuds devient défaillant, l’agent mobile progressera sur le suivi de
son itinéraire en ne tenant pas compte du nœud défaillant. Une possibilité peut
être offerte aux agents mobiles afin de prévenir le service d’itinéraire d’un ou plusieurs nœuds défaillants (utilisation de la méthode onException, cf. table 4.3).
90 Conception d’un mécanisme d’itinéraires dynamiques pour l’administration système et réseau
AM
Noeud
Objet Actif
Interrogation de l’objet actif
Migration vers un autre noeud
Noeud
Fig. 4.15 – Objet actif fournissant des itinéraires en une seule fois
Le nœud défaillant pourra faire l’objet d’une intervention de l’administrateur.
Pour ne pas avoir de références statiques vers l’objet actif en charge de fournir
la liste composant les éléments du réseau à administrer, nous avons utilisé le
service d’enregistrement de Jini [53].
Pré-requis : Pour utiliser Jini dans cette architecture, cela impose le passage
du trafic multicast entre les différents sous-réseaux6 de l’entreprise utilisant une
telle plate-forme.
En effet Jini offre un service d’enregistrement pour les objets qui fournissent
un service sur le réseau. Une explication plus approfondie de Jini et son adaptation
à notre environnement est présentée en annexe 9.1. Le service d’enregistrement
(Lookup Service) utilise les canaux multicast (adresse IP de classe D du type
224.0.0.0) afin de pouvoir être localisé sur le réseau. Le service de localisation de
Jini (mise en œuvre par le Lookup Service) utilise les mêmes canaux multicast
pour localiser le service d’enregistrement et obtenir la référence du service sur le
réseau.
En utilisant Jini, nous sommes en mesure de détacher tous les agents mobiles
des références statiques qui ont été mises en évidence dans la section 4.4.2. Ansi,
chaque agent mobile pourra contacter directement le service du réseau lui offrant
la liste des éléments qui sont potentiellement administrables.
4.4.3.2
Définitions d’itinéraires de visite séquentielle
En possession de ces listes d’éléments, plusieurs types d’itinéraires deviennent
alors possible pour un agent mobile. On peut les classer en deux grandes familles,
6
Dans la communauté de recherche RENATER, le trafic multicast est de plus en plus souvent
ouvert et donc Jini peut s’utiliser sur cette infrastructure.
Conception d’itinéraires pour l’administration
91
ceux qui sont ciblés et ceux qui sont typés.
Itinéraire ciblé : un itinéraire ciblé est un itinéraire dont les éléments de
Destination n’appartiennent qu’à un sous-réseau. La discrimination des éléments
de l’itinéraire se fait par rapport à l’adresse du sous-réseau cible.
Itinéraire typé : un itinéraire typé est un itinéraire regroupant un ensemble
d’éléments ayant des propriétés similaires, comme par exemple un ensemble d’hôtes
ayant le même type de système d’exploitation.
Par exemple, en itérant sur ces définitions d’itinéraires, on peut dire qu’un
itinéraire général, qui permet le parcours de tout le réseau, est l’union de l’ensemble des itinéraire ciblés appliqués à chaque sous-réseau de l’entreprise. Cet
itinéraire général comportera donc tous les éléments de type nœuds et la liste de
tous les équipements actifs du réseau.
4.4.3.3
Description du service d’itinéraire
Nous avons défini un objet actif appelé l’ItineraryServer. Le rôle de cet
objet actif est de mettre à la disposition des agents mobiles la liste des éléments
représentant les nœuds de la plate-forme et la liste des équipements actifs. Cette
liste d’éléments est obtenue à partir de l’algorithme de construction de la topologie
du réseau à administrer, présentée dans le chapitre 5. Chaque ItineraryServer
s’enregistre automatiquement en tant que service Jini afin de pouvoir être localisé
par les agents mobiles. Ainsi, un ItineraryServer joue en quelque sorte le rôle
de l’objet actif proposé dans la section 4.4.3 (figure 4.16).
Pour adapter notre modèle à l’administration système et réseau nous devons
tenir compte de l’existence de sous-réseaux dans le réseau d’une entreprise. Pour
s’adapter à l’existant, notre modèle sera répliqué dans chaque sous-réseau afin
de fournir localement les listes des éléments locaux représentant les nœuds et les
équipements actifs du réseau. Comme nous allons le voir, les serveurs d’itinéraires
de ces sous-réseaux seront utilisés successivement par un agent mobile si besoin.
4.4.3.4
Destination "service d’itinéraire"
Partant du fait que nous souhaitons administrer plusieurs sous-réseaux, nous
avons introduit une nouvelle Destination appelée ISDestination. Cette destination dans le modèle des Destinations (cf. figure 4.17) permettra le passage
d’un sous-réseau à un autre sous-réseau. Cette Destination contient la référence
sous forme d’URL d’un ItineraryServer et le nom de la méthode permettant
d’enrichir l’itinéraire courant. Ainsi, un tel itinéraire intégrant ce nouveau type
de Destination permettra à un agent mobile de passer d’un sous-réseau à un
92 Conception d’un mécanisme d’itinéraires dynamiques pour l’administration système et réseau
ItineraryServer
Noeud
Agent
Mobile
Noeud
Noeud
Agent SNMP
Migration
Client/Serveur SNMP
Noeud
Interrogation du
service d’itinéraire
Fig. 4.16 – Le service d’itinéraire
autre de manière complètement transparente et de progresser dans le suivi de son
itinéraire.
Destination
NodeDestination
SNMPDestination
ISDestination
Fig. 4.17 – Extension de notre hiérarchie des Destinations, incluant la notion
de service d’itinéraire
4.4.3.5
Destination de synchronisation
Il n’existe pas que des itinéraires de type séquentiel, mais nous pouvons proposer simplement, par extension de la notion des Destinations, des itinéraires
permettant aux agents mobiles de fonctionner en parallèle. L’intérêt est de pouvoir faire exécuter la même tâche à des agents mobiles sur des éléments du réseau
Conception d’itinéraires pour l’administration
93
(cf. section 3.3.3).
Itinéraire parallèle : Un itinéraire permettant à des agents mobiles d’exécuter
des tâches en parallèle est un itinéraire qui imposera à l’agent mobile principal
la création d’un ou plusieurs agents mobiles secondaires. Chaque sous itinéraire
est un itinéraire qui peut être séquentiel (cf. section 4.4.3.2), ou alors lui-même
un nouvel itinéraire parallèle. Ce type d’itinéraire nécessite une synchronisation
partielle ou complète des données collectées par les agents mobiles secondaires.
Pour réaliser ce type d’itinéraire fonctionnant en mode parallèle, nous avons
étendu notre définition des itinéraires pour y intégrer le concept de deux nouvelles
destinations (cf. figure 4.18) qui sont :
– une CloneDestination qui permet de créer des agents mobiles pour un
fonctionnement en parallèle
– une RendezVousDestination qui permet de synchroniser, si nécessaire, les
résultats de ces agents mobiles
Destination
NodeDestination
SNMPDestination
ISDestination
CloneDestination
RendezVousDestination
NodeDestination
Fig. 4.18 – Extension de la hiérarchie des destinations, pour les destinations de
type parallèle
La destination CloneDestination permet de bloquer le déroulement de l’itinéraire de l’agent mobile concerné et de lui permettre, soit de se cloner, soit de
créer des agents mobiles secondaires qui exécuteront une tâche déterminée. Cette
destination met à la disposition de l’agent mobile le nombre d’agents mobiles
secondaires qu’il doit créer.
Pour synchroniser le travail des agents mobiles nous utilisons la destination
RendezVousDestination. Cette destination est une destination qui englobe une
NodeDestination. La RendezVousDestination peut être considérée comme la
destination finale de l’itinéraire des agents mobiles secondaires puisqu’ils sont en
94 Conception d’un mécanisme d’itinéraires dynamiques pour l’administration système et réseau
mesure de retourner les informations du travail accompli. Le processus de synchronisation n’impose pas que tous les agents mobiles secondaires aient terminé
leur tâche pour que l’agent mobile principal puisse poursuivre la sienne. Toutefois, une synchronisation complète est possible sur le même schéma. Ce type de
synchronisation dépend effectivement de l’implémentation de l’agent mobile.
Master Agent
NodeDestination
Agent1
SNMPDestination
NodeDestination
NodeDestination
SNMPDestination
CloneDestination
Clonage
RendezVousDestination
Synchronisation
RendezVousDestination
Agent2
SNMPDestination
NodeDestination
Poursuite de l’itinéraire
RendezVousDestination
Fig. 4.19 – Exemple d’intégration de CloneDestinations et de RendezVousDestinations dans un itinéraire de type parallèle
Par exemple (cf. figure 4.19), basons-nous sur un agent mobile qui souhaiterait connaître la charge réseau de N systèmes. Dans son itinéraire de visite
séquentielle, il sera interrompu par une CloneDestination. A partir de cette
destination, il créera N agents mobiles secondaires ayant pour tâche la collecte de
la charge de chaque système que devait visiter l’agent mobile principal. L’agent
mobile principal sera en attente du résultat de tous les agents mobiles secondaires. Dans ce cas précis, l’agent mobile principal continuera sa tâche uniquement lorsque tous les agents mobiles secondaires seront venus se synchroniser avec
lui. Nous utilisons donc une synchronisation complète de tous les agents mobiles.
Pour illustrer un mode de synchronisation avec un seul agent mobile secondaire, prenons l’exemple de la recherche d’un espace disque suffisant pour sauvegarder des données sur N systèmes. La procédure est exactement la même que
dans l’exemple précédent, à la différence que l’agent mobile principal continuera
sa tâche dès qu’il aura obtenu une réponse positive de l’un de ses agents mobiles
secondaires, ou alors l’ensemble des réponses ne pourra satisfaire la demande de
Conception d’itinéraires pour l’administration
95
l’agent mobile père, ce qui sera un échec de la recherche.
Ainsi pour créer de nouveaux types d’itinéraires intégrant de nouvelles destinations, il suffit d’étendre la hiérarchie de la classe Destination pour mettre en
œuvre les nouveaux types nécessaires aux opérations d’administration système et
réseau.
4.4.4
Construction et gestion de l’itinéraire
Sur une architecture où nous regroupons des listes d’éléments différents (nœuds
et équipements actifs), il est concevable de déléguer à un gestionnaire la construction d’un itinéraire. Cela permet de s’affranchir de la création systématique de
l’itinéraire et d’offrir, en quelque sorte, des itinéraires "prêts à l’emploi" aux développeurs d’agents mobiles d’administration. Pour réaliser cela, nous avons créé
la classe abstraite ItineraryManager [73] qui définit les tâches minimales que
doit offrir le gestionnaire de l’itinéraire. Les méthodes fournies par cette classe
regroupent : la localisation du service Jini du ou des ItineraryServers ; la préparation de l’itinéraire ; l’exécution du suivi de l’itinéraire ; l’arrêt du suivi de
l’itinéraire ; l’ajout en cours d’itinéraire d’une Destination urgente ; permettre
à l’agent mobile de savoir à tout instant sur quelle Destination il effectue une
tâche.
En définissant ainsi notre gestionnaire d’itinéraire, nous pouvons construire
des sous-classes de l’ItineraryManager qui permettent de typer les itinéraires
selon la tâche d’administration à effectuer (cf. figure 4.20 et figure 4.21). Deux
grandes familles générales d’itinéraires existent. Celle dont les itinéraires seront
déroulés de manière totalement séquentielle que nous présentons dans la section
4.4.4.1.
Ce sont les itinéraires les plus simples à mettre en œuvre tant du point de
vue du concepteur que de l’utilisation par le programmeur. La deuxième famille
est celle des itinéraires dont les éléments font intervenir des états particuliers :
Duplication, Point de Rendez-Vous, Choix Sélectif parmi plusieurs Destination
possible, en sont des exemples. Cette famille d’itinéraires sera présentée dans la
section 4.4.4.2.
4.4.4.1
Itinéraire de visite séquentielle
Nous avons donc défini des itinéraires de visite séquentielle suivant :
– une administration complète du réseau local (ItineraryManagerLocalNetwork, ItineraryManagerLocalNodes),
– une administration distante, dans un sous-réseau ciblé (ItineraryManagerFilterNetwork),
– une administration incluant tous les sous-réseaux :
– tous les nœuds (ItineraryManagerAllNodes),
96 Conception d’un mécanisme d’itinéraires dynamiques pour l’administration système et réseau
ItineraryManager
ItineraryManagerLocalNodes
ItineraryManagerLocalNetwork
ItineraryManagerWholeNetwork
ItineraryManagerAllNodes
ItineraryManagerAllNetwork
ItineraryManagerSpecificHosts
ItineraryManagerFilterNetwork
Fig. 4.20 – Hiérarchie de classes issue de la classe ItineraryManager
– tous les éléments SNMP (ItineraryManagerAllNetwork),
– tous les nœuds et tous les éléments SNMP (ItineraryManagerWholeNetwork),
– une administration incluant tous les éléments de même type (ItineraryManagerSpecificHosts) :
– toutes les imprimantes,
– tous les routeurs,
– tous les commutateurs
– etc...
Chacune des classes d’itinéraires définies ci-dessus construisent un itinéraire
adapté à chaque situation. Pour diversifier les types d’itinéraires de la plate-forme,
il suffit de dériver une nouvelle classe, c’est-à-dire une nouvelle façon de visiter
certains éléments du réseau.
4.4.4.2
Itinéraire de visite parallèle
Les itinéraires qui entraînent des visites en parallèle sont des itinéraires où
une portion de l’itinéraire sera de type séquentiel. Cependant, la partie la plus
intéressante, reste la mise en œuvre du gestionnaire d’itinéraire. Par rapport à
la hiérarchie de la classe ItineraryManager une extension donne un nouveau
type de gestionnaire que nous avons mis en œuvre : l’ItineraryManagerClone
(cf. figure 4.21). L’ItineraryManagerClone est un gestionnaire qui va permettre
à l’agent mobile principal (voir les exemples section 4.4.3.5) de se cloner ou de
créer des agents mobiles secondaires pour effectuer une tâche d’administration
Conception d’itinéraires pour l’administration
97
système et réseau en parallèle sur plusieurs systèmes simultanément.
ItineraryManager
ItineraryManagerLocalNodes
ItineraryManagerLocalNetwork
ItineraryManagerWholeNetwork
ItineraryManagerAllNodes
ItineraryManagerAllNetwork
ItineraryManagerSpecificHosts
ItineraryManagerFilterNetwork
ItineraryManagerClone
Fig. 4.21 – Hiérarchie de la classe ItineraryManager étendue pour les itinéraires
parallèles
L’ItineraryManagerClone offre des fonctionnalités plus spécifiques que
l’ItineraryManager. Il créé à la volée, un ou plusieurs sous-itinéraires de l’itinéraire
que l’agent mobile doit suivre, afin de répartir dans chaque sous-itinéraire une
partie des Destinations. L’ItineraryManagerClone évite par cette procédure le
recouvrement de mêmes Destinations dans les sous-itinéraires. L’ItineraryManagerClone fixe la destination RendezVousDestination des sous-itinéraires
pour que le ou les agents mobiles d’administration puissent se synchroniser, si
nécessaire, avec l’agent mobile père, fournissant ainsi le résultat de leur travail.
Par extension de la classe ItineraryManager, on obtient un nouveau type
de gestionnaire d’itinéraire adapté à des parcours en parallèle des agents mobiles
d’administration système et réseau.
4.4.5
Utilisation d’itinéraires
Dans la bibliothèque ProActive la classe MigrationStrategyManager est
fournie et a pour rôle de réaliser le suivi d’un itinéraire composé uniquement
de NodeDestination (voir section 4.3.3). La classe MigrationStrategyManager
prend totalement en charge le suivi de l’itinéraire et les appels de méthodes qui
98 Conception d’un mécanisme d’itinéraires dynamiques pour l’administration système et réseau
sont associées à chaque Destination. La classe MigrationStrategyManager sert
avant toute migration, les requêtes qui pourraient être en attente dans la file d’attente des requêtes de l’agent mobile. Une instance de cette classe doit être affectée
à chaque objet actif mobile.
Pour prendre en compte de nouvelles formes de Destinations dans le modèle
de ProActive, nous avons étendu cette classe pour que les actions à entreprendre
en fonction du type de Destinations soient gérées (cf. figure 4.22). Étant données nos extensions sur les Destinations (cf. figure 4.18), il s’agit d’adapter le
comportement de l’agent mobile à ces nouvelles Destinations. Ainsi, la migration n’est effective que pour les Destinations NodeDestination (pour la partie
administration), ISDestination (pour la partie enrichissement de l’itinéraire),
CloneDestination et RendezVousDestination pour la partie liée à la duplication des agents mobiles. Quant à la SNMPDestination, aucune migration n’est
requise (modèle Client/Serveur en SNMP).
Quel que soit le véritable type des Destinations, cela engendre toutefois l’appel d’une méthode pour lancer l’exécution de la tâche associée. Par exemple, une
Destination de type SNMPDestination engendrera l’appel de la méthode associée
(que l’on nomme typiquement SnmpOnArrival ) pour une opération d’administration en Client/Serveur.
La destination ISDestination obligera l’agent mobile à contacter le prochain
ItineraryServer situé dans la liste des ItineraryServers obtenue au préalable
auprès d’un Lookup Service, pour compléter son itinéraire d’administration.
Tant Que Itineraire non Fini Faire
Tant qu’il y a des appels de methode en attente dans la file d’attente faire
Servir les requêtes
Fin Tant Que
Considérer la prochaine Destination
Devons-nous miger ?
non : Appel de la méthode associée à la destination (SNMPDestination)
oui : Si NodeDestination alors l’agent mobile migre et
on exécute l’appel de la méthode à l’arrivée
Si ISDestination alors on contacte l’ItineraryServer associé pour
enrichir l’itinéraire de migration courant
Si CloneDestination alors
appel de la méthode permettant de dupliquer l’agent mobile et
de préparer le point de rendez-vous qui suivra
etc .... (par exemple point de rendez-vous)
Fin Tant Que
Fig. 4.22 – Algorithme du MigrationStrategyManager
4.5
Bilan
Pour résumer ce chapitre, nous avons étendu le système de migration de
ProActive pour prendre en compte de nouvelles Destinations afin d’intégrer
Bilan
99
l’administration réseau. Pour ce faire, nous avons : défini des destinations pour
prendre en compte le modèle Client/Serveur en SNMP ; conçu une solution qui
fournit les listes d’éléments constituant les itinéraires d’administration système et
réseau par le biais d’ItineraryServers ; défini des types généraux d’itinéraires
(les nœuds du réseau local, les équipements actifs du réseau local, etc..) en sous
classant la classe de l’ItineraryManager.
Les Destinations que nous avons ajoutées au modèle de ProActive permettent d’obtenir des itinéraires d’administration système et réseau qui prennent en
compte les équipements actifs du réseau, et le fait qu’un réseau d’entreprise puisse
contenir plusieurs sous-réseaux, chacun de ceux-ci étant géré par un ItineraryServer. L’intégration de ces nouvelles destinations et leurs comportements sont
récapitulés dans la table 4.6.
Destination
NodeDestination
SNMPDestination
ISDestination
CloneDestination
RendezVousDestination
Action
Migration et exécution de l’appel d’une méthode
Appel de méthode
pour un accès en Client/Serveur SNMP
Appel de méthode permettant
de contacter un ItineraryServer
Appel de méthode permettant
de créer des agents mobiles secondaires
Appel de méthode permettant de synchroniser,
les agents mobiles secondaires avec l’agent mobile père
Tab. 4.6 – Actions menées selon les types de Destination, version étendue
Le schéma général pour la construction d’un itinéraire selon le modèle que
nous proposons (cf. figure 4.23) est le suivant :
A) Préparation de l’itinéraire (ItineraryManager) :
1. récupérer la référence de l’ItineraryServer (qui est présent en tant
que service Jini)
2. récupérer la liste des éléments contenus dans l’ItineraryServer
3. transmettre pas à pas les éléments de l’itinéraire au MigrationStrategyManager
B) Faire suivre à l’agent mobile son itinéraire de manière automatique
(via le MigrationStrategyManager)
– si une ISDestination est rencontrée alors le processus reprend :
1. préparer la suite de l’itinéraire (ItineraryManager A) )
2. repartir en B)
100 Conception d’un mécanisme d’itinéraires dynamiques pour l’administration système et réseau
B: Suit et exécute les
tâches de son itinéraire
Agent
Mobile
A−1 : Récupère une
référence de
l’ItineraryServer
ItineraryManager
Jini
A: Construit l’itinéraire
désire
A−2: Récupère la liste
des éléments
A−3: Transmet
l’itinéraire au
gestionnaire de
migration
ItineraryServer
MigrationStrategyManager
Relation entre les objets et/ou les services
Fig. 4.23 – Fonctionnement de la création et du suivi d’un itinéraire
Chapitre 5
Conception et implantation
d’une plate-forme
d’administration système et
réseau
5.1
Architecture générale : principe de conception
Dans l’objectif de concevoir une plate-forme à agents mobiles, nous avons
cherché à distinguer les différents modules (ou services) qui composent cette plateforme. Tout d’abord, il faut pouvoir connaître les éléments constituant le réseau
pour fournir des informations utiles à un administrateur pour qu’il puisse effectuer
son travail. Pour connaître ce réseau, il faut collecter et analyser les informations
disponibles sur les éléments qui y sont connectés, et ce en découvrant les éléments
du réseau. Ces éléments sont de type PCs, serveurs, routeurs, commutateurs, concentrateurs intelligents, imprimante en réseau, etc.., tout ce qui est en activité
sur le réseau.
Cette plate-forme doit pouvoir mettre à disposition les informations collectées
parce qu’elles décrivent le réseau, les éléments qui y sont connectés et qu’elles permettent de dialoguer avec les équipements actifs du réseau. De plus, ces informations permettront aux agents mobiles de se mouvoir sur le réseau à administrer.
La visualisation des données collectées du réseau sera présentée à l’administrateur par le biais d’une interface bâtie au dessus d’un module de supervision
du cycle de vie des objets qui mettent en œuvre la plate-forme.
Le service de supervision offert par la plate-forme permettra aussi de piloter
les agents mobiles d’administration, c’est-à-dire de les créer, de les interroger, de
les déplacer, et de les arrêter, en somme d’intéragir avec eux.
101
102 Conception et implantation d’une plate-forme d’administration système et réseau
5.2
Les services de la plate-forme
Nous allons présenter les services que nous avons pu déterminer comme étant
indispensables dans une plate-forme à agents mobiles destinée à effectuer des
tâches d’administration système et réseau. Cette présentation est décomposée en
trois parties distinctes : le service de collecte, le service de mise à disposition
de l’information et pour finir les services utilisés pour superviser le réseau et les
agents mobiles d’administration.
5.2.1
Service de collecte et d’analyse
5.2.1.1
Service de description du réseau
Comme toute plate-forme d’administration système et réseau, il est nécessaire
d’avoir, avant le démarrage du processus de collecte, des informations propres au
réseau, c’est-à-dire un service de description du réseau, structuré par sous-réseaux.
La description doit conserver cette structuration en sous-réseaux, parce que nous
travaillons dans un contexte d’agents mobiles avec des itinéraires devant refléter
la structure du réseau en sous-réseaux. Ces informations de description sont des
informations naturellement connues statiquement donc il n’y a pas de contrainte
pour offrir ce service de description. Il faut juste décrire ces informations une fois
pour toute et les enregistrer dans un endroit ad hoc.
5.2.1.2
Service de collecte
En constatant que sur un réseau donné il y a une forte évolution des éléments
connectés (ajout, suppression de matériels, par exemple), les informations utiles
ne peuvent pas être données uniquement de manière statique, comme explicité
ci-dessus, mais une partie de ces informations doit être obtenue dynamiquement.
Par exemple, il est courant de nos jours de configurer le fonctionnement des
éléments du réseau en utilisant le protocole DHCP (Dunamic Host Configuration
Protocol [25]). Dans ce cas là, il est impossible de définir statiquement les éléments
composant le réseau parce qu’une partie d’entre eux peut changer d’adresse IP.
Ainsi les services offerts par ces éléments ne seront plus accessibles de la même
manière. Il faudra donc les retrouver pour permettre l’accès aux services qu’ils
offrent sur le réseau.
Remarque : Les services de description et de collecte sont des services complémentaires, car le service de collecte ne fonctionne que si le service de description
du réseau définit l’environnement du réseau. Il est possible de décrire avec plus ou
moins de précision le réseau à analyser : plus ce sera précis plus le temps d’exécution du service de collecte sera faible ; inversement, une description succincte
du réseau entraînera un temps d’exécution de la collecte plus long.
Architecture générale : mise en œuvre
5.2.2
103
Service de mise à disposition des informations collectées et analysées
Par rapport aux services décrits précédemment, le service de mise à disposition de l’information collectée fournira la liste des éléments découverts pendant
la phase de collecte. Ce même service fournira la topologie du réseau découvert,
structurée par sous-réseaux à administrer, représentant l’interconnexion des éléments découverts.
5.2.3
Service de supervision de la plate-forme
Il s’agit du service qui permet la visualisation, l’utilisation et la supervision
des objets composant la plate-forme.
Nous trouvons le service de pilotage, pour l’ensemble du réseau, des objets
de la plate-forme, objets mettant en œuvre les deux grandes familles de services
que nous venons de décrire ci-dessus. Ce service de supervision pourra collecter
les informations décrivant le réseau, d’une part à des fins de sauvegarde sur la
station d’administration, et d’autre part pour avoir une vue en temps réel des
éléments découverts automatiquement et de leur interconnexion.
La supervision des agents mobiles sera effectuée par un service de pilotage
permettant de localiser automatiquement les agents mobiles pendant leur tâche
d’administration par le biais d’un outil tel IC2D [7] (livré en standard avec ProActive) et d’un logiciel ad hoc à la plate-forme permettant entre autre, d’interroger
à distance des agents mobiles d’adminstration.
5.3
5.3.1
Architecture générale : mise en œuvre
Introduction
L’architecture de notre plate-forme se compose de trois grandes familles de
services : les services de description du réseau et les services de scrutation et de
collecte de l’information du réseau ; les services mettant à disposition l’information collectée, par exemple la liste des éléments détectés, mais aussi la topologie
du réseau construite ; la dernière famille de service comprend quant à elle tous les
services de supervision qui permettent d’avoir l’état général du réseau et aussi des
outils permettant d’exploiter cette plate-forme à agents mobiles dans un cadre
d’administration système et réseau.
Pré-requis : Afin d’utiliser de manière complètement transparente cette plateforme à agents mobiles, un service d’enregistrement Jini [53] doit être installé et
accessible, afin que les services puissent être mis à la disposition du domaine
104 Conception et implantation d’une plate-forme d’administration système et réseau
d’administration. Plus techniquement, cela impose le passage du trafic multicast
entre les différents sous-réseaux de l’entreprise utilisant une telle plate-forme.
5.3.2
Connaissance du réseau
Nous allons décrire les services qui permettent d’obtenir la connaissance des
éléments connectés sur le réseau et la topologie du réseau obtenue par corrélation
des informations collectées.
5.3.2.1
Service de description d’un sous-réseau
Cette information doit exister avant le déploiement de la plate-forme, au même
titre que statiquement dans des fichiers ou dans une base de données, comme
dans MobileSpaces [78], Hp Openview [35] ou Nagios [57]. Les trois informations
minimales afin de pouvoir collecter de l’information sur un sous-réseau sont :
l’adresse du routeur par défaut (appelé aussi default gateway), le masque du
réseau (par exemple 255.255.255.0 pour une classe C d’adresse IP 192.168.10.0)
et le nom de la communauté SNMP en lecture (par défaut public) pour accéder
aux informations de la MIB des agents SNMP. Au contraire des autres platesformes, nous voulons rendre disponible cette information en s’abstrayant d’une
localisation fixe, statique. C’est pour cela que cette information est encapsulée
dans un objet Java dont on enregistre une copie dans un ou plusieurs Lookup
Services de Jini. Il suffira de récupérer une copie à la demande, par le biais d’une
opération de recherche auprès d’un des Lookup Service (pour de plus amples
explications de notre utilisation de Jini, voir l’annexe en section 9.1).
Plus concrètement, chaque sous-réseau est décrit par le biais des informations
présentées par la table 5.1 :
De cette table, remarquons que nous avons prévu de prendre en compte certains éléments, en plus des informations générales décrivant le sous-réseau, afin
de pouvoir spécifier certaines valeurs particulières :
– SNMPDestination : définir un élément permanent ayant un agent SNMP
dont les noms de communautés SNMP n’ont pas les même valeurs que les
valeurs par défaut, ou un élément composant le cœur du sous-réseau (par
exemple un commutateur, serveur DNS, etc...)
– NodeDestination : définir un nœud de la plate-forme ProActive actif en
permanence. Ce nœud peut être hébergé, par exemple, sur un serveur ayant
des capacités de traitement suffisantes pour l’administration réseau
Ces informations peuvent être saisies par le biais de l’onglet graphique présenté par la figure 5.2, à partir desquelles un objet décrivant un sous-réseau est
instancié en vue d’être enregistré. Les informations saisies dans cet onglet sont
les mêmes que celles présentées par la table 5.1. Une interface de saisie générique a été définie pour saisir les Destinations permanentes du sous-réseau. Par
Architecture générale : mise en œuvre
Nom du TAG
NetworkName
NetworkAddress
NetworkMaskAddress
NetworkBroadcastAddress
NetworkRouter
SnmpReadDefaultCommunity
SnmpReadWriteCommunity
Destination
105
Description
Nom logique
pour le sous-réseau
Adresse IP
du sous-réseau
Masque
de sous-réseau
Adresse IP
de broadcast du sous-réseau
L’adresse IP
du routeur par défaut
Commutauté SNMP
par défaut en lecture
Communauté SNMP
par défaut en lecture/ecriture
une Destination selon le
modèle de nos destinations
Exemple de Valeur
reseau-168-80-jini
192.168.80.0
255.255.255.0
192.168.80.255
192.168.80.253
public
private
Tab. 5.1 – Explication des Tags du service de description d’un sous-réseau
exemple la figure 5.3 permet de visualiser tous les constructeurs possibles permettant de créer une SNMPDestination. On montre aussi la Javadoc associée afin
que l’utilisateur prenne connaissance de la sémantique (informelle) des différents
paramètres des constructeurs. Une fois le constructeur sélectionné, la figure 5.4
montre l’onglet de saisie associé.
NetworkDescription
getSubNetworkDescription(Adresse IP)
SubNetworkDescription
getSubNetworkDescription()
SubNetworkDescription
getSubNetworkDescription()
SubNetworkDescription
getSubNetworkDescription()
Fig. 5.1 – Hiérarchie des descriptifs des sous-réseaux
La méthode de l’objet, appelé SubNetworkDescription, représentant ce service est : getSubNetworkDescription() pour obtenir le descriptif de tout le
sous-réseau. Un autre objet appelé NetworkDescription qui regroupe les objets de type SubNetworkDescription, et offre une méthode getSubNetworkDescription(Adresse IP) pour obtenir le descriptif d’un sous-réseau particulier
(cf. figure 5.1).
106 Conception et implantation d’une plate-forme d’administration système et réseau
NodeDestination
SnmpDestination
Liste des Destinations permanentes
Fig. 5.2 – Interface pour la saisie du descriptif d’un sous-réseau
5.3.2.2
Service de découverte d’un sous-réseau
Un tel service requiert une activité propre afin d’effectuer la découverte d’un
sous-réseau, à intervalles de temps réguliers. Un tel besoin justifie l’utilisation de
la notion d’object actif, interrogeable afin de récupérer les éléments découverts
[72]. L’activité d’un tel objet consiste en l’exploration du sous-réseau (voir la
section 5.4 pour l’algorithme mis en œuvre). Le résultat de cette activité est
composé de deux structures de données :
– la liste des éléments du sous-réseau (a fortiori la liste des éléments SNMP
et la liste des nœuds de la plate-forme ProActive)
– la topologie détectée, présentée sous forme arborescente
Architecture générale : mise en œuvre
107
Fig. 5.3 – Interface pour la sélection du constructeur de la Destination
Fig. 5.4 – Interface pour la saisie d’une Destination
On alimente dès que possible le service de mise à disposition parce que l’on
veut avoir les données toujours disponibles.
Les méthodes publiques de cet objet sont :
startTopologyDiscovery(SubNetworkDescription) pour lancer le processus
de collecte et d’analyse du sous-réseau et stopTopologyDiscovery() pour arrêter
si nécessaire ce processus. Les services offerts par cet objet aux autres objets
de la plate-forme sont : getSNMPElements() pour obtenir la liste des éléments
SNMP du sous-réseau, getProActiveNodes() pour obtenir la liste des nœuds de
la plate-forme ProActive en activité et getTopologyMap() pour obtenir l’arbre
représentant la topologie du sous-réseau.
5.3.3
Service de mise à disposition des informations découvertes
Un administrateur sait que le processus de découverte des éléments d’un sousréseau n’est pas une action qui s’exécute instantanément. Ainsi, la lenteur relative
du processus de découverte (quelques dizaines de secondes pour quelques dizaines
108 Conception et implantation d’une plate-forme d’administration système et réseau
d’éléments) justifie la présence d’un cache des informations découvertes. Lors de
l’invocation du service de mise à disposition, on renvoie les informations présentes
dans le cache. Les méthodes associées sont : getSNMPElements() pour la liste
des éléments SNMP, getProActiveNodes() pour la liste des nœuds ProActive
et getTopologyMap() pour récupérer la topologie construite. Quant au cache,
il est mis à jour automatiquement grâce à ces méthodes : setTopologyMap(),
setSNMPElements() et setProActiveNodes() par le service de découverte du
réseau.
Pour des raisons à la fois d’exactitude et de rapidité de mise à disposition, le
cache est mis à jour au fur et à mesure qu’un nouvel élément est découvert, et
sera complètement actualisé en fin du processus de découverte, lorsque cette fin
est signalée.
Pour que le service soit accessible, notamment pour construire des itinéraires,
mais aussi pour visualiser les informations mises à disposition pour un sous-réseau
donné, le service va s’enregistrer automatiquement auprès d’un Lookup Service.
5.3.4
Service de supervision
Il s’agit de piloter la création des services de mise à disposition, services qui
eux même font le nécessaire pour déclencher le service de découverte. Un service
de mise à disposition est créé en fonction de chaque description de sous-réseau.
Si sur un sous-réseau donné existe un nœud permanent, le service peut être créé
directement sur le sous-réseau, plutôt que sur le nœud courant. Le fait que le
service de mise à disposition s’exécute sur un nœud permanent présente l’avantage
que ce service sera toujours disponible.
Le service de supervision utilise le service de mise à disposition de chacun des
sous-réseaux décrits (via le service de description du réseau) afin de collecter une
vue globale du réseau à administrer, à l’aide des différentes vues partielles pour
chacun des sous-réseaux. Les méthodes définies par ce service sont :
createItineraryService(SubNetworkDescription) pour créer le service de
mise à disposition, getGlobalTopology() pour récupérer le schéma de la topologie globale du réseau, getGlobalSNMPElements(),
getGlobalProActiveNodes() pour récupérer les listes des éléments du réseau
(SNMP et nœuds de ProActive).
Une fois les objets de la plate-forme déployés, leur pilotage peut être effectué
via l’outil générique de supervision de la plate-forme ProActive, IC2D [7] (cf.
figure 5.5). Par exemple, il est possible utiliser IC2D pour changer l’emplacement
d’objets actifs implantant les différents services afin de rééquilibrer la charge
CPU (cf. projet D-Raje [32] pour obtenir de manière portable la charge CPU)
consommée sur un seul serveur (cf. figure 5.6). Grâce au mécanisme de forwarding
de ProActive (suivi des messages vers la nouvelle localisation de l’objet actif),
ces objets restent joignables. Si de plus ils sont enregistrés dans Jini, lors de
l’expiration du bail, ils se réenregistreront en indiquant à ce moment là leur
Architecture générale : mise en œuvre
109
localisation courante.
Fig. 5.5 – Les services de la plate-forme vus par IC2D
Fig. 5.6 – Répartition des services de la plate-forme sur deux nœuds différents
5.3.5
Récapitulatif
Les différents services de notre plate-forme sont mis en œuvre par des objets
Java distincts, qui sont présentés par la figure 5.7.
Le service de supervision est le service permettant de présenter et de surveiller tous les services de la plate-forme : service de description du réseau, service
de découverte d’un sous-réseau et le service de mise à disposition des informations
découvertes. Il est implanté par l’objet actif DiscoveryManager.
Le service de description de réseau est un service qui s’enregistre dans
un Lookup Service Jini, implanté par un objet (non actif) appelé le NetworkDescription, comme présenté dans la section 5.3.2.1.
Le service de découverte d’un sous-réseau est un service qui est implanté
par deux objets actifs de ProActive : le DiscoveryAgent qui est l’agent de découverte des éléments du réseau et de la topologie ; le NetNodesFinder qui est un
agent de localisation des nœuds ProActive qui sont en cours d’exécution. La mise
en œuvre de ces deux agents distincts est faite afin d’obtenir un délai d’exécution
de chacun de ces services plus rapide.
110 Conception et implantation d’une plate-forme d’administration système et réseau
Service de supervision
de la plate−forme
DiscoveryManager
Service de Mise a disposition des
informations decouvertes
ItineraryServer
Service de Description
du reseau
Service de decouverte d’un
sous−reseau
Service I utilise le service J
DiscoveryAgent
Service localisable par JINI
NetNodesFinder
Service Offert
Objet Actif implementant le service
Fig. 5.7 – Le récapitulatif des services de notre plate-forme à agents mobiles pour
l’administration système et réseau
Le service de mise à disposition des informations découvertes est le
service qui sert de cache de données au service de découverte d’une part, et d’autre
part qui permet d’être interrogé par les agents mobiles d’administration lors de la
construction d’un itinéraire d’administration et par le ou les DiscoveryManagers.
Ce service est un service qui s’enregistre dans un Lookup Service Jini afin d’être
accessible indépendamment de sa localisation.
5.3.6
Interface graphique
Il est bien évident que les administrateurs requièrent d’avoir une interface
graphique (GUI) de supervision pour la plate-forme d’administration système
et réseau. On va évidemment faire appel aux fonctionnalités du service de supervision de la plate-forme qui sait faire remonter l’ensemble des informations
pertinentes pour l’aspect graphique. A chaque GUI est donc associé une instance
du service de supervision de la plate-forme, c’est-à-dire ce que nous avons appelé
un DiscoveryManager.
Architecture générale : mise en œuvre
5.3.6.1
111
Les informations du réseau
Ainsi nous proposons une vue graphique et globale du réseau à administrer
grâce aux informations que nous avons collectées sur le réseau (cf. figure 5.8).
La figure 5.9 présente l’onglet de visualisation des informations qui ont été
collectées sur un élément du réseau. On y retrouve le nom logique de l’élément
(nom DNS), son adresse IP et l’adresse Ethernet qui a été découverte.
5.3.6.2
Pilotage et interrogation d’agents mobiles
De plus, cette GUI va contribuer au service de pilotage des agents mobiles d’administration, en plus d’IC2D qui permet de visualiser, voire de migrer
manuellement des agents (cf. figure 5.10).
On va pouvoir graphiquement préparer et déclencher la création d’agents mobiles accompagnés d’un itinéraire, puis déclencher des invocations de services sur
un agent mobile en activité. Notre outil ad hoc nous permettant de démarrer des
agents mobiles pour leur faire suivre un itinéraire pré-défini est présenté par la
figure 5.11, par la sélection de la classe de l’agent mobile et du type d’itinéraire que
l’on souhaite lui faire suivre. La figure 5.12 présente l’interrogation de cet agent
mobile à distance. Dans l’exemple présenté, l’agent mobile donne des informations
sur l’état du système sur lequel il s’est positionné en attendant un nouvel ordre
de migration.
5.3.6.3
Supervision des ressources d’un élément
Nous avons doté notre bibliothèque d’outils permettant la supervision des
éléments du réseau, et ce directement à partir de l’interface graphique ou bien à
partir de notre outil ad hoc destiné à contrôler le fonctionnement des agents mobiles d’administration (cf. figure 5.11). La figure 5.13 présente le résultat obtenu
par un agent mobile effectuant la supervision d’un élément du réseau. Il s’agit
d’obtenir, quel que soit le système Linux ou Windows, la charge CPU et l’espace
de mémoire libre sur le système.
Pour avoir la charge réseau, nous utilisons un onglet de la GUI d’administration (cf. figure 5.14) qui permet de collecter les informations de trafic sur l’élément
cible. On obtient une collecte des informations de l’élément toutes les 5 secondes
afin d’avoir un aperçu rapide de la charge de l’élément.
5.3.6.4
Plate-forme multi-administrateurs
Comme une GUI fait appel à sa propre instance du service de supervision
de la plate-forme (l’instance du DiscoveryManager qui lui est associée), il est
tout à fait envisageable d’avoir plusieurs GUI actives en même temps. L’intérêt
évident est de permettre d’avoir soit plusieurs administrateurs du même réseau
112 Conception et implantation d’une plate-forme d’administration système et réseau
Les descriptifs de reseaux locaux
Dessin de la topologie
Liste des elements SNMP des reseaux locaux
ou liste des noeuds de la plate−forme repertories
Fig. 5.8 – Interface de visualisation de la topologie
Architecture générale : mise en œuvre
113
Fig. 5.9 – Onglet de visualisation des informations d’un élément
Fig. 5.10 – Les services de la plate-forme et des agents mobiles d’administration
vus par IC2D
en activité simultanément, soit un administrateur mobile qui a démarré autant
de services de supervision que d’emplacements physiques différents où il passe.
114 Conception et implantation d’une plate-forme d’administration système et réseau
Fig. 5.11 – Lancement d’un agent mobile d’administration
5.4
5.4.1
Principes et implantation de l’algorithme de
découverte de la topologie
Introduction
Dans un réseau donné, c’est-à-dire défini par une adresse de réseau unique,
nous allons construire la topologie de niveau 2 du réseau. Nous allons déterminer
l’interconnexion des éléments dans le réseau et nous n’allons pas déterminer la
topologie physique car l’obtention d’une telle topologie est impossible techniquement (il s’agit du câblage à proprement parler). Notre topologie de réseau sera
décrite comme un arbre n-aire, dont la racine est l’élément actif avec une adresse
IP (possédant un agent SNMP) tête du réseau, c’est-à-dire l’élément qui a la
charge la plus élevée, car effectivement tous les liens physiques qui mènent vers
les différentes branches du réseau sont connectés à lui. Nous utiliserons donc le
service de description du réseau (NetworkDescription) pour obtenir l’adresse IP
du réseau pour lequel on désire construire la topologie.
Principes et implantation de l’algorithme de découverte de la topologie
115
Fig. 5.12 – Interrogation à distance de l’agent mobile via la GUI
Fig. 5.13 – AgentMonitoringFrame : Supervision des ressources système d’un
élément
5.4.2
Phase de détection des éléments
Étant donné un SubNetworkDescription (cf. section 5.3.2.1), nous allons
détecter tous les éléments qui ont la même adresse de réseau (label Network
Address) et qui génèrent du trafic. Nous allons lire la table ARP du routeur par
défaut du réseau (indiqué par le label Network Router dans la table 5.1). A partir des informations collectées, on va construire une table ARP globale de façon
incrémentale. La détection d’un nouvel élément, c’est l’occurrence d’un élément
dans une entrée d’une table dont l’adresse IP était inconnue jusqu’alors. Récur-
116 Conception et implantation d’une plate-forme d’administration système et réseau
Fig. 5.14 – Onglet de visualisation de la charge réseau d’un équipement actif
sivement, la table ARP de chaque nouvel élément sera fusionnée à la table ARP
globale en cours de construction. Cela suppose qu’on y a accès, ce qui est le cas
s’il y a un agent SNMP sur l’élément en cours. De manière naturelle, l’algorithme
se termine lorsque tous les éléments ainsi découverts ont déjà été explorés. Pour
forcer les éléments, même générant peu de trafic1 , à en engendrer, on peut au
préalable générer un paquet de type ICMP, sur l’adresse de broadcast du réseau
(par la commande ping, cf. section 2.1). Chaque élément va alors répondre à
l’émetteur.
Informations collectées : Pour chaque élément (avec un agent SNMP) répertorié ou détecté, on collecte les informations suivantes :
– les services fournis : agent SNMP, nœud de ProActive
– le type de service réseau fourni (System)
– la table de routage (ip.ipRouteTable)
– les services IP fournis (tcp.TcpConnTable et udp.UdpTable)
– En fonction du type de service réseau fourni (system.sysServices) :
– la matrice de commutation
(dot1dBridge.dot1dTp.dot1dTpFdbTable) (dans le cas d’un commutateur)
– les informations du Spanning Tree Protocol
(dot1dBridge.dot1dStp.dot1dStpPortTable) (dans le cas d’un commutateur)
– les informations de gestion du répéteur
(snmpDot3RptrMgt.rptrAddrTrackPortInfo) (dans le cas d’un concentrateur Intelligent)
1
Le minimum de trafic généré par un élément en réseau correspond à l’échange d’un paquet
de vérification de l’unicité de l’adresse IP qui lui est allouée par l’administrateur (protocole
ARP)
Principes et implantation de l’algorithme de découverte de la topologie
117
Remarque 1 : la collecte des informations sur la présence d’un nœud ProActive
peut se faire de manière indépendante, et donc en parallèle de l’algorithme itératif
de détection, ce qui économise environ 1/3 du temps de détection total.
Remarque 2 : la récupération de l’information de présence d’un agent SNMP
peut être très performante si on diffuse un paquet SNMP v1 2 (le protocole
SNMP V1 est encore utilisé pour la collecte des données [22]) , auquel répondront
les agents SNMP qui seront ainsi mis, au plus tôt, dans la liste des éléments
découverts.
5.4.3
Phase de connexion des éléments
Ce n’est pas tout de produire la liste des éléments découverts sur le réseau, on
veut aussi détecter de quelle manière ils sont reliés entre eux, pour connaître comment passe le trafic réseau entre eux. Les principes, et quelques détails techniques
lorsque nécessaire, sont donnés dans cette section.
Étant donnée une adresse Ethernet, c’est-à-dire correspondant à un élément
ayant aussi une adresse IP, on cherche : si cette adresse apparaît dans une entrée
d’une table ARP d’un autre élément détecté, on en déduit le numéro de l’interface
par laquelle l’adresse Ethernet a été apprise (l’interface d’entrée) ; s’il s’agit de
rechercher cette adresse dans les informations collectées dans l’agent SNMP d’un
commutateur, alors on utilisera aussi la matrice de commutation pour obtenir
le numéro de l’interface correspondante. Voici ci-dessous une explication plus
détaillée de l’usage que nous faisons de la matrice de commutation.
La matrice de commutation La matrice de commutation d’un commutateur (forwarding database) permet à un tel équipement actif de rediriger le trafic
entrant vers la bonne interface de sortie. Cette matrice de commutation donne
les associations entre les adresses Ethernet des éléments du réseau local et les
interfaces du commutateur. Par exemple le numéro d’interface 38 sur l’exemple
présenté par la table 5.2, correspond à l’adresse Ethernet 00 :04 :76 :97 :86 :46.
C’est-à-dire que si un paquet est pour cette adresse Ethernet, il doit être retransmis par le numéro d’interface 38 de notre exemple.
Après de telles déductions, en considérant tous les éléments découverts, on
obtient une liste exhaustive qui correspond en fait à l’énumération de tous les
chemins de longueur supérieure ou égale à 1 par lesquels du trafic a transité. Par
exemple, supposons le petit réseau sur la figure 5.15 par le biais duquel le PC
imprime.
2
avec l’adresse de diffusion du réseau (label NetworkBroadcastAddress), le nom de la communauté SNMP définit par défaut (label SnmpReadDefaultCommunity) et l’oid correspondant
à la variable system.sysDescr
118 Conception et implantation d’une plate-forme d’administration système et réseau
Forwarding Database
d’un commutateur
Index de hashage
0.4.118.151.134.70
0.4.118.163.61.144
1.128.194.0.0.0
1.128.194.0.0.1
dot1dTpFdbAddress
Adresse Ethernet
00 :04 :76 :97 :86 :46
00 :10 :7B :3A :20 :B5
01 :80 :C2 :00 :00 :00
01 :80 :C2 :00 :00 :01
dot1dTpFdbPort
Le port de sortie
38
22
0
0
Tab. 5.2 – Extrait de la MIB BRIDGE dot1dTpFdb
Imprimante
+ Agent SNMP
Materiel Actif
+ Agent SNMP
Materiel Actif
+ Agent SNMP
B
A
PC + Agent SNMP
Fig. 5.15 – Schéma d’un réseau quelconque
L’étape des déductions fournit la liste de la table 5.3. On voit cependant sur
cet exemple qu’il n’existe pas de lien direct entre le PC et l’imprimante (pourtant
la liste obtenue laisse possible une telle éventualité).
Source → Destination
B → PC
B→A
B→Imprimante
PC → B
PC→A
PC→Imprimante
A→B
A→PC
A→Imprimante
Imprimante→A
Imprimante→B
Imprimante→PC
Tab. 5.3 – Liste résultante de l’énumération des chemins
5.4.3.1
Détermination de la topologie
Il s’agit donc d’arriver à éliminer des éléments de cette liste de sorte à ne
conserver que ceux qui correspondent à des connexions directes.
Repérer les liens qui ne peuvent exister par nature : les principes cidessous sont utilisés :
Principes et implantation de l’algorithme de découverte de la topologie
119
– étant donné 2 éléments autre que des commutateurs, routeurs ou concentrateurs, qui semblent être directement connectés : si on ne détecte aucun
élément de type commutateur, routeur ou concentrateur entre eux, alors on
peut en conclure qu’ils ne sont pas directement connectés.
– étant donné 2 éléments ne possédant chacun qu’une seule interface réseau
(à l’exception d’un routeur), alors il n’est pas possible qu’il existe une
connexion physique directe entre eux.
B→PC
B→A
B→Imprimante
PC→B
PC→A
A→B
A→PC
A→Imprimante
Imprimante→A
Imprimante→B
Tab. 5.4 – Liste résultante de l’énumération des chemins sans connexion impossible
Reprenons l’exemple précédant : étant donnée la liste de la table 5.3, on
obtient ainsi la liste expurgée des connexions directes impossibles présentée par
la table 5.4.
Repérer les liens de connexions indirectes : On essaye de repérer, par
transitivité, des chemins de longueur supérieure à 1 parmi les éléments restant
dans la liste. Pour cela, l’idée est de détecter la présence d’au moins un élément
de type commutateur (ou concentrateur intelligent). Le principe est le suivant :
– étant donné une paire Source-Destination (plus précisément Destination +
numéro de l’interface d’entrée) : intuitivement, un élément intermédiaire
est supposé exister car il existe en plus du chemin Source-Destination, il
existe au moins un autre chemin qui aboutit à la destination sur la même
interface (par exemple PC→B, PC→A et B→A).
Étant donné la liste de la table 5.4, on obtient ainsi la liste expurgée des
connexions indirectes, présentée par la table 5.5.
B→PC
B→A
PC→B
A→B
Imprimante→A
A→Imprimante
Tab. 5.5 – Liste résultante de l’énumération des chemins sans connexion impossible et indirecte
5.4.3.2
Orientation de la topologie
La topologie (sommets, liens bidirectionnels reliant ces sommets) est donc
obtenue. On peut se la représenter comme un graphe. Néanmoins, une telle to-
120 Conception et implantation d’une plate-forme d’administration système et réseau
pologie n’a un sens pour un administrateur que si elle est orientée selon le trafic
(montré comme étant un arbre), c’est-à-dire que les nœuds du graphe obtenu sont
des équipements actifs. Soit en fonction du trafic à destination de l’extérieur du
réseau local (dans ce cas là, la racine de la topologie sera un routeur) ; soit en
fonction du commutateur désigné comme le Designated Root conformément à l’algorithme du Spanning Tree. De ce fait, l’orientation de la topologie doit mener au
fait que pour toute paire d’éléments (e1,e2) on a soit (e1→e2) ou sinon (e2→e1).
Nous devons donc repérer les liens qui ne participent pas au trafic ascendant (des
feuilles vers la racine). On ne sait pas déterminer à la seule observation des tables
ARP, le sens du trafic (ascendant ou descendant). On est obligé de déduire le
sens en fonction de la nature des éléments et donc des services qu’ils rendent au
sein du réseau.
Détermination des feuilles : Typiquement, si un élément n’a qu’une seule
interface physique, il est forcément une feuille et donc, on supprimera tout lien
direct pour lequel cet élément serait indiqué comme étant la destination. Ou bien
si un élément E n’a pas d’agent SNMP malgré que l’on puisse avoir détecté un lien
de cet élément vers un autre élément, ou inversement de cet autre élément vers
E, on décide de ne conserver que le lien de E vers cet autre élément en admettant
que c’est parce qu’il participe au trafic ascendant. En l’absence d’informations
SNMP plus complètes, on ne peut pas faire de déduction plus précise.
Détermination des éléments nœuds : Essentiellement, il s’agit de déterminer le sens dans lequel les éléments qui composent le cœur du réseau (commutateurs, concentrateurs intelligents, routeurs) sont interconnectés. Vu que la
gestion du trafic entre commutateurs est déjà forcément orientée suite à l’application de l’algorithme du Spanning Tree, il suffit de consulter les informations
qui en ont résulté. Ainsi on obtient assez simplement (plus de détail sont donnés
dans le paragraphe "Description de l’algorithme du Spanning Tree" ci-dessous) la
portion de topologie concernée.
Étant donné la liste de la table 5.5, on obtient ainsi la liste présentée par
la table 5.6 permettant de construire un arbre représentant la topologie du réseau de racine A, en supposant que l’algorithme du Spanning Tree ait désigné le
commutateur A comme DesignatedRoot.
B→A
PC→B
Imprimante→A
Tab. 5.6 – Liste résultante pour la construction de la topologie
A priori, la topologie est exacte et précise. On peut, par exemple, la visualiser
graphiquement ou s’en servir en vue de construire des itinéraires (cf le chapitre
Principes et implantation de l’algorithme de découverte de la topologie
121
suivant). Notre algorithme appliqué sur le réseau présenté par la figure 5.15 a
pour topologie résultante le schéma proposé par la figure 5.16.
Workgroup Switch
CiscoSystems
Catalyst
A
Workgroup Switch
CiscoSystems
Catalyst
B
Imprimante
PC
Fig. 5.16 – Topologie obtenue par l’algorithme
Néanmoins pour améliorer la représentation visuelle donnée à l’administrateur, on sait rajouter des éléments qui ne peuvent pas être détectés parce qu’ils
n’ont pas d’adresse IP, bien qu’ils participent effectivement à la réémission de
signaux réseau (tels que les concentrateurs). Un concentrateur qui ne disposerait pas agent SNMP, est détectable de manière implicite lors de la phase de
connexion. En effet, si sur une interface d’un commutateur, on a plusieurs adresses
Ethernet apprises, c’est qu’il y a un concentrateur physiquement relié à cette interface, et sur lequel sont connectés les éléments correspondant à ces adresses
Ethernet.
Bien sûr, si un concentrateur disposait d’un agent SNMP, il aurait été découvert lors de la phase de détection, et son interconnexion avec d’autres éléments
aurait donc pu être explicitement gérée par l’algorithme.
Description de l’algorithme du Spanning Tree : Le Spanning Tree
Protocol (STP) est un protocole de gestion de niveau 2, qui fournit des chemins
redondants dans un réseau local tout en évitant les boucles de routage. Le protocole STP utilise un algorithme réparti qui sélectionne un pont (commutateur)
d’un réseau, dont la connectique physique engendre des liens de secours (soit en
paire torsadée, soit en fibre optique), comme la racine d’un arbre associé à la
topologie courante. Comme dans les réseaux Ethernet un seul chemin actif peut
exister entre deux stations3 , l’installation de liens de secours permet de créer plusieurs chemins actifs entre des stations, ce qui cause inévitablement des boucles
dans le réseau.
Lorsque les boucles surviennent, certains commutateurs reconnaissent une
même station sur plusieurs ports. Cette situation entraîne des erreurs au niveau de l’algorithme d’expédition et engendre la duplication de trames qui seront
3
Les opérations du Spanning Tree sont transparentes pour les stations d’extrémités (les
feuilles de l’arbre de diffusion, c’est-à-dire PCs, imprimantes, etc..).
122 Conception et implantation d’une plate-forme d’administration système et réseau
expédiées. L’algorithme du Spanning Tree fournit un arbre de circulation de l’information en bloquant, dans son arbre de diffusion, un des chemins de données
qui engendre la boucle.
Nous utilisons cet arbre pour la construction de notre topologie.
5.5
Mise en œuvre du service de découverte de
la topologie
Le service de la découverte de la topologie est un service qui se décompose en
deux agents mobiles, pour obtenir une plus grande efficacité dans la réalisation de
l’algorithme. Un premier agent, le NetNodesFinder pour la recherche des nœuds
ProActive en activité sur le sous-réseau et un second, le DiscoveryAgent, agent
responsable de la collecte des informations SNMP et de la construction de la
topologie du sous-réseau. Ces deux agents mobiles sont instanciés par l’ItineraryServer responsable d’un sous-réseau.
5.5.1
Le service de localisation des nœuds ProActive
Ce service est représenté par un agent mobile autonome dans le sens où il
possède une activité propre (objet actif selon ProActive). Le NetNodesFinder
utilise les paramètres qui décrivent le sous-réseau pour itérer sa scrutation de tous
les hôtes du sous-réseau qui seraient susceptibles d’accueillir des agents mobiles,
c’est-à-dire exécutant un nœud ProActive. Il fournit, dès qu’il en a connaissance,
le nom du nouveau nœud au service de mise à disposition. Le NetNodesFinder
arrête son processus de collecte lorsqu’il a atteint la dernière adresse IP de la plage
spécifiée par l’adresse du sous-réseau (Network Address) appliquée au masque
du sous-réseau (Network Mask). Le processus de renouvellement de la liste des
nœuds trouvés est automatiquement réalisé toutes les 2 minutes, après la localisation du dernier nœud du sous-réseau. Une optimisation peut être apportée à
cet algorithme, en utilisant la technique du protocole ICMP, identique à celle de
la phase de détection (voir section 5.4.2).
Remarque : La recherche des nœuds ProActive se fonde sur RMI pour localiser
un rmiregistry sur un hôte distant et s’il existe lui demander la liste des nœuds
ProActive enregistrés. Si l’hôte distant est protégé par un pare-feu, on subit le
timeout RMI qui peut être long.
Plus précisément, la recherche des nœuds ProActive se fonde sur RMI pour
localiser un rmiregistry sur un hôte distant et s’il existe lui demander la liste
des nœuds ProActive enregistrés. Si l’hôte distant est protégé par un pare-feu,
on subit le timeout RMI qui peut être long.
Mise en œuvre du service de découverte de la topologie
5.5.2
123
Le service de découverte
Le service de découverte est implanté via le DiscoveryAgent. Le DiscoveryAgent implémente l’algorithme de la construction de la topologie que nous venons
de décrire.
Remarque : Suite à la remarque faite précédemment au sujet du timeout,
on a mis en place deux agents, plutôt qu’un seul : l’un s’occupe uniquement de
la localisation, l’autre d’implémenter le service de découverte.
5.5.3
Interaction avec le serveur d’itinéraires
L’ItineraryServer est un objet actif mobile qui supervise le fonctionnement
des deux objets que nous venons de décrire : le NetNodesFinder et le DiscoveryAgent. En permanence, l’ItineraryServer veille à ce que les services soient les
plus du sous-réseau supervisé. Si l’ItineraryServer détecte qu’il a la possibilité
de se rapprocher du sous-réseau qu’il supervise (grâce à la liste des nœuds ProActive collectée), alors l’ItineraryServer utilise la possibilité de migration des trois
objets implantant services (lui-même, le DiscoveryAgent et le NetNodesFinder)
afin de les déplacer sur un nœud du sous-réseau.
Par exemple, imaginons les services localisés sur le réseau A (cf. figure 5.17).
Le premier cas présente l’exécution des services sur le réseau A, dont toutes les
requêtes sont à destination du réseau B. Si l’ItineraryServer détecte grâce
à la liste des nœuds ProActive qu’il gère, que l’ensemble des services peuvent
être déplacés vers le sous-réseau B, alors l’ItineraryServer envoie un ordre de
migration au NetNodesFinder et au DiscoveryAgent (2ème cas de la figure).
L’intérêt de cette migration est de permettre plus rapidement l’accomplissement de l’algorithme de construction de la topologie. En effet, se rapprocher du
sous-réseau permet d’utiliser la bande passante du réseau local sans avoir à tenir
compte de la vitesse du lien entre les réseaux A et B de la figure 5.17.
5.5.4
Topologie de réseaux virtuels
La technologie permet désormais de segmenter les réseaux locaux en une multitudes de réseaux virtuels (VLAN pour Virtual LAN ) qui sont gérés par des
commutateurs. On peut définir sur une même classe d’adresse IP, par exemple
192.168.10.0, plusieurs VLANs. Si on se place du côté de la topologie virtuelle,
un algorithme effectuant la distinction par VLANs donnera plusieurs topologies
sur le même sous-réseau. Nous avons choisi de ne pas faire cette distinction pour
obtenir une topologie la plus représentative du sous-réseau, en associant tous les
VLANs existant dans la même topologie. Toutefois, nous mettons à disposition
les listes des éléments par VLAN dans le sous-réseau. Il est cependant possible
d’obtenir, avec notre algorithme de construction de la topologie, une topologie
124 Conception et implantation d’une plate-forme d’administration système et réseau
Réseau B
Réseau A
ProActive Node
IS
DM
SNMP
DA
ND
GUI
RMI
Koumac
Lookup Service
ProActive Node
Yaté
Cas 1
Localisation des noeuds de la plateforme
Localisation des agents SNMP
Réseau A
Réseau B
SNMP
ProActive Node
DA
ND
IS
ProActive Node
DM
RMI
GUI
Koumac
Lookup Service
DA: Discovery Agent
IS: ItineraryServer
Yaté
Cas 2
DM: Discovery Manager
ND: Proactive Node Discovery
Fig. 5.17 – Schéma d’une migration automatique des services au plus proche du
sous-réseau
par VLAN(s) en spécifiant pour les hôtes du réseau qui sont des commutateurs
le nom de la communauté SNMP permettant de filter le VLAN désiré.
Par exemple, dans l’exemple présenté par la table 5.1, on utilisera une SNMPDestination avec comme nom de communauté SNMP la valeur :
[email protected]_du_vlan . On rappelle cependant que le filtre indiqué ici s’applique aux commutateurs de la gamme Cisco. Du matériel d’autres grands constructeurs, comme HP, n’ont pas pu être validés avec notre algorithme.
5.5.5
Evaluation du temps de construction
L’évaluation du temps de construction de la topologie dépend de certains
paramètres comme :
– De l’heure de la journée, car dans la journée il y a plus de charge sur le
réseau que pendant la nuit
Mise en œuvre du service de découverte de la topologie
125
– De la vitesse des interfaces réseau de chacun des éléments sur lesquels on
collecte l’information
– De la vitesse de réponse de l’agent SNMP sur lequel on collecte de l’information
– Du nombre de variables SNMP que l’on collectera sur l’agent SNMP
– Du nombre de :
– Postes de travail connectés, en incluant les serveurs et si quelques uns
d’entre eux ont des Agents SNMP
– Nombre de commutateurs SNMP dans le réseau
– S’il y a plus d’un routeur
On peut considérer que sur un réseau local, pour lequel un administrateur va
devoir intervenir, il va y avoir X éléments connectés. Le temps de détection d’un
élément va varier suivant le type d’élément du réseau que l’on va interroger et si
ces éléments sont équipés d’un agent SNMP. Plutôt que d’attendre un TimeOut
de la couche IP, nous vérifions la connectivité de l’élément (ping) avant d’essayer
d’obtenir plus d’information.
Remarque : Les valeurs qui sont données ici ont été obtenues sur un réseau de
production, dont la charge réseau a été augmentée artificiellement, afin d’obtenir
des valeurs élevées de collecte des variables SNMP. Ces valeurs ne peuvent pas
être appliquées sur d’autres réseaux car elle sont dépendantes de l’architecture
même du réseau, néanmoins comme valeurs réalistes.
Considérons donc X le nombre de machines total du réseau. Statistiquement,
pour X machines connectées en réseau (cf. table 5.7), nous allons pouvoir dire
qu’il y a des routeurs, des commutateurs, des imprimantes en réseau, etc..
Types d’éléments
Nombre
Valeur
Postes Clients
Routeur
Commutateurs
Serveurs
Imprimantes en réseau
X
1
5% * X
6% * X
8% * X
nombre total
au minimum
valeur moyenne
valeur moyenne
valeur moyenne
Estimation haute du
temps de collecte pour
un élément de ce type
0,5 seconde (Ping)
8 secondes
9,5 secondes
2,5 secondes
1,5 secondes
Tab. 5.7 – Répartition par catégories d’éléments sur un réseau
Notre évaluation du temps de construction de la topologie d’un réseau local
peut être estimée à partir de la formule suivante :
126 Conception et implantation d’une plate-forme d’administration système et réseau
Temps de construction = X*0,5s
+ X*5% (nombre moyen de commutateurs SNMP sur ce réseau)*9,5s
+ 1 (routeur)*8s
+ X*8% (nombre imprimantes en réseau)*1,5s
+ X*6% (nombre de serveurs moyens)*2,5s
L’hypothèse est de dire que le trafic moyen ne perturbe pas l’évaluation
moyenne du temps de collecte et que ce temps inclut la vitesse de fonctionnement de l’agent SNMP, la vitesse du client, et l’interconnexion des deux éléments
dans le même réseau local.
5.5.6
Extension de l’agorithme pour le protocole SNMP
V3
Même s’il n’est pas encore totalement déployé dans toutes les infrastructures
de réseau, le protocole SNMP V3 est un protocole incontournable car il apporte la
sécurité dans les opérations d’administration du réseau. On retrouve dans les architectures de réseau actuelles, de plus en plus d’équipements actifs qui intègrent
le protocole SNMP V3, mais aussi une multitude d’équipements actifs fonctionnant encore avec le protocole SNMP V1 (boîtier d’impression, imprimantes en
réseau), des éléments qui restent toutefois à administrer avec la première version
du protocole SNMP. Cette hétérogénéité nous contraint à proposer une solution
de notre algorithme de découverte de la topologie, utilisant les deux variantes de
communication du protocole.
Comparativement à la solution exposée dans la section 5.3.2, le seul problème
est la méthode de localisation des équipements actifs dans le réseau. En effet, dans
le premier algorithme, une méthode dite de broadcast permet de retrouver grâce
au protocole SNMP V1 tous les équipements actifs du réseau associé au nom
de la communauté SNMP fournie (en général public défini dans le descriptif du
sous-réseau). Avec cette technique, l’algorithme de construction de la topologie
localise de manière aisée tous les équipements actifs. Dans le cas de l’utilisation
du protocole SNMP V3, une telle méthode ne peut pas être mise en œuvre. Pour
palier au fait que les équipements actifs SNMP V3 ne répondent pas à ces paquets
de broadcast, nous proposons de faire ainsi : scrutation des éléments de bordure
(par exemple, le routeur par défaut du LAN défini dans le descriptif du sousréseau), qui permet de lancer itérativement la recherche des autres éléments en
activité dans le réseau local.
Successivement et en plusieurs passes, l’ensemble des équipements actifs fonctionnant aussi bien avec le protocole SNMP V1, V2 ou V3 seront ainsi découverts. S’agissant des éléments réseaux conformes au protocole SNMP V3, il est
bien évident que le service de découverte possède déjà les données nécessaires qui
seront utilisées lorsque l’on voudra converser avec de tels éléments. Par la mise
Bilan
127
en œuvre de cette technique, tous les équipements actifs du réseau seront ainsi
répertoriés.
Une fois ces éléments découverts, l’algorithme, implémenté par le service de
découverte, reste le même, puisque la détermination de la topologie se base sur les
mêmes informations que celles obtenues avec la version de protocole non sécurisée.
Du coup, les évaluations de performances faites dans la section précédente pour
la construction de la topologie du réseau ne seront pas modifiées car dès la phase
de démarrage de la construction, les informations listant les équipements actifs
et leur protocole de communication auront été obtenus par la modification qui
vient d’être présentée.
5.6
Bilan
Dans ce chapitre, nous avons défini les services que nous considérons utiles
pour définir une plate-forme pour l’administration système et réseau :
– le service de collecte et d’analyse du réseau qui sert à collecter les données
et les services du réseau (nœuds ProActive, agents SNMP, etc..) : ce service
est mis en œuvre par le NetNodesFinder et le DiscoveryAgent
– le service de mise à disposition de toutes les données collectées, organisées
selon la catégorie d’administration : une liste pour les agents SNMP et une
liste pour les nœuds ProActive : ce service est mis en œuvre par l’ItineraryServer
– le service de supervision de la plate-forme qui permet la visualisation de la
topologie du réseau, la supervision de tous les services inhérents au fonctionnement de la plate-forme, et pour finir l’aide à la supervision des agents
mobiles d’administration (IC2D et un outil ad hoc) : ce service est mis en
œuvre par le DiscoveryManager
Pour obtenir la topologie décrivant le réseau à administrer constitué de sousréseaux, nous avons introduit un objet, de type SubNetworkDescription, qui
regroupe les informations décrivant un sous-réseau. A partir de ces informations,
le service de collecte et d’analyse des données peut construire la topologie d’un
sous-réseau. L’algorithme qui nous permet d’obtenir la topologie d’un sous-réseau
est donné dans la section 5.4, ainsi que l’interprétation des données collectées pour
créer l’arbre n-aire représentant logiquement cette topologie.
128 Conception et implantation d’une plate-forme d’administration système et réseau
Chapitre 6
Programmation d’agents mobiles
pour l’administration système et
réseau
6.1
Introduction
Dans ce chapitre nous mettons en évidence deux facettes dans la programmation des agents mobiles pour des opérations d’administration système et réseau. La première, basée sur le concept des itinéraires que l’agent mobile doit
suivre pour effectuer les tâches programmées. La deuxième basée sur le code de
la fonction d’administration à proprement parler pour laquelle nous proposons
un cadre générique pour le développement d’agents mobiles d’administration.
Nous commencerons la présentation par l’aspect de la fabrication des itinéraires, représentés par des instances de la classe Java ItineraryManager que
nous définissons. Cette classe ItineraryManager est le point d’articulation entre
d’une part la plate-forme sous jacente qui collecte des informations sur le réseau
à administrer (cf. chapitre 5) et d’autre part, les agents mobiles qui sont eux en
charge des fonctions d’administration sur les éléments du réseau qui leur sont
indiqués dans les itinéraires, grâce aux informations collectées.
Pour utiliser nos itinéraires de manière automatique, nous fournissons un modèle de programmation pour un agent (un agent générique), présenté par la classe
Agent, qu’il suffira de spécialiser pour développer de nouveaux agents mobiles
d’administration au sein de notre plate-forme. Toutefois, cette classe Agent n’est
qu’un modèle que le programmeur n’est pas obligé de suivre pour créer ses propres
agents mobiles d’administration. Il s’agit pour nous uniquement de proposer un
cadre général de programmation d’agents de notre plate-forme.
129
130
Programmation d’agents mobiles pour l’administration système et réseau
6.2
6.2.1
Fabrication et suivi d’itinéraires
Architecture générale
Dans le modèle de migration de ProActive, on trouve juste la définition de
ce qu’est un agent mobile et d’une classe permettant de faire suivre un itinéraire
à un agent, le MigrationStrategyManager. Le MigrationStrategyManager est
une classe dont une instance permet de gérer de manière automatique les appels
de méthodes et les ordres de migration pendant le suivi de l’itinéraire. De plus
amples informations seront données sur son fonctionnement dans la section 6.2.3.
Agent Mobile
Modele de ProActive
onArrival
MigrationStrategyManager
add
startStrategy
snmpOnArrival
ItineraryManager
atTheEnd
addUrgentDestination
prepareItinerary
Appel de methode direct
Appel de methode sur Destination (par reification)
Modele avec les itineraires dynamiques
Fig. 6.1 – Interaction entre l’agent mobile, l’ItineraryServer et l’ItineraryManager
Comme on veut faire des itinéraires dynamiques, on a introduit une entité
supplémentaire l’ItineraryManager qui a pour rôle de récupérer auprès d’un
ItineraryServer les éléments qui permettront de construire l’itinéraire. La figure 6.1 présente les deux modèles, celui de base de ProActive et les extensions
que nous avons apportées en introduisant l’ItineraryManager.
L’ItineraryManager met à la disposition de l’agent mobile les méthodes publiques suivantes (voir le code figure 6.2) :
– prepareItinerary, pour demander la création de l’itinéraire selon le modèle de visite désiré (itinéraire local, distant, etc..)
Fabrication et suivi d’itinéraires
131
– setLastDestination, pour qu’une méthode particulière soit appelée à la
fin de l’itinéraire (par le biais de la Destination)
– startItinerary pour lancer le suivi de l’itinéraire
– getCurrentDestination pour obtenir la Destination courante
– addUrgentDestination, pour qu’une Destination urgente soit prise en
compte dans l’itinéraire courant, pour s’occuper de quelque chose de critique, éventuellement dans un autre sous-réseau. Reprise normale de l’itinéraire une fois cette tâche urgente entreprise
– getOthersItineraryServer pour obtenir la liste des autres ItineraryServers actifs
6.2.2
Fabrication de l’itinéraire
Le fonctionnement général de notre système de fabrication d’itinéraire, implémenté par la classe ItineraryManager est décomposé en deux grandes parties. La
première partie consiste en la localisation du bon ItineraryServer, c’est-à-dire
celui qui est responsable de la supervision d’un sous-réseau donné. Pour ce faire, et
grâce à la technologie Jini, notre ItineraryManager va d’abord récupérer la liste
complète de tous les ItineraryServers (ces références sont automatiquement
obtenues par le Lookup Service). Ainsi, pour obtenir la référence vers l’ItineraryServer responsable du bon sous-réseau, il suffit de filtrer la liste résultante
et de ne conserver que celui qui est intéressant pour construire la première portion de l’itinéraire (méthode getLocalItineraryServer, cf. code figure 6.3). Dès
la référence de l’ItineraryServer connue, l’ItineraryManager collecte la liste
des éléments SNMP et la liste des nœuds ProActive détectés par l’algorithme de
construction de la topologie pour ce sous-réseau.
La deuxième partie est la partie qui est propre à chaque type de gestionnaire
d’itinéraire. Pour chacune des sous-classes de l’ItineraryManager la manière
dont doit être suivi l’itinéraire est définie. Par exemple, celui-ci peut n’incorporer que des nœuds de la plate-forme, qu’une liste d’agents SNMP à visiter, ou un
mélange particulier des deux. Ainsi chaque sous-classe permet de fabriquer un itinéraire en alimentant une liste de Destinations représentant les Destinations
qui doivent être prises en compte lors du suivi de l’itinéraire. Cette liste de
Destinations est stockée dans le MigrationStrategyManager dont la tâche est
d’assurer les opérations liées au suivi de l’itinéraire.
6.2.2.1
Un itinéraire avec des éléments de même classe de service
Avec notre modèle et les informations que nous connaissons sur les éléments
qui composent le réseau, il est relativement aisé d’implémenter une classe, par
exemple ItineraryManagerForNetworkPrinter (cf. figure 6.4) qui donnerait un
132
Programmation d’agents mobiles pour l’administration système et réseau
public abstract class ItineraryManager implements java.io.Serializable {
protected MgtMigrationStrategyManagerImpl mgtMigrationStrategyManager;
protected MigrationStrategy myItinerary;
protected ItineraryServerList othersItineraryServer;
protected Body b; // is the Body of the mobile code
protected Destination lastDestination;
private
ArrayList myItineraryServerList=new ArrayList();
/** Constructor */
public ItineraryManager() {}
/** Locate the ItineraryServer and prepare an Itinerary */
abstract public void prepareItinerary();
abstract public void prepareItinerary(ItineraryServer itineraryServer) ;
/** which method to call at the end ? */
public void setLastDestination(Destination aDestination) {
this.lastDestination=aDestination;
}
/** start itinerary */
public void startItinerary() {
try {
mgtMigrationStrategyManager.startStrategy(b);
} catch (Exception e) {e.printStackTrace();}
}
/** Get the current NodeDestination */
public Destination getCurrentDestination() {
return mgtMigrationStrategyManager.getCurrentDestination();
}
/** Add an Urgent Node to visit */
public void addUrgentDestination(Destination node) {
myItinerary.addNext(node);
}
/** return an ItineraryServerList of all ItineraryServers
found, except current one */
public ItineraryServerList getOthersItineraryServer() {
return othersItineraryServer;
}
}
Fig. 6.2 – Les méthodes publiques de la classe de l’ItineraryManager
itinéraire pour n’administrer que des éléments ayant le port TCP 5151 d’ouvert.
Il s’agit uniquement de redéfinir la méthode prepareItinerary de la classe
ItineraryManager pour obtenir l’itinéraire désiré.
6.2.2.2
Un itinéraire couvrant l’ensemble du réseau
Lorsque nous souhaitons bâtir des itinéraires couvrant plusieurs sous-réseaux
(cf. figure 6.5), alors la méthode prepareItinerary a un fonctionnement particulier. Comme nous voulons des itinéraires les plus à jour possible, la méthode
prepareItinerary sera appelée plusieurs fois pendant le déroulement du suivi
de l’itinéraire. En effet, à chaque fin de sous-itinéraire correspondant à un sousréseau, la destination ISDestination sera insérée pour que l’ItineraryMana1
Le numéro de port 515 définissant le service associé à un service d’impression IP (protocole
lpr/lpd [47]).
Fabrication et suivi d’itinéraires
133
// create a MigrationStrategyManager instance
private void createMigrationStrategyManager() {
b = ProActive.getBodyOnThis();
if (mgtMigrationStrategyManager == null) {
mgtMigrationStrategyManager = new MgtMigrationStrategyManagerImpl((Migratable) b);
myItinerary = mgtMigrationStrategyManager.getMigrationStrategy();
}
}
/** Service lookup Discovery */
protected ArrayList getLookupServices(String services) {
ServiceLookup sl = new ServiceLookup(services);
ArrayList listOfService = new ArrayList();
try {
sl.waitForLastDiscovery();
listOfService.addAll(sl.getServices());
} catch (Exception e) {e.printStackTrace();}
}
/** locate our local ItineraryServer */
protected ItineraryServer getLocalItineraryServer() {
IpAddress myAddress = new mgt.ip.InetInfo().getHostIpInfo();
ItineraryServer localItineraryServer=null;
for (int i=0;i<myItineraryServerList.size();i++) {
try {
ItineraryServerProxy isp =( ItineraryServerProxy) myItineraryServerList.get(i);
if (!isp.getSubNetworkDescription().isInNetwork(myAddress))
othersItineraryServer.add(new ISDestination(
(ItineraryServer)ProActive.lookupActive("ItineraryServer",
isp.toString())));
else
localItineraryServer = (ItineraryServer)ProActive.lookupActive(
"mgt.itinerary.ItineraryServer", isp.toString());
} catch (Exception e) {e.printStackTrace();}
}
if (localItineraryServer != null) return localItineraryServer;
// at this point, no itineraryServer is active for my local network
// Create one, and wait for data ready
ArrayList myNetworkList=new ArrayList(getLookupServices("NetworkDescription"));
SubNetworkDescription subNetDescr=null;
for (int i=0;i<myNetworkList.size();i++) {
NetworkDescription NetDescr =( NetworkDescription) myNetworkList.get(i);
if (NetDescr.getSubNetworkDescription(myAddress) != null)
SubNetDescr = NetDescr.getSubNetworkDescription(myAddress);
}
// try to create an ItineraryServer for local network
ItineraryServer itineraryServer=null;
try {
Node nodeToStart = JiniNodeFactory.getDefaultNode();
itineraryServer =
(ItineraryServer) ProActive.newActive("ItineraryServer",null,nodeToStart);
if (subNetDescr != null)
itineraryServer.setSubNetworkDescription(subNetDescr);
else
System.out.println("No configuration Found. "+
Please contact your system administrator !!!");
return ItineraryServer;
} catch (Exception e) {e.printStackTrace();}
}
Fig. 6.3 – Les méthodes privées ou protégées de la classe de l’ItineraryManager
134
Programmation d’agents mobiles pour l’administration système et réseau
Class ItineraryManagerForPrinter extends ItineraryManager{
public void prepareItinerary (....)
// Prepare the itinerary
public void prepareItinerary(ItineraryServer iS) {
createMigrationStrategyManager()
iS.getSnmpNodes();
// éliminer les éléments qui ne conviennent pas
// c’est-à-dire prendre les éléments qui fournissent le service.
// Host.getTcpService contient lpr/lpd, port 515
//parmis ceux qui restent
SnmpDestination dest = new SnmpDestination(host, community, "printerOnArrival");
// c’est ici que l’on détermine le nom de la méthode qui sera invoquée :
// dans ce cas, la méthode appelée "printerOnArrival"
}
}
Fig. 6.4 – Un ItineraryManager pour la collecte de données sur des imprimantes
du sous-réseau représenté par un ItineraryServer
ger puisse enrichir l’itinéraire courant. Il y aura un appel de méthode, comme
pour une NodeDestination qui engendrera l’appel sur la méthode prepareItinerary de l’ItineraryManager. Ainsi l’ItineraryManager enrichira l’itinéraire courant avec les Destinations du nouveau sous-réseau à visiter. Et ce,
tant qu’il existe des ItineraryServers dans la liste obtenue via Jini. Un problème technique est que l’on ne peut pas placer, dès la construction initiale de
l’itinéraire, toutes les ISDestinations dans l’itinéraire car sinon on ne pourrait plus insérer les éléments correspondant à chaque sous-réseau. On ne place
donc à la suite de la liste des éléments du sous-réseau courant que la prochaine
destination de type ISDestination. Lorsque le MigrationStrategyManager déclenche la méthode associée à cette ISDestination sur l’agent, cela déclenchera
l’exécution de prepareItinerary pour le réseau associé à cet ItineraryServer. A nouveau, après insertion des éléments de ce réseau (liste récupérée dynamiquement auprès du ItineraryServer), on rajoute si besoin la prochaine
ISDestination, et ainsi de suite. S’il n’y a plus de ISDestination, la méthode
prepareItinerary rajoute, le cas échéant, la destination indiquée par la méthode
setLastDestination.
Remarque : Toutefois, si l’ItineraryServer n’existe pas pour le réseau cible,
son instanciation est initiée afin de pouvoir créer un itinéraire une fois que les
informations auront été collectées.
6.2.3
Suivi de l’itinéraire
Le suivi de l’itinéraire est assuré par l’entité MigrationStrategyManager (cf.
figure 6.6) qui assure donc les opérations de migration de l’agent mobile et les
Code d’administration
135
public class ItineraryManagerWholeNetwork
extends ItineraryManager implements Serializable {
public ItineraryManagerWholeNetwork() {}
public void prepareItinerary() {
ItineraryServer iServer=getLocalItineraryServer();
prepareItinerary(iServer);
}
/** Locate the ItineraryServer and start to migrate */
public void prepareItinerary(ItineraryServer iServer) {
proActiveNodes = new ArrayList();
try {
ArrayList snmpList = new ArrayList(iServer.getSNMPElements());
proActiveNodes.addAll(iServer.getProActiveNode());
createMigrationStrategyManager(); // create a new
MigrationStrategyManager
for (int i=0;i<proActiveNodes.size();i++) {
NodeDestination nd =(NodeDestination)proActiveNodes.get(i)
myItinerary.add(nd);
int currentPos =
snmpList.indexOf(nd.getDestination().getHostName());
if (currentPos >=0) { // add SNMPDestination for same Host
myItinerary.add(snmpList.remove(currentPos));
}}
}
// add others SNMPDestination, host without any Node
for (int i=0;i<snmpList.size();i++)
myItinerary.add(snmpList.get(i));
if (othersItineraryServer.size() >0) {
// at least another ItineraryServer on whole administrative domain
// add a ISDestination to call another ItineraryServer
// the name of called method : prepareItinerary
myItinerary.add(othersItineraryServer.next());
}
else if (lastDestination != null) {
myItinerary.add(lastDestination);
}
} catch (Exception e) {e.printStackTrace();}
}
}
Fig. 6.5 – Itinéraire couvrant tout le réseau : ItineraryManagerWholeNetwork
appels de méthodes associées aux Destinations.
Pour chaque Destination rencontré pendant le parcours de l’itinéraire, le
MigrationStrategyManager exécute la fonctionnalité suivante :
– Stockage de la Destination courante
– Appel du nom de la méthode contenue dans la Destination
– Si Destination incluant une migration, alors migration de l’agent mobile
6.3
6.3.1
Code d’administration
Les opérations de base
Nous utilisons pour programmer nos fonctions d’administration de réseau la
bibliothèque SNMP fournie par AdventNet [2]. Il est possible d’utiliser l’API
136
Programmation d’agents mobiles pour l’administration système et réseau
public class MgtMigrationStrategyManagerImpl implements
MigrationStrategyManager, MigrationEventListener,
java.io.Serializable {
// La destination cournate
Destination currentDestination = null;
//Indique que l’objet suit un itinéraire
private boolean onItinerary;
// Retourne la destination cournate
public Destination getCurrentDestination() {
return currentDestination;
}
// méthode pour démarrer le suivi de l’itinéraire
public void startStrategy( ..) {
...
}
...
// Les appels de méthodes et la migration
protected void continueStrategy(Body body) throws MigrationException {
if (! onItinerary) return;
Destination dest = migrationStrategy.next();
currentDestination=dest;
if (dest == null) { // fin de l’itinéraire
this.onItinerary = false;
return;
}
methodOnArrival = dest.getMethodName();
if (dest instanceOf mgt.itinerary.SnmpDestination) {
executeMethod(body.getReifiedObject(), methodOnArrival);
continueStrategy(body);
} else {
try {
if ( NodeFactory.isNodeLocal(NodeFactory.getNode(dest.getDestination())) ) {
executeMethod(body.getReifiedObject(), methodOnArrival);
continueStrategy(body);
} else ProActive.migrateTo(body, ie.getDestination(), fifoFirst);
} catch (Exception e) {e.printStackTrace();}
}
}
}
Fig. 6.6 – Classe MgtMigrationStrategyManagerImpl
fournie par AdventNet afin de collecter des informations sur les agents SNMP.
Pour permettre d’écrire des fonctions d’administration plus sophistiquées, nous
avons écrit une bibliothèque de plus haut niveau permettant, par exemple, de
reproduire une table de routage, une matrice de commutation et d’accéder à ces
informations de manière simplifiée.
6.3.1.1
La gestion des traps SNMP
Il est évident que lorsque l’on parle d’un système d’administration système et
réseau la plate-forme qui gère le réseau doit être en mesure de prendre en compte
les événements qui surviennent sur le réseau. Plus précisément dans notre cas,
la récupération des traps [88] et le traitement de ces événements. La gestion et
la compréhension de ces traps SNMP imposent un long travail afin de mettre à
Code d’administration
137
disposition dans la plate-forme d’administration système et réseau toutes les OID
SNMP correspondant chacun à une trap d’un équipement.
public boolean callback(SnmpSession session,SnmpPDU pdu, int requestID){
// check trap version
if(pdu == null) return false;
if (pdu.getCommand() == api.TRP_REQ_MSG) {
System.out.println("Trap received from: "
+pdu.getAddress() +", community: " + pdu.getCommunity());
System.out.println("Enterprise: " + pdu.getEnterprise());
System.out.println("Agent: " + pdu.getAgentAddress());
System.out.println("TRAP_TYPE: " + pdu.getTrapType());
System.out.println("SPECIFIC NUMBER: " + pdu.getSpecificType());
System.out.println("Time: " + pdu.getUpTime()+"\nVARBINDS:");
// print varbinds
for (Enumeration e = pdu.getVariableBindings().elements();e.hasMoreElements();)
System.out.println(((SnmpVarBind) e.nextElement()).toTagString());
}
else
System.err.println("Non trap PDU received.");
System.out.println(""); // a blank line between traps
try {
// create a mobile agent and sent it to see what’s happen
AgentTrap agtrap = (AgentTrap) ProActive.newActive("AgentTrap",null);
agtrap.setTrapFrom(pdu.getAddress().toString(),
pdu.getCommunity().toString(), pdu.getEnterprise().toString());
agtrap.check();
} catch (Exception e) {e.printStackTrace();}
return true; // API CallBack of AdventNet
}
Fig. 6.7 – Exemple de code inspiré par la gestion des traps de AdventNet pour
instancier un agent mobile de gestion de traps
public class AgentTrap extends Agent implements
ArrayList nodeRessource = new ArrayList();
ArrayList arpTable = new ArrayList();
String ipAddress, community, trapOID;
java.io.Serializable {
public AgentTrap() {
super();
}
// method call by a trap listener
public void setTrapFrom(String ipAddress, String community, String trapOID) {
this.ipAddress=ipAddress;
this.community=community;
this.trapOID=trapOID;
}
// go and check what’s happening
public void check() {
System.out.println("A trap is received from "+ipAddress);
}
}
Fig. 6.8 – Un agent générique permettant de gérer une trap SNMP
138
Programmation d’agents mobiles pour l’administration système et réseau
Toutefois, et à titre d’exemple, le code (cf. figure 6.7) basé sur la gestion des
traps SNMP de AdventNet, permet simplement de capturer la trap (fonction
callback et d’instancier ensuite un agent mobile (cf. figure 6.8) qui aurait pour
travail sa gestion. Dans notre exemple, l’agent mobile affiche la provenance de la
trap SNMP, mais pourrait tout aussi bien déclencher un ou plusieurs autres agents
mobiles pour effectuer une tâche d’administration liée à cet événement. Pendant
la phase de traitement de cette trap par l’agent mobile, si un autre événement
survient, alors les données relatives à cette trap peuvent être transmises à l’agent
mobile. En effet, le système de communication de ProActive permet d’échanger
des messages avec un agent mobile pendant son processus de migration, quelque
soit l’emplacement de celui-ci. Par un tel système, l’agent mobile responsable de
la gestion des traps pourra corréler les différents événements si nécessaire.
6.3.1.2
Appels systèmes directs
Pour programmer des fonctions d’administration de systèmes, nous avons selon les cas utilisé les appels systèmes directs, via l’interface native de Java (Java
Native Interface, JNI), utilisé l’API des entrées/sorties de Java, ou utilisé l’API
System de Java.
Nous avons essayé de masquer, par une bibliothèque de fonctions de plus haut
niveau, la complexité et l’hétérogénéité des systèmes (par exemple pour obtenir
les ressources d’un système). Sachant que, même les opérations d’administration
système (de consultation, surveillance) sont de plus en plus réalisables via uniquement l’interrogation d’agents SNMP, il sera dès lors possible de consulter la
MIB des agents SNMP pour obtenir le même type d’information. Par exemple,
les ressources propres d’un système peuvent être accessibles par la Host MIB [36].
6.3.2
Utilisation des opérations de base dans le code de
l’agent
Il suffit d’hériter du squelette de la classe Agent, en se focalisant sur les méthodes qui sont déclenchées automatiquement et qui implantent le code fonctionnel : tout particulièrement onArrival, snmpOnArrival, c’est-à-dire les méthodes
qui sont déclenchées par le MigrationStrategyManager.
6.3.2.1
Squelette de l’agent
Le squelette de l’Agent (figure 6.9) définit les méthodes qui sont nécessaires
pour utiliser cette définition d’un agent mobile avec des itinéraires dynamiques.
Les méthodes onArrival et snmpOnArrival définies permettent seulement de
capturer la destination courante dans une variable afin d’affranchir le programmeur de cette étape et elles devront bien sûr être personnalisées dans les classes
filles. Quant aux méthodes liées à la préparation et au démarrage de l’itinéraire,
Code d’administration
public abstract class Agent java.io.Serializable {
// the Destinations
private ItineraryManager itiManager; // my ItineraryManager
private ArrayList visitedNodes; // collected visited nodes
// constructor
public Agent() {}
public ItineraryManager getItineraryManager() {
// return the ItineraryManager
return itiManager;
}
public ArrayList getVisitedNodes() {
// return an ArrayList of all Visited Nodes
return visitedNodes;
}
// what to do for a NodeDestination
public void onArrival() {
NodeDestination nDest = (NodeDestination)itiManager.getcurrentDestination();
visitedNodes.add(dest.toString());
}
// what to do for a SnmpDestination
public void snmpOnArrival() {
SnmpDestination snmpDest = (SnmpDestination)itiManager.getcurrentDestination();
visitedNodes.add(dest.toString());
}
// Prepare the itinerary
public void prepareItinerary(ItineraryManager itiManager) {
// Prepare an ItineraryManager
this.itiManager=itiManager;
itiManager.prepareItinerary();
}
// Prepare the itinerary
public void prepareItinerary(ItineraryManager itiManager, ItineraryServer iServer) {
// Prepare an ItineraryManager using ItineraryServer iServer
this.itiManager=itiManager;
itiManager.prepareItinerary(iServer);
}
// start to follow the itinerary
public void startItinerary() {
itiManager.startItinerary();
}
// add an urgent Destination to visit
public void addUrgentDestination(Destination destination) {
// the next Destination will be the new one
itiManager.addUrgentDestination(destination);
}
// what to do at the end of itinerary, if necessary
public void setLastDestination(Destination aDestination) {
// add a Destination to visit at the end of the current itinerary
itiManager.setLastDestination(aDestination);
}
// what to do at the end of itinerary, if necessary
public void setLastDestination(String methodName, Node homeNode) {
itiManager.setLastDestination(
new NodeDestination(homeNode.getNodeInformation().getName(),methodName));
}
}// end of class Agent
Fig. 6.9 – Classe abstraite de l’Agent
139
140
Programmation d’agents mobiles pour l’administration système et réseau
elles font appel aux méthodes d’une instance de la classe ItineraryManager
associées à l’agent : prepareItinerary(...) pour préparer l’itinéraire selon le
modèle
d’ItineraryManager choisi, startItinerary() pour démarrer le suivi de l’itinéraire, addUrgentDestination(..) pour prendre en compte une destination à
traiter en urgence quitte à dérouter l’agent de son réseau et setLastDestination(...) pour faire exécuter une tâche en fin de parcours de l’itinéraire. Notons que c’est l’instanciation d’un type d’ItineraryManager voulu qui permet à
l’agent mobile de savoir quel type d’itinéraire il devra suivre mais que l’itinéraire
à proprement parler est créé dynamiquement par l’agent mobile lui-même (par
l’appel à prepareItinerary).
6.3.2.2
Exemple d’utilisation
public class AgentMix extends Agent java.io.Serializable {
ArrayList AllMemInfo = new ArrayList();
ArrayList AllArplTable = new ArrayList();
public AgentMix() {}
public void onArrival() { // override Agent.onArrival
super.onArrival();
SystemResources sr = new SystemResources();
AllMemInfo.add(nodeDest.getDestination());
// Gets TOTAL MEM, USED MEM, FREE MEM into a String
AllMemInfo.add(sr.toString());
}
public void snmpOnArrival() { // overrides Agent.snmpOnArrival
super.snmpOnArrival();
// gets the SNMP MIB Table ip.ipNetToMediaTable
AllArplTable.addAll(new IpMacTable(snmpDest).getArpTable());
}
// Display the collected Data
public void displayData() {
// displays the collected data
System.out.println("Data collected : "
+AllMemInfo+"\n"+AllArplTable);
}
// return partial results
public ArrayList getPartialResult() {
return AllMemInfo;
}
}
Fig. 6.10 – Un agent mixte, récupérant les ressources du système sur chaque
nœud et la table ARP de chaque Agent SNMP
L’AgentMix (figure 6.10) est un exemple d’implémentation d’un agent mobile
effectuant une tâche d’administration pour les nœuds et une collecte de données
pour les agents SNMP. Pour l’écrire, nous avons étendu la classe Agent et décrit
les méthodes qui nous intéressaient : onArrival pour la collecte de la charge des
ressources du système et snmpOnArrival pour la collecte de la table ARP de
l’agent SNMP spécifié dans l’itinéraire. Nous utilisons pour instancier l’AgentMix
Extensibilité du modèle de développement
141
une instance de la classe Launch (cf. figure 6.11). Cette classe fixe les modalités du fonctionnement de l’AgentMix, en fournissant à l’agent mobile l’itinéraire
ItineraryManagerLocalNetwork et en demandant à l’agent mobile d’exécuter à
la fin de son itinéraire, la méthode displayData() qui sera spécifiée lors de la
création de l’agent mobile par l’appel de la méthode setLastDestination(..).
Puis cette classe permet de faire autre chose et de temps en temps si nécessaire,
d’aller demander à l’agent mobile ses résultats intermédiaires.
import org.objectweb.proactive.ProActive;
import org.objectweb.proactive.core.node.NodeFactory;
import AgentMix;
public class Launch {
public static void main(String args[]) {
try {
AgentMix mobileAgent =
(AgentMix)ProActive.newActive("AgentMix", null);
mobileAgent.prepareItinerary(new ItineraryManagerLocalNetwork());
// NodeFactory.getDefaultNode is the ProActive Node on current JVM
mobileAgent.setLastDestination("displayData", NodeFactory.getDefaultNode());
mobileAgent.startItinerary();
// do a job
ArrayList partialResult=mobileAgent.getPartialResult();
} catch (Exception e) { e.printStackTrace(); }
} // main
}
Fig. 6.11 – Code du lanceur de l’AgentMix
6.4
6.4.1
Extensibilité du modèle de développement
Modalités de l’extension
Le cadre de développement des agents mobiles que nous venons d’exposer
permet d’écrire facilement de nouveaux agents mobiles qui utiliseraient notre bibliothèque d’itinéraires dynamiques. C’est ce que nous avons expliqué dans la
section précédente. Ce qu’il serait souhaitable de pouvoir faire, c’est d’étendre le
cadre de développement lui-même. C’est la possibilité de pouvoir définir de nouveaux types de Destinations, de nouveaux types d’itinéraires prenant en compte
ces nouvelles Destinations, et des agents mobiles dont les méthodes à déclencher
pour les destinations d’un itinéraire puissent avoir des noms quelconques. Pour
cela, nous présentons dans la section suivante comment il est possible d’étendre
notre modèle afin que le nom de méthode d’administration à faire exécuter par
un agent mobile est paramétrable, et comment prendre en compte un nouveau
type de Destination.
Puis, pour étendre notre modèle a d’autres types de destinations, il faut bien
sur définir ce nouveau type puis, il suffit d’étendre l’ItineraryManager en faisant
une classe d’itinéraire ad hoc prenant en charge l’organisation de ces destinations
142
Programmation d’agents mobiles pour l’administration système et réseau
pour atteindre l’objectif fixé. En terme de gestion d’itinéraire, il sera nécessaire
que ce nouvel ItineraryManager sache préparer et démarrer le suivi de l’itinéraire.
Pour associer un agent mobile d’administration avec le système des itinéraires
que nous avons développé (ItineraryManager et les classes dérivées), il suffit
juste que le code de l’agent mobile définisse les méthodes qui seront appelées
pendant le suivi de l’itinéraire.
Il n’est pas obligatoire de réutiliser les méthodes que l’on a défini dans la
classe Agent (cf. figure 6.9) (méthodes onArrival, snmpOnArrival), puisque le
nom de ces méthodes, bien que fixe à une valeur initiale par défaut dans toute
classe Destination, peut être redéfinie si besoin est, lors de la preparation de
l’itinéraire.
6.4.2
Exemple : prise en compte d’un nouveau type de
destination
Pour illustrer l’extensibilité de notre modèle d’itinéraire et de programmation
des agents mobiles, nous présentons un agent mobile qui effectuerait une tâche
d’administration sur des équipements actifs supportant le protocole SNMP V3. La
figure 6.12 présente le code de l’agent mobile avec l’implémentation de la méthode
qui sera invoquée (que l’on a appelée secureV3OnArrival à la place du nom de la
méthode définie par défaut qui est snmpV3OnArrival). La classe dérivée de l’ItineraryManager, l’ItineraryManagerSNMPV3 permet de construire un itinéraire
supportant le nouveau type de destination, la SNMPV3Destination (figure 6.13).
On a cependant une restriction qui est que seuls les éléments définis explicitement (via une GUI ad hoc alimentant les données du service de description
d’un sous-réseau, cf. section 5.3.2.1) comme étant de type SNMPV3Destination
pourront être considérés de ce type. En effet, une détection des équipements actifs
supportant le protocole SNMP V3 n’est pas aisée, car les informations concernant
la sécurité (par exemple username, password, etc...) ne peuvent pas être découvertes automatiquement. C’est pour cette raison que le service de découverte d’un
sous-réseau est conçu pour découvrir des éléments SNMP V1, des nœuds ProActive, et qu’une extension de notre algorithme de découverte permet aisément de
prendre en compte les autres éléments du réseau utilisant les améliorations du
protocole SNMP (SNMP V2c et SNMP V3).
6.4.2.1
Sécurisation des échanges
Dans le modèle d’exécution des tâches écrites en Java ProActive, nous ne
faisons pas intervenir un modèle de sécurité parce que nous avons considéré que
les réseaux de l’entreprise étaient directement inter-connectés, sans passer par un
opérateur. Toutefois, avec la dispersion de plus en plus grande des réseaux au sein
du réseau de l’entreprise, il peut être préférable d’utiliser la version sécurisée de la
Extensibilité du modèle de développement
143
Class AgentSnmpV3 extends Agent implements java.io.Serializable {
private ItineraryManager itiManager;
public AgentSnmpV3() {}
// what to do for a NodeDestination
public void onArrival() { }
// what to do for a SnmpDestination
public void secureV3OnArrival() {
// on récupère la destination SnmpV3 dans la variable snmpDest
super.snmpOnArrival();
mgt.snmp.SystemDescr sysDescrV3= new mgt.snmp.SystemDescr();
sysDescrV3.setSystemDescr("v3",snmpDest.getUsername(), snmpDest.getAuthPassword(),
snmpDest.getAuthProtocol(),snmpDest.getPrivPassword());
}
// Prepare the itinerary
public void prepareItinerary(ItineraryManager itiManager) {
// Prepare an ItineraryManager
this.itiManager=itiManager;
itiManager.prepareItinerary(itineraryServerHome);
}
}// end of class AgentSnmpV3
Fig. 6.12 – L’AgentSnmpV3 qui dialogue en SNMP V3 avec des équipements actifs
import mgt.itinerary.SnmpDestination;
Class SnmpV3Destination extends SnmpDestination {
String username; // principal username
String authPassword; // authentication password
String authProtocol; // authentication protocol : MD5/SHA
String privPassword; // privacy control password
String contextName; // context use for snmp v3 pdu
int portNumber=161;
String methodOnArrival="snmpV3OnArrival"; // default method name
public SnmpV3Destination(String host, String username, String authPassword,
String authProtocol, String privPassword) {
....
}
...
// gets values for Snmp V3
public String getUserName() ..
public String getAuthPassword()..
public String getAuthProtocol()..
public String getPrivPassword()..
public String getContextName()..
public int getPortNumber()..
}
Fig. 6.13 – La définition d’une destination pour le protocole SNMP V3
plate-forme ProActive [6] et de ne permettre l’accès aux données sécurisées qu’aux
agents mobiles disposant des droits nécessaires. Regardons à présent comment
exécuter une fonction d’administration pour un élément SNMP V3 qui requiert
que l’agent dispose des informations sur le nom d’utilisateur et le mot de passe
pour le compte duquel il s’exécute. Nous supposons ainsi que ls agents mobiles se déplacent sur des nœuds sécurisés ; leur migration et leur communication
peuvent elle être cryptées. Nous avons imaginé un processus d’échange de clef
144
Programmation d’agents mobiles pour l’administration système et réseau
Class ItineraryManagerSNMPV3 implements ItineraryManager{
// Prepare the itinerary
public void prepareItinerary(ItineraryServer iServer) {
ArrayList snmpV3List = iServer.getSnmpElements();
createMigrationStrategyManager();
for (int i=0;i<snmpV3List.size();i++) {
// prendre les éléments SNMP V3
if (snmp3List.get(i) instanceof SNMPV3Destination) {
// ceux qui ont été définis explicitement étant du SNMP V3
// via la GUI de saisie
SNMPV3Destination destV3=SNMPV3Destination(snmpV3List.get(i));
destV3.setMethodName("secureV3OnArrival");
// on change le nom de la méthode de la destination V3, qui est
// par defaut : snmpV3OnArrival
// c’est ici que l’on détermine le nom de la méthode qui
// devra être appelée à "l’arrivée" sur chaque élément
myItinerary.add(destV3);
}
}
}
}
Fig. 6.14 – Un exemple d’un ItineraryManager pour des destinations du type
SNMP V3
entre les services principaux de notre plate-forme pour que nos agents mobiles
puissent s’authentifier et récupérer des informations confidentielles. Pour ce faire,
on introduit un service supplémentaire, le service de sécurité, que l’on suppose
être infaillible.
Le processus de mise à disposition des clefs privées est le suivant : le service de
sécurité est lancé avec la connaissance de la clef privée, afin de pouvoir authentifier
les agents mobiles qui souhaitent avoir les informations confidentielles sur les accès
sécurisés en SNMP V3. Chaque agent mobile qui serait créé depuis la station
d’administration et qui doit assurer des communications sécurisées en SNMP
V3, se voit associer à sa création la clef privée qui lui est fourni par la station
d’administration (elle même supposée totalement sécurisée). A chacun de ses
déplacements, c’est-à-dire pendant le suivi d’un itinéraire, si un agent mobile a
besoin de converser en utilisant le protocole SNMP V3, alors il utilisera sa clef
privée pour contacter le service de sécurité. L’agent mobile obtiendra alors les
informations confidentielles qui permettront la connexion avec l’agent SNMP V3
de l’équipement actif. Ainsi, à chaque accès sur un équipement actif compatible
avec le protocole SNMP V3, la séquence suivante se déroule :
– l’agent mobile muni de sa clef privée contacte le service de sécurité et s’authentifie,
– le service de sécurité retourne à l’agent mobile authentifié, les informations
SNMP V3 nécessaires à l’établissement de la session sécurisée vers l’agent
SNMP.
Par cette méthode, si un agent mobile est capturé pendant le suivi de son itinéraire
(et si bien sûr l’agent est crypté à chaque migration afin que l’on ne puisse pas
Extensibilité du modèle de développement
Clef privee
Manager
Trap Daemon
145
Clef privee
Service de Securite
Agent Mobile
Clef privee
Transmission de la clef privee
Echange des informations securisees en SNMP v3
Fig. 6.15 – Principe de sécurisation
découvrir sa clef privée), il devient impossible d’accéder aux agents SNMP V3.
Ainsi la sécurité du réseau, et principalement sa configuration, est garantie.
Dans le cas où une alerte est capturée par le service de gestion des traps SNMP,
et que la réaction consiste à déclencher un agent mobile, il faut que l’agent mobile
puisse obtenir les informations concernant les équipements actifs dont les accès
sont sécurisés. Pour cela, le service de gestion des traps SNMP est lancé en portant
à sa connaissance la clef privée permettant l’authentification des agents mobiles
auprès du service de sécurité. Lorsque qu’une alerte est capturée, l’agent mobile
sera lancé avec cette clef privée afin de pouvoir s’authentifier, comme dans le cas
où il est lancé à partir de la station d’administration.
En résumé, puisque dans un itinéraire une Destination SNMP V3 peut être
incorporée, il s’agit dès lors pour l’agent mobile d’établir une connexion sécurisée
vers l’équipement actif. Pour réaliser cela, l’agent mobile contactera le service de
sécurité pour obtenir les informations nécessaires et établira ensuite la connexion
avec l’équipement actif.
6.4.3
Exemple : fabrication d’un nouveau type d’itinéraire
parallèle
On va illustrer ici le fait qu’on est capable d’initier la création d’agents mobiles ayant leur propre itinéraire lors de l’exécution de méthode associée à une
Destination indiquée dans l’itinéraire d’un autre agent mobile. Ceci servira donc
d’exemple à l’utilisation de deux types possibles de Destination que l’on peut décider de rajouter par extension : CloneDestination et RendezVousDestination.
L’exemple consistera à administrer tous les systèmes et les éléments du réseau,
146
Programmation d’agents mobiles pour l’administration système et réseau
de tous les sous-réseaux, en parallèle. L’agent principal aura aussi en charge
d’administrer les éléments de son propre sous-réseau.
L’AgentClone (AC, cf. code 6.20) qui joue le rôle de l’agent principal démarre
avec un ItineraryManagerParalleleWholeNetwork (IMPWN, cf. code 6.16).
La préparation de l’itinéraire consiste à :
public class ItineraryManagerParallelWholeNetwork extends ItineraryManager
implements java.io.Serializable{
/** Constructor */
public ItineraryManagerParallelWholeNetwork() {
super(); }
public void prepareItinerary() {
prepareItinerary((ItineraryServer)null);
}
public void prepareItinerary(ItineraryServer iServer) {
RendezVousDestination rdvDestination;
try {
if (iServer == null) {
iServer=getLocalItineraryServer();
}
// obj contains a reference onto the local Itinerary Server
ArrayList proActiveNodes = iServer.getProActiveNode();
ArrayList snmpList = new ArrayList(iServer.getSNMPElements());
if (proActiveNodes.isEmpty()) return; // nothing to do, may be an error
createMigrationStrategyManager();
// prepare rendez-vous
int lastIndex =proActiveNodes.size() -1;
rdvDestination = new RendezVousDestination((Destination)proActiveNodes.get(lastIndex));
rdvDestination.setMasterAgent((Agent)ProActive.getStubOnThis());
// to synchronize secondary agents
NodeDestination nd =
new NodeDestination(NodeFactory.getDefaultNode().getNodeInformation().getURL(),"");
// A clone destination on current Node, and give it
// the list of others ItineraryServers
CloneDestination cDestination =
new CloneDestination(nd,othersItineraryServer,rdvDestination);
myItinerary.add(cDestination);
for (int i=0;i<proActiveNodes.size() ;i++) {
NodeDestination nd =(NodeDestination)proActiveNodes.get(i)
myItinerary.add(nd);
int currentPos = snmpList.indexOf(nd.getDestination().getHostName());
if (currentPos >=0) // add SNMPDestination for same Host
myItinerary.add(snmpList.remove(currentPos));
}
// add others SNMPDestination, host without a Node
for (int i=0;i<snmpList.size();i++)
myItinerary.add(snmpList.get(i));
// add RendezVous at end of current Itinerary byt modified method named
rdvDestination.setMethodName("rendezVousMaster"); // for master agent only
myItinerary.add(rdvDestination);
} catch (Exception e) {e.printStackTrace();
}
}
}
Fig. 6.16 – Classe de l’ItineraryManagerParalleleWholeNetwork
– contacter l’ItineraryServer (IS) local afin de récupérer la liste des nœuds
ProActive.
Extensibilité du modèle de développement
147
– créer une CloneDestination (CD, cf. code 6.17) pour que l’AC, à son
arrivée sur une telle destination, se mette à préparer le nombre d’agents
mobiles secondaires nécessaire.
– faire en sorte que le premier élément de l’itinéraire de l’AC soit une CloneDestination et les suivants les NodeDestinations obtenus via l’ItineraryServer local.
– fixer la dernière destination (RendezVousDestination, cf. code figure 6.18)
comme celle qui permettra de se synchroniser avec tous les agents secondaires. La méthode appelée pour l’AC sera rendezVousMaster qui permet
de suspendre le suivi de l’itinéraire en vue de se synchroniser avec les agents
secondaires.
public class CloneDestination implements java.io.Serializable,
org.objectweb.proactive.ext.migration.Destination{
private String host, methodName = "cloneOnArrival";
private Destination dest=null;
private int numberOfAgents=0; // Number of agents to duplicate
private DestinationList lastItinerary;
RendezVousDestination rdvDestination;
public CloneDestination(Destination dest, DestinationList lastItinerary) {
this.dest=dest;
this.numberOfAgents=lastItinerary.size();
this.lastItinerary=lastItinerary;
}
public CloneDestination(Destination dest, DestinationList lastItinerary,
RendezVousDestination rdvDestination) {
this.dest=dest;
if (lastItinerary!= null) this.numberOfAgents=lastItinerary.size();
else this.numberOfAgents=-1;;
this.lastItinerary=lastItinerary;
this.rdvDestination = rdvDestination;
}
// return the next part of current itinerary, to be use by clone agents
public DestinationList getLastItinerary() {
return lastItinerary;
}
// return RendezVous Destination
public RendezVousDestination getRendezVousDestination() {
return rdvDestination;
}
// number of agents to wait if necessary
public int getNumberOfAgent() { return numberOfAgents;
}
/** Return method name to execute */
public String getMethodName() {
return methodName;
}
public Destination getCloneDestination() {
return dest;
}
}
Fig. 6.17 – Classe de la CloneDestination
Sur appel de la méthode cloneOnArrival liée à la destination de type Clone-
148
Programmation d’agents mobiles pour l’administration système et réseau
Destination les actions suivantes sont exécutées :
– On récupère la RendezVousDestination (qui est en fait aussi stockée dans
la CloneDestination)
– On récupère le nombre d’ItineraryServers, ce qui donne le nombre d’instances d’AgentGeneric (AG, cf.code 6.19) qui doivent être créés.
– Pour chaque élément de la liste (liste des ItineraryServers)
– le master agent (AC) créé un AG avec un ItineraryManagerLocalNetwork (pour administrer tous ses éléments, nœuds ProActive et agents
SNMP).
– On fixe la dernière Destination comme étant de type RendezVousDestination et on demande la préparation de l’itinéraire via l’ItineraryServer correspondant. On a fait en sorte que dans cette RendezVousDestination on ait une référence vers l’agent principal (ici l’AC)
afin que les agents secondaires puissent le contacter. Cette RendezVousDestination permettra l’appel de la méthode rendezVousPoint pour
les agents secondaires.
– L’AG démarre son itinéraire. Sa dernière Destination sera donc la RendezVousDestination.
– Fin de Pour....
Dès que les AGs arrivent sur leur RendezVousDestination, ils se synchronisent avec l’AC par l’appel de la méthode rendezVousPoint() associée à cette
destination, méthode qui est définie dans le corps de l’AC. Cette méthode décompte le nombre d’AG fils qui l’ont appelée au moment de ce rendez-vous.
Chaque AgentGeneric appelle la méthode collectData de l’AC pour transmettre les données collectées.
6.5
Bilan
Dans ce chapitre nous avons présenté la mise en œuvre de notre système
de gestion d’itinéraire, basé sur la classe ItineraryManager. Ce gestionnaire
d’itinéraire se charge de récupérer les informations mises à disposition par un ou
plusieurs ItineraryServers, qui sont quant à eux localisés sur différents sousréseaux du réseau à administrer. Avec ces informations, nous avons pu construire
différents types d’itinéraires adaptés à des opérations d’administration :
– pour le sous-réseau, comprenant les équipements actifs et les nœuds ProActive
– pour l’ensemble du réseau, c’est-à-dire l’union des itinéraires possibles par
sous-réseau
– par type de service fourni par les éléments du réseau, comme par exemple
un itinéraire pour toutes les imprimantes
Nous avons aussi défini le cadre de programmation des agents mobiles dans le
contexte de l’administration système et réseau en définissant une classe générique
Bilan
149
public class RendezVousDestination implements java.io.Serializable,
org.objectweb.proactive.ext.migration.Destination {
private String host;
private String methodName = "rendezVousPoint";
private Destination lastDestination;
private Agent masterAgent;
public RendezVousDestination(Destination lastDestination) {
this.lastDestination=lastDestination;
methodName=lastDestination.getMethodName();
}
public String toString() {
return " rendezvous point "+lastDestination.getDestination());
}
public void setMasterAgent(Agent masterAgent) {
this.masterAgent=masterAgent;
}
public Agent getMasterAgent() {
return masterAgent;
}
/**Return the snmp method to execute */
public String getMethodName() {
return lastDestination.getMethodName();
}
/**
Return current destination as a string */
public String getDestination() {
return lastDestination.getDestination();
}
// get rendezvous Destination
public Destination getRendezVous() { return lastDestination;}
// set a rendezvous
public void setRendezVous(Destination lastDestination) {
this.lastDestination=lastDestination;
}
}
Fig. 6.18 – Classe de la RendezVousDestination
Agent comprenant toutes les fonctionnalités liées à la construction de l’itinéraire,
à son suivi ainsi que les appels de méthodes permettant d’effectuer une opération
d’administration selon le type d’élément (basé sur la hiérarchie des Destinations
que nous avons construite).
En respectant la méthodologie prônée par notre cadre de développement, nous
avons mis en évidence la simplicité de son extension, qui passe par la création de
nouveaux types de destinations, de nouveaux types d’itinéraires.
Le chapitre suivant présente les évaluations que nous avons réalisées sur notre
plate-forme en utilisant notre modèle de programmation.
150
Programmation d’agents mobiles pour l’administration système et réseau
public class AgentGeneric extends Agent implements
ArrayList nodeRessource = new ArrayList();
ArrayList AllArplTable = new ArrayList();
java.io.Serializable {
public AgentGeneric() {
super();
}
public void setItineraryManager(ItineraryManager itineraryManager) {
this.itineraryManager=itineraryManager;
}
public void onArrival() {
super.onArrival();
SystemResources sr = new SystemResources();
nodeRessource.add(nodeDest);
nodeRessource.add(sr.getSystemOS());
// Gets TOTAL MEM, USED MEM, FREE MEM into a String
nodeRessource.add(sr.toString());
}
public void snmpOnArrival() { // overrides Agent.snmpOnArrival
super.snmpOnArrival();
// gets the SNMP MIB Table ip.ipNetToMediaTable
AllArplTable.addAll(new IpMacTable(snmpDest).getArpTable());
}
public void rendezVousPoint() {
RendezVousDestination rvDestination =
(RendezVousDestination)itiManager.getCurrentDestination();
((AgentClone)rvDestination.getMasterAgent()).rendezVousPoint();
((AgentClone)rvDestination.getMasterAgent()).collectData(nodeRessource);
((AgentClone)rvDestination.getMasterAgent()).collectData(AllArplTable);
}
public void displayData() {
System.out.println("Data collected : "+nodeRessource);
}
}
Fig. 6.19 – Classe abstraite de l’AgentGeneric - agent secondaire
Bilan
151
public class AgentClone extends Agent implements java.io.Serializable {
ArrayList nodeRessource = new ArrayList();
ArrayList AllArplTable = new ArrayList();
ArrayList listAgentsData = new ArrayList();
private int nbAgentToWait=0;
public AgentClone() {
super();
}
// master agent suspend it’s own itinerary
public void rendezVousMaster() {
try { getItineraryManager().suspendItinerary();
} catch (Exception e) {}
}
// method for RendezVousDestination
public void rendezVousPoint() {
System.out.println("MASTER AGENT: A child agent is calling me");
if (nbAgentToWait >0) {
nbAgentToWait--;
}
try {
if (nbAgentToWait == 0) {
System.out.println("Master agent can go to the next Destination");
getItineraryManager().resumeItinerary();
}
} catch (Exception e) {e.printStackTrace();}
}
// method called by sub Agents
public void collectData(ArrayList listOfData) {
listAgentsData.addAll(listOfData);
}
public void cloneOnArrival() {
CloneDestination cloneDest =
((CloneDestination)itiManager.getCurrentDestination());
RendezVousDestination rdvDestination=cloneDest.getRendezVousDestination();
DestinationList allItineraryServer = cloneDest.getRestOfTheItinerary();
int nbItineraryServer = allItineraryServer.size();
nbAgentToWait=nbItineraryServer;
try {
if (nbItineraryServer > 0) {
// create one agent per nodes
for (int i=0;i<nbItineraryServer;i++) {
AgentGeneric mobileAgent =
(AgentGeneric)ProActive.newActive("AgentGeneric", null);
ItineraryServer iServer = (ItineraryServer) allItineraryServer.next();
mobileAgent.setItineraryManager(new ItineraryManagerLocalNetwork());
// nodes and SNMP
mobileAgent.setLastDestination(rdvDestination);
mobileAgent.getItineraryManager().prepareItinerary(iServer);
mobileAgent.startItinerary();
}
}
} catch (Exception e) {e.printStackTrace(); }
}
public void onArrival() {
super.onArrival();
SystemResources sr = new SystemResources();
nodeRessource.add(nodeDest);
nodeRessource.add(sr.getSystemOS());
// Gets TOTAL MEM, USED MEM, FREE MEM into a String
nodeRessource.add(sr.toString());
}
public void snmpOnArrival() {
super.snmpOnArrival();
// gets the SNMP MIB Table ip.ipNetToMediaTable
AllArplTable.addAll(new IpMacTable(snmpDest).getArpTable());
}
public void displayData() {
System.out.println("Data collected : "+listAgentsData);
}
}
Fig. 6.20 – Classe de l’AgentClone
- agent principal
152
Programmation d’agents mobiles pour l’administration système et réseau
Chapitre 7
Performances et évaluation des
agents mobiles pour
l’administration système et
réseau
7.1
Introduction
De manière récurrente l’utilisation des agents mobiles pour l’administration
système et réseau donne les performances comme critère de préférence des agents
mobiles face au modèle Client/Serveur SNMP. En effet, cela se traduit par une
consommation de débit réseau moindre ([85],[101]). L’intérêt de ce chapitre est de
conforter cette idée, dans le cadre de notre plate-forme. Nous allons montrer que,
en ayant automatisé la création et le suivi d’itinéraires dynamiques, certaines opérations de gestion et d’administration ne requiérant pas de délai d’exécution sont
utilement réalisables par des agents mobiles. Par contre, nous montrerons aussi
que des contraintes subsistent quant à l’utilisation des agents mobiles pour l’administration notamment dans le cadre des réseaux sans fils (WLAN). Ce n’est pas
l’évaluation du temps de création d’un itinéraire dynamique que nous cherchons
à évaluer finement dans ce chapitre, car nous avons pu constater que lorsque la
topologie du ou des réseaux est connue, ce temps de création de l’itinéraire varie toujours de quelques millisecondes à une seconde. Par ailleurs, le temps de
construction de la topologie est lui même déjà évalué dans la section 5.5.5.
Par contre, il s’agit dans ce chapitre d’également valider l’exploitation de notre
plate-forme dans un contexte réel, requiérant des opérations d’administration.
A cette fin, quelques performances où le débit du réseau et où le nombre
d’hôtes varient vont être décrites et évaluées. On cherche à démontrer qu’il existe
un seuil à partir duquel il devient plus intéressant d’envoyer un agent mobile
pour réaliser la même fonction d’administration, car transmettre chaque variable
153
154Performances et évaluation des agents mobiles pour l’administration système et réseau
SNMP individuellement en Client/Serveur vers la station d’administration n’est
pas rentable (en terme uniquement de performances). Il s’agit aussi de mettre
en évidence le fait que le choix du Client/Serveur SNMP ou des agents mobiles
n’est finalement pas qu’une question de performances, mais que ce choix dépend
en fait foncièrement du type de fonction d’administration à réaliser, ou du type
d’environnement physique (ce dernier pouvant quand même avoir une incidence
sur des performances du réseau sous-jacent).
7.2
Analyse des performances
On suppose, dans l’évaluation de nos performances, que la plate-forme est
déjà déployée sur tous les éléments intervenant dans la phase de test.
7.2.1
Expériences sur un réseau local
Nous avons cherché à évaluer, dans cette section, le temps d’exécution d’une
opération d’administration à partir d’une station d’administration connectée sur
un réseau distant.
7.2.1.1
Descriptif du réseau de test
Pour notre jeu de tests on se base sur deux réseaux (cf. figure 7.1). Sur le
réseau A, la station d’administration (Yaté)et sur le réseau B, 11 ordinateurs de
différentes puissances et capacités, dont la machine Bourail. Ces machines sont
des PCs (fonctionnant sous Win95, Linux, WinNT, Win2K, WinNt Terminal
Server) et des imprimantes en réseau (HP 4100 et HP 2100) avec un agent SNMP
actif. Toutes ces machines seront la cible d’une opération d’administration.
Pour faire varier le débit du lien inter-réseau, nous avons utilisé un Pentium à
133Mhz (Bourail) fonctionnant sous FreeBSD avec ip_dummynet [74] (cf. figure
7.1) 1 . Par ce biais, nous pouvons simuler le changement du débit du lien interréseau de 100Kbps à 10Mbps. La bande passante de chaque sous-réseau (A et B)
est de 100Mbps.
7.2.1.2
Itinéraire d’administration
L’itinéraire des agents mobiles consiste à effectuer une migration au départ
pour aller de la machine Yaté vers la machine Koumac, une opération SNMP
depuis Koumac vers chacun des éléments du réseau B, et une migration à chaque
fin de l’itinéraire pour retourner sur le nœud ProActive de la machine Yaté afin
de rapatrier les résultats de l’évaluation. L’itinéraire Client/Serveur consiste à
1
Ce PC routeur héberge un agent SNMP actif du côté du réseau B donc nous le considérons
comme un hôte administrable du réseau B
Analyse des performances
155
Chemin de migration
(Yate)
Trafic SNMP
Reseau A (100 Mbps)
PC Routeur (Bourail)
Reseau B (100 Mbps)
CiscoSystems
Cisco 7000
Routeur
(Koumac)
5 serveurs
(WinNT)
SERIES
Imprimante
reseau
Win95 +
Agent SNMP
Fig. 7.1 – Schéma du réseau d’évaluation avec un débit modifiable sur le lien
inter-réseau (via la machine bourail)
effectuer toutes les opérations SNMP depuis la machine Yaté vers chacun des
éléments du réseau B. Dans les deux cas, pour simuler un réseau d’une taille
plus importante, nous réitérons plusieurs fois la visite de chacun des éléments du
réseau B (comme si sur le réseau B, il n’y avait pas 9 éléments mais bien plus).
7.2.1.3
Les opérations d’administration mises en œuvre
Pour évaluer les performances, nous avons mis en œuvre trois fonctions d’administration distinctes dans le but de faire varier le nombre de requêtes SNMP à
l’intention de chaque agent SNMP. Nous avons utilisé la collecte du groupe System, de la table IpRouteTable et pour finir de la table IpNetToMediaTable, plus
communément connue sous le nom de table ARP. Toutes les requêtes qui sont
réalisées dans les jeux de test sont effectuées en mode séquentiel afin d’obtenir
des écarts voulus dans les résultats.
L’objectif de cette évaluation est de pouvoir analyser le temps d’exécution
des différentes méthodes en comparant la solution traditionnelle Client/Serveur
et les agents mobiles pour l’administration. Nous faisons donc varier le débit interréseau géré par la machine Bourail afin de simuler des connexions distantes. Nous
n’engendrons pas de perte de paquets, même si l’outil utilisé, ip_dummynet, le
permet. En même temps, nous augmentons artificiellement le nombre d’hôtes
pour essayer de tirer des conclusions permettant de donner la préférence à la
solution Client/Serveur ou agent mobile selon les cas et les configurations de
réseau testés.
156Performances et évaluation des agents mobiles pour l’administration système et réseau
Groupe System : La collecte des variables SNMP du groupe System (taille
des paquets en moyenne pour cette fonction est de 42 octets 2 ) sur un réseau
ayant un lien faible débit, variant de 100Kbps à 200Kbps (cf. figure 7.2), permet
de mettre en évidence que sur un nombre important d’agents SNMP le temps
d’exécution total de l’opération d’administration en utilisant un agent mobile
est meilleure. Alors que pour une quinzaine d’hôtes sur lesquels l’information
est collectée, le temps d’exécution est comparativement le même, un écart sans
cesse croissant apparaît au delà. On constate en fait, que la faible valeur du débit
(de 100Kbps à 200Kbps) ne perturbe pas l’agent mobile puisque celui exécute la
fonction d’administration en un temps total quasi similaire, alors même qu’il doit
revenir à la station d’administration en transportant les données collectées.
System
12000
Temps (en Millisecs)
10000
Client/Server (100Kbps)
Client/Server (200Kbps)
Agent Mobile (100Kbps)
Agent Mobile (200Kbps)
8000
6000
4000
2000
0
0
10
20
30
Hotes
40
50
60
Fig. 7.2 – Collecte du groupe System (100Kbps-200Kbps)
Le même comportement est obtenu en augmentant le débit inter-réseau (de
1Mbps à 5Mbps) (figure 7.3). En conclusion de ces 4 configurations de test, dans
lesquels le débit inter-réseau est bien moindre que le débit de chaque réseau, la
technologie à agent mobile permet de tirer partie des débits réseau (100Mbps,
bien mieux que le modèle Client/Serveur qui subit la lenteur du lien inter-réseau
pour chaque lecture de variables SNMP.
Groupe IP-ipRouteTable : Afin d’expérimenter la collecte d’un nombre de
variables SNMP non défini statiquement, nous avons collecté sur chaque agent
2
uniquement pour la partie protocolaire SNMP
Analyse des performances
157
System
10000
Temps (en Millisecs)
8000
Client/Server (1Mbps)
Agent Mobile (5Mbps)
Client/Server (5Mbps)
Agent Mobile (1Mbps)
6000
4000
2000
0
0
10
20
30
Hotes
40
50
60
Fig. 7.3 – Collecte du groupe System (1Mbps-5Mbps)
SNMP la table de routage (taille des paquets en moyenne pour cette fonction
est de 298 octets 3 ). Le nombre minimal de variables qui sont collectées est
de 6 (ipRouteDest, ipRouteIfIndex, ipRouteNextHop, ipRouteType, ipRouteProto,
ipRouteMask ) (, mais comme il s’agit d’une table et que plusieurs entrées dans
celle-ci peuvent exister, il est impossible de déterminer à l’avance le nombre de
variables collectées. Cette expérience est mise en œuvre sur les mêmes configurations de test que précédemment (cf. figure 7.4 et figure 7.5).
Par la quantité de variables collectées depuis la station d’administration, le
modèle Client/Serveur est très pénalisé par le goulot d’étranglement induit par
le faible débit du lien inter-réseau. Une nette différence se ressent par rapport à
l’agent mobile qui lui, comme dans l’expérience précédente, tire un grand avantage
du débit du réseau B à 100Mbps.
Groupe IP-ipNetToMediaTable : Il s’agit, ici aussi, de collecter un nombre
important et non statiquement défini de variables SNMP et ce en allant lire les
tables ARP des agents SNMP, tables qui contiennent en général plus de lignes que
celles des tables de routage (taille des paquets en moyenne pour cette fonction
est de 128 octets 4 ). Il s’agit donc d’augmenter la quantité d’information que doit
transporter l’agent mobile. Les variables que nous collectons sur chaque agent
3
4
uniquement pour la partie protocolaire SNMP
uniquement pour la partie protocolaire SNMP
158Performances et évaluation des agents mobiles pour l’administration système et réseau
ip.ipRouteTable
200000
Temps (en Millisecs)
150000
Client/Server (100Kbps)
Client/Server (200Kbps)
Agent Mobile (100Kbps)
Agent Mobile (200Kbps)
100000
50000
0
0
10
20
30
Hotes
40
50
60
Fig. 7.4 – Collecte de la table de Routage (100Kbps-200Kbps)
ip.ipRouteTable
140000
Client/Server (1Mbps)
Agent Mobile (5Mbps)
Client/Server (5Mbps)
Agent Mobile (1Mbps)
Temps (en Millisecs)
120000
100000
80000
60000
40000
20000
0
0
10
20
30
Hotes
40
50
60
Fig. 7.5 – Collecte de la table de Routage (1Mbps-5Mbps)
SNMP sont dans la table ipNetToMediaTable ( ipNetToMediaIfIndex, ipNetToMediaPhysAddress, ipNetToMediaNetAddress, ipNetToMediaNetType).
Analyse des performances
159
ip.ipNetToMediaTable
30000
Temps (en Millisecs)
25000
Client/Server (100Kbps)
Client/Server (200Kbps)
Agent Mobile (100Kbps)
Agent Mobile (200Kbps)
20000
15000
10000
5000
0
0
10
20
30
Hotes
40
50
60
Fig. 7.6 – Collecte de la table ARP (100Kbps-200Kbps)
Les résultats obtenus et présentés dans le paragraphe précédent sont confortés
lors de cette évaluation (figure 7.6 et 7.7). Plus l’information globale à collecter,
à distance, est importante plus la technique à agent mobile devient avantageuse.
Comparatif des fonctions : Pour obtenir une vue plus exhaustive de l’ensemble de nos évaluations, nous regroupons les performances des fonctions d’administration collectant le groupe System et la table ARP (ipNetToMediaTable)
et ce pour les différentes configurations où le débit du lien inter-réseau varie entre
10Kbps et 1Mbps (cf. figure 7.8). En considérant 12 éléments visités (avec agent
SNMP), les meilleures performances sont celles obtenues par l’agent mobile qui
effectue dans des délais plus courts les mêmes opérations que celles effectuées avec
le modèle Client/Serveur traditionnel. On peut constater toutefois, sur la figure
7.8, que pour un nombre limité de variables SNMP (groupe System) à collecter et
que pour un nombre d’éléments faible (ici 12 éléments), les deux solutions (agent
mobile et Client/Serveur) sont presque identiques5 . Un gain de temps substantiel
est obtenu pour la fonction collectant la table ARP de chaque agent SNMP visité.
En conclusion, le modèle à agent mobile est très adapté pour effectuer des
5
Certains fléchissements des courbes que nous avons obtenues sont le fait d’une expérimentation réalisée sur un réseau de production (réseau B). Nous avons choisi ce type d’expérimentation
car celle-ci reflète une situation réaliste.
160Performances et évaluation des agents mobiles pour l’administration système et réseau
ip.ipNetToMediaTable
30000
Temps (en Millisecs)
25000
Client/Server (1Mbps)
Agent Mobile (5Mbps)
Client/Server (5Mbps)
Agent Mobile (1Mbps)
20000
15000
10000
5000
0
0
10
20
30
Hotes
40
50
60
Fig. 7.7 – Collecte de la table ARP (1Mbps-5Mbps)
12 agents SNMP
10000
Temps (en Millisecs)
8000
6000
Agent Mobile (System)
Client/Server (System)
Agent Mobile (ARP)
Client/Server (ARP)
4000
2000
0
100
200
300
400
500
600
700
800
Bande passante sur Bourail (Kbit/s)
900
1000
Fig. 7.8 – Comparatif des fonctions par débits
tâches de longue durée sur des réseaux distants, limitant ainsi l’utilisation de la
bande passante inter-réseau. L’approche que nous avons utilisée dans ces expéri-
Analyse des performances
161
mentations est une approche de délégation de la tâche d’administration réseau,
qui est caractérisée dans la littérature par le modèle Static Delegated Model [85].
Dans ce modèle, on tire un avantage de la position de l’agent mobile sur le réseau
pour effectuer les opérations d’administration à distance, en lieu et en place de la
station d’administration centralisée du modèle Client/Serveur (caractérisé par le
Static Centralized Model ). Nos expérimentations rejoignent ainsi les expérimentations et les conclusions obtenues par Simões [85].
7.2.2
Expériences sur un réseau WLAN
Nous avons cherché à évaluer le comportement des agents mobiles sur un
réseau de nouvelle génération. Pour cela, nous avons pris en compte les réseaux
de type hertzien et essayé d’obtenir des résultats de performance à comparer
ensuite avec ceux obtenus lors des expérimentations précédentes.
7.2.2.1
Descriptif du réseau de test
Le jeu de tests que nous avons effectué est basé sur un réseau sans fil (technologie Wifi [59]) (cf. figure 7.9). Nous avons mis en œuvre ce test pour mettre en
évidence les avantages et les inconvénients de la technologie des agents mobiles
dans l’utilisation de ce type de réseau.
commutateur 10/100Mbps
Reseau Hertzien
a 11 Mbps
10Mbps
100Mbps
Point d’acces Wifi
PC 1
Serveur HTTP + Linux (SRV)
PC 2
PC de test
PC 3
PC 4
Coeur du reseau
Fig. 7.9 – Schéma de la configuration d’évaluation avec un réseau sans fil
Le serveur sous Linux (SRV, RedHat 8.0) fonctionne sur un Pentium IV,
2.4 GHz, 512 Mo de RAM. Il est connecté au cœur du réseau par un lien à
100Mbps (commutateur Catalyst 2950). Le point d’accès Wifi fonctionne en mode
Infrastructure (cf annexe pour plus de détails) et il est connecté en 10 Mbps sur
ce même commutateur. Ce dernier dessert en mode hertzien à 11Mbps, 4 PCs.
Les PCs (PC1, PC2, PC3 et PC4 dans les libellés des figures ci-dessous) sont
des ordinateurs identiques basés sur des Pentium II cadencés à 300 MHz. Ils
sont équipés de 64 Mo de RAM et ils fonctionnent sous WIN98. Chacun des
162Performances et évaluation des agents mobiles pour l’administration système et réseau
ordinateurs est relié au réseau par un adaptateur PCI Wifi. Un serveur HTTP,
fonctionnant sous Apache, est hébergé par le serveur SRV. Ce service HTTP
met à la disposition de la plate-forme à agents mobiles toutes les classes Java
nécessaires au déploiement du code et des fonctions d’administration pour les
agents mobiles (fonction système ou réseau).
7.2.2.2
Itinéraire d’administration
L’itinéraire de migration des agents mobiles dans le cas des tests présentés
sur le réseau Wifi est le suivant :
– Départ de SRV impliquant une migration vers le PC1 connecté via une
liaison sans fil,
– L’agent mobile migre d’un PC à l’autre jusqu’au dernier pour y effectuer
l’opération d’administration,
– Après son passage sur le dernier PC (PC4), il migre vers SRV pour y effectuer la dernière opération d’administration et terminer son exécution.
L’itinéraire Client/Serveur consiste à effectuer l’opération d’administration sur
tous les éléments du réseau (SRV, PCs) depuis SRV.
7.2.2.3
Les opérations d’administration mises en œuvre
Plusieurs séries de tests ont été réalisées avec la même fonction d’administration (le même code Java), que ce soit pour l’exécution en suivant le modèle
Client/Serveur ou en utilisant un agent mobile. Toutes les requêtes qui sont réalisées dans les jeux de test sont effectuées en mode séquentiel, c’est-à-dire sans
burst, en utilisant le même code de programmation.
– Les premiers tests réalisés sont basés sur le modèle Client/Serveur et servent
de base pour une comparaison ultérieure.
– La deuxième série de tests utilise un agent mobile pour effectuer la fonction
d’administration. On mesure les performances lors du 1er suivi de l’itinéraire défini pour ce réseau par l’agent mobile (les classes Java nécessaires à
l’exécution de l’opération ne sont donc pas chargées).
– La troisième série de tests consiste à évaluer les performances lorsque le
code de l’agent mobile et celui des fonctions d’administration ont déjà été
chargés dans la JVM de chacun des éléments intervenant dans l’itinéraire.
Nous cherchons à mettre en évidence l’intérêt du pré-chargement du code
sur les nœuds de la plate-forme
– La quatrième série de tests permet de mettre en évidence le fait que le poids
de l’agent mobile est pénalisant sur ce type de réseau. On mesure donc les
améliorations possibles suite à la dépose des données transportées pendant
les différentes étapes de migration.
Analyse des performances
163
Groupe IP-ipNetToMediaTable : Notre fonction de collecte de la table
ARP (taille des paquets en moyenne pour cette fonction est de 128 octets 6 )est
tout d’abord exécutée en mode Client/Serveur à partir du serveur SRV. Le résultat de cette expérimentation (figure 7.10) donne un temps de collecte d’environ
4,5 secondes. Sur la même figure, on constate un temps d’exécution de cette
fonction par l’agent mobile dix fois supérieur. Ce temps d’exécution est proportionnel au temps de chargement des classes Java d’administration et de l’agent
mobile sur chacun des nœuds, et au fonctionnement général du réseau Wifi. Des
performances plus intéressantes sont obtenues lorsque les classes Java sont déjà
pré-chargées. Malgré cela, le temps d’exécution reste deux fois plus important
que le modèle Client/Serveur.
Migration d’un AM sur un reseau sans fil
60000
50000
Migration + Execution SNMP en local
Migration code charge+ Execution SNMP en local
C/S SNMP depuis le serveur
Temps (en Millisecs)
40000
30000
20000
10000
0
PC 1
PC 2
PC 3
PC 4
Nombre d’hotes visites
SRV
Fin Execution
Fig. 7.10 – Interrogation des agents SNMP en Client/Serveur et avec agent
mobile
Retour à la station d’administration : Dans ce jeu de test, l’ensemble des
PCs à administrer est le même que précédemment, mais après chaque visite d’un
PC, l’agent mobile revient sur la station de départ (SRV) pour déposer et traiter
les données (cf. figure 7.11). Il est évident que ce type d’itinéraire (en "étoile")
n’est pas réaliste sur ce type de réseau à faible débit, à cause du coût engendré
par de nombreuses migrations.
Toutefois, un modèle d’administration plus pertinent consiste à utiliser des
agents stationnaires sur chaque nœud du réseau Wifi et les interroger à distance, par exemple, à partir du serveur d’administration. Ces agents stationnaires
peuvent être simplement créés à partir d’un agent mobile d’administration et déployés sur chacun des nœuds du réseau. Dans une telle configuration, le réseau
6
uniquement pour la partie protocolaire SNMP
164Performances et évaluation des agents mobiles pour l’administration système et réseau
Requete SNMP C/S, Agent Mobile : Execution depuis le Serveur Linux
30000
Temps (en Millisecs)
25000
Execution par AM
Execution en CS
20000
15000
10000
5000
0
PC 1
SRV
PC 2
SRV
PC 3
SRV
Hotes visites
PC 4
SRV
Fin
Fig. 7.11 – Retour systématique à la station de départ
ne sert que pour la collecte des données que chaque agent stationnaire a préparé
pour l’agent d’administration maître localisé sur la station d’administration.
Requete SNMP C/S, Agent Mobile : 1 serveur, 4 PC connectes sur un reseau sans fil
600000
Temps (en Millisecs)
500000
Execution globale C/S
Execution globale avec migration + vidage 10 passages
Execution globale avec migration + vidage 5 passages
Execution globale avec migration sans vidage
400000
300000
200000
100000
0
0
20
40
60
80
Requetes
Fig. 7.12 – Estimation du vidage de l’agent mobile
100
Exemples d’utilisation des agents mobiles
165
Optimisation : Constatant que faire migrer un agent mobile sur un tel réseau
est très pénalisant, d’autant plus si la taille de l’agent mobile est importante, on
a pensé qu’il serait judicieux d’intercaler dans l’itinéraire d’administration le fait
d’aller de temps en temps seulement, sur un nœud (SRV) dans le but d’y déposer
ses données pour "maigrir". On a mesuré les gains obtenus, en variant la fréquence
de dépôt (cf. figure 7.12). Malgré les migrations supplémentaires imposées pour
aller "maigrir" à des emplacements prévus, on constate qu’il y a un gain réel.
7.2.2.4
Itinéraire de migration en mode ad hoc
Il existe une contrainte de localisation des nœuds dans un réseau Wifi en mode
ad hoc (cf. annexe Wifi). Un nœud n’a pas forcément la visibilité de tous les autres
nœuds, ce qui nécessite d’avoir dans notre cas des itinéraires d’administration qui
doivent être modifiés à la volée (cf. figure 7.13).
Par exemple, prenons l’itinéraire de migration que nous avons utilisé lors de
nos expérimentations. SRV→PC1, P1→PC2, PC2→PC3, PC3→PC4 et PC4→SRV.
Si dans le réseau Wifi en mode ad hoc, les zones de couvertures hertziennes sont
les suivantes :
– PC1 et PC3 sont en zone de couverture
– PC3 et PC2 sont en zone de couverture
– PC2 et PC3 sont en zone de couverture
– Le point d’accès est visible par PC1 et PC4
Cela veut dire que PC1 n’est pas visible de PC2 et vice versa, et que le
système Wifi transmette donc les données via un nœud intermédiaire (par exemple
PC3). Pour éviter de passer par des nœuds intermédiaires ce qui augmente le
délai d’exécution, on peut par exemple préparer un itinéraire d’administration
dans lequel toute paire d’éléments successifs est formée d’éléments directement
accessibles. Par exemple : SRV→PC1, PC1→PC3, PC3→PC2, PC2→PC4 et
pour finir PC4→SRV.
Une telle idée a été proposée par Migas [55] en utilisant des agents stationnaires pour essayer de déterminer la politique de migration la plus adaptée pour
les agents mobiles dans un réseau Wifi de type ad hoc.
7.3
7.3.1
Exemples d’utilisation des agents mobiles
Quelques exemples simples exploitant la propriété
d’autonomie
En constatant que les réseaux actuels offrent de plus en plus de bande passante (LAN, WAN, WLAN), nous allons introduire des exemples concrets d’utilisation des agents mobiles dans un cadre d’administration système et réseau.
Ces exemples permettent de justifier le choix de la technologie à agent mobile en
166Performances et évaluation des agents mobiles pour l’administration système et réseau
commutateur 10/100Mbps
10Mbps
100Mbps
PC 1
PC 3
Point d’acces Wifi
PC 4
PC 2
Serveur HTTP + Linux (SRV)
Coeur du reseau
Fig. 7.13 – Schéma d’un réseau Wifi fonctionnant en mode ad hoc
fonction, non pas des performances et du gain en bande passante escompté, mais
en fonction du service rendu. Des critères tels la réactivité, l’autonomie, la prise
en compte de contraintes géographiques sont alors considérés.
Imaginons par exemple, qu’un administrateur veuille effectuer un inventaire
automatique de tous les systèmes connectés au réseau de son entreprise. Pour
cela, on met en œuvre des opérations Java et des requêtes SNMP afin de collecter
le descriptif des systèmes, mais aussi sur chaque hôte (PC, serveur) ayant la MIB
host implanté, toutes les ressources du système. Dans cet exemple, le temps
de réponse n’est pas critique puisque la tâche est une tâche de fond, de longue
haleine. Il s’agit de déployer plusieurs agents mobiles respectant l’architecture
du réseau, c’est-à-dire déployés sur l’ensemble des sites. Avec l’autonomie propre
de chaque agent, lorsque l’opération d’administration est menée à terme, chaque
agent mobile peut ramener à la station d’administration les données collectées
ou alors les transmettre à l’agent responsable de la mise en forme de cellesci. Toutes ces opérations peuvent être effectuées indépendamment de la station
d’administration.
Prenons un autre exemple : un service d’impression sur le réseau s’arrête de
manière inopinée. En urgence, l’administrateur va envoyer un agent mobile dédié
à la supervision de ce service afin de savoir rapidement la cause de cet arrêt. En
même temps, l’agent mobile peut essayer de relancer le service défectueux, ou
de rediriger toutes les impressions bloquées vers un autre service d’impression.
Une solution plus autonome, consiste à utiliser des agents mobiles de supervision qui n’attendraient pas d’ordre direct de l’administrateur pour réagir à toute
modification des services réseaux fournis.
Bilan
7.3.2
167
Exemple : Autoconfiguration des VLANs dans un
réseau
Imaginons un administrateur de réseau qui doit déployer une nouvelle architecture de réseau, bien que notre exemple puisse s’appliquer aisément dans le cas
d’une architecture réseau en exploitation. L’administrateur du réseau prépare les
configurations de base des équipements actifs du réseau, en fonction de ses desiderata : Nom logique, adresse Ip, nom de communauté SNMP V1 en lecture
seule, informations sur la configuration SNMP V3 nécessaire pour les opérations
d’administration, et ce pour chaque commutateur appartenant au cœur du réseau. Il définit aussi des réseaux virtuels (VLANs) afin de contrôler les accès
entre les différents éléments qui seront connectés sur le réseau : PC, serveurs,
imprimantes, dans l’optique de faire des groupes de machines par réseau virtuel.
Pour réaliser cela, l’administrateur doit connaître le lien entre chacune des interfaces sur les commutateurs, les éléments qui doivent y être connectés et le VLAN
dans lequel ces éléments doivent être intégrés. Par défaut, les configurations des
commutateurs associent chaque port au VLAN administratif, qui est le VLAN de
gestion du commutateur. Pour changer cette valeur par défaut, l’administrateur
doit donc, soit se connecter sur le commutateur pour en changer la configuration (en utilisant un client ssh [48], par exemple), soit utiliser pour des raisons
de sécurité et de distance, le protocole SNMP V37 . Dans tous les cas, l’administrateur devra connaître l’adresse IP du commutateur sur lequel il doit effectuer
l’assignation du VLAN sur une interface de ce commutateur.
En nous basant sur l’exemple proposé par la figure 7.14, où le VLAN 180 est
déjà déclaré pour certains éléments, nous allons expliciter comment nous utilisons
un agent mobile pour configurer les VLANs sur les ports des commutateurs.
Ainsi, en utilisant un itinéraire de migration dans le réseau local, ou vers un
réseau local distant, et en fournissant comme information à l’agent mobile : (1)
l’adresse Ethernet de l’élément concerné par l’assignation du VLAN ; (2) le numéro du VLAN pour configurer l’interface du commutateur, l’agent mobile peut
automatiquement configurer l’interface du bon commutateur de manière complètement automatique. En effet, notre algorithme de construction de la topologie
nous permet de détecter automatiquement l’équipement actif sur lequel l’action
de l’agent mobile doit être effectuée.
7.4
Bilan
Par les tests que nous avons mis en œuvre, sur le réseau présenté par la
figure 7.1, nous pouvons constater que la technologie des agents mobiles donne
7
attribut de l’entrée de la MIB : private.cisco.ciscoMgmt.ciscoVlanMembershipMib.ciscoVlanMembershipMIBObjects.
vmMembership.vmMembershipTable.vmMembershipEntry.vmVlan
168Performances et évaluation des agents mobiles pour l’administration système et réseau
Switch 1
Workgroup Switch
CiscoSystems
Catalyst
Switch 2
Switch 3
Workgroup Switch
CiscoSystems
Workgroup Switch
Catalyst
CiscoSystems
Vlan 180
PC 1
Vlan 1
PC 2
Catalyst
Vlan 180
PC 3
Vlan 180
PC 4
Fig. 7.14 – Schéma du réseau pour l’autoconfiguration des VLANs
des avantages en temps d’exécution et que les résultats obtenus ne sont pas trop
dépendants du débit inter-réseau. A contrario, les tests montrent effectivement
que le modèle Client/Serveur exécuté à distance n’est pas adapté à la collecte
d’un nombre important de variables SNMP sur plusieurs agents SNMP. La mise
en œuvre de tâches longues qu’un administrateur souhaite voir exécutées est tout
à fait envisageable en utilisant des agents mobiles, notamment lorsque les éléments
sont situés sur un réseau distant et qu’il est possible de réaliser des opérations sur
des éléments qui n’étaient pas concernés au départ grâce aux itinéraires construits
dynamiquement. Il convient de constater que lorsque les fonctions sont à exécuter
sur le réseau local, les deux techniques (Client/Serveur et agent mobile) sont aussi
bien applicables l’une que l’autre.
Quand on travaille sur un réseau de nouvelle génération (type Wifi), il est
nécessaire de prendre en compte les contraintes qui y sont associées : latence,
faible bande passante, collision, mode de fonctionnement du réseau (infrastructure
ou ad hoc). Ainsi nous avons pu constater par l’évaluation des performances
d’agents mobiles agissant sur un réseau Wifi que des précautions doivent être
prises : il faut alléger l’agent mobile pour une meilleure efficacité ; éviter les allerretour inutiles pendant l’itinéraire, ce qui impose que l’itinéraire d’administration
soit très adapté à ce type de réseau ; l’utilisation d’un agent mobile stationnaire
permet sur ce type de réseau de regrouper et mettre à disposition des informations
d’administration sans pour autant engorger le réseau Wifi.
Pour conclure ce chapitre, nous pensons que les agents mobiles trouvent une
place dans le monde de l’administration système et réseau mais que cette technologie n’est pas adaptée à toutes les fonctions d’administration réseau (par exemple
une fonction de courte durée sur un réseau local). Il est préférable d’utiliser les
agents mobiles pour des tâches "plus longues", réalisables de manière décentralisée
et autonome, et n’imposant pas une urgence particulière.
Chapitre 8
Conclusion
8.1
Bilan, contribution
Nous nous sommes intéressés dans cette thèse à la problématique de l’utilisation des agents mobiles dans un cadre d’administration système et réseau,
en utilisant la bibliothèque ProActive, et au développement d’une plate-forme à
agents mobiles pour l’administration système et réseau.
Nous avons étudié les plates-formes qui relèvent de cette problématique (par
exemple, James, SOMA, Ajanta, etc..) afin de cerner la problématique sur l’automatisation et l’autonomie des agents mobiles. Nous avons constaté que des itinéraires statiques étaient fournis aux agents mobiles ce qui a motivé la définition
d’itinéraires plus dynamiques et mieux adaptés aux opérations d’administration
que les agents mobiles doivent accomplir.
Pour créer des itinéraires dynamiques, la connaissance de la topologie du réseau s’est avérée nécessaire. Il a fallu collecter l’information contenue dans les
équipements actifs du réseau, et déterminer les services que ces éléments fournissent au réseau. L’information collectée permet d’obtenir des listes d’éléments
représentant les équipements actifs et les nœuds ProActive. De même, nous utilisons cette information pour construire une topologie réseau de niveau 2. Cette
information alimente au fur et à mesure des serveurs sur le réseau (ItineraryServers).
En étendant le modèle des Destinations de ProActive, nous avons pu définir les types d’éléments à administrer en fonction des services que ces éléments
mettent à disposition des autres systèmes du réseau : NodeDestination pour
les opérations d’administration de systèmes (impliquant une migration préalable des agents mobiles) et SNMPDestination pour l’administration de réseau
(en Client/Serveur SNMP). L’architecture proposée permet de rajouter d’autres
types de Destinations en fonction des besoins particuliers de l’administrateur.
Pour utiliser, de manière transparente et automatique ces Destinations, nous
avons mis en œuvre un gestionnaire générique d’itinéraire, l’ItineraryManager
169
170
Conclusion
qu’il suffit de spécialiser selon le type d’itinéraire voulu. Ce gestionnaire permet
de construire des itinéraires adaptés aux opérations d’administration, et de les
faire suivre par des agents mobiles d’administration. Nous avons pu, par exemple,
proposer des itinéraires fonctionnant par sous-réseau dans le domaine administré : pour des équipements actifs, pour des systèmes ayant des nœuds ProActive,
et ou toute combinaison des deux. Pour étendre notre solution sur l’ensemble du
réseau, nos itinéraires se construisent à la volée, au moment où l’agent mobile
doit changer de sous-réseau. En se basant sur ce mécanisme d’itinéraires, nous
avons défini un cadre de programmation d’agents mobiles d’administration.
Nous avons pu montrer, par les évaluations de performances que nous avons
réalisées, que l’utilisation des agents mobiles dans un cadre d’administration système et réseau se justifie, mais sous certaines conditions. De manière résumée,
l’utilisation des agents mobiles sur le même sous-réseau que celui où se situe la
station d’administration n’est pas déterminant en terme de performance. En effet, il existe un overhead lié à la plate-forme Java par rapport à des requêtes
SNMP simples (par exemple, collecte de la table ARP). Dès qu’il s’agit d’administrer des éléments sur des sous-réseaux distants reliés par un lien dont le débit
est faible, les performances des agents mobiles sont bien meilleures que celles du
Client/Serveur. Par ailleurs, un certain avantage est obtenu pour des fonctions
d’administration de "longue durée", qui peuvent bénéficier de l’autonomie des
agents mobiles. Pour des fonctions d’administration plus simples, le choix de la
technique (agent mobile ou Client/Serveur) dépend de l’administrateur.
Nous avons de plus, testé les environnements réseaux hertziens (Wifi ) et
constaté que les agents mobiles stationnaires constituent une solution mieux
adaptée que du SNMP Client/Serveur classique. Toutefois, les agents mobiles
peuvent être utilisés dans cet environnement mais leurs itinéraires d’administration doivent être adaptés au mode opératoire du réseau sans fil (cf. annexe 9.3) :
mode infrastructure ou ad hoc.
La souplesse de ProActive et de notre plate-forme d’administration système et
réseau permet d’envisager la mise en œuvre de tous les modes d’administration
répertoriés [85, 54] tels que :
– Migratory Model : un seul agent migre sur l’ensemble des nœuds du
réseau (notre type d’itinéraire est l’ItineraryManagerWholeNetwork)
– Master/Worker Model : le modèle est basé sur une mobilité réduite et une
grande distribution des agents. En effet, la station d’administration déploie
un agent par nœud à superviser et les interroge à la demande. Dans cette
approche en parallèle des tâches d’administration, les performances globales
du système d’administration sont améliorées car toutes les tâches d’administration sont effectuées localement sur les nœuds. (notre type d’itinéraire
adapté est l’ItineraryManagerClone)
– Static Delegated Model, Mobile Distributed Manager :
Administration dans le contexte des applications
171
une hiérarchisation des agents mobiles par domaine, permet à la station
d’administration d’être en contact uniquement avec les agents mobiles maîtres,
qui sont en charge de préparer les données des opérations d’administration.
A leur tour, les agents mobiles maîtres interrogent des agents mobiles secondaires qui effectuent les opérations d’administration, pour collecter les
données recueillies. (notre type d’itinéraire adapté est l’ItineraryManagerLocalNetwork associé à la description du sous-réseau cible)
– Migratory Delegated Model : le modèle est basé sur une répartition
intelligente des agents mobiles sur l’ensemble du domaine à administrer en
utilisant la localisation "de proximité" plutôt que les multiplications des
agents mobiles. En effet, cette approche propose un agent mobile par sousréseau qui supervise tous les nœuds du sous-réseau (notre type d’itinéraire
est l’ItineraryManagerLocalNetwork)
En résumé, nous avons proposé une plate-forme d’administration système et réseau basée sur des agents mobiles qui suivent automatiquement des itinéraires
dynamiques et construits à la volée. Cette plate-forme d’administration système
et réseau offre un cadre évolutif de programmation permettant d’adjoindre facilement de nouvelles fonctionnalités dans la palette de fonctions offerte habituellement à un administrateur.
8.2
Administration dans le contexte des applications
On peut souligner le fait que l’utilisation des agents mobiles dans un cadre
d’administration de systèmes et de réseaux (au sens classique du métier d’administrateur système et réseau) peut s’avérer parfois trop coûteuse en temps
d’installation et de mise en œuvre, surtout pour un administrateur de réseau qui
ne serait pas au fait de la programmation et du déploiement d’applications en
environnement réparti (un cadre d’administration tel celui que nous avons développé constitue bien une application répartie et non triviale à déployer et à
utiliser).
En revanche, une fois une telle difficulté maîtrisée, cette approche permet de
tirer partie de la bonne connaissance du réseau et de fournir des techniques de gestion permettant d’automatiser la supervision d’un vaste ensemble hétérogène de
machines et d’équipements, tel qu’illustré, par exemple, par des grilles de calcul.
Par exemple, obtenir l’état (disponibilité) de tous les nœuds d’une grille de calcul,
peut être entièrement délégué à un ensemble d’agents mobiles qui renseigneraient
soit un ensemble d’administrateurs de la grille, soit des agents de calcul, sur l’état
de la grille. De tels agents jouent alors le rôle de sonde (c’est pour cela qu’on les
rend souvent stationnaires). En considérant qu’un tel système de supervision est
mis à la disposition d’agents de calculs dans un premier temps, le système qui
172
Conclusion
les déploie s’adresse aux agents sondes et cela lui permet ensuite de décider de la
machine d’accueil. Dans un deuxième temps, si les calculs sont mobiles on peut
imaginer les agents qui les exécutent capables de migrer afin de mieux utiliser
les ressources d’autres systèmes. En effet, un problème classique mais réel en réparti, est de décider où exécuter les calculs. Pour cela il faut avoir des moyens
pour connaître la charge des systèmes et des réseaux, le nombre d’agents présents
et le temps CPU qu’ils utilisent [32], le nombre de threads disponibles, etc.., tous
les paramètres utiles à la prise de décision du placement des agents mobiles de
calcul au moment de leur déploiement mais aussi pendant leur cycle de vie.
On voit bien dans cet exemple que les fonctionnalités de supervision (offertes
notamment par NWS [103], un outil incontournable pour la grille) sont offertes
à des couches applicatives (ici, le service de répartition de charge) qui, à l’instar
d’un administrateur humain, ont à prendre des décisions.
De manière orthogonale, la complexité croissante des services et des applications déployés sur les infrastructures réparties justifie la transposition des techniques standard d’administration, des systèmes et des réseaux à ce nouveau
contexte. Un outil comme JMX (voir annexe 9.2) constitue un bel exemple d’outil qui permet de favoriser cette transposition. En effet, JMX permet d’ouvrir
les composants applicatifs au monde de l’administration et notamment, à ses
standards comme SNMP. Supposons un ensemble de composants applicatifs administrables via JMX, il devient nécessaire de concevoir des outils intégrés, donc
des plates-formes d’administration pour superviser ces éléments logiciels (telles
que par exemple James [83] (plate-forme d’administration à agents mobiles, ellemême administrable via JMX), Lira [21], projet OLAN [58], SmartFrog [40]). Les
soucis d’automatisation, de facilité de programmation des fonctions d’administration, de performance, notamment sur des réseaux à faible débit, etc..., nous
semblent à nouveau justifier l’emploi d’agents mobiles dans ces plates-formes.
Nous pensons donc que le travail décrit dans cette thèse trouve son application.
Nous allons essayer à présent d’illustrer cette éventuelle application.
Étant donné une application complexe s’exécutant sur le réseau que l’on désire
administrer, en utilisant des agents mobiles d’administration suivant des itinéraires dynamiques, nous proposons de considérer que les agents vont se déplacer,
non pas sur un groupe d’éléments constituant un réseau, mais sur un groupe de
composants de l’application constituant un groupe de services.
En effet, c’est pertinent de considérer que des applications et des services
peuvent être regroupés par type de service fourni, et ce, même en se plaçant
au niveau réseau. Par exemple, le service d’impression global d’un réseau est
composé du service d’impression de chaque serveur d’impression et de chaque
imprimante quelqu’en soit le type. Ainsi il est possible, en utilisant la technologie
offerte par JMX, d’instrumenter chaque élément du groupe de service et des
applications disponibles. Chaque application peut ainsi devenir administrable par
un protocole tel SNMP en ayant au préalable défini la MIB SNMP associée.
Administration dans le contexte des applications
173
Ensuite, il faut programmer les opérations d’administration de ces services au
sein d’agents mobiles (ProActive), et ce, selon notre cadre de conception. Cela
passe aussi par la définition de nouvelles Destinations qui permettront aux
agents mobiles d’administration d’atteindre, peut être juste virtuellement, les
agents JMX et d’y effectuer les opérations d’administration. A partir de telles
Destinations, on pourra donc prévoir de nouveaux types d’itinéraires adaptés
à ce type d’administration d’applications et les faire suivre à nos agents mobiles
qui feront en sorte que les bonnes méthodes d’administration soient exécutées.
Cette technique appliquée unitairement sur chaque élément logiciel peut être
utilisée à un niveau supérieur dans le sens où l’on voudrait pouvoir administrer
un service indépendamment du nombre d’applications et de composants logiciels
qui mettent en œuvre ce service. Par exemple, on peut considérer un groupe de
services administrables par JMX que l’on aimerait superviser comme un tout,
et ce de façon très simple, à partir d’un navigateur Web ou d’une plate-forme
d’administration réseau standard. Pour cela, on associerait à un tel groupe les
types d’agents mobiles capables d’administrer ces composants et leurs itinéraires.
Ce même groupe de services serait à son tour rendu administrable à distance, soit
en utilisant le protocole HTTP soit le protocole SNMP, grâce à l’instrumentation
fournie par JMX. On pourrait dès lors déclencher les opérations d’administration associées à chaque groupe de services, sans avoir à en connaître le mode de
fonctionnement.
174
Conclusion
Chapitre 9
Annexes
9.1
La technologie Jini
La technologie Jini [53] permet d’enregistrer des objets Java sérialisés dans un
service d’enregistrement (cf. figure 9.1). Ce service d’enregistrement est à l’écoute
sur le réseau multicast des différentes demandes provenant d’autres objets Java.
Il peut exister plusieurs services d’enregistrement par sous-réseau. Chacun de
ces services d’enregistrement répond indépendamment les uns des autres. Sur
un domaine réseau, il est donc possible d’avoir un service d’enregistrement par
sous-réseau du domaine d’administration pour améliorer la fiabilité du système
d’enregistrement.
9.1.1
Les services enregistrés
Les services qui doivent être enregistrés, sont représentés par une instance de
leur classe qui sera enregistrée dans le Lookup Service.
L’interface du service, qui est enregistrée dans le Lookup Service, peut donner
accès au service de plusieurs façons :
– L’interface peut représenter le service entièrement, et dans ce cas, le service
lui-même est transmis au client lors du processus de recherche et est ensuite
exécuté en local par le client.
– L’interface peut aussi n’être qu’un recueil de déclarations de méthodes,
ce qui fait que l’interface se comporte comme un proxy. Lorsque le client
invoque une méthode, l’interface fait suivre la demande vers le fournisseur
du service qui exécute l’instruction.
– L’interface représente une approche intermédiaire des deux précédentes.
Elle consiste à faire exécuter une partie du service en local et une partie
par le fournisseur. Les proxies qui utilisent cette approche sont appelés des
proxy intelligents.
175
176
9.1.2
Annexes
L’enregistrement d’un service
L’enregistrement d’un service dans le Lookup Service se déroule de la manière
suivante (cf. figure 9.1) :
– Recherche du Lookup Service par le fournisseur de service
– Le Lookup Service retourne un objet, appelé le Registrar, qui agit comme
un proxy du Lookup Service. Toute les requêtes à destination du Lookup
Service se font via le Registrar
– Le fournisseur de service enregistre une copie de l’objet du service dans le
Lookup Service
Fournisseur
de Service
Lookup Service
1
Objet du Service
Objet du Service
Etape
3
2
Registrar
1
Recherche du service de localisation de services (Lookup Service)
2
Un registrar est retourne vers le demandeur du service
3
Le service s’enregistre dans le Lookup Service
Fig. 9.1 – Jini du côté serveur
9.1.3
La localisation d’un service
Du côté du client (cf. figure 9.2), le client veut obtenir une copie du service
dans sa propre JVM. Il utilise le même mécanisme que pour l’enregistrement
d’un service (voir ci-dessus) pour récupérer un Registrar. Ensuite, il demande au
Lookup Service une copie du service qu’il recherche.
9.1.4
Utilisation de Jini dans notre plate-forme
Nous utilisons donc les possibilités d’enregistrement et de localisation de Jini
pour enregistrer la localisation de nos objets actifs et pour permettre aux agents
mobiles de les contacter sans avoir à connaître leur localisation (par exemple
l’URL de leur localisation,etc.).
Les objets de notre plate-forme d’administration système et réseau que nous
enregistrons dans le Lookup Service sont les suivants :
Java Management Extension
177
Client
Lookup Service
1
Objet du Service
4
3
Registrar
Etape
Objet du Service
2
1
Recherche du service de localisation des services (Lookup Service)
2
Un registrar est retourne vers le demandeur du service
3
Demande du service, enregistre dans le Lookup Service
4
Le service est retourne au client s’il existe
Fig. 9.2 – Jini du côté du client
– ItineraryServerProxy qui est une instance de la classe ItineraryServerInterface implémentée par les ItineraryServers. Lorsque cet objet est
récupéré via Jini, il est possible d’avoir la localisation (la référence du service ) du ou des ItineraryServers qui s’exécutent.
– NetworkDescription qui est un objet encapsulant les descriptifs des sousréseaux (SubNetworkDescriptions), avec des méthodes permettant l’extraction , par exemple, d’un SubNetworkDescription selon une adresse de
réseau.
9.2
Java Management Extension
Les spécifications Java Management eXtensions (JMX) [52] décrivent un standard destiné à l’administration et la supervision d’applications Java à travers le
réseau.
JMX définit une couche d’isolation entre les ressources à gérer (objets Java) et
le système d’administration. Cette couche intermédiaire est basée sur un standard
permettant de réaliser des "objets JMX" ou "MBeans" (managed beans) qui vivent
dans un "conteneur JMX" et qui offrent une capacité d’administration centralisée
à partir des différents outils. Un client JMX peut accéder aux attributs et invoquer
des méthodes d’un "MBean" ; il peut également recevoir des notifications émises
par un "MBean".
9.2.1
Les niveaux dans JMX
Instrumentation : Les ressources, comme une application, des éléments du
réseau ou des services, sont instrumentés en utilisant des objets Java appelés
178
Annexes
Managed Beans (MBeans). Un MBean expose ses interfaces de gestion, composées
d’attributs et d’opérations, au travers d’un agent JMX pour une administration
et une supervision à distance. Ainsi, n’importe quelle ressource qui doit être
administrée en dehors de la JVM doit s’enregistrer en tant que MBean dans un
serveur MBean.
Agent : Le composant principal d’un agent JMX est le serveur MBean. C’est
un serveur d’objets administrés (le cœur) dans lequel les MBeans sont enregistrés.
Un agent JMX incorpore aussi un ensemble de services pour gérer les MBeans.
Les agents JMX contrôlent directement les ressources et les rendent disponibles
pour des agents d’administration distants.
L’administration distante d’agents JMX : Les adaptateurs de protocoles
et les connecteurs standards font qu’un agent JMX est accessible par des applications d’administration distantes vis à vis de la JVM qui héberge l’agent JMX.
Un adaptateur de protocole permet d’avoir une vue au travers d’un protocole
spécifique (par exemple HTTP, SNMP ou propriétaire) de tous les MBeans qui
sont enregistrés dans le server MBean.
Un connecteur fournit une interface du côté de l’application d’administration
qui gère la communication entre l’application et l’agent JMX. Chaque connecteur fournit la même interface au travers des différents protocoles. Quand une
application d’administration utilise cette interface, le connecteur peut la mettre
en relation, de manière transparente, avec un agent JMX par le réseau, quelque
soit le protocole utilisé.
9.3
Wifi
Il existe deux modes d’accès aux réseaux sans fil, le mode infrastructure et le
mode ad hoc. Chacun des modes diffère par la manière utilisée par les éléments
pour communiquer entre eux.
9.3.1
Les réseaux sans fil en mode Infrastructure
Les réseaux sans fil avec "Point d’accès" (ou "access point", AP en anglais)
sont des réseaux qui fonctionnent en mode infrastructure (cf. figure 9.3). Le AP
est l’équivalent d’un concentrateur en réseau filaire. Lorsqu’on utilise des APs,
les communications entre éléments mobiles passent toutes par ces points d’accès.
Par exemple, en mode infrastructure, les éléments B et C ne peuvent pas voir
directement D, E et F, mais ces éléments peuvent tout de même communiquer
entre eux en utilisant les deux point d’accès (Point d’accès 1 et point d’accès 2).
Zone de couverture de B
Fig. 9.4 – Accès Wifi en mode ad hoc
Les éléments A, B, C peuvent communiquer directement les uns avec les autres
sans passer par un point d’accès. Toutefois, si A désire communiquer avec l’élément C qui n’est pas dans sa Zone de couverture, la communication passera par
l’élément B. L’élément B joue le rôle de routeur entre les deux zones de couvertures.
Zone de couverture de C
C
C
C
B
A
BB
Point d’acces 1
Zone de converture de A
A
A
9.3.2
180
Annexes
Point d’acces 2
D
E
Connexion reseau
F
Fig. 9.3 – Accès Wifi en mode infrastructure
De même, les éléments A, B et C ne peuvent pas se voir et donc utilisent le point
d’accès 1 pour communiquer entre eux.
Les réseaux sans fil en mode ad hoc
Le réseau est composé uniquement de stations (appelées nœuds), sans aucun équipement central (le protocole est donc un protocole point-à-point). Les
nœuds assurent souvent les fonctions de routage (par exemple OLSR [62]) pour
acheminer l’information d’une station vers une autre (cf. figure 9.4).
Bibliographie
[1] N. Abramson. The Aloha system. In AFIPS Press, editor, AFIPS Conference Proceedings, volume 37, pages 281–285, Las Vegas, Nevada, 1970.
2.3.1, 2.3.2
[2] AdventNet. AdventNet SNMP tools, 1998. http://www.adventnet.net.
3.2.4.5, 3.2.6, 6.3.1
[3] Anand R. Tripathi and Neeran M. Karnik and Ram D. Singh and Tanvir
Ahmed and John Eberhard and Arvind Prakash. Development of Mobile
Agent Applications with Ajanta. Technical report, Department of Computer Science, University of Minnesota, 1999. http://www.cs.umn.edu/
Ajanta. 3.2.4.3, 3.3.3.4
[4] Yariv Ardor and Danny B. Lange. Agent Design Patterns : Elements of
Agent Application Design. In Proc. 2nd Int’l Conf. on Autonomous Agents,
pages 108–115. ACM Press, 1998. 3.3.1
[5] Asynchronus Transfer Mode, 1993. RFC 1483. 2.3.2
[6] I. Attali, D. Caromel, and A. Contes. Hierarchical and Declarative Security for Grid Applications. High Performance Computing - HiPC 2003,
10th International Conference, Hyderabad, India, December 17-20, 2003,
Proceedings, 2913() :363–372, December 2003. Lecture Notes in Computer
Science. 6.4.2.1
[7] F. Baude, D. Caromel, F. Huet, L. Mestre, and J. Vayssière. Interactive and
Descriptor-based Deployment of Object-Oriented Grid Applications. 11th
IEEE High Performance Distributed Computing, HPDC-11 (HPDC’20),
2002. 11th IEEE International Symposium on High Performance Distributed Computing (HPDC-11 2002), 23-26 July 2002, Edinburgh, Scotland,
UK. 5.2.3, 5.3.4
[8] Françoise Baude, Denis Caromel, Fabrice Huet, and Julien Vayssière. Objets Actifs Mobiles et Communicants. Technique et Science Informatiques,
21(6) :823–849, 2002. 3.2.4.3, 4.3.1.2
[9] P. Bellavista, A. Corradi, and C. Stefanelli. An Open Secure Mobile
Agent Framework for Systems Management. Journal of Network and Systems Management, 7(3), september 1999. http://citeseer.nj.nec.com/
bellavista99open.html. 3.2.3, 3.2.4.5, 3.3.2.2
181
182
Bibliographie
[10] P. Bellavista, A. Corradi, and C. Stefanelli. How to Monitor and Control
Resource Usage in Mobile Agent Systems. In 3 rd IEEE Int. Symp.
on Distributed Objects and Applications (DOA’01), Italy. IEEE Computer Society Press, September 2001. http://citeseer.nj.nec.com/
bellavista01how.html. 3.2.2, 3.2.6
[11] A. Bieszczad, B. Pagurek, and T. White. Mobile Agents for Network Management. IEEE Communications Surveys 1, 1, 1998. 3.1
[12] Raouf Boutaba and Jin Xiao. Network Management : State of the
Art. In Lyman Chapin, editor, Communication Systems : The State
of the Art (IFIP World Computer Congress), pages 127–146. Kluwer, 2002. www.ifip.tu-graz.ac.at/TC6/events/WCC/WCC2002/papers/
Boutaba.pdf. 2.5.2.2
[13] Yuri Breitbart, Minos N. Garofalakis, Cliff Martin, Rajeev Rastogi, S. Seshadri, and Abraham Silberschatz. Topology Discovery in Heterogeneous IP Networks. In IEEEE/INFOCOM 2000, Nineteenth Annual
Joint Conference of the IEEE Computer and Communications Societies, volume 1, pages 265–274, 2000. http://citeseer.nj.nec.com/
breitbart00topology.html". 3.4.1, 3.4.1.2, 3.4.3.2
[14] D. Milojicicand M. Breugst, I. Busse, J. Campbell, S. Covaci, B. Friedman,
K. Kosaka, D. Lange, K. Ono, M. Oshima, C. Tham, S. Virdhagriswaran,
and J. White. MASIF : The OMG Mobile Agent System Interoperability
Facility. In Second International Workshop on Mobile Agents 98 (MA’98),
September 1998. 3.2.2, 3.2.5
[15] Jean-Pierre Briot and Rachid Guerraoui. Objets pour la programmation
parallèle et répartie : intérêts, évolutions et tendances. Technique et Science
Informatiques (TSI), 15(6) :765–800, June 1996. 4.2.2
[16] Jamie Cameron. A web-based system administration tool for Unix. USENIX Annual Conference, June 2000. http://www.webmin.com/. 2.2.3
[17] D. Caromel, W. Klauser, and J. Vayssiere. Towards Seamless Computing
and Metacomputing in Java. pp. 1043–1061 in Concurrency Practice and
Experience, 10(11–13), 1998. 4.2.2
[18] Denis Caromel. Toward a method of object-oriented concurrent programming. Communications of the ACM, 36(9) :90–102, sep 1993. 4.2.2
[19] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser. RFC 1441. Introduction to SNMP V2, April 1993. http://www.faqs.org/rfcs/rfc1441.
html. 2.4.1.8
[20] J. Case, D. Partain, and B. Stewart. RFC 3410. SNMP V3, December 2002.
http://www.faqs.org/rfcs/rfc3410.html. 2.4.1.8
[21] Marco Castaldi, Antonio Carzaniga, Paola Inverardi, and Alexander L.
Wolf. A Lightweight Infrastructure for Reconfiguring Applications. volume
Bibliographie
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
183
2649/2003, pages 231–244, Februrary 2004. http://www.cs.colorado.
edu/~carzanig/papers/cciw_scm11.pdf. 8.2
Omar CHERKAOUI. Standards pour la gestion des réseaux et des services.
Olivier Festor and André Schaff, 2003. 5.4.2
Graphical network viewer : Cisco Works 2000. http://www.cisco.com/
warp/public/cc/pd/wr2k/. 2.5.2.1
CMOT. The Common Management Information Services and Protocol over
TCP/IP. RFC 1095. http://rfc.sunsite.dk/rfc/rfc1095.html. 4
DHCP. Dynamic host configuration protocol. rfc 1531. http://www.ietf.
org/rfc/rfc1531.txt. 5.2.1.2
DNS : Serveur de nom de domaine. RFC 1034. 5, 3.4.2.2
Etherape. Graphical network viewer. http://etherape.sourceforge.
net/. 2.5.1
S. Fontanini, J. Wainer, V. Bernal, and S. Marangon. Model Based Diagnosis in LANs. In IEEE Workshop on IP Operations and Management,
pages 121–5, Dallas, October 2002. http://www.ic.unicamp.br/~wainer/
papers/ipom2002.pdf. 3.4.1.2
TeleManagement Forum. ITU-T [X.700] OSI Management framework.
http://www.nmf.org. 2.2
Germán Goldszmidt, Yechiam Yemini, and Shaula Yemini. Network Management : The MAD Approach. In Proceedings of the IBM/CAS Conference,
Toronto, Canada, October" 1991. 3.2, 3.2.1
R. S. Gray. Agent Tcl : A flexible and secure mobile-agent system. In
M. Diekhans and M. Roseman, editors, Fourth Annual Tcl/Tk Workshop
(TCL 96), pages 9–23, Monterey, CA, 1996. http://citeseer.ist.psu.
edu/gray97agent.html. 3.2.2
Frédéric Guidec, Yves Mahéo, and Luc Courtrai. "aa java middleware platform for resource-aware distributed applications". In Second International
Symposium on Parallel and Distributed Computing, Ljubljana, Slovenia,
October 2003. http://citeseer.ist.psu.edu/gray97agent.html. 5.3.4,
8.2
Delbert Hart, Mihail Tudoreanu, and Eileen Kraemer. Mobile agents for
monitoring distributed systems. In Jörg P. Müller, Elisabeth Andre, Sandip Sen, and Claude Frasson, editors, Proceedings of the Fifth International Conference on Autonomous Agents, pages 232–233, Montreal, Canada,
2001. ACM Press. http://citeseer.nj.nec.com/hart01mobile.html.
3.4.1.2
P.W Chen H.C Lin, S.C Lai and H.L Lai. Automatic Topology Discovery
of IP Networks, january 2000. IEICE Transactions on Information and
Systems. 3.4.2.2, 3.4.3.2
184
Bibliographie
[35] Hewlett-Packard. HP Network Node Manager. http://www.openview.hp.
com/solutions/nim/index.html. 1.1, 2.2.1, 2.5.2.1, 3.4.2.1, 5.3.2.1
[36] Host Resource MIB, march 2000. RFC 2790. 6.3.1.2
[37] IBM. Nways, 2000. http://www.networking.ibm.com/. 1.1
[38] Internet Control Message Protocol, 1981. RFC 792. 2.3.3
[39] Internet Protocol, 1981. RFC 791. 2.3.3
[40] Julio Guijarro and Manuel Monjo and Patrick Goldsack. Framework for
managing large scale component-based distributed applicaions using JMX.
http://www.j2eeolympus.com/J2EE/JMX/JMXEJB.jsp. 8.2
[41] R. Kavasseri and B. Stewart. Rfc 2981/ event mib, October 2000. http:
//www.faqs.org/rfcs/rfc2981.html. 2.4.3.2
[42] R. Kavasseri and B. Stewart. Rfc 2982 / distributed management expression
mib, October 2000. http://www.faqs.org/rfcs/rfc2982.html. 2.4.3.2
[43] R. Kavasseri and B. Stewart. Rfc 3014/ notification log mib, November
2000. http://www.faqs.org/rfcs/rfc3014.html. 2.4.3.2
[44] LDAP. Lightweight Directory Access Protocol. RFC 1177, 1995. http:
//www.ldapcentral.com/. 4.4.2.1
[45] D. Levi and J. Schoenwaelder. Rfc 2591 / scheduling management operations mib, November 2000. http://www.ietf.org/rfc/rfc2591.txt.
2.4.3.1
[46] Bruce B. Lowekamp, David R. O’Hallaron, and Thomas Gross. Topology
Discovery for Large Ethernet Networks. In Proceedings of SIGCOMM 2001,
pages 237–248. ACM, August 2001. 3.4.1.2, 3.4.3.2
[47] Line Printer Daemon Protocol, august 1990. RFC 1179. 1
[48] M. Forssen and F. Cusack. SSH Connection Protocol. http://openbsd.
appli.se/openssh/txt/draft-ietf-secsh-auth-kbdinteract-01.txt.
7.3.2
[49] J.P. Martin-Flatin, S. Znaty, and J.P. Hubaux. A Survey of Distributed
Enterprise Network and Systems Management Paradigms. In Journal of
Network and Systems Management), volume 7-1, pages 9–26, 1999. http:
//www.cstp.umkc.edu/jnsm/vols/vol07n1.html. 2.5.2.2
[50] MIAMI. Mobile Intelligent Agents for Managing the Information Infrastructure . http://www.cordis.lu/infowin/acts/analysys/products/
thematic/agents/ch3/miami.htm. 3.2.2
[51] Sun MicroSystems. Java developpement kit - version 1.2. 3.1
[52] Sun MicroSystems. Java Management Extensions. http://java.sun.com/
products/JavaManagement/wp/. 9.2
[53] Sun MicroSystems. Jini Network Technology. http://wwws.sun.com/
software/jini/. 4.4.3.1, 5.3.1, 9.1
Bibliographie
185
[54] Nikos Migas, William J. Buchanan, and Kevin A. Mc Aartney. Hierarchical
network management : a scalable and dynamic mobile agent-based approach
. volume 38, pages 693–711, April 2002. 8.1
[55] Nikos Migas, William J. Buchanan, and Kevin A. Mc Aartney. Mobile
Agents for Routing, Topology Discovery, and Automatic Network Reconfiguration in Ad-Hoc Networks . In IEEE International Conference and
Workshop on the Engineering of Computer-Based Systems (ECBS’03),
April 2003. 7.2.2.4
[56] Multi Router Traffic Grapher. http://people.ee.ethz.ch/~oetiker/
webtools/mrtg/. 2.2.1, 2.5.1
[57] Nagios. An open source host, service, and network monitoring program.
http://www.nagios.org. 5.3.2.1
[58] Nöel de Palma. Services d’Administration d’Applications Réparties. Thèse
soutenue à l’Université Joseph Fourier. http://sardes.inrialpes.fr/
people/depalma/perso.html. 8.2
[59] Wireless Local Area Network. Ieee 802.11. http://grouper.ieee.org/
groups/802/11/. 7.2.2.1
[60] The Institute of Electronics and Inc Electronics Engineers. IEEE Standards for Local Area Network : Carrier Sense Multiple Access with Collision
Detection (CSMA/CD) Access Method and Physical Layer Specifications.
Technical report, The Institute of Electronics and Electronics Engineers,
Inc., New York, 1985. 2.3.2
[61] The Institute of Electronics and Inc Electronics Engineers. IEEE Standards for Local Area Networks : Token Ring Access Method and Physical
Layer Specifications. Technical report, The Institute of Electronics and
Electronics Engineers, Inc., New York, 1985. 2.3.2
[62] OLSR. Optimized Link State Routing.
olsr/. 9.3.2
http://hipercom.inria.fr/
[63] M.J. O’Mahony, D. Gavalas, D. Greenwood, and M. Ghanbari. An Infrastructure for Distributed and Dynamic Network Management based on
Mobile Agent Technology. Proc. IEEE International Conference on Communications (ICC’99), 2 :1362–1366, June 1999. http://citeseer.nj.
nec.com/context/1055077/0. 3.2.4.4
[64] B. Pagurek, Y. Wang, and T. White. Integration of Mobile agents with
SNMP : Why and How. In IEEE/IFIP Network Operations and Management Symposium, NOMS 2000, Honolulu, April 2000. http://www.sce.
carleton.ca/netmanage/publications.html. 1.2
[65] D. Plummer. An Ethernet Address Resolution Protocol. Technical report,
Symbolics Cambridge Research Center, November 1982. RFC 826. 2.3.3
186
Bibliographie
[66] A. Pras and J. Schonwalder. Editorial, volume 7. The Simple Times,
http://www.simple-times.org/pub/simple-times/issues/7-2.html,
Novembre 1999. 2.4.3.1
[67] ProActive. INRIA, 1999. http://www-sop.inria.fr/oasis/ProActive.
4.1
[68] A. Puliafito and O. Tomarchio. Security Mechanisms for the MAP Agent
System. In In 8th Euromicro Workshop on Parallel and Distributed Processing (PDP2000), pages 84–91, January 2000. http://sun195.iit.unict.
it/~otomarch/publications.html. 3.2.2
[69] A. Puliafito, O. Tomarchio, and L. Vita. MAP : Design and Implementation
of a Mobile Agent Platform. Journal of System Architecture, 46(2) :145–
162, 2000. 3.2.3, 3.2.4.1, 3.2.4.1, 3.2.4.3
[70] S. Sharma R. Siamwalla and S. Kashav. Discovering Internet topology.
Technical report, Cornell University, Ithaca, NY 14583, July 1998. http:
//www.cs.cornell.edu/skeshav/papers/discovery.pdf. 3.4.2.2, 3.4.2.2
[71] M. Ranganathan, Laurent Andrey, Virgine Galtier, and Virgine Schaal.
AGNI : Encore des Agents Mobiles ! In Colloque Francophone sur l’Ingénierie des Protocoles (CFIP’99), April 1999. http://snad.ncsl.nist.
gov/agni/agni/docs/white-paper/cfip99.ps. 3.2.2, 3.4.2.2
[72] E. Reuter and F. Baude. A mobile-agent and SNMP based management
platform built with the Java ProActive library. IEEE Workshop on IP
Operations and Management (IPOM 2002), pages 140–145, October 2002.
Dallas. 5.3.2.2
[73] E. Reuter and F. Baude. System and Network Management Itineraries for
Mobile Agents. 4th International Workshop on Mobile Agents for Telecommunications Applications, MATA, LNCS(2521) :227–238, October 2002.
Barcelona. 4.4.4
[74] Luigi Rizzo. Dummynet : a simple approach to the evaluation of network
protocols. ACM Computer Communication Review, 27(1) :31–41, 1997.
http://info.iet.unipi.it/~luigi/ip_dummynet. 7.2.1.1
[75] Daniel Rossier-Ramuz. Ecomobile : a Mobile Agent Ecosystem for Active Network Management. Technical report, Departement of Informatics, University of Fribourg, June 2003. http://diuf.unifr.ch/pai/
publications/internal.php. 1.2
[76] A. Sahai and C. Morin. Enabling a Mobile Network Manager (MNM)
Through Mobile Agents. In International Workshop on Mobile Agents.
LNCS, No. 1477, Springer-Verlag, september 1998. 3.2.2
[77] Ichiro Satoh. Network processing of Mobiles Agents, by Mobile Agents,
for Mobile Agents. In 3th International Workshop on Mobile Agents
Bibliographie
187
for Telecommunications Applications, MATA’01, volume 2146, pages 81–
92. Lecture Notes in Computer Science (LNCS), August 2001. http:
//citeseer.nj.nec.com/575168.html. 3.2.2
[78] Ichiro Satoh. A Framework for Building Reusable Mobile Agents for Network Management. In Proceedings of Network Operations and Managements Symposium (NOMS’2002), pages 51–64. IEEE Communication Society, April 2002. http://citeseer.nj.nec.com/575168.html. 3.2.4.1,
3.2.4.1, 3.2.4.3, 3.3.2.3, 5.3.2.1
[79] J. Schonwalder and H. Langendorfer. How to Keep Track of Your Network
Configuration. In Proceedings of the 1993 LISA VII Conference, 1993.
http://citeseer.nj.nec.com/article/to93how.html. 3.4.1, 3.4.2.2
[80] Disman Script Mib. RFC 2592. 2.4.3.1
[81] P. Simões, F. Boavida, and L. Silva. A Generic Management Model for Mobile Agent Infrastructures. In Proceedings of SCI 2000 - The 4th World Multiconference on Systemics, Cybernetics and Informatics, July 2000. 3.2.3
[82] P. Simões, R. Reis, L. Silva, and F. Boavida. Enabling Mobile Agent Technology for Legacy Network Management Frameworks. In Proceedings of
Softcom ’99 - Conference on Software in Telecommunications and Computer Networks. IEEE Communications Society, October 1999. 3.2.3
[83] P. Simões, Luis Moura Silva, and Fernando Boavida. Integrating SNMP
into a Mobile Agent Infrastructure. In Proceedings of DSOM’99 - Tenth
IFIP/IEEE International Workshop on Distributed Systems : Operations
and Management, October 1999. http://citeseer.nj.nec.com/358231.
html. 8.2
[84] Paulo Simões, Paulo Marques, Luís Silva, João Gabriel, and Fernando Boavida. Towards Manageable Mobile Agent Infrastructures. In Proceedings of
ICN’01 (International Conference on Networking). Springer-Verlag LNCS
2094, Colmar, France, July 2001. 3.2.2
[85] Paulo Simões, João Rodrigues, Luís M. Silva, and Fernando Boavida. Distributed Retrieval of Management Information : Is it About Mobility, Locality or Distribution. In NOMS’2002 - Network Operations and Management
Symposium). IEEE Communications Society, April 2002. 7.1, 7.2.1.3, 8.1
[86] Simple Network Management Protocol, 1990. RFC 1157. 2.4.1
[87] Simple Network Management Protocol standard MIB-II, 1990. RFC 1213.
1.1, 2.4.1.1, 2.4.1.4
[88] SNMP TRAPS, march 1991. RFC 1215. 6.3.1.1
[89] Markus Strasser and Kurt Rothermel. Reliability Concepts For Mobile
Agents. International Journal of Cooperative Information Systems (IJCIS),
7(4), 1998. http://citeseer.nj.nec.com/270979.html. 3.3.1
188
Bibliographie
[90] Sun MicroSystems. Java Developpement Kit V 1.4. http://java.sun.com.
4.3.1
[91] Andrew Tanenbaum. Réseaux : Architecture, protocole, applications, 3ème
édition, Dunod. Prentice Hall, 1999. 2.3
[92] Tcl. Tool Command Language. http://www.tcl.tk/scripting/primer.
html. 3.2.2
[93] Transmission Control Protocol, 1981. RFC 793. 2.3.3
[94] The Grasshopper Agent Platform. http://www.grasshopper.de. 3.2.2
[95] Tivoli. A network management tool for enterprises and service providers.
http://www-3.ibm.com/software/tivoli/. 2.5.2.1, 3.4.2.1
[96] User Datagram Protocol, 1980. RFC 768. 2.3.3
[97] Bill Venners. Under the hood : The architecture of aglets. JavaWorld :
IDG’s magazine for the Java community, 2(4), apr 1997. 4.2
[98] Voyager. ObjectSpace, Inc., 1999. www.objectspace.com. 4.2
[99] Chris Wellens and Karl Auerbach.
The Quarterly Newsletter
of SNMP Technology, Comment, and Events (sm), volume 4 (3).
The Simple Times, http://www.simple-times.org/pub/simple-times/
issues/4-3.html, July 1996. 2.5.3
[100] K. White. Rfc 2925. definitions of managed objects for remote ping, traceroute, and lookup operations, September 2000. http://www.faqs.org/
rfcs/rfc2925.html. 2.4.3.2
[101] Buchanan WJ, Naylor M, and Scott AV. Enhancing Network Management
using Mobile Agents. In Seventh IEEE International Conference and Workshop on the Engineering of Computer Based Systems (ECBS 2000)), pages
218–226. IEEE Communications Society, 2000. 7.1
[102] Mark Wolfgang. Nmap hackers, november 2002. White Paper Exploring
Host Discovery. 2.3.3
[103] Rich Wolski, Neil Spring, and Jim Hayes. The Network Weather Service :
A Distributed Resource Performance Forecasting Service for Metacomputing. volume 15, pages 757–768, October 1999. http://nws.cs.ucsb.edu/
publications.html. 8.2
[104] W.Stallings. SNMP, SNMPv2, and CMIP. Don Mills : Addison-Wesley,
1993. 1.1, 2.4.1.1, 2.4.2, 4.4.1.2
Résumé
Depuis le début des années 1990, l’utilisation des agents mobiles dans le cadre
de l’administration système et réseau est étudiée. Des plates-formes à agents mobiles répondant à cet usage ont été développées et se sont penchées en général sur
les problèmes de l’interrogation des équipements actifs du réseau, de la supervision des nœuds des plates-formes, de la sécurité des nœuds visités, etc. Cependant, une contrainte opérationnelle provenant du fait que la présence d’éléments
dans un réseau tend à évoluer dynamiquement n’avait pas été prise en compte.
Une telle évolution requiert que les itinéraires de migration associés aux agents
mobiles d’administration ne soient pas définis comme cela est fait en général,
de manière statique par l’administrateur, mais qu’au contraire de tels itinéraires
puissent être construits à la volée de sorte à refléter la topologie courante du réseau à administrer. Nous avons aussi constaté que les facilités de programmation
obtenues par l’association d’une fonction d’administration à chacun des éléments
d’un itinéraire, et ce, en fonction du type de l’élément, pourraient être bénéfique,
en ce sens que cela pourrait grandement simplifier la définition d’agents mettant
en œuvre de nouvelles fonctions d’administration système et réseau.
Ce travail de thèse consiste à proposer la définition d’un mécanisme de fabrication puis d’utilisation d’itinéraires dynamiques pour l’administration système
et réseau. Nous validons cette définition en fournissant une plate-forme complète
ainsi qu’un cadre de programmation d’agents mobiles d’administration système
et réseau. Pour ce faire, nous utilisons et étendons la bibliothèque ProActive
pour le calcul parallèle, réparti et mobile. En effet, ProActive offre un cadre qui
simplifie grandement la programmation et le déploiement d’agents mobiles en
environnement hétérogène et réparti.
Le mécanisme d’itinéraires proposé suppose la connaissance de la topologie
du réseau et des éléments qui y sont connectés. Nous implantons donc un mécanisme de découverte automatique de la topologie d’un réseau au niveau 2 OSI.
Nous définissons ensuite un cadre générique de programmation d’agents mobiles
bâtie autour de notre mécanisme d’itinéraires pour effectuer des tâches d’administration système et réseau. Pour valider notre approche et son intégration dans
le monde de l’administration système et réseau, nous fournissons des exemples
concrets de l’utilisation des agents mobiles d’administration et ce pour une large
gamme de configurations réseau.
Mots-clés : agents mobiles, administration système et réseau, itinéraire dynamique, migration, SNMP, ProActive.
Abstract
Since the beginning of 1990s, the usage of mobile agents within the framework of system and network management is considered. Platforms with mobile
agents answering this use were developed and in general focus on the problem of
collecting data on network elements, on supervising platform nodes, on the safety
of the visited nodes, etc. However, an operational constraint relates to the fact
that elements in a network tend to evolve/move dynamically ; such a constraint
has not been seriously taken into account in existing platforms. Such a dynamic
evolution requires that migration itineraries be associated with mobile agents for
network and system management ; but such itineraries are generally defined in a
static way by an administrator, alas, on the contrary, such itineraries should be
built on the fly so as to reflect the current network topology to be managed. We
underline that programming facilities could be obtained by associating a management function with each element in an itinerary, and this, according to the type
of each element. This could be beneficial, in the sense that it could largely ease
the programming of mobile agents tasks by enabling to implement new system
and network management functions.
This thesis work consists in proposing the definition of a mechanism to create
and then to use dynamic itineraries for system and network management. We validate this definition by providing a platform and a mobile agents programming
framework for system and network management. In order to achieve this, we use
and extend the ProActive library for parallel, distributed and mobile computing.
Indeed, ProActive offers a framework which largely simplifies the programming
and the deployment of mobile agents in an heterogeneous and distributed environment.
The proposed itineraries mechanism assumes the knowledge of the network topology and how its elements are interconnected. Thus, we design and implement
an automatic discovery mechanism of the OSI level-2 topology of the network
to manage. Then, we define a generic framework for mobile agents programming
based upon our itineraries mechanism so as to carry out system and network management tasks. To validate our approach and its integration in the system and
network management world, we provide several usage scenario of mobile agents,
and this for a broad range of network configurations.
Keywords : mobile agents, system and network management, dynamic itinerary, migration, SNMP, ProActive.

1229032

1231301

1232351

1230203

1231378

1228839

1230714

1230260

1231979

1232016