nagios server redundancy

[Morty]

On Fri, Feb 11, 2011 at 01:35:26PM -0800, Mike Lindsey wrote:

> What I end up doing with my backup master is leave it off, with
> frequent rsyncs of both config and the status files in var.

Thanks!  But I specifically want to leave both running under nominal
conditions.  This gives me the warm fuzzies that the backup is fully
functional, i.e. no missing programs, scripts, firewall rules, or
whatever, and without any single points of failure.  I can live with
duplicate notifications, especially since I'm expecting to report to a
COTS product with built-in dedupe.

The way I handle active/active sync with certain COTS products is to
shutdown the prime; back up the prime (i.e. to a tarball); restart the
prime; transfer the tarball to the backup; shutdown the backup;
restore the tarball on the backup; and restart the backup.  This way,
I never have a moment when both the prime and the backup are down, and
the backup is done on a quiescent system.  If you're successfully
syncing the var dirs, sounds like this should work for nagios as well.

> You cannot - to the best of my knowledge - sync acknowledgments to a
> backup server while it's actively running, unless you want to write
> something that checks for new acks and dumps them into the command
> pipe.  So, if you want to maintain acks and downtime, you'll need to
> have your backup disabled for the syncs.

That's unfortunate.  OK, thanks.

- Morty

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null