L'architecture de Shinken Enterprise comme vue précédemment permet d'avoir un emplacement unique pour la configuration ( la politique de supervision et la définition des démons ).
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 qui 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 démons Shinken qui va gérer les hôtes:
Un royaume :
Dans un royaume, tous les Pollers vont prendre les tâches de tous les Schedulers de ce royaume.
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 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.
Pour faire simple : vous mettez vos hôtes et groupes d'hôtes dans un royaume.
Les royaumes sont une manière de gérer les ressources. Ce sont plusieurs petits "nuages" dans votre infrastructure cloud globale.
PS : cette fonctionnalité est optionnelle, un royaume par défaut est créé.
Prenons 2 exemples d'architecture distribuée à travers le monde.
|
|
Comme vous le voyez, tous les éléments sont dans un royaume unique, on utilise le sous-royaume pour les Reactionners/Brokers.
Dans le répertoire /etc/shinken/realms/, voici la configuration pour l'architecture distribuée avec des royaumes :
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
}
|
La propriété realm_name ne doit pas contenir les caractères suivants:
|
Pour une gestion plus facile des royaumes, nous conseillons de placer chaque définition de royaumes dans un fichier dédié ( royaume All dans all.cfg, royaume Paris dans paris.cfg, etc... ). De la même manière, nous conseillons aussi fortement de placer les définitions des démons dans le dossier approprié puisque les outils livrés avec Shinken supposent que ces conventions sont respectées. Ainsi, on placera par exemple les définitions des Reactionners dans /etc/shinken/reactionners, des Brokers dans /etc/shinken/brokers etc... |
Pour attacher un hôte ou un cluster à un royaume, il faut :
|
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 est impossible d'avoir un Broker commun pour tous.
Vous pouvez activer le multi-brokers avec le paramètre broker_complete_links ( 0 par défaut ).
Vous devez également activer cette option dans TOUS les royaumes. Par exemple :
define realm {
realm_name Europe
broker_complete_links 1
}
|
Cela permettra à chaque Scheduler d'être lié à chaque broker. Cela permet également d'avoir un broker dédié dans un même royaume (un pour l'interface web et un autre pour Graphite par exemple).