Bonnes Pratiques : attachement d’un service à un groupe d’hôtes… Pourquoi c’est une fausse bonne idée!

This post is also available in: Anglais

Hôte, Service, Groupe d’hôtes, services attachés à un Groupe d’hôtes… Les utilisateurs de Nagios © et de Centreon connaissent ces termes par coeur. Beaucoup d’utilisateurs de Centreon sont des habitués de Nagios et souhaitent disposer de toutes les fonctionnalités prévues dans Nagios… même celles qui, de notre point de vue, ne devraient pas l’être ! L’une de ses fonctionnalités est l’attachement d’un service à un groupe d’hôtes. Cet article basé sur notre expertise et notre expérience, a pour but d’expliquer pourquoi vous ne devriez jamais attacher un service à un groupe d’hôtes…

Définitions

Avant attaquer le cœur du sujet, quelques petits rappels ne font jamais de mal :

  • hôte: équipement supervisé (par exemple un serveur Windows/Linux/AIX/HP-UX/Solaris/AS400… ou un switch/routeur/firewall/passerelle SSL/compresseur IP/onduleur/…)
  • service;: point de supervision sur un hôte (par exemple cpu/mémoire/partitions/processus/interface réseau/bande passante/température/connexion/…)
  • groupe d’hôtes : regroupement logique d’hôtes. Le regroupement est « logique » pour un être humain sensé : regroupement par Système d’exploitation (« tous les serveurs Windows », « tous les serveurs Linux », …), par site géographique (continent/pays/région/ville/bâtiment/salle), par type (« base de données », « serveur d’application », …), par application (« ERP ») ou par… ce que vous voulez
  • groupe de services : regroupement logique de services. Le principe est le même que pour les hôtes mais les groupes de service sont généralement dédiés aux applications dans le sens large (« ERP »)

 

Association d’un service à un groupe d’hôtes

Pour créer un service et l’attacher à un groupe d’hôtes, c’est très simple : l’opération est la même que la création d’un service attaché à un hôte à la différence que l’attachement se fait… sur un groupe d’hôtes. Tout d’abord, je crée un service, je lui donne un nom et j’associe un modèle de service :

01_creation_service_ecran_01

Ensuite, on se rend dans l’onglet « Relation », on ne choisit aucun hôte et on sélectionne le groupe d’hôtes souhaité :

02_creation_service_ecran_02

Dans la capture d’écran ci‑dessus, j’ai choisi le groupe d’hôte « Linux-servers ». Je valide…. pourtant mon service créé n’apparaît pas…

03_service_invisible

Il faut se rendre dans la vue des services par groupe d’hôtes pour le voir !

04_service_par_hostgroup_visible

En effet, le service est un service par groupe d’hôtes et non un simple service : l’interface le dissocie pour éviter toute confusion.

Impact (NEGATIF !) de la création d’un service attaché à un groupe d’hôtes

Lorsqu’un service est attaché à un groupe d’hôtes, le service est identique pour tous les hôtes de ce groupe d’hôtes. C’est à dire que s’il y a 200 hôtes dans ce groupe d’hôtes, le service est exactement le même pour ces 200 hôtes. Ce qui signifie :

  • même nom
  • même configuration
  • mêmes valeurs seuils

L’avantage de ce type d’association est la rapidité de configuration : je configure une fois mon service et il est identique partout. Je peux le modifier une fois et tous les services seront modifiés en même temps. Voilà ce que nous avons l’habitude d’entendre chez nos clients et utilisateurs … et pourtant, cette facilité annoncée est en réalité un vrai piège !

Si nous créons un service identique, chaque modification est répercutée sur tous les membres du groupe. Or, un groupe est composé d’éléments uniques : chaque serveur est unique ! En effet, deux serveurs font tourner des applications différentes, avec des charges différentes, des pics de charges à des périodes différentes, etc… On pourrait imaginer un environnement extrêmement standardisé : même constructeur, même modèle de serveur, même CPU, même mémoire vive, même disques physiques, mêmes cartes réseaux, même version de système d’exploitation, même partitionnement, même configuration système, etc… Mais… en plus d’avoir un environnement standard, il faudrait que toutes ces machines aient la même fonction ! Les serveurs ne font toujours pas tourner les mêmes applications et n’ont pas le même rôle. Le taux d’occupation du CPU pour une base de données sera probablement un peu plus élevé que le serveur DHCP. Pourquoi devrait-on avoir la même configuration !?!

Dans ce cas, lorsque je veux adapter ma politique de supervision … , la solution est donc :

