TECHZEN Zenoss User Community ARCHIVE  

Zenoss at mulitple physical locations

Subject: Zenoss at mulitple physical locations
Author: Tony H
Posted: 2015-01-22 13:13

We expanding to a 2nd location in the near future and will need to use Zenoss Core at each location. We will be connected via a 10g link, but I will also need failover options if the link goes down. I am wondering if anyone else has this type of setup and how you went about implementing it.

Basically what I am looking to do is:

1) Have Zenoss Core running in our Location 1
2) Have Zenoss Core running in our Location 2
3) Have the ability to monitor devices FROM either facility AT either facility.
3) Have the ability to independently monitor either location if the link between the sites goes down

I would love you hear if anyone else is current doing this or has idea on how do so.

Thanks in advance!



Subject: I've been thinking about this
Author: [Not Specified]
Posted: 2015-01-22 13:32

I've been thinking about this problem too and haven't actually done anything about it yet, aside from having zenbackups stored cross-site. Be sure you're doing that no matter what else you decide to do.

You could do something like this....

Set up Core Site A and Core Site B

Discover all your devices into both Cores

Let all devices get monitored from both sites all the time (appropriate ACLs on SNMP etc). This way each Core has the same performance and event data for all the nodes.

Set up your notifications to send notifications about Site A nodes from Core A only and vice versa for B (i.e. add location to your triggers) - So you don't get duplicate notifcations during normal operations

If you have a failure affecting just the Core A server itself, change your notifications on Core B to send notifications for Site A devices. (vice-versa for if your failure took out Core B server itself)

If you have a site or wan failure isolating the sites, you could go into each core and set the other Site's devices to Decommissioned mode to prevent unnecessary monitoring cycles on those devices. Maintenance mode will continue to poll.

You'll need a special case to some cross site monitoring, so you'll get told when a site has gone down. Maybe add a special trigger for your core routers on each site to always notify from each Core.

Now I have to go implement this here :-)
Hope this helps,
Dave



Subject: More thoughts
Author: [Not Specified]
Posted: 2015-01-22 13:46

Instead of updating your triggers, which, if you have a lot, could be a pain, you could use some of the other device settings to decide what gets notified from where. Like the Priority setting or maybe a Group or System.

Having everything in two places leaves you with the problem of keeping the two Cores in sync. e.g. creating new users, adding or modifying triggers and notification, process classes, zenpacks, the list goes on. Some scripting with the JSON API and other import/export methods could alleviate some of that by copying stuff from one to another. Using LDAP for user auth would solve the user problem.



Subject: you could also consider using
Author: Andrew Kirch
Posted: 2015-01-26 12:52

you could also consider using the community distributed collector plugin http://wiki.zenoss.org/ZenPack:Distributed_Collector_(Open_Source)

Andrew Kirch

akirch@gvit.com

Need Zenoss support, consulting or custom development Look no further. Email or PM me!

Ready for Distributed Topology (collectors) for Zenoss 5 Coming May 1st from GoVanguard



Subject: These are all good ideas,
Author: Tony H
Posted: 2015-01-27 08:17

These are all good ideas, thanks to all for your input. Our second site will be going live around April, so I have some time to think and get ideas together.



Subject: The best solution I have come
Author: Brad
Posted: 2015-01-30 17:05

The best solution I have come up with so far is to do an Active/backup. Sync the Active to the your second data center every 30 minutes or so. Then on the backup run a monitoring script of the Primary and startup Zenoss on failure.



< Previous
minimax threshold
  Next
Small measured values are stored in RRD rounded to 0.0
>