Projet de création d’un système dynamique de représentation d’un parc informatique

1. Projet de création d’un système dynamique de représentationd’un parc informatique • _________________________________ • Licence professionnelle CDOAM • Conception et Développement Orientés Objets d’Applications Multi-tiers Maitre de stage : GAVARRET Benoit – Tuteur : GREFFIER Françoise BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

2. PRESENTATION La société SCAM Travaux Publics : - Activité - Localisations - Effectifs représentatifs Environnement / lieu de réalisation : - Le service informatique (localisation, effectifs, gestion…) Le projet de création d’un système dynamique de représentation d’un parc informatique : - Objectif principal : Créerune interface capable de représenter les ressources critiques du réseau informatique et de mettre en évidence les machines non connectées. BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

3. PRESENTATION Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

4. ANALYSE PREALABLE AU PROJET Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

5. ANALYSE PREALABLE AU PROJET Les application de supervision existantes OUTILS EXISTANTS OUTILS A DEVELOPPER Outil d’inventaire du parc informatique (GLPI + OCS Inventory) • SUPERVISION • du PARC • INFORMATIQUE Outil de supervision des alertes dites « SNMP » Système dynamique de représentation des ressources critiques Outil de centralisation des logs machines BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

6. ANALYSE PREALABLE AU PROJET Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

7. PRESENTATION ANALYSE PREALABLE AU PROJET Limites des outils actuels Outil d’inventaire du parc informatique (GLPI)Aucune dynamique : l’outil doit être mis à jour quotidiennement par les administrateursOutil de supervision des alertes dites « SNMP »Aucune globalité : chaque alerte concerne une et une seule machine. Ces dernières ne sont pas regroupées, par agence par exemple.Outil de centralisation des logs machinesAucune optimisation : tous les logs générés sur le parc sont remontés. Aucun tri n’est effectué, par importance par exemple.En bref, les deux principales limites sont les suivantes :Aucune représentation dynamique du réseau : Les outilsutilisés ne permettent pas d’avoir une visualisation de l’ensemble du parc.Aucune visualisation rapide de l’état du réseau : Les administrateursne peuvent pas savoir, de manière efficiente, les machines qui ont unproblème. BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

8. ANALYSE PREALABLE AU PROJET Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

9. ANALYSE PREALABLE AU PROJET Besoins exprimés pour la future application L’application doit permettre de :- Représenter graphiquement et dynamiquement l’ensemble des ressources critiques du parc informatique de la société- Visualiser toutes les machines (ressources critiques) recensées par agence grâce à une image descriptive et le nom de la machine- Générer l’état des machines selon leur réponse à la commande « ping »- Mettre en évidence l’état des machines grâce à un code de couleurs ou autres. BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

10. ANALYSE PREALABLE AU PROJET Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

11. ANALYSE PREALABLE AU PROJET Choix de développement Langage de programmation utilisé : JAVAJustifié par : - Son orientation « objet » - Sa portabilité - Sa facilité de réutilisation - Son orientation « client/serveur »Environnement de développement : Eclipse Ganymède 3.4Justifié par : - Sa communauté active - Son environnement modulaire (ajout de plug-ins) BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

12. REALISATION DE L’APPLICATION Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

13. REALISATION DE L’APPLICATION Principe de fonctionnement du système dynamique de représentation L’application est divisée en trois programmes distincts :- L’AGENT DISTANT qui construit l’image de l’agence sur laquelle il est implanté, puis la met à disposition.- LE SUPERVISEUR qui centralise les images de toutes les agences, puis met à disposition un tableau de ces images- L’INTERFACE c’est-à-dire le programme qui se charge de récupérer le tableau « d’images » pour ensuite les afficher dans une fenêtre. BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

14. REALISATION DE L’APPLICATION Principe de fonctionnement du système dynamique de représentation Schémareprésentatif AGENT DISTANT Agence de Bordeaux Agence de Toulouse Agence de Clermont-Ferrand 1 INTERFACE 1 SUPERVISEUR 2 Agence de Montpellier 1 1 Site de Marguerittes 1 1 Agence de Toulouse 1 Site de Marguerittes Site de Marguerittes BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

15. REALISATION DE L’APPLICATION Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

16. REALISATION DE L’APPLICATION Application orientée « réseau » L’application repose sur l’API Java* RMI (Remote Method Invocation).Définition généraleCette bibliothèque permet de manipuler des objets distants (sur une autre machine du réseau) de manière transparente c’est-à-dire comme s’ils étaient sur la même machine.DescriptionL’architecture RMI repose sur trois acteurs : le serveur (qui met à disposition l’objet), le client (qui demande l’objet) et le registre de noms (qui gère les références entre les divers objets).Dans le cadre de l’application, RMI sera utilisé entre : - l’agent distant (serveur) et le superviseur (client) pour récupérer les images de toutes les agences. - le superviseur (serveur) et l’interface (client) pour l’affichage des machines BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

