Une première, une installation complète d’une solution de supervision de classe entreprise comme on dit :-) Bon ça ne va pas tenir en un seul article, alors on est parti pour un premier épisode de présentation.

Introduction

On a de plus en plus d’exigences concernant la disponibilité de ses services mais comment faire du hautement disponible si sa supervision est en vrac au moment d’un incident ? On se rend vite compte qu’il est nécessaire de rendre cet outil indispensable beaucoup plus robuste car c’est le seul moyen d’être pro-actif.

Avec la virtualisation et les applications full web, on a vu nos systèmes d’information exploser en terme de nombre de serveurs et de complexité des architectures, il faut que la supervision suive. Hors un outil monolithique, comme le standard de fait Nagios, n’est pas extensible à l’infini. Il nous faut une solution scalable.

Il faut mettre en valeur notre activité, pas seulement lorsqu’il y a des incidents. De plus nos décideurs et nos utilisateurs finaux sont demandeurs d’information. La supervision, du fait de son périmètre transverse, est l’outil idéal pour produire des tableaux de bord dynamiques, c’est à la mode en ce moment ;-)

Shinken répond à ces trois problématiques.

J’aimerais documenter la mise en place d’une solution de supervision de classe “entreprise” dans tous ces détails : des réflexions sur l’architecture à la configuration de checks. Comme j’ai pas envi d’écrire un roman, je vous propose de faire plusieurs épisodes comme je le fais déjà pour des sujets plus larges. Pour les gourmands voila le menu détaillé, sachant que le plat du jour est l’architecture :

Episode 1 : Architecture.
Episode 2 : Installation d’un master.
Episode 3 : Installation d’une probe.
…

L’architecture

J’ai un contexte intéressant pour mettre en œuvre une architecture distribuée mais c’est pas une raison pour monter 36 000 VMs. L’objectif est de garder quelque chose de simple tout en étant scalable et d’une certaine robustesse. Donc, on va avoir deux types de serveurs : le master pour la configuration centrale et l’interface unique et un certain nombre de sondes qui seront déployées sur les sites géographiques.

Le produit Shinken est divisé en plusieurs rôles, certains seront hébergés sur le master et d’autres sur la sonde. L’architecture distribuée de Shinken se définit à l’aide de sites, des realms. C’est avec ces realms qu’on va calquer l’organisation de notre établissement. On aura un realm global puis un realm par site géographique, le master sera membre du realm global et distribuera les checks aux sondes de chaque site où se trouvent des équipements à monitorer.

Initialement, je voulais que la sonde n’embarque que le rôle poller et ce dernier travaillant en mode passif, c’est à dire qu’il n’initiera pas de connexion vers le master. Plutôt pratique et propre pour les ouvertures de pare-feux ;-) Malheureusement, il est nécessaire d’avoir au moins un scheduler par site et il n’y a pas l’option “manage_sub_realm” pour ce rôle. Soit on multiplie le démon scheduler sur le master (un par realm), soit on place ce rôle sur la sonde, soit on a un type de serveurs supplémentaire n’hébergeant que le scheduler.

Pour garder une architecture simple et comme le service n’est pas “dangereux”, j’ai choisis de déplacer le role scheduler sur les sondes, ça améliorer la scalabilité car c’est les schedulers et les pollers qui absorbent la charge des checks. Pour résumer, on a deux types de nœuds, le master et la probe.

Schéma de principe

Dans notre cas de départ, nous avons deux datacentres, une sonde sera présente sur chaque datacentres et le master sera hébergé sur l’un des deux. Au niveau des flux, le master doit pouvoir contacter toutes les sondes, ces dernières vont contacter de nombreux équipements dans les realms où elles se trouvent.

Pré-requis pour toutes les machines

J’ai fais mes tests avec des Scientific Linux et le dépot EPEL activé. Cela permet d’installer facilement les paquets, de gérer les démons. J’ai eu quelques difficultés, il y a donc des pré-requis à respecter au moment de l’installation système.

On pense à installer le dépot EPEL et on met à jour le système :

yum install epel-release -y
yum update -y

On configure le NTP car il est nécessaire que les sondes soient synchronisées avec le master sinon on a des effets de bord un peu chiant à détecter (génération des graphiques KO par exemple) :

yum install ntpdate -y
crontab -e
0  0  * * *      /usr/sbin/ntpdate europe.pool.ntp.org

Les serveurs des deux datacentres sortent à l’extérieur via un NAT. Les nœuds Shinken vont donc avoir une IP publique et une IP privée. Cela va poser problème car le fichier de conf shinken-specific est unique est distribué à tous les rôles. En supervision, on évite d’être dépendant d’un service DNS qui peut être indisponible. Une solution pas forcément très élégante est de s’appuyer sur les fichiers /etc/hosts pour faire résoudre les noms des serveurs Shinken soit avec l’IP interne soit la routable.

Donc sur un serveur du site1, vous allez faire matcher les noms des serveurs du site1 avec leur IP interne respective et les noms des serveurs du site2 avec les IP routables (on suppose que le master est sur le site1).

vim /etc/hosts
<ip_interne> supervision-master
<ip_interne> supervision-site1
<ip_routable> supervision-site2

Faire l’inverse pour les machine du site2 ;-)

Ouvertures réseaux

On arrive au sujet qui fâche, le réseau. Avec la supervision, c’est plus que jamais le cœur de la problématique car on doit pouvoir accéder à potentiellement tous les équipements du SI. Il est difficile de donner une configuration qui sera utile pour toutes les architectures, ça va beaucoup dépendre de votre cloisonnement réseau. On va donner les flux pour 4 ensembles : Le master, la sonde, les utilisateurs et les services à superviser.

Pour rappel, voici les ports par défaut où répondent les rôles Shinken :

Arbiter : 7770
Broker : 7772
WebUI : 7767
Reactionner : 7769
Scheduler : 7768
Poller : 7771

En écrivant cette partie, je me rend compte que le scheduler n’initie aucune requête, en fait il est en mode passif par défaut, d’une certaine façon. Ca tombe bien, c’est notre master qui contactera nos sondes, les sondes ouvriront des connexions seulement vers les équipements à surveiller. L’admin et les utilisateurs n’ont besoin d’accéder qu’au master. J’ajouterai les infos concernant les mécanisme de HA dans une partie dédiée.

Conclusion de l’épisode

Je pense qu’on a dans cette architecture toute simple un bon point de départ qui pourra monter en charge et en fonctionnalités. J’ai quelques réserves sur les perfs des rôles broker (la webUI) et reactionner (levé d’alertes). On trouve encore assez peu de docs sur la version RPM de shinken ainsi que les architectures distrubées, cela va s’étoffer au fur et à mesure. Le contenu de cet article est peu léger, ce sont des boites vides que l’on va remplir par la suite :-)

Références

Pas mal de schémas et de détails sur les architectures Shinken : http://wiki.monitoring-fr.org/shinken/shinken-work
Sinon le wiki officiel Shinken dont cette page explicitant les realms : http://www.shinken-monitoring.org/wiki/advanced_features

Shinken distribué - épisode 1 : Présentation de l'architecture