Shinken : le dispatching des configurations et les spares

Posted in Nagios by Nap on October 23, 2009 4 Comments

Rappel sur les daemons et les configurations

J’ai déjà évoqué le fait que Shinken utilise plusieurs daemons qui ont chacun leur rôle. Le maître de tous est l’Arbiter qui lit la conf, la découpe et l’envoie vers ses petits camarades. Bien sûr, les satellites comme les pollers ont besoin de connaître l’adresse des ordonnanceurs. Ces derniers ont la responsabilité de l’ordonnancement de la supervision. La perte d’un d’entre eux peu être embêtante : une partie des hôtes ne seront plus surveillés!

C’est pourquoi Shinken utilise un système de spare : des daemons seront lancés mais non actifs. Ils ne se verront affecter une configuration et donc une responsabilité que si un daemon maître meurt. Typiquement un placement de ces spares sur la machine de l’Arbiter peut être utile, il y a peu de chance qu’elle perde le lien avec elle même.

Regardons un peu le dispatching des configurations vers les ordonnanceurs et ce qui se passe lorsqu’un ordonnanceur n’est plus disponible

Dispatch des configurations

L’arbiter lit la configuration globale de l’administrateur, il la coupe en morceaux (autant que l’ordonnanceurs NON spare). Le dispatcheur (une Classe dans l’Arbiter), l’envoi vers les ordonnanceurs. Puis il créé une configuration particulière avec juste les adressess des ordonnanceurs à destinations des satellites comme les pollers ou le broker. Et hop, tout le monde est content.

Ca se résume en un diagramme:

shinken-conf-dispatching

Lorsqu’un ordonnanceur tombe

Personne n’est parfait, les OS non plus. Une machine ca peut tomber, un réseau aussi. Bref, les daemons ne seront pas toujours joignables. C’est pour cela qu’on peut définir des spare qui vont reprendre le flambeau des vérifications. Pour l’instant, seul les ordonnanceurs peuvent avoir un spare, mais ca ne devrait pas tarder pour les satellites car ce n’est pas bien différent.

L’Arbiter vérifie régulièrement que tout le monde est vivant. Si un ordonnanceur est déclaré mort alors qu’il avait la responsabilité d’une configuration, il envoie la configuration vers un spare disponible.Il met à jour les informations des satellites pour qu’ils prennent en compte cette nouvelle disposition.

Un cas intéressant arrive lorsque l’ordonnanceur n’était pas disponible à cause d’une perte réseau (vous savez, cette grande variable aléatoire :mrgreen: ). Il était encore vivant mais on ne le voyait plus c’est tout. Si la conf a été envoyé à un spare, on a un problème : deux ordonnanceurs avec la même conf. Pour l’instant il est demandé à l’ordonnanceur maître de gentiment arrêter son ordonnancement et d’attendre une nouvelle conf. Dans l’avenir, une solution plus élégante sera de demander plutôt au spare de lâcher la main, car il y a de fortes chances que ce dernier aient moins d’informations que le premier.

Ca se résume en un diagramme :

shinken-scheduler-lostEn bref

Imaginez un même système en C (juste le dispatching et la gestion des spares). … Ca y est vous le voyez? Compter le nombre de lignes que ca demande. … Combien alors? Tout ça? Maintenant regardons combien ce prends dans Shinken : dispatcher 200 lignes, satellitelink 100 lignes (et ca va fortement diminuer), satellite pour la gestion de la conf : 50 lignes. Ah oui,  le tout avec 30% de commentaires :-)

Le Python c’est bon.

Related Posts:

