...
L'architecture de Shinken Enterprise selon les principes Unix : un outil, une tâche.
Shinken Enterprise has an architecture where each part is isolated and connects to the others via standard interfaces. Shinken Enterprise is based on the a HTTP backend. This makes building a highly available or distributed monitoring architecture quite easily.
Shinken core uses distributed programming, meaning a daemon will often do remote invocations of code on other daemons, this means that to ensure maximum compatibility and stability, the core language, paths and module versions must be the same everywhere a daemon is running.
Shinken Enterprise Daemon roles
This part is described on the daemon page.
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.
Rôles de chaque démon Shinken Enterprise
Ceci est décrit dans la page démons .
Le load balancing automatique
...
Distribution des hôtes à travers les schedulers
...
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:
- Shard shard 1: Host-1 to au host-5 and all their et tous leurs checks
- shard Shard 2: Host-6 to au Host-8 and all their checks
The shards aggregations into scheduler configurations
When all relation shards are created, the Arbiter aggregates them into N configurations if the administrator has defined N active schedulers (no spares). shards are aggregated into configurations (it's like "Big shards"). The dispatch looks at the weight property of schedulers: the higher weight a scheduler has, the more shards it will have. This can be shown in the following picture :
The configurations sending to satellites
When all configurations are created, the Arbiter sends them to the N active Schedulers. A Scheduler can start processing checks once it has received and loaded it's configuration without having to wait for all schedulers to be ready(v1.2). For larger configurations, having more than one Scheduler, even on a single server is highly recommended, as they will load their configurations(new or updated) faster. The Arbiter also creates configurations for satellites (pollers, reactionners and brokers) with links to Schedulers so they know where to get jobs to do. After sending the configurations, the Arbiter begins to watch for orders from the users and is responsible for monitoring the availability of the satellites.
Pollers connections with more than one scheduler
The high availability
The Shinken Enterprise architecture is a high availability one. Before looking at how this works,let's take a look at how the load balancing works if it's now already done.
When a node dies
Nobody is perfect. A server can crash, an application too. That is why administrators have spares: they can take configurations of failing elements and reassign them. For the moment the only daemon that does not have a spare is the Arbiter, but this will be added in the future. The Arbiter regularly checks if everyone is available. If a scheduler or another satellite is dead, it sends its conf to a spare node, defined by the administrator. All satellites are informed by this change so they can get their jobs from the new element and do not try to reach the dead one. If a node was lost due to a network interruption and it comes back up, the Arbiter will notice and ask the old system to drop its configuration.
The availability parameters can be modified from the default settings when using larger configurations as the Schedulers or Brokers can become busy and delay their availability responses. The timers are aggressive by default for smaller installations. See daemon configuration parameters for more information on the three timers involved.
This can be explained by the following picture :
External commands dispatching
...
- commands that are global to all schedulers
- commands that are specific to one element (host/check).
For each command, Shinken Enterprise knows if it is global or not. If global, it just sends orders to all schedulers. For specific ones, it searches which scheduler manages the element referred by the command (host/check) and sends the order to this scheduler. When the order is received by schedulers they just need to apply them.
Different types of Pollers: poller_tag
The current Shinken Enterprise architecture is useful for someone that uses the same type of poller for checks. But it can be useful to have different types of pollers, like GNU/Linux ones and Windows ones. We already saw that all pollers talk to all schedulers. In fact, pollers can be "tagged" so that they will execute only some checks.
This is useful when the user needs to have hosts in the same scheduler (like with dependencies) but needs some hosts or checks to be checked by specific pollers (see usage cases below).
These checks can in fact be tagged on 3 levels :
- Host
- Check
- Command
The parameter to tag a command, host or check, is "poller_tag". If a check uses a "tagged" or "untagged" command in a untagged host/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.
The pollers can be tagged with multiple poller_tags. If they are tagged, they will only take checks that are tagged, not the untagged ones, unless they defined the tag "None".
Use cases
This capability is useful in the DMZ case.
In the first case, it can be useful to have a windows box in a domain with a poller daemon running under a domain account. If this poller launches WMI queries, the user can have an easy Windows monitoring.
The second case is a classic one: when you have a DMZ network, you need to have a dedicated poller that is in the DMZ, and return results to a scheduler in LAN. With this, you can still have dependencies between DMZ hosts and LAN hosts, and still be sure that checks are done in a DMZ-only poller.
Different types of Reactionners: reactionner_tag
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
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
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!
Make sure to undestand when to use realms and when to use poller_tags.
- realms are used to segregate schedulers
- poller_tags are used to segregate pollers
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.
- If you just need a poller in a DMZ network, use poller_tag.
- If you need a scheduler/poller in a customer LAN, use realms.
Sub realms
...
- et tous leurs checks
L'aggrégation des partitions dans les schedulers
Quand toutes les partitions sont créées, l'Arbiter les 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 :
Envoi des configurations vers des satellites
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 a 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.
.
Connexions aux Pollers avec plus d'un Scheduler
La haute disponibilité
L'architecture de Shinken Enterprise est hautement disponible. Avant de rentrer dans le détail, regardons comment fonctionne le load balancing.
Quand un nœud meurt
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 .
- 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 .
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 :
Distribution par Commande Externe
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 :
- commandes qui concernent tous les Schedulers.
- commandes qui sont spécifiques à un seul élément (hôte/check).
Pour chaque commande, Shinken Enterprise détecte si c'est global ou particulier:
- si global, il envoie les ordres à tous les Schedulers.
- Si particulier, il détecte quel Scheduler gère l'élément concerné par la commande (hôte/check) et envoie l'ordre au bon Scheduler.
Dès réception de l'ordre par les Schedulers, il est appliqué.
Différents types de Pollers: poller_tag
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 Pollers, 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 :
- Hôte
- Check
- Commande
Le paramètre pour qualifier une commande, un hôte ou un check est le "poller_tag".
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 exhaustive.
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 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é..
Différents types de Reactionners: reactionner_tag
D'une manière totalement symétrique aux pollers, les Reactionners peuvent être caractérisés avec un ou plusieurs "reactionner_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 propres 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.
Les Royaumes ne sont pas des poller_tags!
Soyez sûrs de bien comprendre quand utiliser les Royaumes et quand utiliser les poller_tags .
- Les royaumes sont utilisés pour séparer les schedulers
- les poller_tags sont utilisés pour utiliser les pollers séparés
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.
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 arbiter et une seule configuration quelque soit le nombre de royaumes. .
Exemple d'utilisation des 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 :
Usage plus classique: le royaume global (avec reactionner/broker) et les sous-royaumes (avec schedulers/pollers):
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
...
Example of realm usage
...
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.