Plusieurs personnes m'ont demandé comment superviser les grappes d'hôtes ou de services, c'est pourquoi j'ai décidé d'écrire une petite documentation à ce propos. C'est plutôt simple, donc vous devriez trouver ceci facile à comprendre.
Tout d'abord, nous devons définir ce que nous entendons par "grappe". 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é 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 une grappe de services. Cette grappe 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 de la grappe de service DNS, plutôt 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 grappe), je les considérerai comme étant une grappe 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.
Il y a plusieurs façons de superviser des grappes de services ou d'hôtes. Je décrirai la méthode qui me semble être la plus simple. Superviser des grappes de services ou d'hôtes implique deux choses :
Superviser individuellement des éléments d'une grappe 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 grappes de services,
assurez-vous de superviser chacun de ses éléments. Si vous avez
une grappe de cinq serveurs DNS, vérifiez que vous avez bien cinq
définitions de service (probablement en utilisant le plugin
check_dns). Pour les grappes d'hôtes, assurez-vous d'avoir
configuré les définitions d'hôtes pour chaque membre de la grappe
(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 de la grappe
(définitions d'hôtes ou de services). Bien qu'aucune notification
ne soit 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'intérieur de la grappe.
Superviser la grappe dans son ensemble peut être effectué en
utilisant les résultats de la grappe d'éléments précédemment mis
en cache. Bien que vous ayez la possibilité de revérifier tous
les éléments de la grappe pour déterminer son état, pourquoi
gaspiller de la bande passante et des ressources, alors que vous
avez déjà le résultat dans le cache ? Les résultats des éléments
de la grappe mis en cache peuvent être trouvés dans le journal des états (en supposant
que vous supervisiez chaque élément). Le plugin
check_cluster2 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 de la grappe, vous
voudrez les activer pour son contrôle d'ensemble.
Le plugin check_cluster2 est étudié pour vérifier l'état général d'une grappe d'hôtes ou de services. Il fonctionne en vérifiant, pour chaque élément de la grappe d'hôtes ou de services, l'information relative à chaque état et mise en cache dans le fichier journal des états.
Le plugin check_cluster2 peut être trouvé dans le répertoire "contrib" des plugins Nagios® officiels : http://sourceforge.net/projects/nagiosplug/ [Anglais].
Mettons que vous ayez trois serveurs DNS en redondance sur
votre réseau. Vous aurez tout d'abord besoin de superviser chaque
serveur DNS individuellement avant de vérifier la grappe.
Je présume que vous avez donc déjà 3 services séparés (tous
nommés "Service DNS") associés à vos hôtes (nommés "host1",
"host2", "host3").
Afin de superviser ces services comme une grappe, vous avez besoin de créer un nouveau service pour la grappe.
Avant cela, vous devrez avoir défini la commande liée à la surveillance de la grappe. Vous avez donc défini la commande check_service_cluster [NdT : cluster = grappe] de la manière suivante :
define command{
command_name check_service_cluster
command_line /usr/local/nagios/libexec/check_cluster2 --service -l $ARG1$ -w $ARG2$ -c $ARG3$ -d $ARG4$
}
Vous avez maintenant besoin de créer le service "grappe" et utiliser la commande check_service_cluster que vous venez de créer comme commande de vérification. L'exemple ci-dessous détaille comment le faire. Il va générer un état CRITICAL si 2 services ou plus de la grappe ne sont pas en état OK, et un état WARNING, si seulement 1 service n'est pas en état OK. Si tous les services sont en état OK, le service retournera également OK.
define service{
…
check_command check_service_cluster!"DNS Cluster"!1!2!$SERVICESTATEID:host1:DNS Service$,$SERVICESTATEID:host2:DNS Service$,$SERVICESTATEID:host3:DNS Service$
…
}
Il est important de noter que nous passons à la macro $ARG4$ une liste d'éléments - séparateur virgule - de macro d'état de service à la volée. Ce point est important : Nagios® va remplir ces macros avec l'état du service (en numérique plutôt qu'en texte) des membres de la grappe.
La supervision des grappes d'hôtes ressemble beaucoup à celle des grappes de services. Evidemment, la plus grande différence est que les membres de la grappe sont des hôtes et non des services. Afin de superviser l'état d'une grappe d'hôtes, vous devez définir un service qui utilise le plugin check_cluster2. Le service ne doit pas être associé à l'un des hôtes de la grappe, car cela causerait des problèmes relatifs aux notifications de la grappe 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)…
Supposons que vous avez défini la commande check_host_cluster de la manière suivante :
define command{
command_name check_host_cluster
command_line /usr/local/nagios/libexec/check_cluster2 --service -l $ARG1$ -w $ARG2$ -c $ARG3$ -d $ARG4$
}
Supposons que vous ayez trois hôtes (nommés "host1", "host2", "host3") dans votre grappe. Si vous voulez que Nagios® vous envoie un état WARNING si au moins un hôte de la grappe est dans un état différent de OK, ou un état CRITICAL si au moins deux sont dans un état différent de OK, le service à définir pour superviser la grappe d'hôte devra ressembler à :
define service{
…
check_command check_host_cluster!"Super Host Cluster"!1!2!$HOSTSTATEID:host1$,$HOSTSTATEID:host2$,$HOSTSTATEID:host3$
…
}
Il est important de noter que nous passons à la macro $ARG4$ une liste d'éléments - séparateur virgule - de macro d'état d'hôte à la volée. Ce point est important : Nagios® va remplir ces macros avec l'état du service (en numérique plutôt qu'en texte) des membres de la grappe.
Et voilà ! Nagios® contrôlera périodiquement l'état de la grappe d'hôtes, et vous enverra des notifications, quand son état sera dégradé (en supposant que vous ayez autorisé les notifications pour le service). Notez que pour les définitions d'hôtes de chaque membre de la grappe, vous préférerez vraisemblablement ne pas avoir de notifications lorsque l'hôte sera hors service. Souvenez-vous que vous ne vous souciez pas tant de l'état de chaque hôte que de celui de la grappe. 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" dans les définitions d'hôtes.