Étude D'avant Projet de Mise en Place D'une Plateforme de Supervision

Étude d'avant projet de mise en place d'une plateforme de supervision - Wiki de Romain RUDIGER
Connexion
Page Discussion Lire Voir la source Afficher l’historique Lire Rechercher
Étude d'avant projet de mise en place d'une plateforme de supervision

Navigation
L'objectif de ce document est de fournir des éléments pertinents de comparaison pour déterminer la solution de supervision répondant le mieux aux besoins d'un système d'information. Cette étude n'est pas
Accueil complète pour respecter la politique de confidentialité de la société pour laquelle cette étude a été réalisée.
Stage en Bulgarie
Participant : Romain RÜDIGER.
HCS by Nov@
Période : 02/09 - 03/09.
Modifications récentes
Page au hasard
Sommaire [masquer]
1 Présentations, objectifs et contraintes
Boîte à outils 1.1 La supervision
Pages liées 1.2 Plateforme 2

1.2.1 Objectifs
Suivi des pages liées
1.2.2 Contraintes
Pages spéciales
1.3 Plateforme 1
Version imprimable
1.3.1 Objectifs
Lien historique
2 Présentation des plateformes
3 Étude de faisabilité
3.1 Organisation
3.1.1 Stratégie de déploiement
3.1.2 Liste des tâches
3.1.2.1 Lister les dépendances
3.1.2.2 Noter les étapes d'installation
3.1.2.3 Mettre en place chaque type de supervision
3.1.2.4 Configurer les accès
3.1.2.5 Vérifier les performances
3.1.2.6 Vérifier la pérennité
3.1.3 Plan d'action
3.1.4 Ressources humaines et techniques
3.2 Analyse des risques
3.2.1 Risques liés au déploiement
3.2.2 Risques liés à l'exploitation
3.3 Coûts prévisionnels
3.4 Conclusion
4 Étude détaillée
4.1 Domaine couvert, type de licence et langue
4.2 L’interface personne-machine
4.2.1 L’interface elle-même
4.2.2 Organisation des entités surveillées
4.3 La surveillance
4.3.1 Surveillance de la disponibilité
4.3.2 Surveillance des niveaux
4.3.3 Surveillance des services
4.4 Les graphiques
4.5 La cartographie
4.6 La gestion des événements
4.6.1 La notification
4.6.2 Liste des événements
4.7 Le SLA
4.8 La tolérance aux pannes
5 Étude technique
5.1 Étude des solutions de supervision
http://romain.novalan.fr/wiki/Étude_d'avant_projet_de_mise_en_place_d'une_plateforme_de_supervision[21/02/2011 20:30:51]
5.1.1 Objectifs
5.1.2 Comparatif des solutions
5.1.2.1 Les critères de comparaison
5.1.2.2 Tableau comparatif
5.1.3 Conclusion et choix
5.1.3.1 Zabbix
5.1.3.2 Opsview
5.1.3.3 Ganglia
5.2 Réalisation de la maquette
5.2.1 Ressources
5.2.2 La maquette
5.2.2.1 Plateforme 2
5.2.2.2 Plateforme 1
5.2.3 Conclusion
6 Mise en production des solutions
6.1 Plateforme 2
6.1.1 Méthodologie de configuration
6.1.2 Mise en place
6.1.3 Documentation
6.1.4 Conclusion
6.2 Plateforme 1
6.2.1 Méthodologie de configuration
6.2.2 Déploiement
6.2.3 Conclusion
7 Notes
Présentations, objectifs et contraintes

Ce projet s'inscrit dans le cadre de mon stage de fin de cycle d'ingénieur de l'école Polytechnique de l'université de Nantes. Il a pour but de mettre en place une solution de supervision pour deux plateformes
totalement distinctes.
Une première partie permet de situer la supervision dans la fourniture d'un service. Les deux parties suivantes détaillent les objectifs et contraintes de ces deux plateformes.
La supervision
En ce qui concerne la gestion d'un système d'information, il est bon de s'appuyer sur le référentiel ITIL. Voici la définition d'un service selon ITIL :
Les fondations d'un service.
ITIL découpe le cycle de vie d'un service en 5 parties dont une qui est continue. La supervision fait partie intégrante de la phase d'exploitation des services dans la gestion des événements[1] .
Le cycle de vie des services.
Pour pouvoir gérer les événements d'un service, il faut pouvoir les détecter. Il existe deux possibilités :
Ce sont les utilisateurs qui remontent les dysfonctionnements.
C'est le ou les outils des supervision qui détecte les dysfonctionnements.
La supervision est un outil qui permet d'améliorer la gestion des événements et donc la qualité du service.
Plateforme 2
données confidentielles. La plateforme est décrite dans le chapitre suivant.
Objectifs
L'objectif du projet pour cette plateforme est de mettre en place une solution permettant de visualiser l'état des différents éléments constituant la plateforme. Il s'agit donc de spécifier, tester puis déployer un
outil capable de tester les différents services et de notifier les administrateurs lors d'un problème. Les besoins sont décrits dans l'étude détaillée.
La supervision de cette plateforme s'axe sur trois points :
Aspect réseau
Administration de la plateforme
Le cœur de réseau
Aspect service
Le serveur AAA [2]

Le portail captif [3]
Les bases de données utilisateurs
Aspect grappe de serveurs, en effet deux machines de type SUN Fire V280 avec une baie de stockage (SUN StorEdge 3310) forment une grappe de serveurs pour fournir des services de base de données.
Cette grappe forme un point critique qui est à superviser.
Contraintes
Le cout de la licence doit être nul car :
il y a déjà un outil de supervision pour la plateforme de production ;
cet outil sera pour simplifier l'administration ;
ce projet ne fait pas l'objet d'une demande du client.
Plateforme 1
données confidentielles. La plateforme est présentée dans une partie suivante.
Objectifs
L'objectif est de connaître l'utilisation des ressources pour savoir si la plateforme est bien exploitée. Un besoin de connaitre rapidement l'état général et le bon fonctionnement du service est aussi présent.
L'outil doit donc être capable de faire :
de la métrologie de tous les équipements de la plateforme,
de la supervision des serveurs et des services.
Présentation des plateformes

