Étude d'avant projet de mise en place d'une plateforme de supervision

De Wiki de Romain RUDIGER
Aller à : navigation, rechercher


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 complète pour respecter la politique de confidentialité de la société pour laquelle cette étude a été réalisée.

Participant : Romain RÜDIGER.

Période : 02/09 - 03/09.

Sommaire

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
Nom Maturité Interface [10] Prérequis du système Niveau d'hétérogénéité du SI supporté Configuration SLA[9]
Nagios[8] Application très mature avec une large communauté active. 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 ;
    • De l'outil de supervision lui-même.
  • Une carte par groupe logique (les routeurs, les serveurs, les équipements du service d'authentification...) avec des couleurs selon l'état des équipements.
  • Des graphiques pour tous les éléments supervisés.
  • Des couleurs représentatives (rouge, vert, gris...).
Moyen car compilé sur le système (Linux) et car les scripts nécessitent généralement des modules Perl spécifiques. Bon car il existe un très grand nombre de modules permettant de vérifier beaucoup de services applicatifs, équipements...

De plus, NRPE permet de vérifier les informations locales d'un serveur sous Linux.

La configuration de Nagios en elle-même n'est pas très difficile mais nécessite une prise en main du fonctionnement des fichiers de configuration. Grâce aux rapports de Hostgroup Availibility Report et Service Availibility Report.
Pandora FMS[9] Pandora FMS est un système assez mature (3ans), difficile de savoir si la communauté est solide. L'interface est bien pensée, agréable et fonctionnelle pour tous les types d'utilisateurs.
  • Graphiques simples ou combinés,
  • Cartes automatiques et personnalisables,
  • Vue tactique de la plate forme.
Moyen : Apache, Perl, PHP, MySQL, SSH... Donc un système type : Linux. Bon :
  • L'organisation en modules permet au système d'être souple pour s'adapter à toutes les configurations (Pare-Feux, OS spécifiques...) ;
  • Interrogation par commande système en SSH, Telnet ;
  • Système de répartition des serveurs ;
  • Utilisation de Microsoft's SQL language pour interroger un système Microsoft sans installer d'agent.
La configuration semble facile mais surtout efficace grâce à l'utilisation de :
  • Modèles (Network Components Templates/Profiles) permettant de créer des configurations par défaut,
  • L'agent d'exploration du réseau semble plus abouti que sur de nombreux systèmes.
Très bien supporté par un système complexe d'alerte avec par exemple la nécessité d'avoir : (test1 ET test2) OU (test1 ET test3).
Open NMS[10] Application mature qui se veut fiable pour être utilisée pour des milliers d'équipements[11]. L'interface est simple, on retrouve :
  • liste des noeuds ;
  • liste des derniers problèmes ;
  • création de rapports personnalisés (sélection de différents graphiques) ;
  • visualisation des graphiques
  • PAS de carte
  • PAS de regroupement logique possible
Faible : étant écrit en Java, il suffit que le système d'exploitation supporte un SDK 1.4.

Exemple : Linux, Solaris, MAC OS X, Windows... Voir la liste : [11].

Moyen :
  • SNMP : il est facile d'ajouter une entrée de la MIB à surveiller.
  • Service : nativement il est possible de surveiller certains services(liste), cependant pour ajouter un service non supporté, il faut rédiger 2 Class Java (Une pour la détection et une pour l'interrogation). Il faut donc avoir une bonne connaissance en JEE.
Moyen car :
  • Le système d'auto détection est très performant[12].
  • Il n'est pas possible de choisir les services à surveiller pour un équipement particulier.
  • Pour ajouter un équipement qui ne répond pas à une requête ICMP, il faut exécuter un script Perl qui lancera le service capsd.
Le système de vérification de SLA est très bien fait, il est possible d'assigner une heure d'arrêt autorisé, des temps de réponse à respecter...
Nom Maturité Interface [10] Prérequis du système Niveau d'hétérogénéité du SI supporté Configuration SLA[9]
Ganglia[12] Application mature et robuste (Version 3) en constante évolution. 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 :
    • Une vue de synthèse (nombre de nœuds actifs/inactifs, utilisation des nœuds par un diagramme en cercle, charge CPU, réseau et mémoire par graphique en ligne),
    • Une vue de chaque nœud avec sa l'un des indicateurs : charge, température, mémoire, vitesse ventilateurs...
    • Une vue physique de la ferme avec l'emplacement physique 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.
Faible car c'est un système réparti :
  • Un système de supervision sur chaque nœud (gmond),
  • Un système d'agrégation de données (gmetad),
  • Une console de supervision s'appuyant sur l'un des (gmetad).
Bon car il dépend entièrement de la capacité d'hétérogénéité du service gmond : Linux (i386, ia64, sparc, alpha, powerpc, m68k, mips, arm, hppa, s390), FreeBSD, NetBSD, OpenBSD, DragonflyBSD, MacOS X, Solaris, AIX, IRIX, Tru64, HPUX and Windows NT/XP/2000/2003/2008. Moyen car :
  • Pour le service gmond il faut l'adapter en fonction du système d'exploitation présent sur le nœud,
  • Pour le service gmetad il faut lui demander d'interroger chaque nœud,
  • Pour le service Web il faut lui configurer l'emplacement des données.
Pas de mécanisme puisque cet outil est destiné aux administrateurs système.
Zabbix[13] Application mature et assez largement utilisée. L'interface est bien organisée, on retrouve tout ce qu'il faut :
  • Résumé de l'état des éléments supervisés avec des couleurs représentatives ;
  • Graphiques ;
  • Configuration par la GUI ;
  • Cartes personnalisables.
Bon car il existe une documentation complète, il faut :
  • Apache ;
  • PHP, PHP GD ;
  • MySQL / Oracle / PostGreSQL / SQLite.
Bon car il existe :
  • Un agent Windows 2k/XP/Vista/2003/2008 ;
  • Un agent Unix ;
  • Interrogation SNMP avec un index dynamique possible ;
  • Exécution de scripts home made ;
  • Serveur Proxy Zabbix.
Facilitée par la bonne documentation et la console d'administration. Rapport SLA en temps réel et rapport par mois.
Opsview[14] Application mature et basé sur Nagios qui est également. L'interface est très bien organisée, on retrouve tout ce qu'il faut :
  • Résumé de l'état des éléments supervisés avec des couleurs représentatives ;
  • Liste des événements avec des filtres ;
  • Graphiques ;
  • Configuration ;
  • Relance de Nagios ;
  • Cartes automatiques.
Bon, il y a une bonne documentation pour tous les systèmes. Bon car il existe :
  • Un agent pour : Microsoft Windows, Linux, Sun Solaris, AIX and Novell Netware ;
  • Interrogation SNMP avec un index dynamique possible ;
  • Exécution de scripts home made ;
  • Système réparti possible avec de la redondance.
Facilitée par la bonne documentation et la console d'administration. Rapport SLA disponible.
Unnoc[15][13] Application en version stable mais sans activité (développement et documentation) actuellement. L'interface est très simpliste mais donne les informations utiles. On retrouve :
  • Résumé de l'état des éléments supervisés avec une couleur représentative ;
  • Liste des derniers événements ;
  • Graphiques ;
  • Pour chaque équipement, une page détaillée contenant toutes les informations.

Il n'y a pas :

  • Configuration par l'interface ;
  • Carte ;
  • Gestion d'accès.
Bon : modules Perl, Apache, PHP, RRDTool, MySQL. Étant uniquement basé sur le protocole SNMP (sauf pour VMware ESX), un équipement non compatible ne pourrait être supervisé que par un test de type ping.

Cependant, il existe une préconfiguration intéressante de nombreux types d'équipements : serveur (Unix/Windows), aironet, airport, APC, cisco, VMWare VirtualCenter Management Server et ESX. Et de services : OpenLDAP, MySQL, PostgreSQL.

La documentation se présente sous la forme de fichiers de type "lisez moi", malgré tout elle semble relativement complète. Rapport de SLA absent.
Nom Maturité Interface [10] Prérequis du système Niveau d'hétérogénéité du SI supporté Configuration SLA[9]

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.