<html>
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 10 (filtered)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:blue;
text-decoration:underline;}
span.EmailStyle18
{font-family:Arial;
color:navy;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=EN-US link=blue vlink=blue>
<div class=Section1>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>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.</span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'> </span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>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 *<b><span style='font-weight:bold'>don’t</span></b>*
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.</span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'> </span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Tom</span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'> </span></font></p>
<p class=MsoNormal style='margin-left:.5in'><font size=2 face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma'>-----Original Message-----<br>
<b><span style='font-weight:bold'>From:</span></b> Brian Lynch
[mailto:brianlynch@gmail.com] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Tuesday, May 10, 2005 2:22
AM<br>
<b><span style='font-weight:bold'>To:</span></b> hobbit@hswn.dk<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [hobbit] Some thoughts
on clustered hobbit</span></font></p>
<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>
<div>
<div>
<p class=MsoNormal style='margin-right:0in;margin-bottom:12.0pt;margin-left:
.5in'><font size=3 face="Times New Roman"><span style='font-size:12.0pt'><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. </span></font></p>
</div>
<p class=MsoNormal style='margin-right:0in;margin-bottom:12.0pt;margin-left:
.5in'><font size=3 face="Times New Roman"><span style='font-size:12.0pt'>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. </span></font></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'> </span></font></p>
</div>
</body>
</html>