previous up next contents index Projet de fin d'année Logiciel
< Introduction < > Ingénierie de la solution >

Sous-sections


Cahier des charges

Présentation de la problématique

Cadre et besoins

Le réseau informatique de l'ENSEIRB est un réseau commuté de taille assez importante : il comprend environ 450 machines, serveurs, stations, PC et un grand nombre de terminaux.

C'est surtout un réseau ``souple'', en ce sens qu'il y a un brassage assez fréquent des branchements, pour accroître les performances du réseau avec une meilleure répartition des machines, ou parce qu'on a besoin de déplacer ou d'ajouter des machines, ou tout simplement parce qu'un équipement a une défaillance. Il devient alors très difficile de connaître l'organisation des machines.

Au cours de l'année 2001, des élèves de l'école ont implémenté un logiciel facilitant l'administration d'un réseau en calculant sa topologie et en fournissant diverses informations telles que les débits. Cette solution ne prend pas en compte la modification des branchements.

  Depuis janvier 2002, le réseau a été découpé en plusieurs VLAN, afin d'optimiser l'utilisation des ressources et la sécurité en confinant les messages de broadcast dans des sous-réseaux.

Cette nouvelle configuration du réseau implique désormais des dysfonctionnements de la solution évoquée ci-dessus qui ne répond plus complètement aux besoins du client. De nouvelles attentes sont donc maintenant formulées : on désire notamment connaître l'appartenance d'un équipement à un VLAN. Ce sont ces considérations qui sont à l'origine de ce projet, qui a pour but la reprise du logiciel existant et son amélioration.

 

Pour diverses raisons, les ingénieurs systèmes peuvent être amenés à déterminer ponctuellement sur quel n\oeud du réseau est branché un ordinateur :

 

Il est également intéressant pour les administrateurs, de suivre l'évolution de la charge du réseau dans ses différentes parties pour pouvoir apprécier les points critiques et adapter la répartition des machines en conséquence.

Conséquences

