These Reuter

8/6/2019 These Reuter

1/192

Universit de Nice Sophia Antipolis

UFR SCIENCES

cole Doctorale : STIC

THSE

Prsente pour obtenir le titre de :Docteur en SCIENCES

de lUniversit de Nice Sophia Antipolis

Spcialit : Informatique

par

Emmanuel Reuter

quipe daccueil : OASIS - INRIA Sophia Antipolis

Titre de la thse :

Agents Mobiles :Itinraires pour ladministration systme et rseau

Thse dirige par Franoise BAUDESoutenue le 28 Mai 2004

PrsidentM. : Michel Riveill Univ. Nice Sophia Antipolis

RapporteursMM. : Olivier Festor INRIA Lorraine

Serge Chaumette Univ. Bordeaux 1Examinateurs

MM. : Franoise Baude Univ. Nice Sophia AntipolisJean-Luc Ernandez Ingnieur ATOS Origin

tel00207934,version1

18Jan2008
http://hal.archives-ouvertes.fr/http://tel.archives-ouvertes.fr/tel-00207934/fr/


2/192


18Jan2008


3/192

Je remercie avant tout Franoise Baude qui ma encadr durant ces quatre

dernires annes et sans qui cette thse naurait pas pu se faire. Elle a su meguider par ses nombreux conseils, les encouragements mentionns chaque findemails et pendant les nombreux repas de travail que nous nous sommes fixsavec une certaine rgularit.

Laccueil qui ma t rserv dans lquipe OASIS a t la fois chaleureuxet enrichissant scientifiquement et ma permis de mouvrir de nouveaux sujets.Jai beaucoup apprci les changes entre Julien Vassire, Fabrice Huet, RomainQuilici, membres de lquipe Oasis, qui mont permis davancer dans mon travailde recherche tout en occupant un poste lIUFM de lacadmie de Nice.

Je tiens remercier bien entendu les membres du jury : Michel Riveill qui aaccept de prsider ce jury, Olivier Festor, Serge Chaumettre pour avoir acceptdtre rapporteurs et enfin Jean-Luc Ernandez pour avoir accept dtre un exa-minateur de cette thse.

Je tiens remercier les deux directeurs de lIUFM, Franois Rocca et RenLozi, qui mont autoris successivement continuer ma thse en parallle dutravail dingnieur dtudes que jexerce au sein de cet tablissement. Plus par-ticulirement Franois Rocca qui a t pour moi ltincelle de dpart de cettegrande aventure.

Une pense particulire est adresse Richard MANAS, Ingnieur de Re-cherche au Centre Informatique de lUniversit de Nice Sophia Antipolis, pourson aide et les discussions que nous avons eues pendant ces quatres annes.

Je noublie pas le personnel de linformatique de lIUFM qui a su maider dansmes dmarches de tests et qui a parfois support mes absences pendant que jevoguais vers dautres cieux, ceux de la recherche bien sr.

A mon pays, la Nouvelle-Caldonie.


18Jan2008
http://www.iufm.unice.fr/http://www.iufm.unice.fr/


4/192

Table des matires

1 Introduction 111.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3 Contribution et organisation du manuscrit . . . . . . . . . . . . . 13

2 Ladministration des systmes et des rseaux 152.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 Dfinition de ladministration des systmes et des rseaux . . . . 16

2.2.1 Gestion des performances . . . . . . . . . . . . . . . . . . 162.2.2 Gestion des fautes . . . . . . . . . . . . . . . . . . . . . . 172.2.3 Gestion de la configuration . . . . . . . . . . . . . . . . . . 182.2.4 Gestion des informations comptables . . . . . . . . . . . . 18

2.2.5 Gestion de la scurit . . . . . . . . . . . . . . . . . . . . . 182.3 Le kit de survie de ladministrateur rseau . . . . . . . . . . . . . 19

2.3.1 La couche physique . . . . . . . . . . . . . . . . . . . . . . 192.3.2 La couche liaison de donnes . . . . . . . . . . . . . . . . 202.3.3 La couche rseau . . . . . . . . . . . . . . . . . . . . . . . 22

2.4 Ladministration de rseau . . . . . . . . . . . . . . . . . . . . . 242.4.1 Le protocole dadministration de rseau : SNMP . . . . . . 242.4.2 Le protocole CMIP . . . . . . . . . . . . . . . . . . . . . 332.4.3 Administration rpartie . . . . . . . . . . . . . . . . . . . 33

2.5 Quelques outils incontournables pour ladministration . . . . . . . 36

2.5.1 Des outils lmentaires . . . . . . . . . . . . . . . . . . . 362.5.2 Plates-formes dadministration centralise . . . . . . . . . 372.5.3 Des plates-formes dadministration bases sur le Web . . . 41

2.6 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3 Les plates-formes agents mobiles pour ladministration sys-tme et rseau : tat de lart 433.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.2 tat de lart des plates-formes agents mobiles . . . . . . . . . . 44

3.2.1 Principe de ladministration par delegation . . . . . . . . . 443.2.2 Plates-formes tournes vers ladministration . . . . . . . . 45

1


18Jan2008


5/192

2 Table des matires

3.2.3 Installation des plates-formes . . . . . . . . . . . . . . . . 47

3.2.4 Programmation des agents . . . . . . . . . . . . . . . . . . 483.2.5 Communication entre agents mobiles . . . . . . . . . . . . 543.2.6 Accs aux donnes de la MIB SNMP . . . . . . . . . . . . 56

3.3 Itinraires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.3.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.3.2 Structuration dun itinraire de visite . . . . . . . . . . . . 573.3.3 Autres structurations dun itinraire . . . . . . . . . . . . 59

3.4 La topologie du rseau . . . . . . . . . . . . . . . . . . . . . . . . 623.4.1 Motivation : besoin de dcouverte automatise . . . . . . . 623.4.2 Techniques de dcouverte de la topologie . . . . . . . . . . 643.4.3 Topologie de niveau 2 . . . . . . . . . . . . . . . . . . . . 67

3.5 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4 Conception dun mcanisme ditinraires dynamiques pour lad-ministration systme et rseau 714.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 714.2 Les agents mobiles dans ProActive . . . . . . . . . . . . . . . . . 72

4.2.1 ProActive : objets actifs asynchrones communicants . . . . 724.2.2 Modle de base . . . . . . . . . . . . . . . . . . . . . . . . 734.2.3 Cration des objects actifs . . . . . . . . . . . . . . . . . . 734.2.4 Activits, contrle explicite et abstractions . . . . . . . . . 75

4.3 Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.3.1 Migration Faible . . . . . . . . . . . . . . . . . . . . . . . 764.3.2 Abstractions pour la mobilit . . . . . . . . . . . . . . . . 784.3.3 Modle de suivi ditinraire de ProActive . . . . . . . . . . 82

4.4 Conception ditinraires pour ladministration . . . . . . . . . . . 834.4.1 Destinations . . . . . . . . . . . . . . . . . . . . . . . . . . 834.4.2 Techniques dobtention des lments dun itinraire . . . . 864.4.3 Le modle de service ditinraire propos . . . . . . . . . . 894.4.4 Construction et gestion de litinraire . . . . . . . . . . . . 954.4.5 Utilisation ditinraires . . . . . . . . . . . . . . . . . . . . 97

4.5 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

5 Conception et implantation dune plate-forme dadministrationsystme et rseau 1015.1 Architecture gnrale : principe de conception . . . . . . . . . . . 1015.2 Les services de la plate-forme . . . . . . . . . . . . . . . . . . . . 102

5.2.1 Service de collecte et danalyse . . . . . . . . . . . . . . . 1025.2.2 Service de mise disposition des informations collectes et

analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035.2.3 Service de supervision de la plate-forme . . . . . . . . . . . 103

5.3 Architecture gnrale : mise en uvre . . . . . . . . . . . . . . . . 103


18Jan2008


6/192

Table des matires 3

5.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 103

5.3.2 Connaissance du rseau . . . . . . . . . . . . . . . . . . . 1045.3.3 Service de mise disposition des informations dcouvertes 1075.3.4 Service de supervision . . . . . . . . . . . . . . . . . . . . 1085.3.5 Rcapitulatif . . . . . . . . . . . . . . . . . . . . . . . . . 1095.3.6 Interface graphique . . . . . . . . . . . . . . . . . . . . . . 110

5.4 Principes et implantation de lalgorithme de dcouverte de la to-pologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1145.4.2 Phase de dtection des lments . . . . . . . . . . . . . . . 1155.4.3 Phase de connexion des lments . . . . . . . . . . . . . . 117

5.5 Mise en uvre du service de dcouverte de la topologie . . . . . . 1225.5.1 Le service de localisation des nuds ProActive . . . . . . . 1225.5.2 Le service de dcouverte . . . . . . . . . . . . . . . . . . . 1235.5.3 Interaction avec le serveur ditinraires . . . . . . . . . . . 1235.5.4 Topologie de rseaux virtuels . . . . . . . . . . . . . . . . 1235.5.5 Evaluation du temps de construction . . . . . . . . . . . . 1245.5.6 Extension de lagorithme pour le protocole SNMP V3 . . . 126

5.6 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

6 Programmation dagents mobiles pour ladministration systmeet rseau 129

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1296.2 Fabrication et suivi ditinraires . . . . . . . . . . . . . . . . . . . 130

6.2.1 Architecture gnrale . . . . . . . . . . . . . . . . . . . . . 1306.2.2 Fabrication de litinraire . . . . . . . . . . . . . . . . . . . 1316.2.3 Suivi de litinraire . . . . . . . . . . . . . . . . . . . . . . 134

6.3 Code dadministration . . . . . . . . . . . . . . . . . . . . . . . . 1356.3.1 Les oprations de base . . . . . . . . . . . . . . . . . . . . 1356.3.2 Utilisation des oprations de base dans le code de lagent . 138

6.4 Extensibilit du modle de dveloppement . . . . . . . . . . . . . 1416.4.1 Modalits de lextension . . . . . . . . . . . . . . . . . . . 141

