La plateforme de supervision est souvent un élément très important d'un parc informatique. Il faut pouvoir avoir pleinement confiance dans cette plateforme, et en sa capacité à informer des erreurs et problèmes potentiels du périmètre de machines supervisées.
Il est donc intéressant d'avoir une architecture hautement disponible pour la supervision afin que celle ci soit fonctionnelle même lors d'un problème sur une partie du logiciel de supervision.
Shinken Entreprise permet de configurer les démons qui composent une installation de manière à obtenir une supervision hautement disponible.
Chaque démon dans Shinken Entreprise peut être secondé par un démon de même type configuré en tant que Spare. Le principe des Spares permet d'assurer une haute disponibilité en assurant un service continu même lorsqu'un démon cesse de fonctionner.
On classe alors les démons dans 2 catégories: les démons maîtres et les démons Spare.
Le cycle de vie d'un Spare est le suivant:
|
Plusieurs remarques peuvent être effectuées sur le fonctionnement des spares.
L'ajout d'un démon Spare s'effectue en 4 étapes:
Pour illustrer la configuration d'un démon spare, on prend l'exemple d'un Poller qu'on va configurer en tant que spare.
La configuration d'un Spare, comme pour la configuration d'un démon classique, s'effectue sur la machine hébergeant le démon Arbiter. Aucune modification au niveau des fichiers de configuration n'est à effectuer sur la machine hébergeant le Poller spare.
define poller {
poller_name poller-spare
address adresse-poller-spare (ip ou nom dns)
port 7771
use_ssl› 0
keep_timeout_time 1200
min_workers 0
processes_by_worker 256
polling_interval 1
#exec_stat_range 50, 100, 200, 300, 400
max_ram_percent 95
#max_cpu_queue_per_cpu 4
timeout 3
data_timeout 120
max_check_attempts 3
check_interval 60
modules
realm All
manage_sub_realms 0
#poller_tags None
passive 0
spare 0
enabled 1
} |
define poller {
...
spare 1
...
} |
Activation du poller sur la machine distante
Enfin, sur la machine hébergeant le Poller spare, il faut vérifier que le poller est bien activé. Cette vérification va se faire avec les commandes de Manipulation des démons Shinken.
On vérifie d'abord que le démon Poller est activé (sur la machine du spare):
$ shinken-daemons-list |
Si le Poller n'est pas activé sur la machine spare, on peut l'activer grâce à la commande shinken-daemons-enable:
$ shinken-daemons-enable poller |
Aussi, seul les démons utilisés doivent être activés sur la machine de spare, sous peine d'avoir des comportements hasardeux en cas de mauvaise configuration. Les démons inutilisés peuvent être désactivés grâce à la commande shinken-daemons-disable:
$ shinken-daemons-disable demon1 demon2 ... |
Nous avons vu que dans Shinken Entreprise, l'ajout d'un démon spare n'était pas plus difficile que l'ajout de n'importe quel autre démon:
Deux démons échappent à cette règle de configuration pour le cas des spares: l'Arbiter et le Synchronizer
En effet, ces deux démons sont spéciaux dans le sens ou ils ne peuvent pas être répliqués facilement:
Compte tenu de son rôle central, la configuration d'un Arbiter spare nécessite donc des étapes supplémentaires:
define arbiter {
arbiter_name arbiter-spare
host_name lab-vm3
address adresse-arbiter-spare
port 7770
use_ssl› 0
timeout 3
data_timeout 120
max_check_attempts 1
check_interval 10
spare 0
modules synchronizer-import
enabled 1
} |
Activation du paramètre spare
Dans le fichier de configuration de l'Arbiter spare, on passe ensuite le paramètre spare à 1
define arbiter {
...
spare 1
...
} |
Mise en place du paramètre host_name sur les 2 Arbiters
Chaque Arbiter dans la configuration doit pouvoir s'identifier. Puisqu'il ne peut y avoir qu'un seul Arbiter par machine, on choisit d'identifier chaque Arbiter par le hostname machine sur laquelle il est installé.
Pour cela, on spécifié le nom du hostname de la machine dans le paramètre host_name de chaque Arbiter.
Par exemple, sur la machine de l'Arbiter spare, on cherche le hostname de la machine:
$ hostname hostname_machine_spare |
Sur la machine hébergeant l'Arbiter master, et donc la machine centrale sur laquelle s'effectue la configuration des démons, on spécifie pour chaque Arbiter le paramètre host_name (à effectuer pour les 2 Arbiters).
define arbiter {
...
host_name hostname_machine_spare
...
} |
Activation du paramètre spare sur la machine hébergeant l'Arbiter spare
En règle générale, la configuration de tous les démons se fait sur la machine centrale de l'installation Shinken (celle qui héberge l'Arbiter maître).
Le cas de l'Arbiter spare est un cas particulier. Puisqu'il a un rôle central, lorsqu'il démarre, il agit automatiquement comme arbitre avec les autres démons. Dans le cas d'un spare, on veut par contre qu'il reste inactif et n'essaye pas d'envoyer de configuration aux autres démons.
Pour cela, il faut, sur la machine du spare, spécifier que le démon est en spare.
define arbiter {
arbiter_name arbiter-master
...
spare 1
...
} |
Le fait qu'un démon soit en spare est une information importante lorsqu'on veut déterminer le fonctionnement d'une configuration Shinken Entreprise. La propriété spare d'un démon peut être vue à 2 endroits:
Dans le Shinken-healthcheck, les démons spare sont accompagnés d'une annotation "SPARE", qui permet de déterminer facilement si un démon est un démon maître un ou démon spare.
|
Les checks du pack Shinken permettent de superviser les démons Shinken. Ces checks affichent une pastille spare lorsque le démon supervisé est un démon Spare.
|