Il existe cependant des choix de la solution actuelle qui ne sont pas à remettre en cause (utilisation du système de gestion de bases de données MySQL et de l'API GTK pour l'interface graphique, présentation hiérarchique dans l'interface des équipements, utilisation de la bibliothèque ucd-snmp).

  Nous devons donc reprendre la solution existante que l'on doit adapter (exigences nouvelles dues aux VLAN) et compléter (nouvelles attentes du client et nouvelles fonctionnalités). Il y a également un travail de normalisation et de structuration du code à réaliser (dans la mesure du possible).

Déroulement

L'environnement de déploiement est le réseau de l'ENSEIRB.

 

Les différents intervenants sont :

Evolutions et cycle de vie

Supposition fondamentale

La détermination de la topologie d'un réseau s'appuye sur l'interrogation de ses équipements de liaison. Ainsi est-il nécessaire de disposer de commutateurs administrables ou ``manageable switches''.

C'est une condition nécessaire mais pas suffisante : il faut également que les n\oeuds du réseau soient compatibles avec le protocole SNMP, ou plus précisément qu'ils implémentent le BRIDGE-MIB.


Evolutions prévisibles

Afin de permettre la reprise et la maintenance du logiciel, les sources et la documentation seront placés sur http://www.sourceforge.net, un site internet permettant le dépôt de projets libres.

 

Il existe un grand nombre d'équipements qui respectent ou implémentent à différents degrés les spécifications des protocoles (SNMP et RMON) permettant l'extraction des données.

Ceci signifie qu'une compatibilité totale n'est pas garantie avec tous les équipements, autres que ceux utilisés par le client. Il est envisageable que cette compatibilité soit apportée ultérieurement.

  Il faut également préciser que nous sommes à priori limités pour nos tests et nos manipulations. En effet le seul environnement réseau utilisé sera celui de l'ENSEIRB (au moins dans un premier temps), sur lequel nous ne pouvons agir que de manière restreinte : on ne pourra pas modifier les cablages, les configurations, ou perturber son bon fonctionnment.

Besoins fonctionnels

Si certains besoins fonctionnels sont essentiels au logiciel, d'autres ne sont pas aussi importants mais restent vivement souhaités.

Etablissement de la topologie

Cela constitue la base du logiciel. Celle-ci doit être mise à jour régulièrement selon un intervalle de temps spécifié et mettre en évidence les correspondances entre équipements réseau et port de branchement. La topologie devra prendre en compte l'existence des VLAN.

 

On complète la topologie par des informations caractéristiques du réseau.

Récupération de données statiques

Mode de fonctionnement :
Le logiciel pourra également fournir le mode de fonctionnement des différentes interfaces réseau. Ces renseignements permettront aux administrateurs d'identifier les causes de performances bien inférieures à celles attendues.

Un port peut ainsi être configuré en ``full ou half duplex'' ; si les deux extrémités d'une liaison ne sont pas configurées de la même manière, des débits médiocres sont à prévoir...

Récupération de données dynamiques

Débits :
La récupération des débits doit être effectuée dynamiquement sur chaque branche du réseau. Plutôt que de fournir les débits circulant dans les câbles, on préfèrera donner le rapport entre leur débit effectif et leur débit maximal.

 

Statistiques :
Bien plus que des données instantanées, les données statistiques, moyennées sur une journée ou une semaine, sont significatives du fonctionnement du réseau.

La charge sur une branche du réseau peut varier énormément en fonction du nombre d'utilisateurs connectés, des applications s'exécutant... la charge moyenne traduit mieux le comportement du réseau : problème de configuration des ports ou topologie mal ``équilibrée''.

 

``Monitoring'' d'une grandeur :
Il peut être intéressant de suivre l'évolution d'un paramètre, indépendamment de ce qu'effectue le reste du programme.

Besoins non fonctionnels

Contraintes sur le produit

Concernant la portabilité, le programme doit impérativement fonctionner sur les systèmes Sun Solaris 7 et versions supérieures, et il serait fort souhaitable qu'il s'exécute aussi sous GNU/Linux.

  La topologie du réseau et les informations complémentaires doivent être visualisées par une interface graphique. Celle-ci doit offrir d'une part une vue globale de l'arbre du réseau, et d'autre part une vue graphique centrée sur un équipement réseau. Sur cette vue, on pourra représenter certaines informations comme les débits ou les VLAN en coloriant les liens par exemple. Afin de rendre l'affichage plus lisible, on pourra également masquer certaines machines en fonction de critères comme l'appartenance aux VLAN. Les fils d'un équipement donné pourront aussi être triés suivant des critères similaires.

Dans le projet repris, l'affichage graphique ne permet de visualiser que les fils directs du boitier réseau sélectionné. Il serait souhaitable de rendre ce comportement plus souple.

  Le comportement du programme doit être paramétrable par des fichiers texte de configuration. Par exemple, l'affichage à partir des données doit pouvoir se faire grâce à des méthodes génériques paramétrables.

  Le projet que nous reprenons ne fonctionne qu'avec une base MySQL. Il serait souhaitable d'avoir une couche d'abstraction afin d'avoir la possibilité de stocker les informations dans un autre système de gestion de bases de données voire dans des fichiers textes.

D'autre part, il serait intéressant de pouvoir exporter certaines informations pour pouvoir les exploiter avec des scripts externes ou bien d'autres applications. La topologie devra en particulier être exportable dans un format texte. Quant aux mesures concernants les débits, un export dans un format compatible avec un grapheur externe comme RRDTOOL est envisagé.

Réciproquement, des données pourraient être importées par le logiciel pour effectuer un traitement : par exemple, chargement d'une sauvegarde.

 

La récupération de la liste des machines du réseau est faite par NIS dans le projet repris. Ceci pourrait être rendu plus souple en proposant un certain nombre de méthodes de collecte de listes de machines comme un transfert de zone DNS ou bien encore une interrogation LDAP. Le choix de la méthode de collecte pourrait être automatique en s'appuyant sur les fichiers de configuration du système.

Contraintes sur le développement

Plusieurs langages de programmation peuvent être utilisés : essentiellement le C/C++, mais aussi les langages de script sh et Perl.

 

Quant à la récupération des informations du réseau, elle devra s'appuyer sur le protocole SNMP.

L'utilisation de RMON[14] est envisagée pour récupérer l'historique des différents compteurs (nombre de paquets, nombre d'octets, nombre d'erreurs, etc.) afin de pouvoir grapher ces valeurs sans surcharger le réseau.

RMON tient également à jour une matrice dont les lignes et les colonnes sont des machines et dont chaque cellule contient un certain nombre de compteurs relatifs aux transferts entre les machines associées. Cette information pourra être utilisée pour la représentation des débits en particulier.


previous up next contents index Projet de fin d'année Logiciel
< Introduction < > Ingénierie de la solution >
Christophe GIAUME 2002-05-27