Comments
  • Sylvain:

    Quel est l’intérêt de tout refaire en C ?

    Certes les performances du C sont meilleures mais d’après tes billets, les performances de shinken en python déchirent celles de nagios en C. Le langage compte mais l’architecture aussi. Penses-tu que la même implémentation en C serait vraiment plus performante et justifierait une complexité de code bien plus importante.

    Je suis assez bluffé par le nombre de lignes de code que tu annonces ! En lisant tes billets, je me dis que nagios vieillit. shinken, le fork icinga montrent bien que nagios a besoin d’évoluer et la partie graphique n’est pas le plus important. Si on pouvait avoir une architecture distribuée qui peut monter en puissance, assurer les cas de secours tout en centralisant la configuration et les résultats des checks, on aurait un outil réellement performant et le tout en libre.

    J’attends tes prochains billets avec impatience.

    • Nap:

      Tout d’abord merci de l’intérêt que tu portes à mon projet :)

      Le problème c’est que Nagios a est connu, a une implémentation certes perfectible mais qui a l’intérêt d’avoir été testée depuis 10ans.

      Concernant les perfs, il est possible d’être plus rapide que Shinken en reprenant les idées et en les intégrant à Nagios mais en effet ça demande un effort énorme, sûrement autant que pour tout le dev de Shinken. On peut espérer gagner encore 50% par rapport à Shinken à vue de nez en C. Reste à voir si ça vaut le coup. Je ne parle même pas de l’effort pour

      Concernant Icinga, je ne sais pas trop ce qu’ils apportent pour l’instant. Il me semble qu’ils se sont concentrés principalement sur un remplaçant de ndo2db, ce qui n’est pas une mauvaise chose, mais ne révolutionne pas le mode de fonctionnement de Nagios (oups pardon, Icinga).

      Pour l’instant Shinken est un proof of concept illustrant mes idées pour Nagios. J’ai commencé à les proposer à l’équipe de dev. J’ai commencé SOFT avec juste le pool de process et le repear de fichiers plats changé en retour direct au processus maître. Et bien c’est pas gagné.

      Faire un “fork” couperait la communauté, ce qui est moyen car la concurrence elle avance, et vite. Il ne me semble pas que les grands concurrents comme Zabbix ont des architectures distribuées évoluées, mais je me trompe peut être.

      Mon but est de faire avancer la supervision libre et j’utilise toutes les armes à ma disposition pour cela. Je n’ai pas pour habitude de prendre des gants. Il ne faut pas brusquer la communauté, mais il n’est pas de même avec les dev (moi y compris). Et après tout, c’est bien ça aussi le libre.

      Ça devrait se décanter rapidement de toute manière.

      • Sylvain:

        Si ce n’est pas indiscret, pourquoi les dev de nagios sont-ils frileux au pool de process à l’abandon du reaper des fichiers plats ? Ils ont de meilleures idées en tête ;-)

        inciga a déjà brusqué un peu Ethan mais je ne pense pas que ce projet bouleverse la supervision libre. Par contre, les idées que tu mets en œuvre dans shinken sont intéressantes et ta méthode pour prouver que ça peut marcher aussi.

        • Nap:

          La (seule) réponse que j’ai eu pour l’instant c’est : “cela change beaucoup de choses”. Et là j’avoue que je suis resté perplexe sur cette réponse.

          C’est un changement purement technique. Je ne propose pas une nouvelle théorie sur l’utilité des hôtes et services, mais de garder un pool de process qui vont faire les actions que font déjà des process qui sont lancés à chaque demande.
          Le reaper n’est pas d’une quelconque utilité pour l’utilisateur, lui il veut que les résultats des checks soit retourné à Nagios, il lui importe peux que ce soit par fichier plat ou par socket.

          Bien sûr on a une solution “qui marche” (encore heureux hein? :) ). Mais le libre c’est aussi se remettre en cause. On a beaucoup moins de contraite pour le dev. Je ne demande pas qu’on inclu un patch dès que je vais en proposer un, faut bien le tester avant c’est bien normal. Ce que je veux c’est un accord de principe que si je fais cela, il ne se verra pas refusé sans (bonne) raison.

          Incinga a fait un joli coup de bluff, mais ça n’a pas suivi derrière : quelqu’un peut-il me dire que qu’Incigna apporte par rapport à Nagios? Leur crédo a été : “ca n’avance pas assez, on veut le faire nous”. Très bien, c’est un fork, c’est dans l’esprit, faut du courage. Mais vu que leur orientation est plutôt porté sur les interfaces, ce n’est pas Nagios qu’il auraient dû forker.

          Bref, je vais continuer le forcing de mes idées, à moins qu’on me pruve qu’elles sont débiles et n’apporte rien à la supervision open-source. En ce qui concerne les perf, je crois que ca va être dur de me le prouver ;)