Advanced architectures
Advanced architectures
Mixed architectures and DMZ monitoring
The Shinken architecture allows the administrator to solve easily two majors problems in IT monitoring : Windows based and/or DMZ monitoring. For the first one, it can be useful to have checks launched from a Windows box : it’s already in the domain, so with WMI queries, monitoring is very easy. It’s far more complex to to it from GNU/Linux box.
For DMZ monitoring : having checks launch from a box in the DMZ is useful if it can gave back results to a server in the LAN. It involves far less holes in the firewall!
In fact it can be useful to say to a command or a host “Hey, I’d rather run in this particular poller”. Thanks to Shinken, it’s possible, and even easy! All you need to do is to “tag” your host or your command in the global configuration and also tagged the poller with. Multiples tags are possibles. And it’s done. For the DMZ case, the only part of the Shinken architecture in this part of the network will be the poller. It will return to the LAN scheduler. For Windows poller, GNU/Linux based commands will be launched on GNU/Linux poller, Windows on Windows poller!
You have a mixed architecture with nearly no effort. Thanks Shinken Architecture.
Branches and customers management with Realms
Shinken’s architecture allows the administrator to have a unique point of administration with numerous schedulers, pollers, reactionners and brokers. Hosts are dispatched with their own services to schedulers and the satellites (pollers/reactionners/brokers) get jobs from them. Everyone is happy.
Or almost everyone. Think about an administrator who has a distributed architecture around the world in all it’s customer sites. The hosts are dispatched to all schedulers and satellites so the administrator cannot be sure that hosts from customer A will not be managed by a scheduler in the customer B infrastructure!
It’s the same problems with branches. Such organisational “separations” must be possible. The simple Shinken architecture is useful for load balancing with high availability, but for a unique site. Site management with a common administration must be possible.
Be happy : this is possible, and even very easy to have : such management is done with realms.
Realms in few words
A realm is a pool of resources (scheduler, poller, reactionner and broker) on which hosts or hostgroups can be attached. A host or hostgroup can be attached to only one realm. All “dependancies” or parents of this hosts must be in the same realm. A realm can be said as “default”‘ and unattached hosts will be put into it.
In a realm, pollers, reactionners and brokers will only get jobs from schedulers of the same realm.
Sub realms
In fact my last sentence is not totally exact. A realm can contain another realms. It does not change anything for schedulers : they only got host 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. Poller can also get jobs from sub realms, but it’s less useful so it’s disabled by default.
So in fact you can factorize all data and notifications for all yours customers very easily!
For the Arbiter it doesn’t change a thing: there is still only one Arbiter and one configuration independently to the number of realms you have.
Example of realm usage
Not really clear? Ok let’s take a look at two distributed envrionnements. 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.
