I'd like to hear about your setup...<br><br><br><div class="gmail_quote">On Mon, May 19, 2008 at 4:03 AM, Iain Miller <<a href="mailto:iainonthemove@gmail.com">iainonthemove@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Phil,<br>
<br>
I know you said you don't want to use a HA/clustering solution, but I<br>
have a similar situation to yourself and I use a HA solution with<br>
heartbeat/drbd and being honest it saves me a load of hassle.  OK the<br>
failover fails automatically and I don't know that it has (which I'd<br>
argue is how I want it) but all the rrd files are kept in sync and all<br>
maintenance settings get maintained across the two servers.  Plus I<br>
don't need to recall which server was down and which server I need to<br>
rsync from and to - DRBD resource maintains all that for me and I just<br>
worry about configuring hobbit.  Plus as hobbit is only running on the<br>
active server, it's the only one sending out alerts.<br>
<br>
I can give you more details on my configuration if you are interested.<br>
<br>
Cheers,<br>
<br>
Iain.<br>
<br>
2008/5/19 Phil Wild <<a href="mailto:philwild@gmail.com">philwild@gmail.com</a>>:<br>
<div><div></div><div class="Wj3C7c">> Hi all,<br>
><br>
> I am redesigning the method we use for performing a failover to a disaster<br>
> recovery installation of hobbit. I am interested in opinions on the approach<br>
> and any shortcomings.<br>
><br>
> Note: This is not HA/clustering, it is for DR purposes.<br>
><br>
> We are aiming to have:<br>
><br>
> a production hobbit deployment<br>
> a DR hobbit deployment<br>
><br>
> clients will be configured to send metrics to both servers. which will keep<br>
> historical rrd data up to date etc.<br>
><br>
> The production server will be configured to send out alerts. The dr server<br>
> will not.<br>
><br>
> At regular intervals, rsync will be used to synchronise data from the<br>
> production server to the dr server, including the in memory checkpoint file.<br>
><br>
> In the event of a dr, the dr hobbit server will be promoted to active by<br>
> restarting hobbit, and loading the checkpoint and alert configurations.<br>
><br>
> I am expecting that this will ensure that the dr server will be "up to date"<br>
> with proudction as per the last checkpoint. This includes tests that have<br>
> been disabled or acknowledged.<br>
><br>
> Prior to failback to the production hobbit installation, the reverse of the<br>
> above would be performed.<br>
> An rsync of rrd data files would be performed to cover any windows where one<br>
> of the servers was offline for a period of time.<br>
><br>
> Is there anything wrong with this approach?<br>
><br>
> Cheers<br>
><br>
> Phil<br>
><br>
><br>
> --<br>
> Tel: 0400 466 952<br>
> Fax: 0433 123 226<br>
> email: philwild AT <a href="http://gmail.com" target="_blank">gmail.com</a><br>
<br>
<br>
<br>
</div></div><font color="#888888">--<br>
Iain Miller<br>
<a href="mailto:iainonthemove@gmail.com">iainonthemove@gmail.com</a><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>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Stewart<br><br>The revolution will not be televised.<br>The revolution will be no re-run brothers;<br>The revolution will be live.