6.4.2 Exemple : prise en compte dun nouveau type de destination1426.4.3 Exemple : fabrication dun nouveau type ditinraire parallle1456.5 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

7 Performances et valuation des agents mobiles pour ladminis-tration systme et rseau 1537.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1537.2 Analyse des performances . . . . . . . . . . . . . . . . . . . . . . 154

7.2.1 Expriences sur un rseau local . . . . . . . . . . . . . . . 1547.2.2 Expriences sur un rseau WLAN . . . . . . . . . . . . . . 161

7.3 Exemples dutilisation des agents mobiles . . . . . . . . . . . . . . 165


18Jan2008


7/192

4 Table des matires

7.3.1 Quelques exemples simples exploitant la proprit dauto-

nomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1657.3.2 Exemple : Autoconfiguration des VLANs dans un rseau . 1677.4 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

8 Conclusion 1698.1 Bilan, contribution . . . . . . . . . . . . . . . . . . . . . . . . . . 1698.2 Administration dans le contexte des applications . . . . . . . . . 171

9 Annexes 1759.1 La technologie Jini . . . . . . . . . . . . . . . . . . . . . . . . . . 175

9.1.1 Les services enregistrs . . . . . . . . . . . . . . . . . . . . 175

9.1.2 Lenregistrement dun service . . . . . . . . . . . . . . . . 1769.1.3 La localisation dun service . . . . . . . . . . . . . . . . . . 1769.1.4 Utilisation de Jini dans notre plate-forme . . . . . . . . . . 176

9.2 Java Management Extension . . . . . . . . . . . . . . . . . . . . . 1779.2.1 Les niveaux dans JMX . . . . . . . . . . . . . . . . . . . . 177

9.3 Wifi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1789.3.1 Les rseaux sans fil en mode Infrastructure . . . . . . . . . 1789.3.2 Les rseaux sans fil en mode ad hoc . . . . . . . . . . . . . 180

Bibliographie 180

Rsum 189


18Jan2008


8/192

Table des figures

2.1 Rseau Ethernet non segment . . . . . . . . . . . . . . . . . . . . 172.2 Rseau Ethernet segment . . . . . . . . . . . . . . . . . . . . . . 172.3 Exemple dune topologie en bus . . . . . . . . . . . . . . . . . . . 212.4 Exemple dune topologie en toile . . . . . . . . . . . . . . . . . . 212.5 Architecture Client/Serveur sur laquelle se base lutilisation dun

protocole dadministration dans un rseau . . . . . . . . . . . . . 252.6 Structure dindexation des donnes dans la MIB-2 SNMP . . . . . 262.7 Les groupes dobjets de la MIB-2 . . . . . . . . . . . . . . . . . . 282.8 Dlgation un gestionnaire intermdiaire des oprations dadmi-

nistration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.9 Plate-forme de supervision du trafic rseau instantan . . . . . . . 372.10 Plate-forme dadministration de rseaux centralise . . . . . . . . 39

2.11 Capture dcran de la topologie rseau obtenue par la plate-formeHP Network Node Manager . . . . . . . . . . . . . . . . . . . . . 40

2.12 Capture du segment 8 . . . . . . . . . . . . . . . . . . . . . . . . 402.13 Principe du Web-Based Management . . . . . . . . . . . . . . . . 41

3.1 Architecture de MAD . . . . . . . . . . . . . . . . . . . . . . . . . 453.2 Classe gnrique dun agent mobile . . . . . . . . . . . . . . . . . 513.3 Classe HelloAgent de la plate-forme Ajanta . . . . . . . . . . . . . 513.4 Classe dun agent mobile dans MAP . . . . . . . . . . . . . . . . 523.5 Classe dun agent mobile dans SOMA . . . . . . . . . . . . . . . . 55

3.6 Modle des domaines de SOMA . . . . . . . . . . . . . . . . . . . 583.7 Les itinraires dans MobileSpaces . . . . . . . . . . . . . . . . . . 593.8 Les Patterns de migration dans Ajanta . . . . . . . . . . . . . . . 613.9 Une portion de lInternet . . . . . . . . . . . . . . . . . . . . . . . 653.10 Topologie de niveau 2 . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.1 Cration des objects actifs : Instanciation-, Object-based . . . . . 744.2 Cration dun objet actif avec une politique de service RunActive 744.3 Cration dun objet actif dans la JVM en cours, distance ou par

co-allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.4 Programmation explicite du contrle . . . . . . . . . . . . . . . . 75

5


18Jan2008


9/192

6 Table des figures

4.5 SimpleAgent : exemple dun objet actif mobile . . . . . . . . . . 77

4.6 Localisation avec rpteurs . . . . . . . . . . . . . . . . . . . . . . 784.7 Excution automatique de mthodes et itinraires . . . . . . . . . 804.8 Modle gnrique dactivit dun agent mobile . . . . . . . . . . . 814.9 Un itinraire dfini manuellement, construit avec la bibliothque

ProActive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 824.10 Types dintervention dun agent mobile dadministration . . . . . 844.11 Hirarchie de classes issue de la classe Destination . . . . . . . . . 854.12 Un itinraire dynamique construit selon le modle des Destinations 864.13 Serveur dannuaire contenant les lments ncessaires la cration

des itinraires dadministration . . . . . . . . . . . . . . . . . . . 874.14 Objet actif fournissant des itinraires pas pas . . . . . . . . . . 884.15 Objet actif fournissant des itinraires en une seule fois . . . . . . . 904.16 Le service ditinraire . . . . . . . . . . . . . . . . . . . . . . . . . 924.17 Extension de notre hirarchie des Destinations, incluant la notion

de service ditinraire . . . . . . . . . . . . . . . . . . . . . . . . . 924.18 Extension de la hirarchie des destinations, pour les destinations

de type parallle . . . . . . . . . . . . . . . . . . . . . . . . . . . 934.19 Exemple dintgration de CloneDestinations et de RendezVous-

Destinations dans un itinraire de type parallle . . . . . . . . . 944.20 Hirarchie de classes issue de la classe ItineraryManager . . . . . 964.21 Hirarchie de la classe ItineraryManager tendue pour les itin-

raires parallles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 974.22 Algorithme du MigrationStrategyManager . . . . . . . . . . . . . 984.23 Fonctionnement de la cration et du suivi dun itinraire . . . . . 100

5.1 Hirarchie des descriptifs des sous-rseaux . . . . . . . . . . . . . 1055.2 Interface pour la saisie du descriptif dun sous-rseau . . . . . . . 1065.3 Interface pour la slection du constructeur de la Destination . . 1075.4 Interface pour la saisie dune Destination . . . . . . . . . . . . 1075.5 Les services de la plate-forme vus par IC2D . . . . . . . . . . . . 1095.6 Rpartition des services de la plate-forme sur deux nuds diffrents109

5.7 Le rcapitulatif des services de notre plate-forme agents mobilespour ladministration systme et rseau . . . . . . . . . . . . . . . 1105.8 Interface de visualisation de la topologie . . . . . . . . . . . . . . 1125.9 Onglet de visualisation des informations dun lment . . . . . . . 1135.10 Les services de la plate-forme et des agents mobiles dadministra-

tion vus par IC2D . . . . . . . . . . . . . . . . . . . . . . . . . . . 1135.11 Lancement dun agent mobile dadministration . . . . . . . . . . . 1145.12 Interrogation distance de lagent mobile via la GUI . . . . . . . 1155.13 AgentMonitoringFrame : Supervision des ressources systme dun

lment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1155.14 Onglet de visualisation de la charge rseau dun quipement actif 116


18Jan2008


10/192

Table des figures 7

5.15 Schma dun rseau quelconque . . . . . . . . . . . . . . . . . . . 118

5.16 Topologie obtenue par lalgorithme . . . . . . . . . . . . . . . . . 1215.17 Schma dune migration automatique des services au plus prochedu sous-rseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

6.1 Interaction entre lagent mobile, lItineraryServer et lItinerary-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

6.2 Les mthodes publiques de la classe de lItineraryManager . . . 1326.3 Les mthodes prives ou protges de la classe de lItineraryMa-

nager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1336.4 Un ItineraryManager pour la collecte de donnes sur des impri-

mantes du sous-rseau reprsent par un ItineraryServer . . . . . 134

6.5 Itinraire couvrant tout le rseau : ItineraryManagerWholeNetwork 1356.6 Classe MgtMigrationStrategyManagerImpl . . . . . . . . . . . . 1366.7 Exemple de code inspir par la gestion des traps de AdventNet

pour instancier un agent mobile de gestion de traps . . . . . . . . 1376.8 Un agent gnrique permettant de grer une trap SNMP . . . . . 1376.9 Classe abstraite de lAgent . . . . . . . . . . . . . . . . . . . . . . 1396.10 Un agent mixte, rcuprant les ressources du systme sur chaque

nud et la table ARP de chaque Agent SNMP . . . . . . . . . . . 1406.11 Code du lanceur de lAgentMix . . . . . . . . . . . . . . . . . . . 1416.12 LAgentSnmpV3 qui dialogue en SNMP V3 avec des quipements

actifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1436.13 La dfinition dune destination pour le protocole SNMP V3 . . . . 1436.14 Un exemple dun ItineraryManager pour des destinations du type

SNMP V3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1446.15 Principe de scurisation . . . . . . . . . . . . . . . . . . . . . . . 1456.16 Classe de lItineraryManagerParalleleWholeNetwork . . . . . . 1466.17 Classe de la CloneDestination . . . . . . . . . . . . . . . . . . . 1476.18 Classe de la RendezVousDestination . . . . . . . . . . . . . . . . 1496.19 Classe abstraite de lAgentGeneric - agent secondaire . . . . . . . 1506.20 Classe de lAgentClone . . . . . . . . . . . . . . . . . . . . . . . . 151

7.1 Schma du rseau dvaluation avec un dbit modifiable sur le lieninter-rseau (via la machine bourail) . . . . . . . . . . . . . . . . 155

