Multi
...
clients et/
...
ou datacenters:
...
ROYAUMES
L'architecture de Shinken Enterprise 's architecture like we saw allows us to have a unique administration and data locationcomme vu précédemment permet d'avoir un emplacement unique pour la configuration et pour les données. All pollers the hosts are cut and sent to sont découpées et envoyées aux schedulers, and the pollers take jobs from all schedulers. Every one is happy.
Every one? In fact no. If an administrator got a continental distributed architecture he can have serious problems. If the architecture is common to multiple customers network, a customer A scheduler can have a customer B poller that asks him jobs. It's not a good solution. Even with distributed network, distant pollers should not ask jobs to schedulers in the other continent, it's not network efficient.
That is where the site/customers management is useful. In Shinken Enterprise, it's managed by the **realms**.
A realm is a group of resources that will manage hosts or hostgroups. Such a link will be unique: a host cannot be in multiple realms. If you put a hostgroup in a realm, all hosts in this group will be in the realm (unless a host already has the realm set, the host value will be taken).
A realm is:
- at least a scheduler
- at least a poller
- can have a reactionner
- can have a broker
- can have a recevier
In a realm, all realm pollers will take all realm schedulers jobs.
Important: there is only ONE arbiter (and a spare of course) for ALL realms. The arbiter manages all realms and all that is inside.
Sub-realms
...
The fact that reactionners/brokers (and in fact pollers too) can take jobs from sub-schedulers is decided by the presence of the manage_sub_realms parameter. For pollers the default value is 0, but it's 1 for reactionners/brokers.
...
et les pollers exécutent les tâches provenant des schedulers.Tout se passe 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é)
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
- au moins un poller
- peut avoir un reactionner
- peut avoir un broker
- peut avoir un recevier
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.
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.
Un exemple
Pour faire simple: vous mettez vos hôtes et groupes d'hôtes dans un royaume. Celui-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 perfromance dans le royaume ou si vou ssouhaitez rajouter des satellites.
Les royaumes sont une manière de gérer les ressources. Ce sont plus 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 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éé
Realms are a way to manage resources. They are the smaller clouds in your global cloud infrastructure.
If you do not need this feature, that's not a problem, it's optional. There will be a default realm created and every one will be put into.
It's the same for hosts that don't have a realm configured: they will be put in the realm that has the "default" parameter.
...
Let's take two examples of distributed architectures around the world. In the first case, the administrator don't want to share resources between realms. They are distinct. In the second, the reactionners and brokers are shared with all realms (so all notifications are send from a unique place, and so is all data).
Here is the isolated one:
And a more common way of sharing reactionner/brokerVersion partagée:
As you can see, all elements are in a unique realm. That's the sub-realm functionality used for Comme vous le voyez, tous les éléments sont dans un royaume unique, on utilise le sous-royaumes pour les reactionner/broker.
...
Configuration
Voici la configuration pour l'architecturedistribuéeHere is the configuration for the shared architecture:
| Code Block | ||||
|---|---|---|---|---|
| ||||
define realm {
realm_name All
realm_members Europe,US,Asia
default 1 ;Is the default realm. Should be unique!
}
define realm{
realm_name Europe
realm_members Paris ;This realm is IN Europe
}
#An now the satellites:
define scheduler{
scheduler_name scheduler_Paris
realm Paris ;It will only manage Paris hosts
}
define reactionner{
reactionner_name reactionner-master
realm All ;Will reach ALL schedulers
}
|
And the host link into a realm will be on the host configuration pageLe lien de l'hôte vers le royaume est fait dans sa page de configuration :
Multi levels brokers
Brokers multi-niveaux
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 In the previous samples, if you put numerous brokers into the realm, each scheduler will have only one broker at the same time. It was also impossible to have a common Broker in All, and one brokers in each sub-realms.You can activate multi-brokers features with a realm parameter, the broker_complete_links optionoption (0 by defaultpar défaut).
You will have to enable this option in ALL your realms! For example:
Vous devez également activer cette option dans TOUS les royaumes. Par exemple :
| Code Block | ||||
|---|---|---|---|---|
| ||||
define realm{
realm_name Europe
broker_complete_links 1
}
|
This will enable the fact that each scheduler will be linked to each brokers. This will make possible to have dedicated brokers in a same realm (one for the web interface, another for Graphite for example). It will also make possible to have a common Broker in "All", and one broker in each of its sub-realms (Europe, US and Asia). Of course the sub-brokers will only see the data from their realms, and the sub-realms (like Paris for Europe for example).
Cela permettra à chaque schedulers d'être lié à chaque brokers. Cela permet également d'avoir un broker dédié dans un même royaume (un pour l'interface web et au autre pour graphite par exemple).