Hi Phil,
I know you said you don't want to use a HA/clustering solution, but I
have a similar situation to yourself and I use a HA solution with
heartbeat/drbd and being honest it saves me a load of hassle. OK the
failover fails automatically and I don't know that it has (which I'd
argue is how I want it) but all the rrd files are kept in sync and all
maintenance settings get maintained across the two servers. Plus I
don't need to recall which server was down and which server I need to
rsync from and to - DRBD resource maintains all that for me and I just
worry about configuring hobbit. Plus as hobbit is only running on the
active server, it's the only one sending out alerts.
I can give you more details on my configuration if you are interested.
Cheers,
Iain.
2008/5/19 Phil Wild <user-e365c1418192@xymon.invalid>:
Hi all,
I am redesigning the method we use for performing a failover to a
disaster
recovery installation of hobbit. I am interested in opinions on the
approach
and any shortcomings.
Note: This is not HA/clustering, it is for DR purposes.
We are aiming to have:
a production hobbit deployment
a DR hobbit deployment
clients will be configured to send metrics to both servers. which will
keep
historical rrd data up to date etc.
The production server will be configured to send out alerts. The dr
server
will not.
At regular intervals, rsync will be used to synchronise data from the
production server to the dr server, including the in memory checkpoint
file.
In the event of a dr, the dr hobbit server will be promoted to active by
restarting hobbit, and loading the checkpoint and alert configurations.
I am expecting that this will ensure that the dr server will be "up to
date"
with proudction as per the last checkpoint. This includes tests that have
been disabled or acknowledged.
Prior to failback to the production hobbit installation, the reverse of
the
above would be performed.
An rsync of rrd data files would be performed to cover any windows where
one
of the servers was offline for a period of time.
Is there anything wrong with this approach?
Cheers
Phil
--
Tel: XXXX XXX XXX
Fax: XXXX XXX XXX
email: user-e365c1418192@xymon.invalid
--
Iain Miller
user-6f16c60bcd50@xymon.invalid