L'architecture de Shinken Enterprise comme vu précédemment permet d'avoir un emplacement unique pour la configuration et pour les données. All pollers the hosts sont découpées et envoyées aux schedulers, 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) 

Dans un royaume, tous les pollers vont prendre les tâches de tous les schedulers de ce royaume. 

Les royaumes en quelques mots

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) 

Dans un royaume, tous les pollers vont prendre les tâches de tous les schedulers de ce royaume. 

Les royaumes sont différents des poller_tags

Vérifiez que vous comprenez bien quand utiliser les royaumes et quand utiliser les poller_tags.

• les royaumes sont faits pour séparer les schedulers

• les poller_tags sont faits pour séparer les pollers

Dans certains cas, la fonctionnalité de poller_tag peut être faite en utilisant les royaumes. La question à se poser est  : est-ce suffisant ? ou devez-vous séparer totalement au niveau du scheduler en utilisant les royaumes. 

• 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 :

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.

Variable Descriptions

Example Definition

  define realm{
      realm_name     World
      realm_members  Europe,America,Asia
      default        0
  }