1. je ne le fais pas : si je le fais, tous mes services seront impactés, or je ne veux changer qu’un seul seuil par exemple
2. je le fais en configurant la valeur seuil la plus haute possible : de cette façon, je suis sûr de ne pas avoir de faux positif. Problème : je ne vois pas les vrais positifs qui m’indiquent que le taux d’occupation du CPU d’un serveur qui est sensé ne faire presque rien est anormalement élevé… C’est étonnant… il ne devrait (presque) rien faire mais il est chargé… il doit se passer quelque chose… mais je ne le verrai pas car la valeur seuil est trop haute, je ne serai pas averti
3. je le fais en « sortant » l’hôte du groupe d’hôtes puis en créant mon service spécifique sur cet hôte… Alors que j’avais initialement crée un Groupe « serveurs Linux » je vais désormais avoir une machine Linux toute seule ?
4. je crée plusieurs groupes d’hôtes, un pour les CPU très chargés, un autre pour les CPU chargés et un dernier pour les CPU peu chargés. Bien sûr : et je découpe en trois aussi pour la mémoire, puis en trois pour le swap puis encore en trois pour la partition / et encore en trois pour la partition /var et encore…. Quelle complexité ! J’étais parti pour me simplifier la vie et je ne comprends plus rien à ma configuration.

Conclusion : on n’associe pas un service à un groupe d’hôtes ! C’est certes très pratique pour la première configuration mais un système d’information vit : de nouveaux serveurs arrivent, d’autres partent, des applications sont fortement utilisées pendant une période puis après beaucoup moins, des serveurs sont consolidés puis séparés pour une meilleure sécurité puis reconsolider pour la virtualisation puis re-séparés … Les valeurs seuils doivent suivre. Sinon, la supervision est inutile car elle ne permet pas de refléter la réalité.

Le seul cas conseillé d’association d’un service à un groupe d’hôtes est lorsque l’on est sûr et certain que ce service sera toujours, dans les trois prochaines années au moins, exactement identique, tant dans sa configuration que dans ses valeurs seuils. Je n’en vois qu’un : le ping… et encore, on distingue le ping sur un LAN du ping sur un WAN…

Comment obtenir le même résultat ?

Rassurez vous, il est possible d’obtenir le même résultat (ou à peu près) avec Centreon, en utilisant les modèles de service ! Les modèles de service vous seront présentés dans les prochains articles. Leur configuration est un peu difficile à appréhender au départ, mais une fois maîtrisés, ils sont extrêmement efficaces.
Cependant, nous allons quand même vous donner une piste pour commencer à les utiliser:  1
. créer un modèle d’hôte Linux
2. créer un modèle de service CPU (spécifique Linux), définir des macros pour ce service et associer ce modèle de service au modèle d’hôte créé précédemment
3. lorsque vous créez un nouvel hôte Linux, utiliser ce modèle d’hôte Dès lors, tout nouvel hôte basé sur ce modèle d’hôte sera parfaitement identique ==> industrialisation de la configuration.

Vous souhaitez modifier une valeur seuil du service CPU sur un hôte bien particulier : vous pouvez toujours le faire en modifiant la macro correspondante : on conserve la flexibilité de la configuration ! Magique… à voir dans les prochains articles !

2 réflexions au sujet de « Bonnes Pratiques : attachement d’un service à un groupe d’hôtes… Pourquoi c’est une fausse bonne idée! »

  1. Un cas d’usage très pratique et tout à fait cohérent: les clusters applicatifs, je tiens à ce que mon service soit identique sur l’ensemble du cluster (nombre de requète en cours sur un cluster mysql par exemple, si un des deux passe le seuil, il me faut vérifier le load balancing, pas changer le seuil du noeud en alerte…)

    Au passage lorsque j’ajoute un hôte à ce cluster je tiens à ce qu’il utilise les même valeurs que les autres, en cas d’alerte c’est bien lui qui a un problème, pas le seuil qui est faux.

    Lorsque l’on a une architecture de 60 serveurs pour 20 clusters avec des hôtes changeant de cluster en fonction des besoins, les changer de groupe d’hôte plutôt que les supprimer/recréer avec le bon modèle est tout de même bien + rapide et exploitable lorsque l’on parle d’un total de 80 test par hôte.

    Les raisons avancée dans cet article sont défendables pour des groupes d’hôtes génériques (OS, Région) mais pas pour des groupes spécifiques.

    Il serait temps de prendre en compte cet intérêt des groupe d’hôte même si il complique sérieusement la gestion de l’interface.

    • Merci de ton commentaire,

      Selon les retours de nos experts, c’est l’exception qui confirme la règle :D.
      Nous sommes dans un cas particulier qui, pour des besoins spécifiques, préfèrera l’utilisation des groupes d’hôtes plutôt que le mécanisme des modèles d’hôtes et de services.

      Ton point de vue reste tout-à-fait défendable mais pas forcément générique.

Leave a Reply