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é..
Like for the pollers, reactionners can also have 'tags'. So you can tag your host/check or commands with
"reactionner_tag". If a notification or an event handler uses a "tagged" or "untagged" command in a untagged host/check, it takes the reactionner_tag of this host/check. 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
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.
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.
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.