Hypervision, une vision consolidée de l’état du SI
Là où, quelques années auparavant une application était fournie par un serveur unique et monolithique, on voit apparaitre des plates-formes applicatives ou des fermes de services. Ce qui complexifie la supervision.
Le recul des grands systèmes et l’avènement des systèmes ouverts ont considérablement modifié la physiologie des datacenters. Là où, quelques années auparavant une application ou fonction applicative était fournie par un serveur unique et monolithique, on voit apparaitre des plates-formes applicatives ou des fermes de services. Les architectures d’application ainsi que leur supervision deviennent dès lors plus complexes : quel est le rôle de chaque serveur ? Quels serveurs participent à une application donnée ?Les grandes organisations subissent de plein fouet ces contraintes et doivent s'adapter en repensant intégralement leur CMDB (Configuration Management DataBase) et leur supervision.
Les limites d'une supervision traditionnelle ?
Se doter d'une "super-supervision" n'est pas toujours possible. Le modèle d'une supervision globale montre très vite ses limites pour les grandes organisations :
- Généralement un unique outil de supervision ne permet pas de couvrir efficacement l'ensemble des besoins d'une entreprise : réseau, sécurité, système, sgbd, middleware,...
- Le déploiement d'un agent sur un parc hétérogène de serveurs est un frein opérationnel
- L'important volume des flux échangés entre un patrimoine informatique de plusieurs milliers de machines et un serveur qui centralise la remontée des alertes, fragilise l'architecture technique d'une supervision unifiée (risque de contention réseau, de non respect des fréquences de rafraichissement des contrôles...)
Une approche respectueuse de l'organisation en place
L'hypervision permet de lever l'ensemble de ces contraintes en repensant l'architecture et en redistribuant les tâches. Les fonctions natives de surveillance restent assurées par les superviseurs : tests, seuils d'alerte... Se positionnant comme une brique additionnelle, l'hyperviseur ne dialogue pas avec le parc de serveurs de production (un nouvel agent n'est en conséquence pas nécessaire) mais hérite des changements d'état remontés par chaque superviseur. La mise en œuvre d'un hyperviseur respecte en conséquence les outils existant tout en proposant de nouveaux services :
- Consolider les informations dans une console unique en lieu et place d'une multitude de superviseurs
- Enrichir les évènements sur la base des relations décrite dans un référentiel externe (CMDB...). Il est ainsi possible de lier une alerte à une application, une fonction, une équipe...
- Corréler les alertes en elles afin de mettre en avant la cause première d'un incident et montrer les relations entre les alertes issues de différents superviseurs
- Offrir des services additionnels
o Génération automatique de tickets d'incident. Systématiser cette pratique permet de mieux suivre et tracer la qualité de service d'une application
o Reporting d'alertes afin de suivre et analyser la gestion des incidents et des problèmes
D'une vue de l'expert vers une vue applicative
Les solutions traditionnelles de supervision sont axées sur des vues techniques pour experts (ingénieurs système, réseau, DBA ...) et négligent la dimension applicative des composants. En tirant pleinement partie d'une CMDB et en rationalisant les alertes, l'hypervision se positionne comme le chainon manquant entre technologie et métier et permet de mieux partager des informations entre Production Informatique, Études et utilisateurs.