...
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 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
Like for the pollers, reactionners can also have 'tags'. So you can tag your host/check or commands with
Comme pour les Pollers, les Reactionners peuvent eux aussi avoir des caractéristiques . Vous pouvez donc caractériser vos hôtes/checks et commandes par le "reactionner_tag". If a notification or an event handler uses a Si une notification ou un gestionnaire d’événements utilise une commande "tagged" or ou "untagged" command in a untagged hostsur un hôte/check , it takes the reactionner_tag of this host/checknon 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.
The reactionners can be tagged with multiple reactionner_tags. If they are tagged, they will only take checks that are tagged, not the untagged ones, unless they defined the tag "None".
Like for the poller case, it's mainly useful for DMZ/LAN
Advanced architectures: Realms
Shinken Enterprise's architecture allows the administrator to have a unique point of administration with numerous schedulers, pollers, reactionners and brokers. Hosts are dispatched with their own checks to schedulers and the satellites (pollers/reactionners/brokers) get jobs from them. Everyone is happy.
Or almost everyone. Think about an administrator who has a distributed architecture around the world. With the current Shinken Enterprise architecture the administrator can put a couple of scheduler/poller daemons in Europe and another set in Asia, but he cannot "tag" hosts in Asia to be checked by the asian scheduler . Also trying to check an asian server with an european scheduler can be very sub-optimal, read very sloooow. The hosts are dispatched to all schedulers and satellites so the administrator cannot be sure that asian hosts will be checked by the asian monitoring servers.
In the normal Shinken Enterprise Architecture,it is useful for load balancing with high availability, for single site.
Shinken Enterprise provides a way to manage different geographic or organizational sites.
We will use a generic term for this site management, Realms.
Realms in few words
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.
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 checks vers les Schedulers et ses satellites récupèrent directement leurs tâches. Jusque là tout se passe bien.
Ou presque bien... Imaginons un administrateur qui a une infrastructure répartie dans le monde entier. En version simple avec Shinken Enterprise, l'administrateur peut installer plusieurs couples Scheduler/Poller dans différentes zones géographiques (par exemple Europe et Asie), mais il ne peut pas forcer les checks "Asie" à être réalisés par le Scheduler "Asie". Essayer de lancer un check en Asie depuis le serveur Europe peut également se révéler très leeennnnnnt, les hôtes étant répartis sur tous les Schedulers et leurs satellites, donc il n'y a aucune garantie que les hôtes locaux seront checkés par leurs serveurs locaux.
Shinken Enterprise permet alors de gérer la notion de zones géographiques ou organisations séparées.
Le terme utilisé pour gérer cette notion de séparation dans l'outil est le Royaume.
Les Royaumes en quelques mots
Un royaume est un ensemble de ressources (scheduler, poller, reactionner et broker) auxquelless sont rattachés des hôtes ou des groupes d'hôtes. Un hôte ou un groupe d'hôte ne peut être rattaché qu'à un seul royaume. Toutes les dépendances ou parents des hôtes doivent également être dans le même royaume. Un royaume peut être défini par défaut, les hôtes non affectés lui seront automatiquement rattachés. Dans un royaume, les pollers, reactionners et brokers ne recevront les tâches que des schedulers du même royaume. A realm is a pool of resources (scheduler, poller, reactionner and broker) that hosts or hostgroups can be attached to. A host or hostgroup can be attached to only one realm. All "dependancies" or parents of this hosts must be in the same realm. A realm can be tagged "default"' and realm untagged hosts will be put into it. In a realm, pollers, reactionners and brokers will only get jobs from schedulers of the same realm.
Realms are not poller_tags!
...