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 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 .
Basé sur un back-end HTTP , cela vous permettra de construire une architecture distribuée et hautement disponible très simplement
Le moteur Shinken utilise une programmation distribuée, ce qui veut dire qu'un démon va souvent lancer des invocations de code en asynchrone sur d'autres démons, ce qui implique que la version de code , les chemins et les versions de modules doivent être identiques partout où un démon tourne.
Ceci est décrit dans la page démons .
Shinken Enterprise est capable de couper la configuration en plusieurs parties et les distribuer aux Schedulers .
Le load balancing est fait automatiquement : l'administrateur n'a pas besoin de se souvenir quel hôte est lié à tel autre pour créer les packs
La répartition est basée sur les hôtes : cela veut dire que tous les checks associés à un hôte seront dans le même Scheduler que l'hôte . Cela signifie que l'administrateur n'a pas besoin de connaître toutes les relations entre éléments comme les parents,, dépendances d'hôtes ou dépendances de checks : Shinken Enterprise est capable de lire ses relations et de rassembler tous les éléments liés dans la même partition.
Cette action se fait en 2 parties :
L'action de hachage se fait en se basant sur 2 éléments : les hôtes et les checks. Les checks sont liés à l'hôte donc ils seront dans la même partition.
D'autres relations sont prises en compte :
Shinken Enterprise regardent toutes les relations et créée un graphe avec. Un graphe est une partition de relations.
Illustration :
Dans cet exemple, nous avons 2 partitions:
Quand toutes les partitions sont créées, l'Arbiter les agrègent 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 :
Une fois que toutes les configurations sont créées, l'Arbiter les envoie aux N Schedulers actifs .
Un Scheduler peut commencer à lancer des checks une fois qu'il reçu et chargé sa configuration sans avoir à attendre que TOUS les Schedulers soient prêts.
Pour des configurations plus importantes, avoir plusieurs Schedulers (même sur un seul serveur) est fortement recommandé car ils chargeront leur configuration beaucoup plus vite (nouvelle ou modification)
L'Arbiter crée également les configurations pour ses satellites (pollers, reactionners et brokers) avec les liens permettant de savoir où réaliser les tâches .
Après avoir envoyé les configurations, l'Arbiter commence à traiter les ordres (appelées commandes externes) des utilisateurs et est responsable de vérifier la disponibilité des satellites.
.
L'architecture de Shinken Enterprise est hautement disponible. Avant de rentrer dans le détail, regardons comment fonctionne le load balancing.
Un serveur peut crasher, une application également. C'est pour cela que les administrateurs ont des back up : ils peuvent recharger la configuration des éléments tombés .
A ce jour, un seul démon n'est pas encore doublé : l'Arbiter. Cela sera fait dans le futur. L'Arbiter vérifie régulièrement que tous les démons sont disponibles. Si un Scheduler ou un autre satellite est tombé, l'Arbiter envoit sa configuration au nœud spare défini par l’administrateur .
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.
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 :
L'administrateur doit envoyer des ordres aux Schedulers (comme par exemple un nouveau statut pour un check passif).
Dans Shinken Enterprise, l'administrateur envoie uniquement l'ordre à l'Arbiter, c'est tout. Les commandes externes sont de 2 types :
Pour chaque commande, Shinken Enterprise détecte si c'est global ou particulier:
Dès réception de l'ordre par les Schedulers, il est appliqué.
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 Poller, 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.
C'est très utile quand un utilisateur a des hôtes dans le même Scheduler (comme les dépendances) mais nécessite de lancer des checks depuis un Poller dédié.
Ces checks peuvent être caractérisés à 3 niveaux :
Le paramètre pour caractériser 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.
Les 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". .
Cette fonctionnalité est très utile pour une DMZ.
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 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é..
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". 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.
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.
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.
Make sure to undestand when to use realms and when to use poller_tags.
For some cases poller_tag functionality could also be done using Realms. The question you need to ask yourself: Is a poller_tag "enough", or do you need to fully segregate a the scheduler level and use Realms. In realms, schedulers do not communicate with schedulers from other Realms.
A realm can contain another realm. It does not change anything for schedulers: they are only responsible for hosts of their realm not the ones of the sub realms. The realm tree is useful for satellites like reactionners or brokers: they can get jobs from the schedulers of their realm, but also from schedulers of sub realms. Pollers can also get jobs from sub realms, but it's less useful so it's disabled by default. Warning: having more than one broker in a scheduler is not a good idea. The jobs for brokers can be taken by only one broker. For the Arbiter it does not change a thing: there is still only one Arbiter and one configuration whatever realms you have.
Let's take a look at two distributed environnements. In the first case the administrator wants totally distinct daemons. In the second one he just wants the schedulers/pollers to be distincts, but still have one place to send notifications (reactionners) and one place for database export (broker).
Distincts realms :
More common usage, the global realm with reactionner/broker, and sub realms with schedulers/pollers:
Satellites can be used for their realm or sub realms too. It's just a parameter in the configuration of the element.