mod_gearman : Nagios distribué 2.0

Posted by Olivier Jan on 5 Oct 2011 in Astuces, Planet | 1 comment

Jusqu’à présent, pour gérer Nagios en mode distribué, c’est à dire avec un serveur central et plusieurs pollers (satellites) qui sont chargés de l’exécution des contrôles, vous aviez le choix entre le setup « officiel » de la documentation, vieux et au nombreux goulets d’étranglements ou Centreon et sa capacité à marquer certains hôtes, services comme devant être vérifié par tel ou tel poller. La solution avec Centreon étant quand même beaucoup plus conviviale. Citons encore Merlin de chez OP5 mais le projet ne semble pas très utilisé dans le monde francophone et ne présente pas de réelles nouveautés par rapport à un setup distribué Centreon.

Même si ces deux méthodes ont fait leur preuve, elles présentent les inconvénients suivants :

• Installer autant d’instances de Nagios qu’il y a de pollers, satellites.
• Envoyer sur chaque poller les fichiers de configuration pour le périmètre que chacun se doit de contrôler.

Il y a bien eu il y quelques temps un premier projet nommé DNX (Distributed Nagios eXecutor) pour palier ces inconvénients mais le projet ne semble pas très actif (dernière version 0.20 de avril 2010) et lui aussi souffre d’un inconvénient : l’incapacité à pouvoir exécuter certains contrôles d’hôtes et/ou de services sur un poller particulier. DNX se contente de répartir la charge sur différents workers DNX, ce qui est déjà pas mal. Il y a avait déjà cependant un premier pas franchi avec la capacité à ne plus avoir à installer d’instances Nagios sur chaque poller et donc à s’affranchir du découpage de la configuration pour chacun d’eux. Ne reste plus dans cette architecture qu’à distribuer, copier les plugins sur chaque worker DNX pour que ce setup fonctionne.

C’est dans ce contexte qu’il devenait donc urgent de vous présenter mod_gearman. Outre le fait que celui-ci est développé par des « pointures » de la supervision, ce projet est à la fois bien actif et s’appuie sur un logiciel tierce nommé gearman. Et il se trouve que Gearman est prévu pour une chose : distribuer de la charge.

Architecture distribué avec mod_gearman

Une architecture distribuée avec mod_gearman est composée comme suit :

• Un serveur Nagios et un seul qui ne fait plus aucun contrôles.
• Un module NEB mod_gearman chargé par le démon Nagios central.
• Un à n workers Gearman avec les plugins pour les contrôles installés sur chacun.

Avantages de mod_gearman

Il y a pas mal d’avantages à utiliser mod_gearman en setup distribué :

• Pas d’installation de Nagios à faire sur les workers, uniquement les plugins à distribuer à l’instar de Nagios DNX.
• Une configuration centrale de Nagios qui permet néanmoins comme Centreon de spécifier les contrôles à exécuter par worker en utilisant des groupes de services ou d’hôtes spécifiques.
• Vous continuez à utiliser l’interface de configuration que vous préférez (Centreon, vi, nconf…
• Pas d’eventhandlers à activer dans Nagios (chute des performances de Nagios) contrairement au setup distribué classique et pas de découpe de configuration par worker.
• Permet de gérer les contrôles de services, d’hôtes mais également les event handlers.
• Gère aussi bien la haute disponibilité que la balance de charge. Vous pouvez avoir autant de serveurs Gearman et de workers que vous le souhaitez.
• Peut remplacer NSCA pour les retours de contrôles passifs.

À partir de cette architecture, c’est tout bénéfice comme le démontre les schémas sur la page du projet. Pour faire exécuter un contrôle d’hôte ou de service particulier, il suffit de « jouer » avec les groupes d’hôtes et les groupes de services. Rien que du standard en somme.

Côté performance, c’est du tout bon. Les tests réalisés sur deux workers virtualisés ont permis de tenir la cadence de 2000 exécutions de contrôles toutes les minutes. De quoi voir venir.

Vous n’aurez aucune excuse à ne pas tester ce module quand vous saurez que nous vous avons concocté le tutoriel d’installation de l’ensemble dans le wiki.