Combining two seperate Icinga master-master installations

[willfurnell (Will)]

We currently have two completely seperate Icinga installations in our department, as they are in different networks, checking different hosts for two groups.

We are looking into merging these instances as much as we can, so the configuration and web interface can be managed from a single master instance and sent from this to the satellites and then to the agents, and our existing master and failover servers in the groups become satellites in different zones.

At the moment configuration is edited on the group A and group B masters, and sent down to the agents.
We would need to keep any configuration and checks for group A seperate from group B - as we don’t want group A satellites monitoring group B hosts and vice versa.

Here’s a diagram of the sort of thing we’d like to achieve. Do you think something like this is realistic?
What do you think would be the best way to go about this to minimise the downtime of all the monitoring systems? I’d be really interested in all your opinions whether this setup as shown is a good idea or not!

I know we’d have to re-sign all certificates, which is quite annoying, so if there’s any way to combine the CAs too then I’d definitely be interested to learn Thank you so much!

[Someone]

Hello @willfurnell
As far as i know, no, there is no way to merge the CAs, so yup you got to resign everything.
EDIT : you can halve the process if you export the CA you used on ones of the zone on your master, you’ll however need to resign everything manually for other zone.

Given your diagram, i would say that yes it will work, and it’s a pretty common icinga configuration (ref here )
I’d however advise you to cluster your master with an other instance to ensure resilience, for the database part its more or less critical, but depending how much you rely on it it can be required to cluster it as well.

Also, from experience i’d advise you to have at least one satellite or one master or one database from same cluster in different physical location of its twin to ensure resilience of icinga zones if you can afford it (let say for example to avoid loosing your monitoring if a room get out of network/energy )

If you are interested in getting the database resilient there is a well made tuto here, for others parts of your diagram, for now it’s common enought to rely safely on the official docs.