...
L'architecture de Shinken Enterprise comme vue précédemment permet d'avoir un emplacement unique pour la configuration et pour les données. Les hôtes sont répartis parmi les Schedulers, qui définissent les commandes a exécuter. Les Pollers vient alors récupérer ces tâches pour les exécuter.
Ou presque ! .. En fait, si vous avez une architecture distribuée sur plusieurs continents, vous pouvez avoir des problèmes. Si 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é) .
C'est là que devient intéressante la gestion des clients par site. Dans Shinken Enterprise, on le gère à travers les "royaumes"..
Un royaume est un groupe de ressources qui va gérer les hôtes et les groupes d'hôtes. Ce lien doit être unique, un hôte ne peut pas appartenir à plusieurs royaumes. Si vous mettez un groupe d'hôtes dans un royaume, tous les hôtes rattachés feront partie de ce royaume (sauf si vous avez déjà défini un royaume particulier sur un hôte) .
Un royaume, c'est :
- au moins un scheduler
...
Dans un royaume, tous les pollers vont prendre les tâches de tous les schedulers de ce royaume.
Important : il n'y a qu'UN SEUL arbiter (et son spare) pour TOUS les royaumes. L'arbiter gère TOUS les royaumes et ce qui s'y rattache.
...
Un royaume peut avoir des sous-royaumes. Cela ne change rien pour les schedulers., mais peut être utile pour les autres satellites et spares. Les 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 les reactionners/brokers.
Un exemple
Pour faire simple : vous mettez vos hôtes et groupes d'hôtes dans un royaume. CeluiCelui-ci est considéré comme un pool de ressources. Vous n'avez pas besoin de modifier la définition de vos hôtes et groupes d'hôtes si vous avez besoin de plus/moins de performance dans le royaume ou si vous souhaitez rajouter des satellites.
Les royaumes sont sont une manière de gérer les ressources. Ce sont plus plusieurs petits "nuages" dans votre infrastructure cloud globale.
PS : cette fonctionnalité est optionnelle, un royaume par défaut est créé. .
Schéma
Prenons 2 exemples d'architecture distribuée à travers le monde. Dans le 1er premier 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) .
Version isoléé (cas 1) :
Version partagée (cas 2) :
Comme vous le voyez, tous les éléments sont dans un royaume unique, on utilise le sous-royaumes pour les reactionner/broker.
...
Voici la configuration pour l'architecture distribuée :
| Code Block | ||||
|---|---|---|---|---|
| ||||
define realm {
realm_name World
# Now you define SUB REALMS of World
realm_members Europe,US,Asia
# Element without explicit realm setting will be set in the World realm
default 1
}
# We define our SUB REALMS
# EUROPE
define realm{
realm_name Europe
# This one have it's own SUB REALM
realm_members Paris
}
# Paris: sub realm for Europe
define realm{
realm_name Paris
}
# USA
define realm{
realm_name USA
}
# Asia
define realm{
realm_name Asia
}
# For example the daemons for the Paris realm
define scheduler{
scheduler_name scheduler_Paris
realm Paris
}
# Example of a TOP level realm (WORLD) daemon that can reach daemons of the SUB realms
# so will reach Europe, Paris, USA and Asia
define reactionner{
reactionner_name reactionner-master
realm World
}
|
...
Dans les exemples précédents, si vous mettez plusieurs brokers dans le royaume, chaque scheduler aura accès à un seul broker en même temps, il . Il est impossible d'avoir un broker commun pour tous.
...