7.2 Collecte du groupe System (100Kbps-200Kbps) . . . . . . . . . . 1567.3 Collecte du groupe System (1Mbps-5Mbps) . . . . . . . . . . . . . 1577.4 Collecte de la table de Routage (100Kbps-200Kbps) . . . . . . . . 1587.5 Collecte de la table de Routage (1Mbps-5Mbps) . . . . . . . . . . 1587.6 Collecte de la table ARP (100Kbps-200Kbps) . . . . . . . . . . . 1597.7 Collecte de la table ARP (1Mbps-5Mbps) . . . . . . . . . . . . . . 1607.8 Comparatif des fonctions par dbits . . . . . . . . . . . . . . . . . 1607.9 Schma de la configuration dvaluation avec un rseau sans fil . . 161


18Jan2008


11/192

8 Table des figures

7.10 Interrogation des agents SNMP en Client/Serveur et avec agent

mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1637.11 Retour systmatique la station de dpart . . . . . . . . . . . . . 1647.12 Estimation du vidage de lagent mobile . . . . . . . . . . . . . . . 1647.13 Schma dun rseau Wifi fonctionnant en mode ad hoc . . . . . . 1667.14 Schma du rseau pour lautoconfiguration des VLANs . . . . . . 168

9.1 Jini du ct serveur . . . . . . . . . . . . . . . . . . . . . . . . . . 1769.2 Jini du ct du client . . . . . . . . . . . . . . . . . . . . . . . . . 1779.3 Accs Wifi en mode infrastructure . . . . . . . . . . . . . . . . . . 1809.4 Accs Wifi en mode ad hoc . . . . . . . . . . . . . . . . . . . . . 180


18Jan2008


12/192

Liste des tableaux

2.1 Exemple de rsultat de la commande ping . . . . . . . . . . . . . 222.2 Exemple de rsultat de la commande arp . . . . . . . . . . . . . . 232.3 Exemple de rsultat de la commande traceroute . . . . . . . . . . 232.4 Exemple de rsultat de la commande nmap -sT 192.168.80.0 . . . 242.5 Informations principales de la MIB-2 SNMP . . . . . . . . . . . . 272.6 Oprations dfinies par le protocole SNMP . . . . . . . . . . . . . 292.7 Exemple dune table de routage obtenue en SNMP . . . . . . . . 302.8 Exemple dune table ARP obtenue en SNMP . . . . . . . . . . . . 302.9 Exemple dutilisation de la commande snmpset sur un commutateur 31

4.1 Routines de service . . . . . . . . . . . . . . . . . . . . . . . . . . 764.2 Primitives de migration (mthodes statiques) . . . . . . . . . . . . 77

4.3 API dexcution automatique de mthode, notamment sur dpartet arrive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.4 API dutilisation dun itinraire . . . . . . . . . . . . . . . . . . . 804.5 Actions menes selon les types de Destination . . . . . . . . . . . 864.6 Actions menes selon les types de Destination, version tendue . . 99

5.1 Explication des Tags du service de description dun sous-rseau . 1055.2 Extrait de la MIB BRIDGE dot1dTpFdb . . . . . . . . . . . . . . 1185.3 Liste rsultante de lnumration des chemins . . . . . . . . . . . 1185.4 Liste rsultante de lnumration des chemins sans connexion im-

possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

5.5 Liste rsultante de lnumration des chemins sans connexion im-possible et indirecte . . . . . . . . . . . . . . . . . . . . . . . . . . 119

5.6 Liste rsultante pour la construction de la topologie . . . . . . . . 1205.7 Rpartition par catgories dlments sur un rseau . . . . . . . . 125

9


18Jan2008


13/192

10 Liste des tableaux


18Jan2008


14/192

Chapitre 1

Introduction

1.1 Contexte

De nos jours, toutes les entreprises sont quipes au minimum dun rseaulocal, et pour les plus importantes dentre elles de rseaux longue distance (WideArea Network). Ladministration de rseaux est devenue un point critique danstoutes ces entreprises par lhtrognit mme des lments composant le rseau.Du fait de cette htrognit, il devient indispensable de surveiller en perma-nence les lments-clefs du rseau, afin que les utilisateurs ne soient pas affectspar des incidents de fonctionnement et que la perte dexploitation soit la plus

faible possible en cas dincident. Pour cela, les entreprises investissent dans desoutils dadministration de rseau trs onreux [35, 37] et qui ne sont pas nces-sairement adapts chacune dentre elles.

Un systme dadministration de rseau, qui fournit des mcanismes de sur-veillance, est compos dune ou plusieurs stations de supervision qui commu-niquent entre elles et avec les lments du rseau par un protocole dadministra-tion de rseau, les plus connus tant SNMP [87] et CMIP [104]. Il est ncessairedarriver le rpartir dans les sous-rseaux de lentreprise pour diminuer lutili-sation de la bande passante sur les liens inter-rseaux, damliorer la ractivitdu systme dadministration en le distribuant sur chaque sous-rseaux de lentre-

prise.

1.2 Motivation

Il y a de plus en plus dlments dans les rseaux des entreprises quun admi-nistrateur doit surveiller. Pour cela il dispose, normalement, doutils pour analyserson rseau, surveiller son systme, mais une plate-forme agents mobiles peutapporter une aide substantielle un administrateur. En effet, certaines tchesroutinires, comme par exemple leffacement de fichiers temporaires ou le d-ploiement de logiciels, peuvent tre directement effectues par des agents mobiles

11


18Jan2008


15/192

12 Introduction

et relativement autonomes. La programmation de tels agents mobiles peut tre

simplifie ds lors quun cadre dadministration de systmes et de rseaux four-nissant les outils appropris est disponible. Par exemple, linventaire automatisdu parc informatique est une opration facilement ralisable avec une technique agents mobiles par laquelle on dploit un ou plusieurs agents autonomes. Lemcanisme de migration fourni dans les plates-formes agents mobiles permet defaire dplacer sans souci les agents mobiles et de faire excuter automatiquementune tche pr-programme adapte une opration dadministration localementsur chaque lment. Il est prsent admis que les agents mobiles dans un cadredadministration systme et rseau permettent la rduction du temps de traite-ment des messages changs entre des lments du rseau, permettent de limiterla bande passante ncessaire aux oprations dadministration distantes, et enfinle traitement local des informations permet de ragir plus rapidement aux chan-gements dans le rseau [64]. Par ailleurs, la technologie des agents mobiles sembleaussi adapte ladministration des rseaux en mergence que sont les active net-works, notamment en facilitant le dploiement des tches dadministrations dansce nouveau type de rseau [75].

Pour utiliser des agents mobiles dans un cadre dadministration systme etrseau, la mise en uvre ditinraires permettant lexcution de tches dadmi-nistration est un besoin pour rendre compltement autonomes ces agents mobilespendant lexcution des tches pr-programmes. Idalement, un itinraire dyna-miquement cr par la connaissance automatique de linfrastructure du rseau,

serait adapt pour suivre lvolution des rseaux et des services que ces rseauxpeuvent fournir et pour dployer dynamiquement, en parallle si ncessaire, lesagents mobiles dadministration ayant en charge la supervision de tels rseaux.Un tel concept ditinraire dynamique et intelligent pour son suivi, offrirait plusdavantages quun itinraire statique, qui plus est dfini manuellement : litinraireserait toujours jour, et son suivi serait adapt aux conditions rseaux environ-nantes, cest--dire prenant en compte des pannes dans le rseau, les nouveauxlments, et ce de manire compltement transparente ladministrateur.

Donnons un exemple ditinraire que lon peut appliquer au genre humain.Imaginons un voyageur partant de Nice destination de Nouma, pour aller

sinstaller en Nouvelle-Caldonie. Dcrivons plus prcisment son itinraire devoyage. A laroport de Nice-Cte dAzur, notre voyageur se rend au comptoir dela compagnie afin de rcuprer son titre de transport. Il prend son premier avion destination de Paris, dparts Internationaux. A laroport de Roissy, il rcupredes prsents pour ses amis no-caldoniens et les emportent avec lui dans lavionqui lamne Osaka, aroport de transit. Profitant de la baisse du cours du Yen,notre voyageur acquiert un appareil photo de bonne qualit afin de ramener dessouvenirs de son voyage. Arriv destination, notre voyageur offre les prsents ses amis sur le territoire. Nanmoins, notre voyageur noubliera pas de rester encontact avec sa ville de dpart.

Revenons notre agent mobile. En se basant sur le descriptif de litinraire de


18Jan2008


16/192

Contribution et organisation du manuscrit 13

voyage, notre agent mobile se rend de sa station de dpart (Nice) vers la station

Roissy, premier point darrt. Sur la station Roissy, il excute une premire col-lecte de donnes avant de reprendre son chemin vers la station Osaka. Deuximepoint darrt, pour lequel lagent mobile prend une image de ltat du systme.Lagent mobile se dirige ensuite vers sa station darrive, Nouma, o il termineson itinraire. Mme distance, lui et sa station dorigine peuvent rester en com-munication et ainsi notre agent mobile peut transmettre les informations quil acollectes pendant son itinraire.

Pour gnraliser une telle solution, un administrateur doit tre en mesure defournir un itinraire dadministration aux agents mobiles. La cration de ces itin-raires peut tre statique, cest--dire des itinraires dfinis manuellement rseaupar rseau. Une solution gnralisable qui donnerait des itinraires dynamiques etadaptables selon les rseaux et les lments qui y sont connects est plus appro-prie, cause des changements incessants qui surviennent dans les rseaux. Pource faire, la connaissance de linfrastructure interconnectant les lments entreeux est ncessaire, typiquement la topologie des diffrents rseaux constituant lerseau de lentreprise.

1.3 Contribution et organisation du manuscrit

Dans un premier temps nous dtaillons le mtier de ladministration des sys-

tmes et de rseaux afin de mieux cerner lintrt et les difficults dun tel mtierau sein des entreprises (chapitre 2).Lmergence des plates-formes agents mobiles et leur intgration possible

dans le monde de ladministration systme et rseau permettent denvisager dessolutions pour aider un administrateur dans le mtier quil exerce jour aprsjour, afin de satisfaire aux contraintes dexploitation des systmes et des rseauxdont il a la charge. Une analyse comparative dtaille de telles plates-formes estprsente dans le chapitre 3. Elle permet de mettre en vidence lintrt quepourrait avoir le fait de disposer ditinraires dadministration qui puissent treconstruits dynamiquement plutt que statiquement.

