...
Shinken Enterprise peut être configuré pour supporter une architecture distribuée .
L'objectif de cette architecture distribuée est de réduire la charge (CPU...) et d'améliorer les temps de traitement des checks d'une approche "un seul serveur qui traite" vers une approche "plusieurs serveurs qui traitent". La
La plupart des environnements simples ne nécessiteront pas la mise en place de cette architecture distribuée, mais quand vous commencez à gérer plusieurs milliers d'hôtes, cela devient crucial.
...
L'architecture de Shinken Enterprise selon les principes Unix : un outil, une tâche. Shinken Enterprise a une architecture où chaque partie est isolée et se connecte aux autres une interface standard HTTP .
...
- Tous les satellites sont informés de ce changement, de façon à recevoir leur tâches du nouvel élément sans essayer de joindre le démon tombé .
- Si un nœud est perdu du à une coupure réseau, puis revient , l'Arbiter en prend note et demande au système de supprimer son ancienne configuration . lui renvoie sa configuration. Le nœud spare l'ayant remplacé redeviendra spare.
Les critères de disponibilité peuvent être modifiés dans les paramètres par défaut lorsqu'il s'agit d'une grosse installation car les Schedulers et Brokers peuvent être surchargés et du coup avoir des temps de réponse de disponibilité plus longs.
...
Dans un 1er cas, il peut être utile d'avoir une boîte 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 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é..
...
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 leeennnnnntlent, 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.
...
Dans certains cas, la fonctionnalité poller_tag peut aussi être réalisée en utilisant les royaumes. La vraie question à se poser est : est que le poller_tag est suffisant, ou est-ce nécessaire de totalement séparer les environnements au niveau du scheduler à travers la notion de royaume. enough", Dans un royaume, les schedulers ne communiquent qu'avec les autres schedulers du même royaume, et jamais avec d'autres.
- si vous avez juste besoin d'un poller dans une DMZ, utiliser le poller_tag.
- Si vous avez besoin d'un scheduler/poller dans un LAN client, utiliser les royaumes.
Sous royaumes
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.
...