L'architecture de Shinken Enterprise
...
permet a un administrateur d'avoir un
...
point central de configuration et ce, indépendamment du nombre de Schedulers, Pollers, Reactionners et Brokers. Les hôtes et leurs checks sont repartis entre les Schedulers et les satellites (Pollers/Reactionners/Brokers) reçoivent des actions à exécuter de ces Schedulers.Tout fonctionne bien...
Ou presque ! .. En fait, si vous avez une architecture distribuée sur plusieurs continents, vous pouvez avoir des problèmes. Si l'architecture est commune à plusieurs réseaux, un scheduler d'un client A peut avoir un Poller d'un client B lui demandant des tâches.. Ce n'est pas une bonne idée pour des questions d'efficacité du réseau (même avec un réseau distribué)
...
- 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
Sub 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.
Example of realm usage
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 :
...
Les sous-royaumes
Un royaume peut avoir des sous-royaumes. Cela ne change rien pour les schedulers., mais peut être utile pour les autres satellites et spare. Les reactionners et brokers sont liés au même royaume, mais ils peuvent traiter les tâches des sous-royaumes également.De cette façon, vous pouvez avoir moins de reactionners et de brokers.
Cela se fait grâce au paramètre manage_sub_realms . Pour les pollers la valeur par défaut est 0, mais c'est 1 pour reactionners/brokers.
Exemple d'usage de royaumes
Prenons 2 exemples d'architecture distribuée à travers le monde Dans le 1er cas, l'administrateur ne souhaite pas partager les ressources entre royaumes. Dans le second, les reactionners et brokers sont partagés entre royaumes. (donc toutes les notifications sont envoyées d'un seul endroit, idem pour le stockage des données) .
Royaumes distincts :
Usage plus classique :
Les satellites peuvent être utilisés pour leurs royaumes ou sous royaumes.
Description des variables
| Propriété | Défaut |
|---|
...
Variable Descriptions
| Description | |
|---|---|
| realm_name | N/A |
| Cette variable est utilisée pour identifier le nom raccourci du royaume. | |
| realm_members | N/A |
Example Definition
| Cette directive est utilisée pour lister les sous-royaumes . | ||
| broker_complete_links | 0 | Si placé à 1, ceci autorise les brokers à être plusieurs à prendre les informations d'un même scheduler. Dans le cas par défaut (0), un broker unique est assigné à un scheduler, ce qui empèche de voir ses données dans un realm de plus haut niveau si un broker est déjà présent dans son royaume. |
| default | 0 | Cette directive est utilisée pour définir si il s'agit du royaume par défaut ou non. Un seul est autorisé comme "par défaut" |
...
| Code Block |
|---|
define realm{
realm_name World
realm_members Europe,America,Asia
default 0
} |