Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Shinken Enterprise regardent toutes les relations et créée un graphe avec. Un graphe est une partition de relations.

Illustration :

Image Removed

 Image Added

Dans cet exemple, nous avons 2 partitions:

...

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

La répartition se fait sur un critère de poids des Schedulers : plus le poids est élevé, plus il y a de packs .

 

Illustration :

Image RemovedImage Added

Envoi des configurations vers des satellites 

...

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. 

...

Les délais sont volontairement très courts pour de petites installations ( Voir paramètres de configuration des Démons pour plus d'information ).

Illustration :

 

Image RemovedImage Added

 

Distribution par Commande Externe 

...

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. 

...

Ces checks peuvent être caractérisés à 3 niveaux :

  • Hôte
  • Check
  • Commande

 

Le paramètre pour caractériser qualifier une commande, un hôte ou un check , est le "poller_tag". Si un check utilise une valeur "tagged" ou une commande "untagged", il utilise le "poller_tag" de ce couple hôte/check it takes the poller_tag of this host/check. In a "untagged" host/check, it's the command tag that is taken into account. 

 

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 pollers peuvent être 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és spécifiquement par une liste de 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 exhaustiveLes Pollers peuvent être caractérisés par plusieurs "poller_tag". Si ils sont caractérisés, ils prendront uniquement les checks correspondant, excepté si la valeur du tag est "none". .

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 :

 

Image Removed

 Image Added

 

 

Usage plus classique: le royaume global (avec reactionner/broker) et les sous-royaumes (avec schedulers/pollers):

 

Image Removed

  

Image Added


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.

...