The shinken's architecture like we saw allows us to have a unique administration and data location. All pollers the hosts are cut and sent to 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 multile customers network, a customer A scheduler can have a customer B poller that asks him jobs. It's not a good solution. Even with distibuted 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, 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 an 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 In a realm, all realm pollers will take all realm schedulers jobs.

A realm can have sub-realms. It doesnt change anything for schedulers, but it can be useful for other satellites and spares. Reactionners and brokers are linked to a realm, but they can take jobs from all sub-realms too. This way you can have less reactionners and brokers (like we soon will see).

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.

To make it simple : you put hosts and/or hostgroups in a realm. This last one is to be considered as a ressources pool. You don't need to touch the host/hostgroup definition if you need more/less performances in the realm or if you want to add a new satellites (a new reactionner for example).

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 optionnal. 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.

Diagrams are good :)

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 distincts. 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/broker :

Like you can see, all elements are in a unique realm. That's the sub-realm functionality used for reactionner/broker.

Here is the configuration for the shared architecture :

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
}

define host{
   host_name         server-paris
   realm             Paris         ;Will be put in the Paris realm
   [...]
}

define hostgroups{
   hostgroup_name		linux-servers
   alias			Linux Servers
   members			srv1,srv2
   realm                        Europe       ;Will be put in the Europe realm
}