17. REALISATION DE L’APPLICATION Application orientée « réseau » ARCHITECTURE RMI (Mise à disposition de l’objet par le serveur) : JVM CLIENT RMIREGISTRY (Serveur de noms) JVM SERVEUR 2 Naming Stub 1 rebind() Client Serveur 3 Mise à disposition Skeleton Stub Etape n°0 : A la création de l’objet, un stub et un skeleton sont créés, coté serveur. Etape n°1 : L’objet serveur s’enregistre auprès du Naming de sa JVM : méthode rebind(). Etape n°2 : Le Naming enregistre le stub de l’objet auprès du serveur de noms (rmiregistry). Etape n°3 : Le serveur de noms est prêt à donner des références à l’objet distant. BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

18. REALISATION DE L’APPLICATION Application orientée « réseau » ARCHITECTURE RMI (Appel de l’objet par le client) : JVM CLIENT RMIREGISTRY (Serveur de noms) JVM SERVEUR Naming Naming 5 Stub 4 Lookup() Client Serveur 6 Installation 7 Skeleton Stub Etape n°4 : L’objet client fait appel au Naming pour localiser l’objet serveur : « lookup() ». Etape n°5 : Le Naming récupère le stub vers l’objet serveur. Etape n°6 : Le Naming installe l’objet Stub et retourne sa référence au client. Etape n°7 : Le client effectue l’appel à l’objet serveur par appel à l’objet Stub. BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

19. REALISATION DE L’APPLICATION Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

20. REALISATION DE L’APPLICATION Détails de la construction d’une agence (Agent Distant) Classe « ReseauLocalmpl » ReseauLocalImpl dateMAJ : String tabNoeuds : Vector tabSwitchs : Vector tabLiens : Vector L’image construite d’une agence est un objet de type « ReseauLocalImpl ». Ces attributs sont initialisés, en partie, à l’aide d’un fichier de configuration.Initialisation « tabNoeuds » : Lecture du fichier Classe « Noeud» Création d’un nœud pour chaque ligne renseignée Noeud adresseMAC : String adresseIP : inetAddress type : String fonction : String descrpiton : String nomHote : String ping : Boolean icone : imageIcon Ajout du nœud dans « tabNoeuds » BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

21. REALISATION DE L’APPLICATION Détails de la construction d’une agence (Agent Distant) Extraction des switchs présents dans « tabNoeuds » Mise à jour des tables de correspondances des switchs Création de la topologie entre les switchs Initialisation « tabSwitchs » :Initialisation « tabLiens » : Parcours des tables de correspondances des switchs Création d’un lien entre le switch concerné et le nœud présent dans sa table de correspondance Ajout de l’objet « Liens » créé dans le tableau de liens Ces étapes passées, l’image de l’agence peut ensuite être mise à disposition sur le réseau. BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

22. RESULTATS OBTENUS Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

23. RESULTATS OBTENUS Objectifs réalisés ? Objectifs réalisés :- L’objectif principal a été correctement mis en place- L’application est réutilisable à tout moment, pour poursuivre la supervision globale du parcLimites :- L’application cible que les ressources critiques- La dynamique n’est pas entièrement complète (fichier de configuration) BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

24. RESULTATS OBTENUS Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

25. RESULTATS OBTENUS Evolutions possibles Les évolutions possibles, qui conviendraient à l’entreprise, sont les suivantes : - Mise en place d’un historique : Il serait logique que les administrateurs puissent revoir l’état du réseau à un moment donné passé (ex : le semaine précédente).- Création d’une vue fonctionnelle : Cette fonctionnalité permettrait une représentation du réseau en arborescence (comme l’explorateur Windows). Ainsi, lors du clic souris sur une machine précise, le détail de sa configuration matérielle et logicielle apparaitrait.A cela s’ajoute, l’intégration des outils existants. En effet, il reste encore de nombreuses possibilités d’évolutions pour cette application, afin d’arriver à l’objectif d’une supervision du parc informatique de la société. BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

26. CONCLUSION PERSONNELLE Introduction I. Analyse préalable au projet 1). Les applications de supervision existantes 2). Limites de ces outils actuels 3). Besoins exprimés pour la future application 4). Choix de développement II. Réalisation du système de représentation dynamique 1). Principe de fonctionnement global du système 2). Application orientée « réseau » 3). Détails de la construction d’une agence III. Résultats 1). Objectif réalisé ? 2). Evolutions possibles Conclusion BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

27. CONCLUSION PERSONNELLE Difficultés rencontréesDifficultés basiques avec le langage de programmation JavaRéalisation de l’algorithme d’architecture des SwitchsL’interface graphique en elle-même avec la superposition de couchesApports personnelsUn apport de connaissances incontestableDes compétences renforcées et de nouvelles crééesUne motivation encore plus forte quant à mon objectif professionnel BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009

28. Projet de création d’un système dynamique de représentationd’un parc informatique • _________________________________ • Licence professionnelle CDOAM • Conception et Développement Orientés Objets d’Applications Multi-tiers Maitre de stage : GAVARRET Benoit – Tuteur : GREFFIER Françoise BERNARDIN Benoît Université de Franche-Comté – Année 2008/2009