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.