WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Conception d'un outil d'administration réseaux

( Télécharger le fichier original )
par Walid Zayani
Université de Carthage Tunisie - Mastère professionnel en technologie des réseaux des télécommunications 2012
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

Conclusion :

Dans ce chapitre nous avons situé le projet dans son cadre. Dans le chapitre suivant, nous passons à l'étude du système qu'on va réaliser.

Chapitre 2 :

Spécification des besoins

CHAPITRE II: Spécification des besoins

Introduction :

Dans ce chapitre, nous allons présenter les spécifications de notre solution d'administration réseau. Nous commencerons par le principe général d'administration en suite et nous terminerons par l'identification des besoins

IV. Principe général d'administration

Sur le point de l'administration, un système de réseau informatique se compose d'un ensemble d'objets qu'un système d'administration surveille et contrôle. Chaque objet est géré localement par un processus appelé agent qui transmet régulièrement ou sur sollicitation les informations de gestion relatives à son état et aux événements qui le concernent au système

d'administration.

Le système d'administration comprend un processus (manager ou gérant) qui peut accéder aux informations de gestion de la MIB locale via un protocole d'administration qui le met en relation avec les divers agents.

Le principe se repose donc sur les échanges :

· D'une part, entre une base d'informations appelée MIB (Management Information Base) et l'ensemble des éléments administrés (objets) ;

· D'autre part, entre les éléments administrés et le système d'administration.

- Figure 3 : processus agent/gérant-

V. Architecture d'administration

L'architecture classique d'administration la plus utilisée est le modèle Gérant/ Agent (Manager/Agent).comme nous l'avons montré dans le principe d'administration. Le système est composé d'une entité d'administration et des entités de gestion (NME) qui sont géré par cette entité et un protocole pour la gestion

Chaque entité dans le réseau a un Agent pour l'opération de gestion, une base de données stockées dans MIB et assume les travaux ci-dessous :

· Collecter des informations statistiques concernant à la communication, les opérations de réseau.

· Stocker les informations localement dans les MIBs.

· Répondre les commands de l'entité de contrôle de réseau, inclus : Transmet des informations statistiques à l'entité d'administration de réseau, modifie les paramètres, donne des informations d'état...

VI. Identification des besoins

Les besoins d'utilisation de l'application sont repartis en besoins fonctionnels et en besoins non fonctionnels.

Les besoins fonctionnels

Les besoins fonctionnels incluent le module gestion de l'application, module de supervision des équipements, module de gestion des faute, module de gestion de la performance et en fin module de générations des rapports et journalisations (historique).

II.5. Module de gestion d'application

Le module de gestion d'application est forme par deux sous modules principaux qui sont :

- Authentification aupres de l'interface : ce module permet à l'administrateur de sécurité de ce connecté à l'interface en introduisant le login et son mot de passe. Ce module va chercher dans la base des données le login et le mot de passe entres, s'il ya correspondance alors ouverture de session de sinon un message d'erreur afficher.

- Gestion d'utilisateurs : Ce module permet d'ajouter, modifier et supprimer d'un autre administrateur.

Remarque : Impossible de supprimer un administrateur si le seul qui existe dans la base.

II.6. Module de supervisions des équipements

Ce module est formé par trois sous modules principaux qui sont :

- Gestions des équipements : Ce module permet d'ajouter ou supprimer un équipement (routeur, serveur ou commutateur) pour superviser l'ajout se fait simplement d'ajout l'adresse de l'équipement dans la base des données et la même pour la suppression.

- Contrôle des équipements : Ce module permet de contrôler si les équipements sont en marche ou non (UP, DOWN) et collecter les informations de chaque équipement en utilisant le protocole SNMP.

- Scanner les ports d'équipements : Ce module permet de scanner les ports de chaque équipement en entrant son adresse. Il y a deux choix de scan scan d'un seul port précis ou d'une plage des ports.

II.7. Module de gestion des fautes

