From 4fedfed495cc2a0a6951ef68568b7fc3368ee314 Mon Sep 17 00:00:00 2001 From: Ludovic Poujol Date: Thu, 8 Jun 2017 17:33:33 +0200 Subject: [PATCH] =?UTF-8?q?Corrections=20&=20ajouts=20sur=20check=20sant?= =?UTF-8?q?=C3=A9=20du=20cluster?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- HowtoIcinga.md | 36 ++++++++++++++++++++++++++++++------ 1 file changed, 30 insertions(+), 6 deletions(-) diff --git a/HowtoIcinga.md b/HowtoIcinga.md index c144c551..622aa72f 100644 --- a/HowtoIcinga.md +++ b/HowtoIcinga.md @@ -19,7 +19,7 @@ Il existe plusieurs manières de déployer Icinga2 pour surveiller un ensemble d ![Illustration des noms des rôles dans Icinga2](howtoicinga_distributed_roles.png) -Il faut savoir que cette hiérarchie s'applique en fait à des *zones* et non directement aux noeuds. Les noeuds (ou *endpoints*) font partie d'une *zone*. Habituellement une *zone* contient un seul noeud et porte le même nom par convention. Mais pour des *zones* de type master ou satellite, on peut être amené à placer plusieurs noeuds dans cette même *zone* pour les faire travailler ensemble en mode haute disponibilité et/ou répartition de charge. +Il faut savoir que cette hiérarchie s'applique en fait à des **zones** et non directement aux noeuds. Les noeuds (ou **endpoints**) font partie d'une *zone*. Habituellement une *zone* contient un seul noeud et porte le même nom par convention. Mais pour des *zones* de type master ou satellite, on peut être amené à placer plusieurs noeuds dans cette même *zone* pour les faire travailler ensemble en mode haute disponibilité et/ou répartition de charge. C'est la notion de *zones* qui permet de décrire les portions de configuration à déployer sur les autres membres du cluster. La configuration contenue dans `/etc/icinga2/zone.d/foo` est poussé vers la zone **foo** @@ -51,10 +51,12 @@ Dans la suite, on va détailler l'installation puis la configuration de plusieur * *icinga2-master* (192.0.2.1) - Master de notre cluster. Il hébergera aussi l'interface web * *icinga2-client1* (192.0.2.10) - Client qui va recevoir la configuration du master -* *icinga2-client2* (192.0.2.20) - Client qui va être juste servir de pont d'éxécution de commandes +* *icinga2-client2* (192.0.2.20) - Client qui va servir de pont d'éxécution de commandes * *no-icinga2-host* (192.0.2.30) - Machine surveillée sans instance icinga2 locale -L'installation d'icinga2 est relativement simple. Cependant, la documentation disponible en ligne conseille d'utiliser les paquetages officiels disponible sur les dépôts proposés par les développeurs. +L'installation d'icinga2 est relativement simple. C'est le même paquetage à utiliser quelque soit la fonction de la machine dans le cluster. + +Autre détail, la documentation disponible en ligne conseille d'utiliser les paquetages officiels disponible sur les dépôts proposés par les développeurs. En effet la version présente dans les dépôts de débian est assez ancienne et ne couvre pas toutes les fonctionalité mentionées ici. (Une autre solution est d'utiliser la version présente dans les backports de jessie, mais tout les paquets relatifs à l'interface web y sont absent). ~~~ # wget -O - http://packages.icinga.com/icinga.key | apt-key add - @@ -302,7 +304,7 @@ Et voilà ! En théorie, le master et le client peuvent se parler ! Comme nous n #### Cas A - Client avec configuration centrale sur le master -Avec le type de configuration que l'on a choisi, les fichiers de configuration sont modifiés sur le master, qui les synchronise sur le(s) client(s). +Dans ce premier cas, les fichiers de configuration sont présent et modifiés sur le master, qui les synchronise sur le(s) client(s). Nous allons donc ajouter nos tests sur le master dans *zones.d*, le dossier prévu à cet effet. On commence par y créer un nouveau dossier correspondant à la zone (donc le client appartenant à celle-ci) que l'on souhaite configurer : ~~~ @@ -369,7 +371,7 @@ apply Service "ssh" { #### Cas B - Configuration en pont d'éxécution de commandes -Dans ce cas présent, toute la configuration va rester sur la machine *icinga2-master*. (et donc dans le dossier `/etc/icinga2/zone.d/icinga2-master/`). +Dans ce cas, toute la configuration va rester sur la machine *icinga2-master*. (et donc dans le dossier `/etc/icinga2/zone.d/icinga2-master/`). C'est le master qui va planifier l'exécution des checks. Ainsi, on peut définir dans un fichier `icinga2-client2.conf` @@ -508,7 +510,6 @@ object Zone "global-templates" { } ~~~ - ### Envoi de notifications Contrôler le bon fonctionnement de services, c'est bien. Alerter en cas de défaillance c'est mieux ! @@ -557,6 +558,29 @@ object TimePeriod "HO" { } ~~~ +### Contrôle de santé du cluster + +Une autre bonne pratique est de rajouter des checks pour s'assurer du bon fonctionnement de notre cluster. Il existe deux commandes utilisables qui sont complémentaires : + +* cluster : Elle s'assure que tout les *endpoints* de la zone soient actifs et que les zones directement connectés fonctionnent correctement +* cluster-zone : Elle s'assure que la zone donnée en paramètres est bien connecté au cluster + +Idéalement, il faut donc utiliser **cluster** pour des zones de plus d'une machines, et **cluster-zone** pour s'assurer que chaque zone filles fonctionnent bien. Dans notre cas on va utiliser des checks *cluster-health* depuis le master pour s'assurer que nos deux endpoints *icinga2-client1* et *icinga2-client2* soient bien connectés. + +Exemple avec *cluster-zone* : + +~~~ +# cat /etc/icinga2/zone.d/icinga2-master/cluster.conf + +apply Service "cluster-health" { + check_command = "cluster-zone" + + display_name = "cluster-health-" + host.name + vars.cluster_zone = host.name + + assign where host.vars.client_endpoint +} +~~~ ### Haute disponibilité