<br><br><div><span class="gmail_quote">On 5/9/05, <b class="gmail_sendername">Kauffman, Tom</b> <<a href="mailto:KauffmanT@nibco.com">KauffmanT@nibco.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

First, let me express my thanks to Brian for putting this document together and allowing Henrik to distribute it! I've a lot of experience with IBM's HACMP for AIX, and getting a clustered configuration working as desired is not a trivial procedure.

<br><br>Henrik -- check me on this: it's my impression we no longer need a<br>'BBPAGER' entry on the client-side bb-hosts because the hobbit server<br>passes all potentially alertable statuses to hobbit-alert and it decides

<br>if an alert is really required.<br><br>Brian -- no offense, but I would rather categorise your configuration as<br>"active/inactive". I'm looking at doing an "active/passive" cluster when<br>time frees up -- about a month from now. The difference? I'm running two

<br>hobbit/apache instances all the time -- but the 'passive' (fallover)<br>side is not doing alerting or network tests. It does build displays<br>(it's my technical documentation server as well) and it does keep both<br>

history and rrd data updated. Both hosts show up on the client side as 'BBDISPLAY'. On failover it will take over the IP address for the hobbit display and re-launch hobbit with network testing and alerting enabled.

</blockquote><div><br>

I agree with your assessment, but chose the model for a few reasons<br>

(note that I'm basing my experience on about 2 1/2 years running a dual<br>

big brother failover setup):<br>

 <br>

1. There is always one repository for both configuration and data that are<br>

kept reasonably identical on both systems (within the synch delay). <br>

2. There is only one ip address accepting BB reports cutting down on <br>

both network traffic and firewall rules (for hosts in locked down vlans). <br>

3. The other system can be dedicated to another purpose (it currently<br>

hosts our documentation site that fails over in the opposite direction).<br>

4. No redundant work is done. Indeed, no load is being 'shared' across<br>

the systems unless you host the web server on the other box.<br>

 There is a risk to this based on the possibility of complete machine failure<br>

 in between synchronizations.  Hence, Hobbit may come up without all<br>

 the updates for hosts or alerts.  Based on my current model, I will lose <br>

about a day of historical data.  These synch rates can be changed and <br>

a gigabit crossover between machines cuts down on any traffic imposed <br>

by multiple synch's. <br>

<br>

</div>Note that you could very easily turn off the hobbit alerts with the same<br>

clustering software by truncating and restoring the hobbit-alerts.cfg file. <br>

Not sure how to disable the network tests, so that may require some<br>

custom coding... Once complete, you could use the same cluster<br>

resource sw to accomplish a 'hot' standby. <br>

<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Depending on host count and test count, this might be a bad idea -- but we've only got about 300 entries in bb-hosts.

<br><br>So -- thanks ever so much, again, for providing this -- it will make my<br>life ever so much easier next month when I get the time to automate the<br>failover environment.<br><br>Tom<br><br>Tom Kauffman<br>NIBCO, Inc

<br><br>To unsubscribe from the hobbit list, send an e-mail to<br><a href="mailto:hobbit-unsubscribe@hswn.dk">hobbit-unsubscribe@hswn.dk</a><br><br></blockquote></div><br>