Page History

Multi clients et/ou datacenters: ROYAUMES

L'architecture de Shinken Enterprise comme vu vue 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.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 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é) 

...

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 sparespares.  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 performance dans le royaume ou si vou ssouhaitez vous souhaitez rajouter des satellites. 

...

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) 

...

Comme vous le voyez, tous les éléments sont dans un royaume unique, on utilise le sous-royaumes pour les reactionner/broker.

Royaume Monde et ses sous-Royaumes (Configuration)

Voici la  configuration configuration pour l'architecturedistribuéearchitecture distribuée:

define realm {
  realm_name All      World
  # Now you define SUB REALMS of World
  realm_members   Europe,US,Asia
  default 1 ;Is the default realm. Should be unique! 
}
 # 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 ;This realm is IN Europe
}
 

#An now the satellites:



}
# 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 ;It
}
 
# Example of a TOP level realm (WORLD) daemon that can reach daemons of the SUB realms
# so will onlyreach manageEurope, Paris hosts
}

, USA and Asia
define reactionner{
  reactionner_name     reactionner-master
  realm All ;Will reach ALL schedulers                World
}
 

Le lien de l'hôte vers le royaume est fait dans sa page de configuration :

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.  

...

define realm{
realm_name Europe
broker_complete_links 1
}
 

Cela permettra à chaque schedulers scheduler d'être lié à chaque brokersbroker. Cela permet également d'avoir un broker dédié dans un même royaume (un pour l'interface web et au un autre pour graphite par exemple). 

...