NOTE 2021: grand merci à la voiture de ma femme qui a eu besoin d'aller se faire réparer à l'époque, le temps d'attente
           pour la réparation a été utile, avec un petit café et un cachier, j'ai mis sur papier ce que vous voyez ci-dessous
           et qui restera LE gros ajout de Shinken jusqu'à encore aujourd'hui, les royaumes (appelé Pool au début)

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 :)

Jean Gabès