<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On May 10, 2005, at 3:21 AM, Brian Lynch wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><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<BR>together and allowing Henrik to distribute it! I've a lot of experience<BR>with IBM's HACMP for AIX, and getting a clustered configuration working<BR>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<BR>'BBDISPLAY'. On failover it will take over the IP address for the hobbit<BR>display and re-launch hobbit with network testing and alerting enabled. </BLOCKQUOTE><DIV><BR></DIV></DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV>Software exists to do this active/passive, a search for HA or FAILOVER will the Linux-HA project is one example.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I biggest issue in my view is keeping the systems in sync and is often done with a shared storage.</DIV><DIV><BR><BLOCKQUOTE type="cite"><DIV><DIV> 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> <BR></DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>So I think the only issue you have with this method is that you don't want the extra network load. If you are willing to require a cross-over cable, and that is a requirement for most HA solutions, then one solution might be to add the idea of a BACKUP_BBDISPLAY.  The BBDISPLAY server would forward all incoming messages to the BACKUP and if you have the private network cable it would not cause any load on your network. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>You would also need a way of telling the Hobbit software on the system that is it the BACKUP server. </DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>John</DIV><DIV><BR class="khtml-block-placeholder"></DIV></DIV></BODY></HTML>