...
Quand toutes les partitions sont créées, l'Arbiter les agrègent agrège dans N configurations si l'administrateur a défini N Schedulers actifs (sans spare).
...
Un Scheduler peut commencer à lancer des checks une fois qu'il a reçu et chargé sa configuration sans avoir à attendre que TOUS les Schedulers soient prêts.
...
L'architecture de Shinken Enterprise est très pratique quand on utilise le même type de Poller pour tous les checks. Mais il peut également être nécessaire d'avoir plusieurs types de PollerPollers, comme par exemple un GNU/Linux et un Windows.Nous avons déjà vu que tous les Pollers communiquent avec tous les Schedulers. En fait, les Pollers peuvent être caractérisés ("tag") afin qu'ils n'exécutent que certains checks définis.
...
Le paramètre pour qualifier une commande, un hôte ou un check est le "poller_tag".
L'existance L’existence du paramètre est détermité déterminé dans l'ordre de cascade suivant:
- On regarde d'abord sur la commande
- puis Puis le check
- puis Puis sur l'hote.
Les pollers peuvent être identifié identifiés par plusieurs poller_tags. Si ils ont des tags, ils ne prendront que les checks qui correspondent à ce tag.
Pour avoir les checks caractérisé caractérisés spécifiquement par une liste depollerde poller_tag et ceux non défini, il faut juste rajouter explicitement le tag "None". Ceci permet d'exclure certains tags sans avoir à définir une liste exaustiveexhaustive.
Cas d'usage
Cette fonctionnalité est très utile pour une DMZ.
Dans un 1er cas, il peut être utile d'avoir une boîte windows Windows dans un domaine avec un Poller tournant dans un compte domaine. Si ce Poller lance les requêtes WMI, il est ainsi aisé de mettre en place une supervision windows. .
Le 2ème cas de figure est assez classique : quand vous avez une DMZ, vous devez avoir un Poller dédié qui est DANS la DMZ et qui renvoie les résultats des checks à un Scheduler via le LAN. Ainsi, vous pouvez avoir des dépendances entre des hôtes en DMZ te et des hôtes en LAN, et être certains que les checks seront réalisés à l'intérieur de l'espace sécurisé grâce au Poller dédié..
...
Différents types de Reactionners: reactionner_tag
Comme pour les PollersD'une manière totalement symétrique aux pollers, les Reactionners peuvent eux aussi avoir des caractéristiques . Vous pouvez donc caractériser vos hôtes/checks et commandes par le être caractérisés avec un ou plusieurs "reactionner_tag". Si une notification ou un gestionnaire d’événements utilise une commande "tagged" ou "untagged" sur un hôte/check non caractérisé, il prendra automatiquement la caractéristique du Reactionner. In a "untaged" host/check, it's the command tag that is taken into account.
Le Reactionner peut être caractérisé avec plusieurs "reactionner_tags".
Comme pour les Poller, il existe plusieurs cas d'usage, le principal étant l'usage en DMZ.
tags". Leur logique est complètement identique au paramètre poller_tags, mais elle permet de distribuer les exécutions dans les reactionners plutôt que les pollers.
Ce paramètre peux être caractérisés à 3 niveaux :
- Hôte
- Check
- Commande
Là encore, l’existence du paramètre est déterminé dans l'ordre de cascade suivant:
- On regarde d'abord sur la commande
- Puis le check
- Puis sur l'hote.
Les reactionners peuvent être identifiés par plusieurs reactionner_tags. Si ils ont des tags, ils ne prendront que les commandes qui correspondent à ce tag.
Pour avoir les commandes caractérisées spécifiquement par une liste de reactionner_tag et ceux non défini, il faut juste rajouter explicitement le tag "None". Ceci permet d'exclure certains tags sans avoir à définir une liste exaustive.
Architecture avancée: les Royaumes
L'architecture de Shinken Enterprise permet à l'administrateur d'avoir un point unique de gestion pour tous les Schedulers, Pollers, Reactionners et Brokers. Les hôtes sont répartis avec leur propores propres checks vers les Schedulers et ses satellites récupèrent directement leurs tâches. Jusque là tout se passe bien.
...
Un royaume peut contenir un autre royaume (sous royaume). Cela ne change rien pour les schedulers : ils ne sont responsables que des hôtes de leur royaume/sous royaume. L’arborescence royaumes est utile pour les satellites comme les reactionners ou brokers: ils peuvent recevoir les tâches des schedulers de leur royaume mais aussi des schedulers des sous royaumes. Les pollers peuvent également recevoir les tâches des sous royaumes, mais c'est moins intéressant donc désactivé par défaut.
ATTENTION : avoir plusieurs brokers dans un royaume n'est pas une bonne idée. Même chose pour l'arbiter, il n'y a qu'un seul arbier arbiter et une suele seule configuration quelque soit le nombre de royaumes. .
...
Regardons 2 environnements distribués. Dans le 1er cas, l'administrateur veut des démons totalement distincts. Dans le second cas, il veut simplement avoir des schedulers/pollers distincts, tout en gardant un seul endroit pour envoyer les notifications (reactionners) et un seul endroit pour l'export de base (broker).
Royaumes distincts :
Usage plus classique: le royaume global (avec reactionner/broker) et les sous-royaumes (avec schedulers/pollers):
Les satellites peuvent être rattachés également aux royaumes et sous-royaumes.Ce n'est qu'un paramètre dans la configuration de l'élément.
...