[hobbit] Some thoughts on clustered hobbit

[Kauffman, Tom]

I'm planning to have (on the failover system) two hobbitlaunch.cfg files
- a hobbitlaunch.stby and a hobbitlaunch.run. The .stby file has bbpage
and bbnet disabled, while .run does not. At failover time, stop hobbit,
copy the .run to .cfg, and start hobbit. At recovery time, stop hobbit,
copy .stby to .cfg, start hobbit.

 

I'm already syncing the config files from the primary to the standby
whenever changes occur (I'm the only one making changes, so far). What I
*don't* have in place is a dedicated IP address; right now, if the BB
server (now primary hobbit server) goes down, you need to know which
system is running the fallover display. And I'm trying to decide if I
want to sync the history and the rrds BACK to the primary on recovery,
or just leave a hole in the data. Right now, I'm leaning toward doing
this manually after the fact.

 

Tom

 

-----Original Message-----
From: Brian Lynch [mailto:brianlynch at gmail.com] 
Sent: Tuesday, May 10, 2005 2:22 AM
To: hobbit at hswn.dk
Subject: Re: [hobbit] Some thoughts on clustered hobbit

 


I agree with your assessment, but chose the model for a few reasons
(note that I'm basing my experience on about 2 1/2 years running a dual
big brother failover setup):
 
1. There is always one repository for both configuration and data that
are
kept reasonably identical on both systems (within the synch delay). 
2. There is only one ip address accepting BB reports cutting down on 
both network traffic and firewall rules (for hosts in locked down
vlans). 
3. The other system can be dedicated to another purpose (it currently
hosts our documentation site that fails over in the opposite direction).
4. No redundant work is done. Indeed, no load is being 'shared' across
the systems unless you host the web server on the other box.
 There is a risk to this based on the possibility of complete machine
failure
 in between synchronizations.  Hence, Hobbit may come up without all
 the updates for hosts or alerts.  Based on my current model, I will
lose 
about a day of historical data.  These synch rates can be changed and 
a gigabit crossover between machines cuts down on any traffic imposed 
by multiple synch's. 

Note that you could very easily turn off the hobbit alerts with the same
clustering software by truncating and restoring the hobbit-alerts.cfg
file. 
Not sure how to disable the network tests, so that may require some
custom coding... Once complete, you could use the same cluster
resource sw to accomplish a 'hot' standby. 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20050511/b0911934/attachment.html>