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.
