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:

Lorsqu'un ordonnanceur tombe

Personne n'est parfait, les OS non plus. Une machine ça 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 :

En 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.

NOTE 2021: bon on doit être à 10x plus dans le code actuel, facilement. Mais d'expérience c'est classqiue: 10% du temps pour coder un truc, 90% restant pour le stabiliser et
           gérer TOUS les cas à la con et faire que les utilisateurs ne soient pas perdu

NOTE 2021: 30% de commentaires, j'en suis encore à ce ratio après 20ans de code, juste que mes commentaires sont différents, mais j'en ferai un article
           (qui énervera Ben, coucou ben ^^ )

Jean Gabès