Ce domaine recouvre la détection, l'isolement et la correction des pannes survenant sur un équipement. L'action curative qui en découle peut être faite à distance (si l'équipement répond) ou par un contact humain qui agira sur l'équipement. Un historique des évènements est également disponible

-Figure 4 : Gestion des fautes-

Type de panne

Les pannes peuvent ~tre d'origine interne, à caractère permanent (composant en pannes) ou externes (goulets d'étranglement, trafic intense, etc.), Cette dernière est plus difficile à détecter, car elle est à caractère aléatoire.

La gestion de faute couvre l'ensemble des fonctionnalités suivantes :

· La détection des fautes : elle comprend la préparation de rapports d'incidents de fonctionnement, la gestion de compteurs ou des seuils d'alarme, le filtrage d'événements par filtrage en amont des informations, l'affichage des dysfonctionnements.

· La localisation : on y procède au moyen de rapports d'alarme, de mesures et de tests.

· La réparation : elle consiste à prendre les mesures correctives (réaffectation de ressources, routages, limitation du trafic par filtrage, maintenance), ou encore à rétablir le service (tests de fonctionnement, gestion de systèmes de secours, etc.).

· L'enregistrement des historiques d'incidents et statistiques : la gestion des fautes ne peut se limiter à ces actions ponctuelles, nécessaires mais insuffisantes pour donner le service attendu. C'est la raison pour laquelle elle comporte aussi, d'une part, l'enregistrement d'historiques d'incidents et la compilation de statistiques qui peuvent porter sur la probabilité des pannes, leur durée, les délais de réparation et, d'autre part,

un rôle d'interface avec les usagers qui consiste à les informer des problèmes réseau et à leur donner la possibilité de signaler eux-mêmes des incidents telle que :

· La déconnexion d'un câble ;

· Une mauvaise configuration d'un équipement ;

· Une interface défectueuse d'un routeur ;

· La réinitialisation accidentelle

II.8. Module de gestion de la performance

Ce domaine comprend la collecte des données et l'analyse statistique permettant la création de tableaux de bord. Ce domaine est essentiellement lié à l'évolution du réseau (permet de planifier les changements à apporter afin d'améliorer les performances du réseau).

-Figure 5 : Gestion de Performance-

L'objectif est d'établir des statistiques à partir des paramètres du réseau.

· Débit.

· Temps de réponse.

· Taux d'erreur.

· Temps d'établissement des connexions

Elle fournit des fonctions qui permettent à des fins de planification des ressources du réseau : - De recueillir des données statistiques (taux d'erreurs, temps de transit, débit, etc.) ;

- De maintenir et analyser des journaux sur l'historique de l'état du système (événements). Les informations obtenues serviront à l'analyse et à la planification du réseau. On peut diviser cette partie en deux : l'une traitant de la gestion de la performance en temps réel et l'autre en temps différé. Pour gérer la performance d'un réseau en temps réel, il faut mettre en place la fonction suivante :

· Enregistrements des mesures de performance : cela passe par l'établissement et la mise à jour des critères et des conditions de mesure, la gestion de la collecte d'informations, le filtrage, la compilation de statistiques, l'adoption de mesures à la demande ou encore la gestion des fichiers de collecte.

II.9. Module de générations des rapports et journalisations (historique).

Notre application permet de générer des rapports de chaque équipement qui décrit tous ses informations et aussi génère des rapports des pannes.

Et permet d'enregistrer chaque trace d'administrateur dans un historique.

Les besoins non fonctionnels

Ce sont des exigences qui ne concernent pas spécifiquement le comportement du système mais plutôt identifient des contraintes internes et externes du système.

Les principaux besoins non fonctionnels de notre application ce résument dans les points suivants :

n Le code doit être clair pour permettre des futures évolutions ou améliorations ;

n L'ergonomie : l'application offre une interface conviviale et facile à utiliser ;

n La sécurité : l'application doit respecter la confidentialité des données ;

· Garantir l'intégrité et la cohérence des données à chaque mise à jour et à chaque insertion.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Je voudrais vivre pour étudier, non pas étudier pour vivre"   Francis Bacon