Ce travail de thse consiste donc proposer la dfinition dun mcanismede fabrication puis dutilisation ditinraires dynamiques pour ladministrationsystme et rseau. Ces itinraires, dfinis dynamiquement, et dans un premiertemps sous-rseau par sous-rseau, sont des itinraires locaux qui sont par lasuite combins dynamiquement entre eux de sorte pouvoir prendre en consid-ration lintgralit de larchitecture superviser. Nous validons cette dfinitionen fournissant une plate-forme complte ainsi quun cadre de programmationdagents mobiles dadministration systme et rseau. Pour ce faire, nous nousbasons sur la bibliothque ProActive pour le calcul parallle, rparti et mobile.

En nous basant sur le modle de programmation dagents mobiles quoffre la


18Jan2008


17/192

14 Introduction

bibliothque ProActive, nous dcrivons quelles extensions nous y avons apportes

dans le but de dfinir un mcanisme ditinraires pour ladministration systmeet rseau (chapitre 4).La conception dune plate-forme dadministration base dagents mobiles

ProActive mettant en uvre des itinraires dadministration est dcrite en termesde services quil est ncessaire de mettre en place (chapitre 5). Une prsentationdtaille dun algorithme de dcouverte de la topologie est ensuite donne. Cetalgorithme a pour objectif de fournir la plate-forme dadministration dveloppedes listes dlments dcouverts, afin de permettre la programmation aise diti-nraires dadministration pour des agents mobiles dadministration systme etrseau.

Une fois une telle plate-forme disponible, nous sommes en mesure dexpliciteren dtails comment programmer aisment des agents mobiles dadministrationsystme et rseau (chapitre 6).

Le chapitre 7 a comme intrt de valider cette plate-forme et son applicabilit.On fournit des exemples rels dimplantation dagents dadministration et desmesures et des analyses de performances comparatives avec de ladministrationclassique SNMP centralise, et ce pour une large gamme de configuration derseau.

Nous concluons par un rcapitulatif de la contribution que nous avons ap-porte quant la mise en uvre des itinraires dadministration, et donnons lesperspectives associes une telle mise en uvre : supervision dune plate-forme

agents mobiles, supervision et aide la rpartition des agents mobiles sur unegrille de calculs, en sont des perspectives possibles.


18Jan2008


18/192

Chapitre 2

Ladministration des systmes et

des rseaux

2.1 Motivation

Lvolution des moyens de communication mis la disposition des entreprises,lhtrognit de linfrastructure des rseaux et des lments qui les composent,la quantit dinformations dont veulent disposer les entreprises, tout cet ensemblencessite dapporter une cohrence dans le fonctionnement de linfrastructure de

communication.Pour ce faire, et malgr la diversit des lments constituant le cur du rseau(par exemple les quipements actifs) proposs par les constructeurs, ladminis-tration des systmes et des rseaux repose fondamentalement sur la connaissancede linfrastructure des rseaux et sur celle du fonctionnement des systmes in-formatiques entrant en jeu. Le fonctionnement de ces systmes doit tre assurpar un ou plusieurs administrateurs, en fonction du nombre dlments qui in-terviennent au sein de linfrastructure de communication. Ces administrateurspeuvent travailler de concert pour assurer la maintenance des diffrents mat-riels, la mise--jour des logiciels, la prparation et lvolution des infrastructures

et la mise en service des nouveaux quipements. La connaissance du fonction-nement des rseaux permet aux administrateurs de choisir le type de techniquesadaptes afin den assurer la prennit (par exemple doublage des quipementsactifs, liens de secours, liens hertziens, etc..).

Pour obtenir un fonctionnement quasi-permanent des systmes et des rseaux,les administrateurs doivent pouvoir rcuprer tout instant un rapport sur ltatdu fonctionnement du rseau et de celui des systmes qui y sont connects. Celaimplique une collecte des informations disponibles dans le rseau pour dterminerson tat. Les administrateurs peuvent dterminer, par la collecte des informations,les dfaillances possibles et les surcharges pouvant amener un dysfonctionne-ment. Comme la quantit dinformations recueillie est importante, il va de soi que

15


18Jan2008


19/192

16 Ladministration des systmes et des rseaux

cette tche doit tre automatise pour que ladministrateur nait que de linfor-

mation utile pour effectuer son travail. Cest dans cette optique que les stationset les logiciels dadministration ont t crs. Ces logiciels donnent une vue com-plte du rseau et ils permettent ladministrateur (ou aux administrateurs) uneintervention rapide et efficace.

Dans la section 2.2 nous dcrirons les tches des administrateurs et les couchesdu modle OSI entrant en jeu dans un systme dadministration de rseau. Lekit de survie de ladministrateur rseau, cest--dire les outils de base utiles unadministrateur, sera prsent dans la section 2.3

Par la suite nous dfinirons dans la section 2.4 les protocoles dadministra-tion de rseau et les outils les plus usits pour raliser des tches dadministra-tion. Toutefois, les outils les plus usits dans le mtier de ladministration rseaufournissent des informations qui ne peuvent malheureusement pas tre prises encompte automatiquement par dautres outils ou plates-formes que ladministra-teur souhaiterait mettre en uvre.

2.2 Dfinition de ladministration des systmeset des rseaux

Ladministration des systmes et des rseaux consiste contrler, coordonneret surveiller les diffrentes ressources mises en uvre afin de fournir des services

oprationnels aux utilisateurs : ces ressources sont les quipements, le rseau, lesservices sont ceux offerts par les diffrents serveurs, les applications, Internet,etc... Par exemple, ces services peuvent tre :

laccs aux donnes et aux ressources informatiques partages (base de don-nes, annuaires, etc)

la consultation des sites Internet ; laccs au rseau informatiqueToute entreprise possdant un grand nombre dordinateurs, emploie des ad-

ministrateurs de rseau et de systmes pour assurer la qualit et la continuit duservice.

Le modle de ladministration de rseau selon la classification SMFA (Specific

Management Functional Areas [29]) consiste en 5 domaines de comptence : lagestion des performances, la gestion des fautes, la gestion de la configuration, lagestion des informations comptables, la gestion de la scurit.

2.2.1 Gestion des performances

Un administrateur rseau a comme responsabilit la mise en place, le suiviet lvolution des moyens de communication. Compte tenu de laugmentationrgulire du trafic sur un rseau local, par exemple, un administrateur doit envi-sager le changement de linfrastructure rseau afin damliorer le dbit offert auxutilisateurs. En fonction de la charge du rseau quun administrateur supervise,


18Jan2008


20/192

Dfinition de ladministration des systmes et des rseaux 17

il peut prvoir le changement de la structure de communication du rseau (cf.

figure 2.1) en introduisant une segmentation du trafic par lajout dun nouvelquipement actif (par exemple, un commutateur). La consquence directe seralamlioration du trafic dans le cur du rseau et une meilleure segmentation dutrafic (cf. figure 2.2) dans chaque sous-rseau connect.

Pour superviser les moyens de communication, ladministrateur peut disposerdoutils danalyse (par exemple Multi Router Traffic Grapher [56], HP NetworkNode Manager [35]) afin de suivre en temps rel les diffrents flux qui circulent surles rseaux dont il a la charge. De tels outils danalyse permettent deffectuer desprospectives dvolution de linfrastructure physique tant sur le point de vue duchangement de dbit que sur le type de liaison utilise (par exemple : une liaisonspcialise plutt quune liaison point--point Numris active la demande).

Hub Hub

! Power

COL123 45678 1236 2550801210010

Ether10/100

! Power

COL123 45678 1236 2550801210010

Ether10/100

Fig. 2.1 Rseau Ethernet non segment

Commutateur

Hub Hub! Power

COL123456 78 1236 2550801210010

Ether10/100

! Power

COL123456 78 1236 2550801210010

Ether10/100

Switch

Ethernet

Fig. 2.2 Rseau Ethernet segment

2.2.2 Gestion des fautes

Quels que soient les systmes informatique dont ladministrateur a la charge,chacun de ces systmes ne peut tre exempt derreurs. Le travail de ladminis-trateur consiste assurer le fonctionnement de ces systmes. Par exemple, lapanne dun commutateur dans le rseau est un vnement rare mais trs impor-tant dont ladministrateur doit tenir compte dans ses procdures de gestion desincidents. Ladministrateur doit tre en mesure de pouvoir prendre les dcisionsncessaires afin de corriger dans un temps trs bref la dfaillance de son systme.Les procdures mises en place pour assurer la continuit de service ou un fonc-tionnement en mode dgrad sont des lments ncessaires pour que les usagersde linfrastructure de communication soient le moins pnaliss par des pannes surle rseau.


18Jan2008


21/192


2.2.3 Gestion de la configuration

Un administrateur de systmes informatique a pour tche linstallation, lamise en route de services rseaux et la maintenance de ces diffrents systmes.Ladministrateur assure aussi la configuration, la mise niveau des quipementsactifs de linfrastructure du rseau et il se trouve en mesure de prvoir les diff-rentes oprations de maintenance ncessaires. Par exemple, le changement de laversion dun systme dexploitation sur un commutateur faisant suite un avisdu constructeur de lquipement actif est une tche qui lui incombe et quil doitmettre en uvre.

Ladministrateur est responsable de ladressage des machines sur le rseau,il suit lvolution du parc de machines connectes et il organise, si ncessaire, le

redploiement des systmes sur son infrastructure de communication.Pour tre aid dans sa tche de gestion, ladministrateur peut disposer en fonc-

tion du type du systme dexploitation de ses systmes, doutils divers et varismais dont lusage reste souvent propritaire un type de plate-forme (WinNT,Solaris, etc..). Par exemple, Webmin [16] fonctionnant sous Linux permet unadministrateur deffectuer de la maintenance ou de la configuration de son sys-tme.

2.2.4 Gestion des informations comptables

