Architecture distribuée redondante

Fonctionnement

L’architecture distribuée redondante consiste à avoir deux types d’entités :

  • Le serveur central qui centralise les informations de supervision
  • Un ou plusieurs collecteurs qui sont chargés de la supervision des équipements

Afin d’assurer une redondance, le serveur central est répliqué à l’identique.

Les serveurs centraux regroupent les éléments suivants :

  • L’interface web de Centreon
  • Le moteur de supervision
  • Le broker
  • Les bases de données (MySQL + RRD)

Le collecteur contient les éléments suivants :

  • Le moteur de supervision
  • Le module de broker qui permet l’envoi des informations de supervision vers le serveur central

Cette architecture a plusieurs intérêts :

  • Elle permet la répartition de la charge de supervision entre plusieurs serveurs de supervision
  • Isolation des flux réseaux : si votre infrastructure de supervision est chargée de superviser une DMZ, il est plus simple (et sécurisant) de placer un collecteur sur le réseau DMZ
  • Avoir une redondance au niveau des serveurs Centraux, si un serveur central tombe alors le second serveur central existe toujours et permet d’assurer une continuité de service

Entités

Serveur centraux

Il existe deux types de serveur central :

  • Un master qui fonctionne normalement
  • Un slave qui est configuré de la même manière que le serveur master mais qui n’a démarré que les services Centreon Broker RRD et MySQL

Le serveur central master fonctionne normalement :

  • Le serveur Apache est chargé d’héberger l’interface web de Centreon
  • Plusieurs bases de données MySQL sont chargées de stocker la configuration de Centreon, les informations de supervision ainsi que les données de performances
  • Le service CentCore est chargé d’exporter la configuration des moteurs de supervision vers le serveur central et collecteurs ainsi que du redémarrage des moteurs de supervision
  • Le moteur de supervision supervise le système d’informations
  • Les informations de supervision sont envoyées via cbmod à Centreon Broker SQL
  • Centreon Broker SQL est chargé d’insérer les données de supervision en base de données et de transmettre les données de performances aux 2 services Centreon Broker RRD (le premier se situe sur le master et l’autre sur le slave)
  • Centreon Broker RRD est chargé de générer les fichiers RRD (qui servent à générer les graphiques de performances)

Une réplication MySQL permet de conserver la configuration de Centreon, les informations de supervision ainsi que les données de performances entre les deux serveurs centraux.

Le serveur slave lui est uniquement chargé de générer les fichiers RRD.

En cas de panne du master, on démarre les services : Apache, CentCore, Centreon Engine ainsi que Centreon Broker SQL sur le serveur slave. Le serveur slave remplace le serveur master.

La bascule master/slave ainsi que le démarrage et l’arrêt des services sont gérés par le couple Corosync + Pacemaker.

Architecture

Le schéma ci-dessous résume le fonctionnement de l’architecture :

../../_images/Architecture_redundancy.png