Introduction
Plusieurs personnes m'ont demandé comment superviser les clusters d'hôtes ou de services, c'est pourquoi j'ai décidé d'écrire une petite documentation à ce propos. C'est plutot "carré", donc vous devriez trouver des choses faciles à comprendre...
Tout d'abord, nous devons définir ce que nous entendons par "cluster". La façon la plus simple de comprendre est de prendre un exemple. Supposons que votre société dispose de 5 hôtes qui lui offrent des services DNS redondants. Si l'un d'eux a un défaut, ce n'est pas une catastrophe majeure, car les serveurs restants continueront à fournir des services de résolution de noms. Si vous êtes concernés par la supervision de la disponibilité du service DNS de votre société, vous voudrez superviser cinq serveurs DNS. C'est ce que je considère comme un cluster de services. Ce cluster de services consiste en 5 services DNS distincts que vous supervisez. Bien que vous vouliez superviser chaque service individuellement, votre préoccupation première est l'état général du cluster de service DNS, plus que la disponibilité d'un service en particulier.
Si votre société a un groupe d'hôtes qui procure une solution à haute-disponibilité (type cluster), je les considèrerai comme étant un cluster d'hôtes. Si un hôte particulier ne répond plus, un autre prendra à son compte toutes les tâches du serveur en panne. A ce sujet, vous pouvez consulter le site High-Availability Linux Project [Anglais] pour des informations concernant la redondance d'hôtes sous Linux.
Plan d'attaque
Il y a plusieurs façons de superviser des clusters de services ou d'hôtes. Je décrirai la méthode qui me semble être la plus simple. Superviser des clusters de services ou d'hôtes implique deux choses :
Superviser individuellement des éléments d'un cluster d'hôtes ou de services
est plus simple que vous ne l'imaginez. En fait, vous le faites sans doute déjà.
Pour les clusters de services, assurez-vous de superviser chacun de ses éléments.
Si vous avez un cluster de cinq serveurs DNS, verifiez que vous avez bien cinq
définitions de service (probablement en utilisant le plugin check_dns).
Pour les clusters d'hôtes, assurez-vous d'avoir configuré les définitions
d'hôtes pour chaque membre du cluster (vous aurez aussi besoin de définir au
moins un service à superviser pour chacun des hôtes).
Important: Vous allez sans doute vouloir désactiver les notifications
pour les éléments individuels du cluster (définitions d'hôtes ou de services).
Bien qu'aucune notification ne sera envoyée à propos des éléments individuels,
vous aurez encore un affichage visuel de l'état individuel de l'hôte ou du service
dans le CGI d'état. Cela sera utile
à l'avenir pour retrouver exactement la source de problèmes à l'interieur du
cluster.
Superviser le cluster dans son ensemble peut être effectué en utilisant les
résultats du cluster d'éléments précédemment mis en cache. Bien que vous ayez
la possibilité de revérifier tous les éléments du cluster pour déterminer son
état, pourquoi gaspiller de la bande passante et des ressources alors que vous
avez déjà le resultat dans le cache ? Les résultats des éléments du cluster
mis en cache peuvent être trouvés dans le journal
des états (en supposant que vous supervisiez chaque élément). Le plugin
check_cluster a été développé spécialement pour vérifier les états des
hôtes et services mis en cache dans le journal des états.
Important : Bien que vous n'ayez pas activé les notifications pour les
éléments individuels du cluster, vous voudrez les activer pour son contrôle
d'ensemble.
Utilisation du plugin check_cluster
Le plugin check_cluster est étudié pour vérifier l'état général d'un cluster d'hôte ou de service. Il fonctionne en vérifiant, pour chaque élément du cluster d'hôtes ou de services, l'information relative à chaque état et mise en cache dans le fichier journal des états.
Bientôt dans les bacs... Le plugin check_cluster peut être temporairement obtenu depuis http://www.nagios.org/download/alpha [Anglais].
Superviser les clusters de services
Tout d'abord, vous aurez à définir un service pour superviser le cluster. Ce service exécutera la vérification complète de l'état du cluster. Vous voudrez certainement avoir les notifications activées pour ce service afin que vous puissiez savoir à quel moment arrivent les problèmes qui doivent être pris en compte. Par contre vous faites probablement moins de cas des états de chaque service composant le cluster, vous pouvez donc suspendre les notifications pour ces définitions de services.
Bien, supposons que vous ayez défini la commande check_service_cluster de la manière suivante :
command[check_service_cluster]=/usr/local/nagios/libexec/check_cluster --service /usr/local/Nagios/var/status.log $ARG1$ $ARG2$ < $ARG3$
Supposons que vous ayez cinq services dans le cluster. Si vous voulez que Nagios vous envoie une alerte de type 'warning' si au moins deux services du cluster sont dans un état différent de 'OK', ou une alerte 'critical' si au moins trois sont dans un état différent de 'OK', l'argument <check_command> du service que vous définissez pour superviser le cluster devra ressembler à :
check_service_cluster!2!3!/usr/local/nagios/etc/servicecluster.cfg
La macro $ARG3$ sera remplacée par /usr/local/nagios/etc/servicecluster.cfg quand le contrôle sera effectué. Comme c'est le fichier à partir duquel le plugin check_cluster lira les noms des membres du cluster, vous devrez créer ce fichier et ajouter les services qui en font partie (un par ligne). Le format d'un service est le nom court (short name) de l'hôte auquel le service est associé, suivi d'un point-virgule, puis la description du service. Voici un exemple du contenu de ce fichier :
host1;DNS Service
host2;DNS Service
host3;DNS Service
host4;DNS Service
host5;DNS Service
host6;DNS Service
Supervision des clusters d'hôtes
La supervision des clusters d'hôtes ressemble beaucoup à celle des clusters de service. Evidemment, la plus grande différence est que les membres du cluster sont des hôtes et non des services. Afin de superviser l'état d'un cluster d'hôtes, vous devez définir un service qui utilise le plugin check_cluster. Le service ne doit pas être associé à l'un des hôtes du cluster, car cela causerait des problèmes relatifs aux notifications du cluster si cet hôte était hors service. Une bonne idée serait d'associer le service à l'hôte sur lequel Nagios tourne. Car, si l'hôte sur lequel tourne Nagios tombe, alors Nagios ne fonctionne plus et vous ne pouvez plus rien superviser (sauf si vous avez prévu une supervision redondante d'hôtes)...
Bien, supposons que vous avez défini la commande check_host_cluster de la manière suivante :
command[check_host_cluster]=/usr/local/nagios/libexec/check_cluster --host /usr/local/Nagios/var/status.log $ARG1$ $ARG2$ < $ARG3$
Supposons que vous ayez six hôtes dans votre cluster. Si vous voulez que Nagios vous envoie une alerte 'warning' si au moins deux hôtes du cluster sont dans un état différent de 'OK', ou une alerte 'critical' si au moins quatre sont dans un état différent de 'OK', l'argument <check_command> du service que vous définissez pour superviser le cluster devra ressembler à :
check_host_cluster!2!4!/usr/local/nagios/etc/hostcluster.cfg
La macro $ARG3$ sera remplacée par /usr/local/nagios/etc/hostcluster.cfg quand le contrôle sera effectué. Comme c'est le fichier à partir duquel le plugin check_cluster lira les noms des membres du cluster, vous devrez créer ce fichier et ajouter le nom court des hôtes que vous avez défini dans vos définitions d'hôtes (un par ligne). Voici un exemple du contenu de ce fichier :
host1
host2
host3
host4
host5
host6
Et voilà ! Nagios contrôlera périodiquement l'état du cluster d'hôtes et vous enverra des notifications quand son état sera dégradé (en supposant que vous avez autorisé les notifications pour le service). Notez que pour les définitions d'hôtes de chaque membre du cluster, vous préfèrerez vraisemblablement ne pas avoir de notifications lorsque l'hôte sera hors service (en utilisant l'option <notify_down>). Souvenez-vous que vous ne vous souciez pas tant de l'état de chaque hôte que de celui du cluster. Suivant la configuration de votre réseau et ce que vous souhaitez accomplir, vous voudrez peut-être laisser les notifications s'effectuer pour les états 'inaccessible' (à l'aide de l'option <notify_unreachable>) dans les définitions d'hôtes.