Un administrateur peut fournir aux instances dirigeantes de son entreprise lescots engendrs par telle ou telle application. Pour cela, ladministrateur ralisedes calculs de cots en fonction des dbits rseaux utiliss, de la charge des ma-chines sur lesquelles tournent les applications. Ladministrateur doit disposer pourcela doutils pour mesurer le trafic, calculer le taux de charge des applications. Parexemple, les applications Internet payantes (http://link.springer.de) sont la charge de ladministrateur qui doit assurer pour son entreprise la comptabili-sation des accs aux services fournis et permettre louverture de nouveaux accs ces mmes services.

2.2.5 Gestion de la scuritUn administrateur systme et un administrateur rseau doivent travailler de

concert pour la mise en uvre de nouveaux services. Les administrateurs doiventassurer la scurit des informations et la scurit des accs. Par exemple, un an-nuaire dentreprise doit pouvoir tre consult mais il convient de sassurer que lapopulation ayant accs ces informations soit une population limite : un Inter-naute quelconque ne bnficierait pas des mmes droits daccs quun employ delentreprise hbergeant ce service. Il sagit donc davoir des procdures de miseen route de nouveaux services tout en prservant la scurit et la fonctionnalitdes services dj existant.


18Jan2008
http://link.springer.de/http://link.springer.de/


22/192

Le kit de survie de ladministrateur rseau 19

2.3 Le kit de survie de ladministrateur rseau

Lobjectif de cette section est de prsenter les couches du modle OSI quisont directement lies au mtier de ladministrateur rseau : la couche physique,la couche liaison de donnes et la couche rseau, toutes les trois intervenant dansle fonctionnement dun rseau. Nous donnerons les dtails des concepts et desoutils quil est ncessaire de connatre afin de pouvoir comprendre le mtier deladministrateur de rseau.

Dfinition 1 quipements actifs : Le terme quipements actifs, sous entend dansce manuscrit, les lments qui sont connects sur un rseau, qui participent sonfonctionnement et qui sont administrables, cest--dire quips dun agent SNMP.

Dfinition 2 Rseau : Le rseau est lensemble de voies de communication, con-ducteurs lectriques, etc., qui desservent une mme unit gographique, dpendantde la mme entreprise. Nous nous baserons sur cette dfinition pour nous rappro-cher plus prcisement du rseau que nous utilisons tous les jours, cest--dire unmoyen de communication et dchange entre diffrentes entits.

Ainsi, le rseau en tant quentit communiquante est la partie principale denotre proccupation puisque celle-ci se situe au cur de tout le trafic qui y circule.Il va de soi quil faut donc une architecture physique afin de relier les entits le

constituant et des protocoles de communication pour permettre ces diffrentesentits de dialoguer entre elles. Pour dfinir les diffrents niveaux permettant ces entits de dialoguer entre elles, lISO (organisation internationale de norma-lisation) a donc dfini un modle en sept couches appel modle de rfrence(modle OSI : Open Systems Interconnection). Ce modle en sept couches estdfini comme suit : Physique, Liaison, Rseau, Transport, Session, Prsentation,Application.

Dans ce modle et en rapport avec ladministration des systmes et des r-seaux, nous nous proccuperons principalement de deux couches du modle OSI :la couche liaison et la couche rseau [91]. Effectivement, ces deux couches ont

une trs grande importance puisquelles relvent activement du fonctionnementdu rseau, et quil est ncessaire dassurer leur disponibilit et leur fiabilit.

2.3.1 La couche physique

Cest la couche qui soccupe de la transmission des bits dinformation de faon ce que le rcepteur des donnes recueille une information non altre par le canalde communication.

La partie physique dune architecture rseau dpend de la qualit de serviceque lon souhaite obtenir. Plusieurs types de couche physique existent, commela partie en cble coaxial (10Base-2 ou 10Base-5 [1]), le cble tlphonique


18Jan2008


23/192


paires torsades (10BaseT ou 100BaseT [1]), les connexions en fibre optique, les

connexions par voie hertzienne, etc.., tout ce qui permet de faire circuler de lin-formation. La qualit de linstallation de cette couche est primordiale puisquelle aune incidence sur le fonctionnement mme du rseau. Par exemple, un connecteurRJ45 mal serti engendrerait des perturbations sur le rseau (collision, tentativepour trouver la vitesse du mdia, etc..).

Le contrle de la qualit de cette liaison peut se faire par exemple dans le casdun rseau 10Base-T, par lutilisation dun testeur de cbles. Cette techniquepermet de se rendre compte des problmes de connectivit lectrique sur le mdiautilis.

2.3.2 La couche liaison de donnesLa tche principale de cette couche est de prendre un moyen de communi-

cation brut et de le transformer en une liaison qui parat exempte derreurs detransmission la couche rseau (on parle de trames). Quelques types de protocolessont utiliss pour assurer le fonctionnement du canal de communication comme leprotocole CSMA/CD [60], lanneau jeton [61], ou de faon plus volue lATM(Asynchronous Transfert Mode [5]).

Pour vrifier la qualit du canal de communication offerte par la couche deliaison dans le cas dune topologie rseau en toile, une technique simpliste maisassez efficace consiste utiliser deux ordinateurs connects sur un concentrateur

(Hub) ou un commutateur (Switch) et dappliquer un outil client/serveur quimet des trames depuis un poste destination de lautre. Si dans ce cas les tramesmises sont reues par lautre ordinateur, alors le canal de communication peuttre considr comme fiable.

Nous allons dtailler les rseaux de type Ethernet[1]. Ces rseaux sont les pluscourants et la technologie Ethernet a permis une large diffusion de ces rseauxdans les entreprises. Dans ce type de rseau, les stations partagent le mmecanal de communication et elles changent entre elles des trames. Le protocoleCSMA/CD a t dfini pour laccs partag ce mdia de communication.

Les premiers rseaux de type Ethernetutilisaient une technologie de type cble

coaxial pour fonctionner selon une topologie en bus (cf. figure 2.3). Ces rseauxfonctionnaient sans quipement actif intermdiaire. Lvolution des technologies apermis dabandonner ce type de technologie et de passer des rseaux construitssur une topologie en toile. Le cur de ces rseaux est compos dquipementsactifs intelligents (par exemple pour une meilleure gestion du trafic). Nous tudie-rons plus prcisment les rseaux Ethernet en toile puisque ceux-ci ncessitentla prsence dquipements actifs pour fonctionner. En effet, la construction de latopologie en toile ncessite du matriel actif pour connecter le cur du rseauet les autres lments (PC, Imprimantes, quipements actifs , etc..). La figure2.4 prsente un exemple de rseau typique sur lequel nous avons conduit nosexprimentations.


18Jan2008


24/192

Le kit de survie de ladministrateur rseau 21

Postes de travail sur le rseau, PC, Mac, Serveurs dimpressions, etc...

Fig. 2.3 Exemple dune topologie en bus

Station de supervision Modem

Serveur Web, Messagerie

Proxy, Annuaire

Commutateur

Commutateur, coeur du rseau

Vers lInternet ou un autre rseau de lentreprise

Pont Ethernet

Concentrateur

Postes de travail sur le rseau, PC, Mac, Serveurs dimpression, etc...

CommutateurPower

COL12 345 67 8 12 3 6 2 550801210010

Ether10/100

CommutateurPower

COL12 345 67 8 12 3 6 2 550801210010

Ether10/100

Routeur

Fig. 2.4 Exemple dune topologie en toile

Avec lvolution des techniques relatives la couche de liaison de donnes,plusieurs quipements actifs existent sur le march informatique, dont principa-lement :

les ponts Ethernet (Bridges) : ces quipements actifs ne font que rpter lesignal du canal de communication destination des autres interfaces quilspossdent,

les concentrateurs (Hubs) : ces quipements actifs rptent le signal reusur tous les ports de sortie except celui par lequel est arrive linformation,

les commutateurs (Switches) : ces quipements actifs rptent le signal sur

le port de sortie qui correspond ladresse 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 dun rseauvers un autre rseau de destination.

Lavantage dune topologie en toile par rapport une topologie en bus est quelorsque une connexion du rseau devient dfaillante sauf sur le cur du rseau,les communications sur le rseau perdurent lexception du brin dfaillant, saufsi tous les services du rseau sont concerns par cette dfaillance. Il sagit leffectivement dune meilleure scurit pour assurer une qualit de service plusimportante aux usagers.


18Jan2008


25/192


2.3.3 La couche rseau

Cette couche permet de grer la faon par laquelle les informations (ici pa-quets) sont achemines depuis lmetteur jusquau destinataire, et de sassurerque linformation sera rcupre dans le mme ordre quelle a t mise. Le pro-tocole rseau le plus usit de nos jours reste le protocole IP [39], avec les deuxcouches de transport : UDP [96] et TCP [93]. Pour avoir un aperu du fonc-tionnement dun rseau, nous allons prsenter quelques outils qui servent dans lesuivi et lobservation de la couche rseau. Nous ne dtaillerons pas les protocolesassocis.

Ping-Pong Pour vrifier la connectivit entre deux ordinateurs possdant une

adresse IP, le protocole ICMP (Internet Control Message Protocol) [38] est uti-lis. Son fonctionnement de base est le suivant : mission dun datagramme versune machine de destination (ICMP Echo-Request), qui demande la machine dedestination de rpondre par un datagramme vers lmetteur (ICMP Echo-Reply).Son fonctionnement est relativement simple, mais lutilisation de ce protocole per-met de dterminer rapidement la panne dun quipement actif du rseau. Il sagitici dutiliser une des nombreuses fonctionnalits de ce protocole. La commandesystme associe la plus utilise est la commande ping(cf. table 2.1 par exemple).

Ping de pacifique.iufm.unice.fr vers www.unice.fr

Rponse de www.unice.fr octets=32 temps0) {

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 nodesfor (int i=0;i


155/192

152 Programmation dagents mobiles pour ladministration systme et rseau


18Jan2008


156/192

Chapitre 7

Performances et valuation des

agents mobiles pourladministration systme etrseau

7.1 Introduction

De manire rcurrente lutilisation des agents mobiles pour ladministrationsystme et rseau donne les performances comme critre de prfrence des agentsmobiles face au modle Client/Serveur SNMP. En effet, cela se traduit par uneconsommation de dbit rseau moindre ([85],[101]). Lintrt de ce chapitre est deconforter cette ide, dans le cadre de notre plate-forme. Nous allons montrer que,en ayant automatis la cration et le suivi ditinraires dynamiques, certaines op-rations de gestion et dadministration ne requirant pas de dlai dexcution sontutilement ralisables par des agents mobiles. Par contre, nous montrerons aussique des contraintes subsistent quant lutilisation des agents mobiles pour lad-ministration notamment dans le cadre des rseaux sans fils (WLAN). Ce nest pas

lvaluation du temps de cration dun itinraire dynamique que nous cherchons valuer finement dans ce chapitre, car nous avons pu constater que lorsque latopologie du ou des rseaux est connue, ce temps de cration de litinraire va-rie toujours de quelques millisecondes une seconde. Par ailleurs, le temps deconstruction de la topologie est lui mme dj valu dans la section 5.5.5.

Par contre, il sagit dans ce chapitre dgalement valider lexploitation de notreplate-forme dans un contexte rel, requirant des oprations dadministration.

A cette fin, quelques performances o le dbit du rseau et o le nombredhtes varient vont tre dcrites et values. On cherche dmontrer quil existeun seuil partir duquel il devient plus intressant denvoyer un agent mobilepour raliser la mme fonction dadministration, car transmettre chaque variable

153


18Jan2008


157/192

154Performances et valuation des agents mobiles pour ladministration systme et rseau

SNMP individuellement en Client/Serveur vers la station dadministration nest

pas rentable (en terme uniquement de performances). Il sagit aussi de mettreen vidence le fait que le choix du Client/Serveur SNMP ou des agents mobilesnest finalement pas quune question de performances, mais que ce choix dpenden fait foncirement du type de fonction dadministration raliser, ou du typedenvironnement physique (ce dernier pouvant quand mme avoir une incidencesur des performances du rseau sous-jacent).

7.2 Analyse des performances

On suppose, dans lvaluation de nos performances, que la plate-forme est

dj dploye sur tous les lments intervenant dans la phase de test.

7.2.1 Expriences sur un rseau local

Nous avons cherch valuer, dans cette section, le temps dexcution duneopration dadministration partir dune station dadministration connecte surun rseau distant.

7.2.1.1 Descriptif du rseau de test

Pour notre jeu de tests on se base sur deux rseaux (cf. figure 7.1). Sur lerseau A, la station dadministration (Yat)et sur le rseau B, 11 ordinateurs dediffrentes puissances et capacits, dont la machine Bourail. Ces machines sontdes PCs (fonctionnant sous Win95, Linux, WinNT, Win2K, WinNt TerminalServer) et des imprimantes en rseau (HP 4100 et HP 2100) avec un agent SNMPactif. Toutes ces machines seront la cible dune opration dadministration.

Pour faire varier le dbit du lien inter-rseau, nous avons utilis un Pentium 133Mhz (Bourail) fonctionnant sous FreeBSD avec ip_dummynet [74] (cf. figure7.1) 1. Par ce biais, nous pouvons simuler le changement du dbit du lien inter-rseau de 100Kbps 10Mbps. La bande passante de chaque sous-rseau (A et B)est de 100Mbps.

7.2.1.2 Itinraire dadministration

Litinraire des agents mobiles consiste effectuer une migration au dpartpour aller de la machine Yat vers la machine Koumac, une opration SNMPdepuis Koumac vers chacun des lments du rseau B, et une migration chaquefin de litinraire pour retourner sur le nud ProActive de la machine Yat afinde rapatrier les rsultats de lvaluation. Litinraire Client/Serveur consiste

1Ce PC routeur hberge un agent SNMP actif du ct du rseau B donc nous le considronscomme un hte administrable du rseau B


18Jan2008


158/192

Analyse des performances 155

PC Routeur (Bourail)

(Yate)

5 serveursWin95 +

Agent SNMP(WinNT)

RouteurImprimante

reseau

Chemin de migration

Trafic SNMP

(Koumac)

Reseau B (100 Mbps)

Reseau A (100 Mbps)

CiscoSystemsCisco 7000 SERIES

Fig. 7.1 Schma du rseau dvaluation avec un dbit modifiable sur le lieninter-rseau (via la machine bourail)

effectuer toutes les oprations SNMP depuis la machine Yat vers chacun deslments du rseau B. Dans les deux cas, pour simuler un rseau dune tailleplus importante, nous ritrons plusieurs fois la visite de chacun des lments du

rseau B (comme si sur le rseau B, il ny avait pas 9 lments mais bien plus).

7.2.1.3 Les oprations dadministration mises en uvre

Pour valuer les performances, nous avons mis en uvre trois fonctions dad-ministration distinctes dans le but de faire varier le nombre de requtes SNMP lintention de chaque agent SNMP. Nous avons utilis la collecte du groupe Sys-tem, de la table IpRouteTable et pour finir de la table IpNetToMediaTable, pluscommunment connue sous le nom de table ARP. Toutes les requtes qui sont

ralises dans les jeux de test sont effectues en mode squentiel afin dobtenirdes carts voulus dans les rsultats.Lobjectif de cette valuation est de pouvoir analyser le temps dexcution

des diffrentes mthodes en comparant la solution traditionnelle Client/Serveuret les agents mobiles pour ladministration. Nous faisons donc varier le dbit inter-rseau gr par la machine Bourail afin de simuler des connexions distantes. Nousnengendrons pas de perte de paquets, mme si loutil utilis, ip_dummynet, lepermet. En mme temps, nous augmentons artificiellement le nombre dhtespour essayer de tirer des conclusions permettant de donner la prfrence lasolution Client/Serveur ou agent mobile selon les cas et les configurations derseau tests.


18Jan2008


159/192


Groupe System : La collecte des variables SNMP du groupe System (taille

des paquets en moyenne pour cette fonction est de 42 octets2

) sur un rseauayant un lien faible dbit, variant de 100Kbps 200Kbps (cf. figure 7.2), permetde mettre en vidence que sur un nombre important dagents SNMP le tempsdexcution total de lopration dadministration en utilisant un agent mobileest meilleure. Alors que pour une quinzaine dhtes sur lesquels linformationest collecte, le temps dexcution est comparativement le mme, un cart sanscesse croissant apparat au del. On constate en fait, que la faible valeur du dbit(de 100Kbps 200Kbps) ne perturbe pas lagent mobile puisque celui excute lafonction dadministration en un temps total quasi similaire, alors mme quil doitrevenir la station dadministration en transportant les donnes collectes.

0

2000

4000

6000

8000

10000

12000

0 10 20 30 40 50 60

Temps(enMillisecs)

Hotes

System

Client/Server (100Kbps)Client/Server (200Kbps)Agent Mobile (100Kbps)Agent Mobile (200Kbps)

Fig. 7.2 Collecte du groupe System (100Kbps-200Kbps)

Le mme comportement est obtenu en augmentant le dbit inter-rseau (de1Mbps 5Mbps) (figure 7.3). En conclusion de ces 4 configurations de test, dans

lesquels le dbit inter-rseau est bien moindre que le dbit de chaque rseau, latechnologie agent mobile permet de tirer partie des dbits rseau (100Mbps,bien mieux que le modle Client/Serveur qui subit la lenteur du lien inter-rseaupour chaque lecture de variables SNMP.

Groupe IP-ipRouteTable : Afin dexprimenter la collecte dun nombre devariables SNMP non dfini statiquement, nous avons collect sur chaque agent

2uniquement pour la partie protocolaire SNMP


18Jan2008


160/192


0

2000

4000

6000

8000

10000

0 10 20 30 40 50 60

Temps(enMillisecs)

Hotes

System

Client/Server (1Mbps)Agent Mobile (5Mbps)Client/Server (5Mbps)Agent Mobile (1Mbps)

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 octets3

). Le nombre minimal de variables qui sont collectes estde 6 (ipRouteDest, ipRouteIfIndex, ipRouteNextHop, ipRouteType, ipRouteProto,ipRouteMask) (, mais comme il sagit dune table et que plusieurs entres danscelle-ci peuvent exister, il est impossible de dterminer lavance le nombre devariables collectes. Cette exprience est mise en uvre sur les mmes configura-tions de test que prcdemment (cf. figure 7.4 et figure 7.5).

Par la quantit de variables collectes depuis la station dadministration, lemodle Client/Serveur est trs pnalis par le goulot dtranglement induit parle faible dbit du lien inter-rseau. Une nette diffrence se ressent par rapport lagent mobile qui lui, comme dans lexprience prcdente, tire un grand avantage

du dbit du rseau B 100Mbps.

Groupe IP-ipNetToMediaTable : Il sagit, ici aussi, de collecter un nombreimportant et non statiquement dfini de variables SNMP et ce en allant lire lestables ARP des agents SNMP, tables qui contiennent en gnral plus de lignes quecelles des tables de routage (taille des paquets en moyenne pour cette fonctionest de 128 octets 4). Il sagit donc daugmenter la quantit dinformation que doittransporter lagent mobile. Les variables que nous collectons sur chaque agent

3uniquement pour la partie protocolaire SNMP4uniquement pour la partie protocolaire SNMP


18Jan2008


161/192


0

50000

100000

150000

200000

0 10 20 30 40 50 60

Temps(enMillisecs)

Hotes

ip.ipRouteTable


Fig. 7.4 Collecte de la table de Routage (100Kbps-200Kbps)

0

20000

40000

60000

80000

100000

120000

140000

0 10 20 30 40 50 60

Temps(enMillisecs)

Hotes

ip.ipRouteTable


Fig. 7.5 Collecte de la table de Routage (1Mbps-5Mbps)

SNMP sont dans la table ipNetToMediaTable ( ipNetToMediaIfIndex, ipNetTo-MediaPhysAddress, ipNetToMediaNetAddress, ipNetToMediaNetType ).


18Jan2008


162/192


0

5000

10000

15000

20000

25000

30000

0 10 20 30 40 50 60

Temps(enMillisecs)

Hotes

ip.ipNetToMediaTable


Fig. 7.6 Collecte de la table ARP (100Kbps-200Kbps)

Les rsultats obtenus et prsents dans le paragraphe prcdent sont conforts

lors de cette valuation (figure 7.6 et 7.7). Plus linformation globale collecter, distance, est importante plus la technique agent mobile devient avantageuse.

Comparatif des fonctions : Pour obtenir une vue plus exhaustive de len-semble de nos valuations, nous regroupons les performances des fonctions dad-ministration collectant le groupe System et la table ARP (ipNetToMediaTable )et ce pour les diffrentes configurations o le dbit du lien inter-rseau varie entre10Kbps et 1Mbps (cf. figure 7.8). En considrant 12 lments visits (avec agentSNMP), les meilleures performances sont celles obtenues par lagent mobile quieffectue dans des dlais plus courts les mmes oprations que celles effectues avec

le modle Client/Serveur traditionnel. On peut constater toutefois, sur la figure7.8, que pour un nombre limit de variables SNMP (groupe System) collecter etque pour un nombre dlments faible (ici 12 lments), les deux solutions (agentmobile et Client/Serveur) sont presque identiques5. Un gain de temps substantielest obtenu pour la fonction collectant la table ARP de chaque agent SNMP visit.

En conclusion, le modle agent mobile est trs adapt pour effectuer des

5Certains flchissements des courbes que nous avons obtenues sont le fait dune exprimenta-tion ralise sur un rseau de production (rseau B). Nous avons choisi ce type dexprimentationcar celle-ci reflte une situation raliste.


18Jan2008


163/192


0

5000

10000

15000

20000

25000

30000

0 10 20 30 40 50 60

Temps(enMillisecs)

Hotes

ip.ipNetToMediaTable


Fig. 7.7 Collecte de la table ARP (1Mbps-5Mbps)

0

2000

4000

6000

8000

10000

100 200 300 400 500 600 700 800 900 1000

Temps(enMillisecs)

Bande passante sur Bourail (Kbit/s)

12 agents SNMP

Agent Mobile (System)Client/Server (System)

Agent Mobile (ARP)Client/Server (ARP)

Fig. 7.8 Comparatif des fonctions par dbits

tches de longue dure sur des rseaux distants, limitant ainsi lutilisation de labande passante inter-rseau. Lapproche que nous avons utilise dans ces expri-


18Jan2008


164/192


mentations est une approche de dlgation de la tche dadministration rseau,

qui est caractrise dans la littrature par le modle Static Delegated Model [85].Dans ce modle, on tire un avantage de la position de lagent mobile sur le rseaupour effectuer les oprations dadministration distance, en lieu et en place de lastation dadministration centralise du modle Client/Serveur (caractris par leStatic Centralized Model). Nos exprimentations rejoignent ainsi les exprimen-tations et les conclusions obtenues par Simes [85].

7.2.2 Expriences sur un rseau WLAN

Nous avons cherch valuer le comportement des agents mobiles sur unrseau de nouvelle gnration. Pour cela, nous avons pris en compte les rseauxde type hertzien et essay dobtenir des rsultats de performance comparerensuite avec ceux obtenus lors des exprimentations prcdentes.

7.2.2.1 Descriptif du rseau de test

Le jeu de tests que nous avons effectu est bas sur un rseau sans fil (techno-logie Wifi [59]) (cf. figure 7.9). Nous avons mis en uvre ce test pour mettre envidence les avantages et les inconvnients de la technologie des agents mobilesdans lutilisation de ce type de rseau.

Serveur HTTP + Linux (SRV) PC de test

Point dacces Wifi

commutateur 10/100Mbps

Coeur du reseau

Reseau Hertzien

PC 1 PC 2 PC 3 PC 4

100Mbps

10Mbps a 11 Mbps

Fig. 7.9 Schma de la configuration dvaluation avec un rseau 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 cur du rseau par un lien 100Mbps (commutateur Catalyst 2950). Le point daccs Wifi fonctionne en modeInfrastructure (cf annexe pour plus de dtails) et il est connect en 10 Mbps surce mme commutateur. Ce dernier dessert en mode hertzien 11Mbps, 4 PCs.Les PCs (PC1, PC2, PC3 et PC4 dans les libells des figures ci-dessous) sontdes ordinateurs identiques bass sur des Pentium II cadencs 300 MHz. Ilssont quips de 64 Mo de RAM et ils fonctionnent sous WIN98. Chacun des


18Jan2008


165/192


ordinateurs est reli au rseau par un adaptateur PCI Wifi. Un serveur HTTP,

fonctionnant sous Apache, est hberg par le serveur SRV. Ce service HTTPmet la disposition de la plate-forme agents mobiles toutes les classes Javancessaires au dploiement du code et des fonctions dadministration pour lesagents mobiles (fonction systme ou rseau).

7.2.2.2 Itinraire dadministration

Litinraire de migration des agents mobiles dans le cas des tests prsentssur le rseau Wifi est le suivant :

Dpart de SRV impliquant une migration vers le PC1 connect via une

liaison sans fil, Lagent mobile migre dun PC lautre jusquau dernier pour y effectuer

lopration dadministration, Aprs son passage sur le dernier PC (PC4), il migre vers SRV pour y effec-

tuer la dernire opration dadministration et terminer son excution.Litinraire Client/Serveur consiste effectuer lopration dadministration surtous les lments du rseau (SRV, PCs) depuis SRV.

7.2.2.3 Les oprations dadministration mises en uvre

Plusieurs sries de tests ont t ralises avec la mme fonction dadminis-tration (le mme code Java), que ce soit pour lexcution en suivant le modleClient/Serveur ou en utilisant un agent mobile. Toutes les requtes qui sont ra-lises dans les jeux de test sont effectues en mode squentiel, cest--dire sansburst, en utilisant le mme code de programmation.

Les premiers tests raliss sont bass sur le modle Client/Serveur et serventde base pour une comparaison ultrieure.

La deuxime srie de tests utilise un agent mobile pour effectuer la fonctiondadministration. On mesure les performances lors du 1er suivi de litin-

raire dfini pour ce rseau par lagent mobile (les classes Java ncessaires lexcution de lopration ne sont donc pas charges). La troisime srie de tests consiste valuer les performances lorsque le

code de lagent mobile et celui des fonctions dadministration ont dj tchargs dans la JVM de chacun des lments intervenant dans litinraire.Nous cherchons mettre en vidence lintrt du pr-chargement du codesur les nuds de la plate-forme

La quatrime srie de tests permet de mettre en vidence le fait que le poidsde lagent mobile est pnalisant sur ce type de rseau. On mesure donc lesamliorations possibles suite la dpose des donnes transportes pendantles diffrentes tapes de migration.


18Jan2008


166/192


Groupe IP-ipNetToMediaTable : Notre fonction de collecte de la table

ARP (taille des paquets en moyenne pour cette fonction est de 128 octets6

)esttout dabord excute en mode Client/Serveur partir du serveur SRV. Le rsul-tat de cette exprimentation (figure 7.10) donne un temps de collecte denviron4,5 secondes. Sur la mme figure, on constate un temps dexcution de cettefonction par lagent mobile dix fois suprieur. Ce temps dexcution est propor-tionnel au temps de chargement des classes Java dadministration et de lagentmobile sur chacun des nuds, et au fonctionnement gnral du rseau Wifi. Desperformances plus intressantes sont obtenues lorsque les classes Java sont djpr-charges. Malgr cela, le temps dexcution reste deux fois plus importantque le modle Client/Serveur.

0

10000

20000

30000

40000

50000

60000

PC 1 PC 2 PC 3 PC 4 SRV Fin Execution

Temps(enMillisecs)

Nombre dhotes visites

Migration dun AM sur un reseau sans fil

Migration + Execution SNMP en localMigration code charge+ Execution SNMP en local

C/S SNMP depuis le serveur

Fig. 7.10 Interrogation des agents SNMP en Client/Serveur et avec agentmobile

Retour la station dadministration : Dans ce jeu de test, lensemble desPCs administrer est le mme que prcdemment, mais aprs chaque visite dunPC, lagent mobile revient sur la station de dpart (SRV) pour dposer et traiterles donnes (cf. figure 7.11). Il est vident que ce type ditinraire (en "toile")nest pas raliste sur ce type de rseau faible dbit, cause du cot engendrpar de nombreuses migrations.

Toutefois, un modle dadministration plus pertinent consiste utiliser desagents stationnaires sur chaque nud du rseau Wifi et les interroger dis-tance, par exemple, partir du serveur dadministration. Ces agents stationnairespeuvent tre simplement crs partir dun agent mobile dadministration et d-ploys sur chacun des nuds du rseau. Dans une telle configuration, le rseau

6uniquement pour la partie protocolaire SNMP


18Jan2008


167/192


0

5000

10000

15000

20000

25000

30000

PC 1 SRV PC 2 SRV PC 3 SRV PC 4 SRV Fi

Temps(enMillisecs)

Hotes visites

Requete SNMP C/S, Agent Mobile : Execution depuis le Serveur Linux

Execution par AMExecution en CS

Fig. 7.11 Retour systmatique la station de dpart

ne sert que pour la collecte des donnes que chaque agent stationnaire a prparpour lagent dadministration matre localis sur la station dadministration.

0

100000

200000

300000

400000

500000

600000

0 20 40 60 80 100

Temps(enMillisecs)

Requetes

Requete SNMP C/S, Agent Mobile : 1 serveur, 4 PC connectes sur un reseau sans fil

Execution globale C/SExecution globale avec migration + vidage 10 passages

Execution globale avec migration + vidage 5 passagesExecution globale avec migration sans vidage

Fig. 7.12 Estimation du vidage de lagent mobile


18Jan2008


168/192

Exemples dutilisation des agents mobiles 165

Optimisation : Constatant que faire migrer un agent mobile sur un tel rseau

est trs pnalisant, dautant plus si la taille de lagent mobile est importante, ona pens quil serait judicieux dintercaler dans litinraire dadministration le faitdaller de temps en temps seulement, sur un nud (SRV) dans le but dy dposerses donnes pour "maigrir". On a mesur les gains obtenus, en variant la frquencede dpt (cf. figure 7.12). Malgr les migrations supplmentaires imposes pouraller "maigrir" des emplacements prvus, on constate quil y a un gain rel.

7.2.2.4 Itinraire de migration en mode ad hoc

Il existe une contrainte de localisation des nuds dans un rseau Wifi en mode

ad hoc (cf. annexe Wifi). Un nud na pas forcment la visibilit de tous les autresnuds, ce qui ncessite davoir dans notre cas des itinraires dadministration quidoivent tre modifis la vole (cf. figure 7.13).

Par exemple, prenons litinraire de migration que nous avons utilis lors denos exprimentations. SRVPC1, P1PC2, PC2PC3, PC3PC4 et PC4SRV.Si dans le rseau Wifi en mode ad hoc, les zones de couvertures hertziennes sontles 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 daccs est visible par PC1 et PC4Cela veut dire que PC1 nest pas visible de PC2 et vice versa, et que le

systme Wifi transmette donc les donnes via un nud intermdiaire (par exemplePC3). Pour viter de passer par des nuds intermdiaires ce qui augmente ledlai dexcution, on peut par exemple prparer un itinraire dadministrationdans lequel toute paire dlments successifs est forme dlments directementaccessibles. Par exemple : SRVPC1, PC1PC3, PC3PC2, PC2PC4 etpour finir PC4SRV.

Une telle ide a t propose par Migas [55] en utilisant des agents station-naires pour essayer de dterminer la politique de migration la plus adapte pourles agents mobiles dans un rseau Wifi de type ad hoc.

7.3 Exemples dutilisation des agents mobiles

7.3.1 Quelques exemples simples exploitant la propritdautonomie

En constatant que les rseaux actuels offrent de plus en plus de bande pas-sante (LAN, WAN, WLAN), nous allons introduire des exemples concrets duti-lisation des agents mobiles dans un cadre dadministration systme et rseau.Ces exemples permettent de justifier le choix de la technologie agent mobile en


18Jan2008


169/192


PC 4

PC 2

PC 1PC 3

Serveur HTTP + Linux (SRV)

Point dacces Wifi

commutateur 10/100Mbps

Coeur du reseau

100Mbps

10Mbps

Fig. 7.13 Schma dun rseau Wifi fonctionnant en mode ad hoc

fonction, non pas des performances et du gain en bande passante escompt, maisen fonction du service rendu. Des critres tels la ractivit, lautonomie, la priseen compte de contraintes gographiques sont alors considrs.

Imaginons par exemple, quun administrateur veuille effectuer un inventaireautomatique de tous les systmes connects au rseau de son entreprise. Pourcela, on met en uvre des oprations Java et des requtes SNMP afin de collecter

le descriptif des systmes, mais aussi sur chaque hte (PC, serveur) ayant la MIBhost implant, toutes les ressources du systme. Dans cet exemple, le tempsde rponse nest pas critique puisque la tche est une tche de fond, de longuehaleine. Il sagit de dployer plusieurs agents mobiles respectant larchitecturedu rseau, cest--dire dploys sur lensemble des sites. Avec lautonomie proprede chaque agent, lorsque lopration dadministration est mene terme, chaqueagent mobile peut ramener la station dadministration les donnes collectesou alors les transmettre lagent responsable de la mise en forme de celles-ci. Toutes ces oprations peuvent tre effectues indpendamment de la stationdadministration.

Prenons un autre exemple : un service dimpression sur le rseau sarrte demanire inopine. En urgence, ladministrateur va envoyer un agent mobile ddi la supervision de ce service afin de savoir rapidement la cause de cet arrt. Enmme temps, lagent mobile peut essayer de relancer le service dfectueux, oude rediriger toutes les impressions bloques vers un autre service dimpression.Une solution plus autonome, consiste utiliser des agents mobiles de supervi-sion qui nattendraient pas dordre direct de ladministrateur pour ragir toutemodification des services rseaux fournis.


18Jan2008


170/192

Bilan 167

7.3.2 Exemple : Autoconfiguration des VLANs dans un

rseauImaginons un administrateur de rseau qui doit dployer une nouvelle archi-

tecture de rseau, bien que notre exemple puisse sappliquer aisment dans le casdune architecture rseau en exploitation. Ladministrateur du rseau prpare lesconfigurations de base des quipements actifs du rseau, en fonction de ses de-siderata : Nom logique, adresse Ip, nom de communaut SNMP V1 en lectureseule, informations sur la configuration SNMP V3 ncessaire pour les oprationsdadministration, et ce pour chaque commutateur appartenant au cur du r-seau. Il dfinit aussi des rseaux virtuels (VLANs) afin de contrler les accsentre les diffrents lments qui seront connects sur le rseau : PC, serveurs,

imprimantes, dans loptique de faire des groupes de machines par rseau virtuel.Pour raliser cela, ladministrateur doit connatre le lien entre chacune des inter-faces sur les commutateurs, les lments qui doivent y tre connects et le VLANdans lequel ces lments doivent tre intgrs. Par dfaut, les configurations descommutateurs associent chaque port au VLAN administratif, qui est le VLAN degestion du commutateur. Pour changer cette valeur par dfaut, ladministrateurdoit donc, soit se connecter sur le commutateur pour en changer la configura-tion (en utilisant un client ssh [48], par exemple), soit utiliser pour des raisonsde scurit et de distance, le protocole SNMP V37. Dans tous les cas, ladminis-trateur devra connatre ladresse IP du commutateur sur lequel il doit effectuer

lassignation du VLAN sur une interface de ce commutateur.En nous basant sur lexemple propos par la figure 7.14, o le VLAN 180 estdj dclar pour certains lments, nous allons expliciter comment nous utilisonsun agent mobile pour configurer les VLANs sur les ports des commutateurs.

Ainsi, en utilisant un itinraire de migration dans le rseau local, ou vers unrseau local distant, et en fournissant comme information lagent mobile : (1)ladresse Ethernet de llment concern par lassignation du VLAN; (2) le nu-mro du VLAN pour configurer linterface du commutateur, lagent mobile peutautomatiquement configurer linterface du bon commutateur de manire compl-tement automatique. En effet, notre algorithme de construction de la topologie

nous permet de dtecter automatiquement lquipement actif sur lequel lactionde lagent mobile doit tre effectue.

7.4 Bilan

Par les tests que nous avons mis en uvre, sur le rseau prsent par lafigure 7.1, nous pouvons constater que la technologie des agents mobiles donne

7attribut de lentre de la MIB : private.cisco.ciscoMgmt.ciscoVlanMembershipMib.-ciscoVlanMembershipMIBObjects. vmMembership.vmMembershipTable.-vmMembershipEntry.vmVlan


18Jan2008


171/192


PC 4PC 3

Vlan 1Vlan 180 Vlan 180

Vlan 180

PC 2PC 1

Switch 3Switch 2

Switch 1

Workgroup Switch

Catalyst

Workgroup Switch

Catalyst

WorkgroupSwitch

Catalyst CiscoSystems

CiscoSystems

CiscoSystems

Fig. 7.14 Schma du rseau pour lautoconfiguration des VLANs

des avantages en temps dexcution et que les rsultats obtenus ne sont pas tropdpendants du dbit inter-rseau. A contrario, les tests montrent effectivementque le modle Client/Serveur excut distance nest pas adapt la collectedun nombre important de variables SNMP sur plusieurs agents SNMP. La miseen uvre de tches longues quun administrateur souhaite voir excutes est tout fait envisageable en utilisant des agents mobiles, notamment lorsque les lmentssont situs sur un rseau distant et quil est possible de raliser des oprations sur

des lments qui ntaient pas concerns au dpart grce aux itinraires construitsdynamiquement. Il convient de constater que lorsque les fonctions sont excutersur le rseau local, les deux techniques (Client/Serveur et agent mobile) sont aussibien applicables lune que lautre.

Quand on travaille sur un rseau de nouvelle gnration (type Wifi), il estncessaire de prendre en compte les contraintes qui y sont associes : latence,faible bande passante, collision, mode de fonctionnement du rseau (infrastructureou ad hoc). Ainsi nous avons pu constater par lvaluation des performancesdagents mobiles agissant sur un rseau Wifi que des prcautions doivent treprises : il faut allger lagent mobile pour une meilleure efficacit ; viter les aller-

retour inutiles pendant litinraire, ce qui impose que litinraire dadministrationsoit trs adapt ce type de rseau ; lutilisation dun agent mobile stationnairepermet sur ce type de rseau de regrouper et mettre disposition des informationsdadministration sans pour autant engorger le rseau Wifi.

Pour conclure ce chapitre, nous pensons que les agents mobiles trouvent uneplace dans le monde de ladministration systme et rseau mais que cette techno-logie nest pas adapte toutes les fonctions dadministration rseau (par exempleune fonction de courte dure sur un rseau local). Il est prfrable dutiliser lesagents mobiles pour des tches "plus longues", ralisables de manire dcentraliseet autonome, et nimposant pas une urgence particulire.


18Jan2008


172/192

Chapitre 8

Conclusion

8.1 Bilan, contribution

Nous nous sommes intresss dans cette thse la problmatique de luti-lisation des agents mobiles dans un cadre dadministration systme et rseau,en utilisant la bibliothque ProActive, et au dveloppement dune plate-forme agents mobiles pour ladministration systme et rseau.

Nous avons tudi les plates-formes qui relvent de cette problmatique (parexemple, James, SOMA, Ajanta, etc..) afin de cerner la problmatique sur lau-

tomatisation et lautonomie des agents mobiles. Nous avons constat que des iti-nraires statiques taient fournis aux agents mobiles ce qui a motiv la dfinitionditinraires plus dynamiques et mieux adapts aux oprations dadministrationque les agents mobiles doivent accomplir.

Pour crer des itinraires dynamiques, la connaissance de la topologie du r-seau sest avre ncessaire. Il a fallu collecter linformation contenue dans lesquipements actifs du rseau, et dt

These Reuter

Documents

Transcript of These Reuter