L’illumination du jour
Bonjour,
Hier j’ai eu tout le temps de pousser l’architecture de Shinken plus loin que je ne l’avais fait jusqu’alors. En effet, elle permet dans sa forme actuelle d’avoir un point unique d’administration de plusieurs ordonnanceurs, pollers, reactionners et brokers. Les hôtes sont dispatchés sur les ordonnanceurs, les services suivent, les satellites (poller/reactionner/broker) tapent sur tous les ordonnanceurs. C’est implémenté, et le pire, c’est que ça fonctionne. Tout le monde est content.
Tout le monde? Non. Un petit village d’irréductibles gaul… oups, je m’égare…
Tout le monde? Non. Imaginons un peu qu’un administrateur ait une infrastructure distribuée sur plusieurs continents (un quelconque rapport avec l’infra de l’auteur est fort plausible…). Avec l’archi de Shinken actuellement, si l’administrateur a mis deux ordonnanceur : un a Bordeaux et un à Shangaï (toujours par le plus grand des hasard hein…) et de même un poller sur Bordeaux, et un sur Shangaï, les pollers tapent sur les deux ordonnanceurs, et pour ceux qui n’ont pas le grand bonheur d’avoir un site à shangaï, autant vous dire que les lignes internet sont plutôt… bon disons que c’est aléatoire pour rester poli. De plus, un hôte va se voir affecté sur un ordonnanceur ou un autre sans pouvoir influer dessus.
Bref, Shinken, dans son état actuel, est pratique pour avoir de la haute dispo, répartition de charge et performance mais pour un site unique. Et là vous me voyez venir à des kilomètres : la gestion des sites.
Un pool, des pools
Alors on va utiliser un nom plus général qu’un site (après tout ça peut être une séparation plus organisationnelle que géographique) : un pool. (A ne pas confondre avec les pollers donc).
Un pool est un groupe de ressources indissociables auquel vont pouvoir être rattachés des hôtes ou des groupes d’hôtes. Une telle association sera unique, un hôte ne pourra se trouver que dans un pool donné et il faudra que ses parents soient dans le même pool (sinon le découpage de conf et le dispatchign ne sera pas content). Si ces derniers n’ont pas de pool désignés, il hériterons de celui-là.
Un pool est donc un groupe de schedulers, pollers, [reactionners], [brokers] (les deux derniers sont optionnels). Dans un pool, les pool vont se connecter à tous les schedulers du pool.
Un pool peut contenir un autre pool. Ceci ne change rien pour les ordonnanceurs/pollers, ceux-ci ne s’adressant qu’aux ordonnanceurs du même pool. Les hôte d’un pool ne seront dispatchés que sur les schedulers du pool, pas de ses fils. Là où une hiérarchie de pool devient utile concerne les reactionners/brokers : ils sont associés à un pool, mais si ce dernier contient d’autres pools (qui eux même en contiennent d’autres etc etc) et bien les reactionners/broker vont chercher les infos sur tous les ordonnanceurs de la hiérarchie de pool.
En fait, cette notion de satallites qui peuvent atteindre les sous-pools devrait être paramétrable, genre une option acces_inner_pool avec comme valeur par défaut les pollers a 0, et les reactioners/broker 1. Si après l’administrateur veux le changer pour décloisonner/cloisonner, libre à lui.
Il faut bien retenir une chose : un seul Arbiter (et son spare) et une seule conf, quelque soit le nombre de pools que vous avez. Ah une autre chose : pour l’instant rien n’est implémenté! Mais bon ça ne devrait pas être trop méchant je pense.
Au secours, je comprends rien!
Pas clair? Oui je m’en doute un peu, avec mes pools, sous-pool, pollers et schedulers.
En résumé, vous mettez un hôte ou un groupe d’hôte dans un pool. Celui-ci est un ensemble de ressources pour superviser vos hôtes et les services qui y sont raccrochés. Vous pouvez enlever ou rajouter des ressources au pool sans avoir à changer la conf des 30K hôtes que vous avez patiemment configuré car vous avec rajouté un ordonnanceur ou un poller de plus dans le lot.
Bref, le pool est une facilité pour gérer ses ressources. Si vous n’avez qu’un petit site gérable par un ordonnanceur/poller/reactionner/broker, pas la peine de vous embêter avec un pool, par défaut shinken en créera un pour vous à la volée et vous n’en entendrez même pas parler 
Dessine moi un diagramme
Des diagrammes, c’est encore mieux que toutes ces explications
Imaginons que l’on a deux environnements distribués un peu partout dans le monde. Dans un cas, on souhaite un cloisonnement total des continents. Dans un autre, on accepte que les réactionners et brokers soient communs à tous les ordonnanceurs du monde (oui, rien que ça ).
Les diagrammes
Voici le cas isolé :
Et le cas plus communs avec les réactionner/broker de communs :
Comme vous pouvez le voir, les éléments sont raccrochés à un seul pool. suivant l’héritage qu’on leur a donné, ils utilisent les ordonnanceurs des sous-pool ou non.
Et dans la conf, ça donne quoi?
Voici ce que ça devrait donner pour le second cas :
define pool {
pool_name All
pools Europe, US, Asia
}
define pool{
pool_name Europe
pools Paris
}
(je ne sais pas encore si c’est bien utile de forcer la définition des autres pools même s’ils n’ont qu’un nom…).
define scheduler{
scheduler_name sched Paris
pool Paris
}
define reactionner{
reactionner_name reactionner-maitre
pool All
}
Et dans les hôtes :
define host{
host_name serveur-paris
pool Paris
[...]
}
Pour ces derniers ce paramètre sera géré par l’héritage comme toutes les propriétés des hôtes.
Ce qui est susceptible de changer
Il me reste quelques petits points à voir : doit-on faire le lien entre les schedulers/pollers/reactionners/broker et les pools au niveaux du define des pools, ou bien comme ci-dessus au niveau des éléments? Les deux? Mais quoi faire en cas d’incompatibilité des deux types de configuration? Je prends tout commentaires
). 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.