Cette partie n'est pas disponible : données confidentielles. Elle partie présentait les deux plateformes en détail pour mieux les comprendre, mais également dégager les contraintes techniques rapidement.
Étude de faisabilité
Cette étude s'inscrit dans la phase préparatoire du projet, elle vise à vérifier la faisabilité économique, technique et organisationnelle du projet. Elle sera suivie d'un cahier des charges fonctionnel puis de
conception.
Organisation
L'organisation du projet permet de savoir ce qu'il faut faire pour chaque phase du projet. Cela donne une première idée concernant les différentes phases et surtout le temps qui sera nécessaire. C'est une
référence pour l'avancement du projet, elle permet également d'établir un calendrier prévisionnel.
Stratégie de déploiement
La solution risquant d'être propre à chaque plateforme, le déploiement se fera par plateforme.
La solution ne remplaçant pas un service existant et stratégique, le déploiement pourra se faire de façon progressive et par étape.
Une première stratégie par couche est possible, voici les cinq étapes :
1. Installation des dépendances de la solution ;
2. Installation et configuration de base de la solution ;
3. Pour tous les équipements :
Configurer la vérification réseau de cet équipement,
Configurer les notifications relatives à cet équipement.
4. A chaque type de supervision (e.g. la charge processeur d'une machine fonctionnant sur un système de type Unix.) :
configuration de ce type de supervision (i.e. configuration du numéro d'OID[4] de la MIB [5] SNMP [6] ) ;
déploiement de ce type de supervision à tous les équipements pertinents,
Configurer les notifications relatives à ce type supervisé.
5. Configuration de l'interface.
Une seconde stratégie par équipement est également possible, voici les étapes :
1. Installation des dépendances de la solution
2. Installation et configuration de base de la solution ;
3. Pour chaque équipement :
Configurer la vérification réseau de cet équipement,
Configurer les types de supervision pour l'équipement,
Configurer les notifications relatives à cet équipement.
4. Configuration de l'interface.
Ces stratégies ont chacune leurs avantages, en cas de manque de temps :
la première permettra d'obtenir une solution complète en terme de supervision réseau,
la seconde permettra d'obtenir une supervision complète de certains équipements.
Le choix d'une des possibilités est difficile dans l'état actuel des choses, le choix sera fait après la réalisation de la maquette.
Liste des tâches

Ce chapitre contient une liste non exhaustive des tâches relatives au déploiement d'une solution. Cette liste va permettre d'améliorer la fiabilité du calendrier prévisionnel.
Lister les dépendances

Il s'agit de dresser la liste complète des dépendances logicielles et matérielles. Cette liste permettra éventuellement de déceler un conflit entre deux solutions présentes sur un même système (c.-à-d. deux
versions différentes d'un même logiciel est nécessaire).
Noter les étapes d'installation

Dans l'optique de pouvoir rejouer l'opération d'installation et de configuration de la solution, il est important de rédiger un tel document.
Mettre en place chaque type de supervision

Pour chaque type de supervision, il faut :
Noter le processus de mise en place pour éventuellement le rejouer ;
Tester sur un échantillon d'équipement la pertinence et la véracité du type supervisé ;
Mettre en place le type de notification souhaité et tester la notification ;
Déployer ce type sur tous les équipements le nécessitant.
Configurer les accès

Il faut configurer les accès à la plateforme. Différents niveaux d'accès sont possibles. Cette configuration dépendra directement des besoins exprimés dans l'étude détaillée.
Vérifier les performances

Les performances doivent être vérifiées périodiquement, par exemple lors de l'ajout d'un type de supervision.
Vérifier la pérennité
Une bonne solution sera stable en terme de ressource dans le temps si la configuration ne change pas. Il faudra donc vérifier périodiquement (toutes les semaines) les ressources (processeur, mémoire
centrale, disque et réseau) pour s'assurer de la stabilité de la solution et donc de sa pérennité.
Plan d'action
Un calendrier prévisionnel a été réalisé pour décrire le plan d'action de ce projet.
Ce calendrier permettra, à chaque étape du projet, de mesurer l'écart entre le prévisionnel et l'effectif. Si cet écart devient trop important, il faudra effectuer un réajustement et le prendre en compte lors du bilan
pour le retour d'expérience.
Ressources humaines et techniques

Le projet, outre moi, ne comprendra personne de façon permanente. Cependant, il fera appel, à plusieurs reprises, aux personnes utilisant les plateformes pour :
La validation de chaque étape ;
L'étude détaillée et technique ;
La réalisation de la solution ;
Et pour le bilan de réalisation.
Il est également possible que le projet fasse appel à des personnes ayant des compétences techniques particulières (notamment pour la supervision du système SUN).
La réalisation de la maquette qui s'étale sur 8 jours-hommes est une phase importante qui permettra d'éliminer de nombreux risques liés au déploiement. Cette maquette doit donc reproduire, au mieux, les
caractéristiques des plateformes cibles. Les ressources techniques sont :
Une machine pouvant supporter quatre systèmes virtuels :
Une pour la solution de supervision, il doit être identique à la machine cible de réalisation,
Trois pour déployer des serveurs de production caractéristiques (OS et/ou applications différents).
Du matériel réseau représentatif de la plateforme ou au moins une liaison vers ce matériel pour vérifier le bon fonctionnement des tests.
Éventuellement du matériel réseau de base pour l'interconnexion de la machine de virtualisation avec le matériel réseau représentatif ainsi que mon poste de travail.
Différents systèmes d'exploitation ainsi qu'une copie de certains serveurs de production (clone ou manuel d'installation avec tous les logiciels utilisés).
Le choix de virtualiser les serveurs permet une réalisation à priori plus rapide de la maquette. Cependant, il pourra y avoir des effets de bords dus aux pilotes des serveurs par exemple.
Lors de la réalisation :
Un serveur physique ou virtuel pour la solution de supervision ;
Une liaison entre la solution de supervision et le cœur du réseau ;
Les droits suffisants pour l'éventuel paramétrage des équipements et des serveurs.
Analyse des risques

Le déploiement d'une solution sur une plateforme implique l'apparition de risques. Ce chapitre n'a pas pour vocation de dresser une analyse complète en utilisant l'une des nombreuses méthodes existantes
(EBIOS[5] , Mehari[6] , Octave[7] ...) mais de déceler les risques pour les éviter.
Par ailleurs, la politique de sécurité n'est pas la même selon la plateforme.
Risques liés au déploiement

Des dysfonctionnements peuvent être provoqués par :
l'installation de dépendances,
la mise à jour de bibliothèques,
l'installation de nouveaux services pour le fonctionnement de la solution,
l'installation de la solution elle-même,
la ré initialisation d'un équipement,
le changement de configuration d'un équipement,
l'installation d'un agent sur un équipement pour le superviser.
Ils peuvent impacter d'autres services présents sur le même système d'exploitation ou non. Il faut donc :
réaliser une maquette la plus proche possible de la plateforme selon les moyens disponibles,
rédiger un Mode Opératoire d'Installation (MOI) lors de la réalisation de la maquette,
prévoir l'impact d'un changement de configuration, d'une ré initialisation d'un équipement avec l'équipe de la plateforme,
sauvegarder la plateforme complète avant de lancer le processus de déploiement.
Risques liés à l'exploitation

Par nature la solution nécessite un accès au cœur de la plateforme pour observer celui-ci, ceci implique donc un risque de créer une vulnérabilité. L'accès physique et logique au système supportant la solution
de supervision est à protéger et restreindre de la même façon que tous les équipements du cœur de la plateforme.
Une fois, déployer la solution ne génère pas de risque en elle-même. Par contre, une mauvaise manipulation de la solution peut entraîner des problèmes. Pour éviter ceci, il est nécessaire de réaliser un manuel
d'utilisation pour guider :
la configuration d'un nouvel équipement,
l'ajout d'un type de service supervisé,
la gestion des notifications,
l'administration des comptes utilisateurs.
Coûts prévisionnels
Le coût de la solution de supervision en elle-même est nul, car la solution sera de type open source.
Le coût en ressources humaines de ce projet est évalué à 32 jours-hommes pour sa réalisation. Ce coût ne représente pas le temps passé par certains collaborateurs pour la définition des besoins, la
validation des étapes ainsi que l'aide technique.
Conclusion
Cette étude de faisabilité a montré que ce projet est faisable.
Une recommandation est tout de même nécessaire au niveau du temps imparti pour la partie de réalisation. Il est probable, par manque de temps, de ne pas réussir à mettre en place une supervision
d'éléments particuliers qui nécessiteront un travail de recherche et l'écriture de scripts. Cependant, une solution répondant à la majorité des besoins est réalisable.
Étude détaillée
Cette étude permet d'exprimer et de clarifier les besoins fonctionnels des deux équipes (l'équipe de la plate-forme 1 et celle de 2). C'est une étape importante pour déterminer une solution qui réponde aux
besoins.
Domaine couvert, type de licence et langue

Il ne faut pas multiplier les outils, car l’administration deviendra vite trop lourde, cependant l'utilisation d'un ou de deux outils complémentaires pour la supervision d'une même plateforme est envisageable.
La licence doit être de type libre comme la Licence publique générale GNU.
La langue utilisée, pour la plateforme 1, sera de préférence française puisque des utilisateurs seront peut-être dans le futur amenés à utiliser la solution.
L’interface personne-machine
Une solution de supervision ne sera pérenne et efficace qu'avec une bonne interface personne-machine. L’interface entre la solution et l’utilisateur doit donc répondre à de nombreux critères.
L’interface elle-même
L’interface locale n'a pas beaucoup d'importance, car la solution sera utilisée à distance, elle peut donc être de type fenêtré ou texte.
L’interface distante (accessible aux utilisateurs depuis leur poste) peut être sous la forme d’un client lourd type JAVA ou de pages HTTP, elle est donc accessible par un navigateur WEB.
Organisation des entités surveillées

Un hôte définit une entité physique connectée sur le réseau comme une station de travail, un routeur, un commutateur, un serveur… Chaque hôte possède ses propres propriétés :
Le nom (par exemple DNS) ;
Son adresse IP ;
Son icône (pour une meilleure compréhension de la carte du réseau) ;
Sa communauté SNMP en lecture et/ou en lecture et écriture ;
Son père (Pour la distinction de l'état in joignable et défaillant);
Pour un routeur, un commutateur et serveurs :
Interfaces à analyser ;
Lien vers l’administration(HTTP(S), SSH, telnet...).
La surveillance
La solution doit au moins être en mesure de surveiller les serveurs (sous Windows 2000/2003, RHEL[7] ), Solaris), les routeurs (matériel Cisco en majorité), les commutateurs (Cisco ou 3Com) et les pare-feux
(Cisco également).
Les sous partis suivants détailleront certains types de surveillances :
Surveillance de la disponibilité
C'est une surveillance de base pour contrôler la disponibilité des équipements en effectuant une interrogation SNMP ou ICMP (requête de type echo request) à intervalle régulier personnalisable par
équipement.
La couleur de chacune des entités (sur la carte) doit représenter leur état :
Rouge lorsque l’équipement ne répond pas un certain nombre de fois consécutives (seuil réglable);
Orange pour avertir d'une alerte (indisponibilité temporaire par exemple) ;
Vert quand l’équipement répond ;
Gris si la présence de l’équipement n’est pas testée.
Surveillance des niveaux

Ce type de surveillance est généralement effectué par le protocole SNMP[6] ou par l'utilisation d'un agent spécifique installé sur l'équipement.
Cela permet de connaitre l'état de l'équipement :
Charge processeur ;
Utilisation de la mémoire ;
Nombre de requêtes SNMP traitées ;
Pour un serveur ou une station de travail :
Espace disque utilisé et restant,
Nombre de processus en cours,
Utilisation des interfaces réseaux,
Utilisation des unités de calcul.
Pour un routeur, un commutateur et un pare-feu :
Nombre de paquets par seconde par interface,
Nombre de ko par seconde par interface,
Nombre de règles appliquées par seconde (routage, filtrage...).
Pour le NAS de la plateforme 1 :
Utilisation CPU,
Utilisation du cache,
Nombre d'écriture disque,
Nombre de lecture disque.
Surveillance des services

C'est le type de surveillance qui sera le plus long à mettre en place de par la spécificité de chaque service. C'est un contrôle fait par :
Le protocole SNMP ;
Un agent spécifique capable de superviser le service ;
Un script écrit spécifiquement pour tel ou tel service.
Les services possibles sont :
Web : requête http et/ou HTTPS ;
FTP : tentative de connexion ;
DNS : résolution d’un nom de domaine ;
POP et/ou SMTP : test de connexion à la messagerie ;
Partage de fichiers : test selon le type de partage ;
Radius et/ou LDAP : test de consultation et/ou d'authentification sur l’annuaire.
Spécifiquement pour 2... données confidentielles
Les graphiques
Il doit être possible de générer différents graphiques pour toutes les ressources systèmes et réseaux que l’on souhaite et cela sur différentes échelles. Par exemple pour les graphiques en fonction du temps :
les 5 dernières minutes, la dernière heure, les dernières 24 heures, les 7 derniers jours, les 30 derniers jours et les 365 derniers jours.
Le taux d’échantillonnage pour une bonne consolidation des données doit être approximativement de :
Pour les dernières 5 minutes et pour la dernière heure : taux correspondant à la fréquence des relevés ;
Pour les graphiques journaliers : un échantillon toutes les 5 minutes ;
Pour les graphiques hebdomadaires : un échantillon toutes les heures ;
Pour les graphiques mensuels : un échantillon toutes les 6 heures ;
Pour les graphiques annuels : un échantillon par jour ;
Optionnellement :
La possibilité de générer un graphique personnalisé en précisant une période comme de 8 h à 20 h il y a trois jours ;
La possibilité de permettre d’afficher plusieurs graphiques en même temps pour par exemple étudier la charge processeur d’un routeur et le flux d’une de ses interfaces réseau : affichage en un graphique
regroupant plusieurs paramètres ou sur plusieurs graphiques ;
La possibilité d’une exportation vers un format portable ;
L’affichage du maximum ;
La configuration des échelles utilisées (axe x et y) ;
La personnalisation des couleurs, du titre, des légendes...
La cartographie
La cartographie est un élément complexe, mais qui permet une visualisation rapide de l'état de la plateforme. Un système de cartographie complet est donc nécessaire pour permettre aux utilisateurs d’avoir
une vue globale de tous les équipements du réseau et de voir rapidement par exemple l’impact qu’aurait la coupure d’un lien. Le système doit être complet, mais synthétique pour trouver efficacement d’où vient
le problème.
Une cartographie automatique et manuelle doit donc être disponible sur la solution choisie. La gestion manuelle de la cartographie permettra une meilleure hiérarchisation des éléments ce qui rend plus
compréhensives les cartes.
La couleur d’un élément constitutif d'une carte doit représenter son état de disponibilité.
Une carte des flux permettant de voir l’utilisation de la bande passante (en pourcentage) entre certains équipements constituant le réseau permettrait de voir rapidement les éventuels goulots d’étranglement et
donc les évolutions à prévoir en termes de bandes passantes nécessaires.
La gestion des événements

Un événement est déclenché par un changement d’état d’un équipement (c.-à-d. non-réponse d’un routeur). La gestion des événements est l'un des points vitaux d'un outil de supervision. La solution ne doit
pas se contenter de rapporter une quantité importante de données, elle doit savoir analyser ces données et détecter une anomalie, une surcharge, une dégradation de la qualité d’un service…
La notification
Une notification intervient lorsqu’un événement à lieu et si cet événement doit engendrer une notification. Elle a pour but d’informer le plus rapidement possible les personnes souhaitées. Bien sûr tous les
événements ne doivent pas provoquer une notification, il doit être possible définir les événements à notifier, le seuil de notification, la fréquence de notification et les utilisateurs et/ou les groupes à notifier.
On doit pouvoir modifier la fréquence de ces notifications (c.-à-d. une notification toutes les 5 minutes et cela trois fois) et cela par moyen utilisé : courriel, mini message… Par exemple, il est important de
limiter le nombre maximal de mini message à envoyer, car cela à un coût beaucoup plus élevé que l'envoie d'un courriel.
Le système de notification doit gérer l’organisation logique du réseau et donc faire la distinction entre un service non rendu et un service in joignable.
Liste des événements

Pour mieux comprendre la perte ou la dégradation d'un service, il est nécessaire de pouvoir retrouver sur l’interface la liste de tous les événements qui ont eu lieu. Un système de filtre permettant de ne
visualiser que les événements concernant un seul équipement par exemple ainsi qu’un système de comptage des événements sont souhaitables.
Le SLA
La gestion de la notion de niveau de service est importante dans le cadre de ce projet, la solution doit être capable de rapporter toute défaillance à la qualité exigée. Cette détection sera faite par l'observation
de différentes métriques représentatives de l'état du service.
Le rapport de SLA devra inclure :
La période de conformité de service ;
La période de non-conformité de service ;
La période de maintenance.
La tolérance aux pannes

En cas de redémarrage par coupure électrique ou d’une coupure électrique de la machine, la solution doit être capable de se relancer seule sans erreur.
Dans le cas d'une panne système, les cahiers d'installation et de configuration ainsi que la sauvegarde des fichiers de configuration devront permettre de redémarrer la solution de supervision assez rapidement.
Étude technique
Il s'agit de trouver une solution qui corresponde aux fonctionnalités décrites dans les précédentes études et aux contraintes techniques.
Comparaison des solutions
Sélection d'une ou de solutions
Mise en valeur des contraintes techniques de la ou des solution(s)
Étude des solutions de supervision
Objectifs
L'objectif de cette partie est de fournir des éléments pertinents de comparaison pour déterminer la solution de supervision[8] répondant le mieux aux besoins d'un système d'information.
Il s'agit de :
faire l'état de l'art des solutions de supervision du monde libre ;
sélectionner les caractéristiques pertinentes ;
comparer les solutions ;
sélectionner les solutions et faire une suggestion en fonction des besoins.
Comparatif des solutions

Cette partie concerne la sélection des critères de comparaison ainsi que le tableau comparatif des solutions.
Les critères de comparaison

1. La maturité de la solution est un critère important pour mettre en place une solution pérenne. La maturité comprend :
une bonne documentation ;
une version stable récente ;
une communauté active (et non pas seulement trois développeurs par exemple).
2. L'interface est un élément important, elle doit permettre une vision rapide de l'état du réseau ainsi que la possibilité d'observer des éléments de façon précise (comme la liste des services associés à
un équipement).
3. prérequis du système, il s'agit d'étudier les prérequis du système qui supportera la plate forme de supervision.
4. Le niveau d'hétérogénéité du SI supporté permet de mesurer si la plate forme sera capable de superviser des équipements hétérogènes (Routeur, commutateur, serveur SUN...). En plus des
services communs (HTTP, FTP, DNS, DHCP...), il doit donc être possible d'ajouter des scripts permettant de superviser des équipements particuliers.
5. La configuration de la plate forme doit être jugée. Elle doit être assez intuitive, mais également complète. Par exemple, si le seul moyen d'ajouter un équipement est celui de l'autodécouverte, la
configuration sera jugée comme mauvaise.
Il y a aussi la notion de modèle (Template) ou de reprise d'une configuration d'un équipement. Par exemple la création d'une configuration par défaut pour tous les routeurs, tous les commutateurs... sont
un très bon point.
6. Un rapport de SLA [9] serait un point positif.
Tableau comparatif
Comparatif des solutions

Prérequis du
Nom Maturité Interface [10] Niveau d'hétérogénéité du SI supporté Configuration SLA [9]
système
L'interface simple permet de retrouver

rapidement les informations :
Une vue synthétique des états :
Des liens réseaux ;
Des équipements supervisés ;
Des services supervisés ;
Moyen car compilé sur le Bon car il existe un très grand nombre de modules
De l'outil de supervision lui- La configuration de Nagios en
Application très système (Linux) et car permettant de vérifier beaucoup de services applicatifs,
même. elle-même n'est pas très difficile Grâce aux rapports de
mature avec une les scripts nécessitent équipements...
Nagios[8] Une carte par groupe logique (les mais nécessite une prise en Hostgroup Availibility Report et
large communauté routeurs, les serveurs, les généralement des
De plus, NRPE permet de vérifier les informations locales main du fonctionnement des Service Availibility Report.
active. équipements du service modules Perl
d'un serveur sous Linux. fichiers de configuration.
d'authentification...) avec des spécifiques.
couleurs selon l'état des
équipements.
Des graphiques pour tous les
éléments supervisés.
Des couleurs représentatives
(rouge, vert, gris...).
La configuration semble facile

mais surtout efficace grâce à
Bon : l'utilisation de :
L'interface est bien pensée, agréable
Pandora FMS est un L'organisation en modules permet au système d'être Modèles (Network
et fonctionnelle pour tous les types Très bien supporté par un
système assez Moyen : Apache, Perl, souple pour s'adapter à toutes les configurations Components
d'utilisateurs. système complexe d'alerte
Pandora mature (3ans), PHP, MySQL, SSH... (Pare-Feux, OS spécifiques...) ; Templates/Profiles)
Graphiques simples ou combinés, avec par exemple la nécessité
FMS[9] difficile de savoir si la Donc un système type : Interrogation par commande système en SSH, Telnet ; permettant de créer des
Cartes automatiques et d'avoir : (test1 ET test2) OU
communauté est Linux. Système de répartition des serveurs ; configurations par défaut,
personnalisables, (test1 ET test3).
solide. Utilisation de Microsoft's SQL language pour L'agent d'exploration du
Vue tactique de la plate forme.
interroger un système Microsoft sans installer d'agent. réseau semble plus abouti
que sur de nombreux
systèmes.
Moyen car :
L'interface est simple, on retrouve : Le système d'auto détection
liste des noeuds ; Faible : étant écrit en Moyen : est très performant [12].
Application mature liste des derniers problèmes ; Java, il suffit que le SNMP : il est facile d'ajouter une entrée de la MIB à Il n'est pas possible de Le système de vérification de
qui se veut fiable création de rapports personnalisés système d'exploitation surveiller. choisir les services à SLA est très bien fait, il est
Open (sélection de différents supporte un SDK 1.4. Service : nativement il est possible de surveiller surveiller pour un
pour être utilisée possible d'assigner une heure
NMS[10] graphiques) ; certains services(liste ), cependant pour ajouter un équipement particulier.
pour des milliers Exemple : Linux, Solaris, d'arrêt autorisé, des temps de
visualisation des graphiques service non supporté, il faut rédiger 2 Class Java (Une Pour ajouter un équipement
d'équipements[11]. MAC OS X, Windows... réponse à respecter...
PAS de carte pour la détection et une pour l'interrogation). Il faut qui ne répond pas à une
Voir la liste : [11] .
PAS de regroupement logique donc avoir une bonne connaissance en JEE. requête ICMP, il faut
possible exécuter un script Perl qui
lancera le service capsd.
Prérequis du
système
L'interface est très bien pour la

supervision d'une ferme, on retrouve :
Une page avec la liste des fermes
(clusters) avec : nombre de
nœuds, nombre de CPUs, charge
moyenne, nombre de processus;
Pour chaque ferme : Faible car c'est un
système réparti : Moyen car :
Une vue de synthèse (nombre
de nœuds actifs/inactifs, Un système de Pour le service gmond il faut
utilisation des nœuds par un supervision sur l'adapter en fonction du
Bon car il dépend entièrement de la capacité
Application mature et diagramme en cercle, charge chaque nœud système d'exploitation
(gmond), d'hétérogénéité du service gmond : Linux (i386, ia64, sparc, présent sur le nœud, Pas de mécanisme puisque cet
robuste (Version 3) CPU, réseau et mémoire par
Ganglia[12] graphique en ligne), Un système alpha, powerpc, m68k, mips, arm, hppa, s390), FreeBSD, NetBSD, Pour le service gmetad il outil est destiné aux
en constante
Une vue de chaque nœud avec d'agrégation de OpenBSD, DragonflyBSD, MacOS X, Solaris, AIX, IRIX, Tru64, faut lui demander administrateurs système.
évolution.
sa l'un des indicateurs : données (gmetad), HPUX and Windows NT/XP/2000/2003/2008 . d'interroger chaque nœud,
charge, température, mémoire, Une console de Pour le service Web il faut
vitesse ventilateurs... supervision lui configurer l'emplacement
Une vue physique de la ferme s'appuyant sur l'un des données.
avec l'emplacement physique des (gmetad).
des nœuds,
Pour chaque nœud : un résumé
avec le nombre de CPUs, la
mémoire, l'espace disque ; ainsi
qu'un graphique pour chaque
élément.
L'interface est bien organisée, on Bon car il existe une

Bon car il existe :
retrouve tout ce qu'il faut : documentation complète,
Un agent Windows 2k/XP/Vista/2003/2008 ;
Résumé de l'état des éléments il faut :
Application mature et Un agent Unix ; Facilitée par la bonne
supervisés avec des couleurs Apache ; Rapport SLA en temps réel et
Zabbix[13] assez largement Interrogation SNMP avec un index dynamique documentation et la console
représentatives ; PHP, PHP GD ; rapport par mois.
utilisée. possible ; d'administration.
Graphiques ; MySQL / Oracle /
Exécution de scripts home made ;
Configuration par la GUI ; PostGreSQL /
Serveur Proxy Zabbix.
Cartes personnalisables. SQLite.
L'interface est très bien organisée, on

retrouve tout ce qu'il faut :
Résumé de l'état des éléments Bon car il existe :
supervisés avec des couleurs Un agent pour : Microsoft Windows, Linux, Sun Solaris, AIX
Application mature et représentatives ; Bon, il y a une bonne and Novell Netware ; Facilitée par la bonne
Opsview[14] basé sur Nagios Liste des événements avec des documentation pour tous Interrogation SNMP avec un index dynamique documentation et la console Rapport SLA disponible.
qui est également. filtres ; les systèmes. possible ; d'administration.
Graphiques ; Exécution de scripts home made ;
Configuration ; Système réparti possible avec de la redondance.
Relance de Nagios ;
Cartes automatiques.
L'interface est très simpliste mais

donne les informations utiles. On
retrouve :
Résumé de l'état des éléments Étant uniquement basé sur le protocole SNMP (sauf pour
supervisés avec une couleur VMware ESX), un équipement non compatible ne pourrait
Application en
représentative ;
version stable mais être supervisé que par un test de type ping. La documentation se présente
Liste des derniers événements ; Bon : modules Perl,
sans activité Cependant, il existe une préconfiguration intéressante de sous la forme de fichiers de type
Unnoc[15] [13] Graphiques ; Apache, PHP, RRDTool, Rapport de SLA absent.
(développement et nombreux types d'équipements : serveur (Unix/Windows), "lisez moi", malgré tout elle
Pour chaque équipement, une MySQL.
documentation) aironet, airport, APC, cisco, VMWare VirtualCenter Management semble relativement complète.
page détaillée contenant toutes les
actuellement. Server et ESX . Et de services : OpenLDAP, MySQL,
informations.
PostgreSQL .
Il n'y a pas :
Configuration par l'interface ;

Carte ;
Gestion d'accès.
Prérequis du
système
Légende :
En rouge : la caractéristique n'est pas satisfaite,
En orange : la caractéristique n'est pas entièrement satisfaite,
En vert : la caractéristique est pleinement satisfaite.
Conclusion et choix
En résumé de cette étude, trois solutions ressortent :
Zabbix [16] : semble idéal pour surveiller une plateforme ayant une architecture réseau simple.
Opsview[17] : basé sur Nagios, cet outil se veut puissant et flexible. Il me semble envisageable pour une plateforme ayant une architecture complexe.
Ganglia[18] : solution sur mesure pour gérer un système en cluster quelque soit le système d'exploitation.
Comme prévu, il n'y a pas une solution qui réponde à tous les besoins. Certaines sont lourdes, mais très flexibles, d'autres, plus simples, ne répondent pas à toutes les exigences.
Dans les 3 sous-parties ci-dessous vous retrouverez les motivations pour chaque solution sélectionnée.
Zabbix
Cette plateforme offre deux agents efficaces (l'un pour Windows et l'autre pour Linux) ainsi qu'une exploitation poussée du protocole SNMP. À la vue des caractéristiques de la plateforme 1 :
Nombreuses machines identiques sous Windows pour l'analyse, l'enregistrement et la modification des données,
Quelques serveurs pour la gestion des machines ci-dessus,
Stockage des fichiers sur un NAS/SAN,
Interconnexion par des commutateurs supportant SNMP.
La supervision consistera principalement à surveiller :
l'espace disque,
la bande passante,
la charge de calcul,
l'espace mémoire vive.
Zabbix est un outil qui semble être tout à fait en mesure de répondre à ces problématiques.
Opsview
Ospview est une plateforme basée sur Nagios qui n'a plus ses preuves à faire en ce qui concerne les tâches de bases :
ordonnancer les vérifications,
sortir des statistiques,

alerter en cas de problème.
Opsview est une couche d'abstraction qui permet de simplifier l'administration de Nagios et d'ajouter des fonctionnalités sans diminuer les performances :
des agents performants pour Windows, Linux, SUN Solaris...
une cartographie personnalisable pour une meilleure compréhension de l'état du système,
une notification avancée.
Cet agrégat d'outils permet de répondre à des exigences spécifiques comme celles de la plateforme 2. Il sera ainsi possible d'obtenir un outil de supervision capable de vérifier l'état d'un service complexe.
Ganglia
Ganglia est beaucoup plus spécifique, c'est réellement un outil de supervision complémentaire destiné à la supervision d'un système en cluster comme le serveur SUN présent sur la plateforme 1.
Comme cette solution ne semble pas très complexe et nécessite les mêmes prérequis que la solution Opsview, il est envisageable de la mettre en place exclusivement pour superviser le cluster SUN.
Réalisation de la maquette
Le but de réaliser une maquette est de valider les choix, écrire des manuels d'installation et se familiariser avec les solutions avant de les installer pour la mise en production.
Ressources
Les ressources matérielles sont :
2 serveurs IBM x3550
1 ordinateur portable
Les ressources logicielles sont :
Windows 2003 serveur
Windows 2000
Debian lenny netinst
CentOS 5.2
VMware ESX 3.5
La maquette
Cette maquette doit être rapide à mettre en place, 8 jours-homme. Un choix de virtualiser les hôtes semble le plus efficace. Il est ainsi possible de dupliquer un hôte virtuel et faire des sauvegardes
instantanées. Le logiciel VMware ESX a été installé sur l'un des serveurs IBM x3550, la console de gestion (VMware Infrastructure Client) a été installée sur un ordinateur portable.
Plateforme 2
Pour la plateforme 1, un hôte virtuel "SUP_1" a été créé. Le système d'exploitation choisi est Linux Debian 5.0 2.6.26-1-686, ce système d'exploitation permettra une installation rapide de OpsView.
Pour pouvoir télécharger les sources et paquets par Internet, une passerelle a été configurée sur l'ordinateur portable, le script créé est disponible en annexe.
Les étapes d'installation de OpsView sous Debian sont détaillées en annexe données confidentielles.
Les fonctionnalités attendues de cette solution ont été validées, l'installation d'un agent sur une machine de test sous Unix a également permis de vérifier son bon fonctionnement et la possibilité de superviser
les services.
données confidentielles : Diagramme logique de la maquette mise en place pour le test de la solution de supervision de la plateforme 1.
Plateforme 1
La maquette de 1 se base sur le système d'exploitation CentOS 5.2 qui est une préconisation de mon tuteur. Cette maquette a permis de valider le manuel d'installation officiel de Zabbix 1.6.2.
Les étapes d'installation de Zabbix sous CentOS 5.2 sont détaillées en annexe données confidentielles.
Une machine de la plateforme de test a été mise à ma disposition pour vérifier la possibilité de superviser certains services, processus, cartes réseaux et le nombre d'échange disque. Lors de la mise en place
de l'agent sur ce serveur, je me suis aperçu que le nom et le nombre des services ne sont pas homogènes sur le parc. Ceci posant un problème d'automatisation de l'installation des agents ainsi que d'auto
configuration de Zabbix, il fallait trouver et réaliser une solution. La seule solution trouvée a été de créer un script d'automatisation de l'installation des agents permettant :
une configuration automatisée hétérogène au niveau des agents ;
une configuration automatisée du serveur Zabbix homogène à tous les serveurs (analyseurs, enregistreurs et transcodeurs).
Le lundi 16, j'ai effectué une démonstration complète de Zabbix à mon tuteur de stage pour valider l'utilisation de Zabbix en production et passer à la phase suivante (mise en production).
données confidentielles : Diagramme logique de la maquette mise en place pour le test de la solution de supervision de la plateforme 1.
Conclusion
La mise en place de ces maquettes a permis de se familiariser avec les solutions, de les valider et de prendre des notes pour éviter les erreurs lors de la mise en production.
À cause des différents problèmes rencontrés, le temps alloué à la réalisation de la maquette a été dépassé d'une semaine. Un point sera fait à la fin de la mise en production de la solution pour la plateforme
2.
Mise en production des solutions

La mise en production est en quelque sorte l'aboutissement et la validation des études faites précédemment. Dans ce chapitre vous retrouverez pour les deux plateformes les actions effectuées lors de cette
étape.
Plateforme 2
Ce chapitre constitue le rapport de l'activité de mise en production de la solution de supervision sur la plateforme 2. Vous y retrouverez la méthodologie de configuration, la liste des éléments supervisés ainsi
qu'une conclusion analysant le déroulement de cette phase.
Méthodologie de configuration
Pour superviser la plateforme, il y avait deux stratégies possibles :
une première par couche qui consiste à superviser les couches basses de tous les équipements puis les couches supérieures.
L'avantage serait que même par un manque de temps, l'ensemble de la plateforme sera supervisé.
L'inconvénient est que le manque de temps empêchera une supervision de type service.
la seconde stratégie est une approche par équipement, il s'agit de superviser tout ce qui est pertinent par machine.
L'avantage est de superviser complètement chaque équipement fait.
L'inconvénient est de risquer d'avoir des discontinuités de la supervision sur la plateforme (des trous noirs).
La solution choisie est la seconde avec une approche par équipement. Avec mon tuteur de stage, nous avons établi équipement par équipement les services à superviser en tenant compte du temps qui m'a
été imparti pour la réalisation.
Mise en place
Lors de la mise en place, j'ai eu l'occasion de découvrir un système d'exploitation : SunOS et que Bash n'est pas un interpréteur forcément présent ! Pour effectuer certains tests, des scripts ont été écrits :
Présence IP par telnet ;
Présence d'un processus :
par nom,
par numéro,
par fichier PID.
Rapport de l'état d'une interface HSRP ;
Test de l'IPTakeOver.
Même laborieuse pour débusquer des applications cachées, la mise en place s'est bien passée. Au total c'est 20 équipements et 119 services testés. Il devrait y en avoir beaucoup plus mais le temps est une
denrée rare !
Documentation
Avec les notes d'installation, j'ai créé une documentation qui permet de rejouer l'installation et la configuration de la solution.
La documentation pour une application dont la configuration n'est pas achevée trouve tout son sens. L'application va évoluer avec la plateforme et les administrateurs devront être capables de maintenir
l'application. Pour ces raisons une bonne documentation a été réalisée :
Installation de Opsview sous Debian
Installation de OpsView sous CentOS 5.2
Installation de NRPE sous Fédora
Installation de NRPE sous RHEL4
Installation de Nagios-plugins sous Unix
Authentification SSH par clé publique
Commande sudo sans mot de passe
Configuration de OpsView
Gestion des hôtes
Ajout d'un hôte
Création d'un service
Création d'un plugiciel
Ajouter une icône
Superviser un serveur Unix
Superviser un équipement réseau
Pour changer de main l'outil de supervision, j'ai effectué une démonstration pendant environ 45 minutes pour que les administrateurs comprennent comment l'outil fonctionne sans pour autant lire la
documentation. Cette documentation leur permettra d'effectuer la configuration pas-à-pas d'un nouvel équipement.
Conclusion
L'installation de la solution de production n'a pas posé de difficulté particulière grâce au savoir-faire acquis avec la maquette.
Le temps de réalisation de la maquette ayant pris plus de temps que prévue, la mise en production a été repoussée semaine 12 et 13. Le but n'était pas de tout superviser, mais la stratégie de configuration
par équipement a permis de superviser tous les éléments définis avec mon tuteur de stage dans la partie "Méthodologie de configuration".
En conclusion, après ces deux semaines, une solution fonctionnelle a été mise en place. Cependant la solution Ganglia pour le cluster SUN n'a pas été mise en place par manque de temps.
Vous retrouverez en annexe toute les documentations pour l'installation et la configuration de la solution ainsi que pour les agents.
Plateforme 1
Ce chapitre rapport l'activité de mise en production de la solution de supervision sur la plateforme 1.
Méthodologie de configuration
Pour superviser la plateforme, je n'ai pas eu l'autorisation de déployer la supervision sur tous les équipements, mais seulement sur certains. La méthodologie a donc consisté à tester sur quelques équipements
"échantillon" l'outil de supervision et sa configuration.
L'avantage est de voir en profondeur les capacités de l'outil et de découvrir de nouvelles fonctionnalités.
Déploiement
La mise en production de la solution se caractérise par l'installation de Zabbix sur une machine virtuelle déjà existante. Cette machine virtuelle était initialement hébergée par un serveur ESX du système
d'information de la société. Ce serveur étant surchargé, il a fallu migrer la machine sur un serveur de la plateforme 1 en utilisant la version gratuite de ESX (ESXi).
Pour ce qui est des hôtes, l'installation et la configuration de l'agent étant automatique grâce au script réalisé lors de la maquette, le déploiement a été rapide.
Conclusion
La mise en production de la solution de supervision n'a posé aucun problème. Le projet 1 étant actuellement en "pause", il n'était pas pertinent de déployer la supervision sur tous les équipements. Cependant,
les recherches sur la solution, sa prise en main, le développement de scripts et l'étude du fonctionnement de la plateforme ont été des actions pertinentes et formatrices.
Sur l'outil Zabbix, la conclusion est qu'il est efficace et permet un grand gain de temps pour un usage sur une plateforme classique sans équipements ni services particuliers.
Notes
1. ↑ Un événement est un fait détectable qui présente une certaine importance en ce qui concerne la gestion des infrastructures ou la production d'un service.
2. ↑ AAA est un protocole de sécurité informatique qui signifie : l'authentification, l'autorisation, et la traçabilité. Pour plus d'information, voir la définition de Wikipédia [1] .
3. ↑ Un Portail Captif (CP) permet de rediriger un client vers une page WEB pour généralement lui demander de s'authentifier pour pouvoir accéder à Internet (voir la définition de Wikipédia [2] ).
4. ↑ OID pour Object Identifier représente le chemin unique pour un élément de la MIB.
5. ↑ MIB pour Management Information Base est une base de données du protocole SNMP.
6. ↑ 6,0 et 6,1 Simple Network Management Protocol[3] est un protocole défini par l'IETF pour supervision un système d'information.
7. ↑ Red Hat Enterprise Linux[4] est une distribution Linux commerciale.
8. ↑ La supervision réseau porte sur la surveillance de manière continue de la disponibilité des services en ligne - du fonctionnement, des débits, de la sécurité, mais également du contrôle des flux (définition de wikipedia ).
9. ↑ 9,0, 9,1, 9,2 et 9,3 Service Level Agreement est une notion du référentiel ITIL qui définit un niveau de service. Dans notre cas il s'agit de noter si oui ou non la solution de supervision est capable de fournir des rapports de
respect d'un niveau de qualité préalablement défini.
10. ↑ 10,0 , 10,1 et 10,2 L'interface se définit par les critères suivants : l'ergonomie, l'accessibilité, la présence de cartographies des équipements, mais également de graphiques (même si cela se rapproche de la métrologie).
11. ↑ Sur OpenNMS.org : OpenNMS was developed from the beginning to be an enterprise-grade solution capable of monitoring a theoretically unlimited number of devices (via a distributed and tiered system).
12. ↑ La détection des équipements de OpenNMS est performante dans le sens où elle teste la présence d'un équipement par une requête ICMP de type "echo request" (par le service discovery) puis chaque service que la plate
forme est capable de surveiller (par le service capsd).
13. ↑ Unnoc vient de NOC(Network operations center ) qui représente une application de gestion d'un réseau Informatique.
Catégories : Rapports | Réseau informatique
Dernière modification de cette page le 21 avril 2009 à 14:37.
Cette page a été consultée 1 316 fois.
Contenu disponible sous Attribution-NonCommercial-ShareAlike 3.0 Unported.
Politique de confidentialité À propos de Wiki de Romain RUDIGER Avertissements

Étude D'avant Projet de Mise en Place D'une Plateforme de Supervision - Wiki

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Étude D'avant Projet de Mise en Place D'une Plateforme de Supervision - Wiki

Diunggah oleh

Hak Cipta:

Format Tersedia

Étude d'avant projet de mise en place d'une plateforme de supervision - Wiki de Romain RUDIGER

Page Discussion Lire Voir la source Afficher l’historique Lire Rechercher

Pages liées 1.2 Plateforme 2

Présentations, objectifs et contraintes

Les fondations d'un service.

Le cycle de vie des services.

Le serveur AAA [2]

Présentation des plateformes

Liste des tâches

Lister les dépendances

Noter les étapes d'installation

Mettre en place chaque type de supervision

Configurer les accès

Vérifier les performances

Ressources humaines et techniques

Analyse des risques

Risques liés au déploiement

Risques liés à l'exploitation

Domaine couvert, type de licence et langue

Organisation des entités surveillées

Surveillance des niveaux

Surveillance des services

La gestion des événements

Liste des événements

La tolérance aux pannes

Étude des solutions de supervision

Comparatif des solutions

Les critères de comparaison

Comparatif des solutions

L'interface simple permet de retrouver

La configuration semble facile

L'interface est très bien pour la

L'interface est bien organisée, on Bon car il existe une

L'interface est très bien organisée, on

L'interface est très simpliste mais

Configuration par l'interface ;

sortir des statistiques,

Mise en production des solutions

Catégories : Rapports | Réseau informatique

Dernière modification de cette page le 21 avril 2009 à 14:37.

Cette page a été consultée 1 316 fois.

Contenu disponible sous Attribution-NonCommercial-ShareAlike 3.0 Unported.

Politique de confidentialité À propos de Wiki de Romain RUDIGER Avertissements

Anda mungkin juga menyukai