[mrtg] Re: MRTG High Availability

[Adam Crosby]

Backups are always good ;)
Depending on the amount of money you are willing to spend on the HA solution, you could probably invest in a SAN and 2 node 'cluster'.  Write a perl script that checks for a tag file on the shared SAN storage area, and then writes it's own 'tag' - have this script run on your two machines (have mrtg store it's configs, data, and output on the SAN, so it's machine independent) every minute or so, and if one of them discovers the other hasn't written to the 'tag' file, it starts up mrtg itself (say, copy /etc/crontab.mrtg /etc/crontab or something), and runs it until it can't connect to the SAN.  
This is how Novell does their failover clustering (they call it a 'split brain partition') - so it can be done ;)

------------------------------------------------
Adam Crosby
District Systems Engineer
Norfolk Public Schools
(757) 628-3450
------------------------------------------------

>>> tony bourke <tony at vegan.net> 04/24/02 06:24PM >>>

Another compelling story for the importance of trending data :)

MRTG is alot like database applications (well, I guess it is), similiar in
that it's easier to build up (adding more procs, RAM, ) than to build out
(adding more servers), as with typical web servers.  Because of this, you
may want to pursue the data integrity angle rather than the absolute
uptime angle, depending on your requirements.

Most of the time people are concerned more with data integrity with MRTG,
more than uptime.  To help this, regular backups (easy with MRTG, more
difficult with RRDTool) and/or a RAID array of some sort will allow you to
fairly quickly recover from any mishap or failure.

In this case, the worst that can happen is your machine completely dies
and you have to do a restore from backup, loosing a day or so of data,
depending on when your last backup would be.  Backups for MRTG would
generally be bery small, and easy to do every couple of hours if it's that
critical.

In the situations I've been in, I've been more apt to spend the time and
energy to make sure that nothing happens to the data rather than
concentrating on making it available 100% of the time.

With the various MRTG/RRDTool files/databases constantly being written to,
keeping that data in sync between two or more machines can be very tricky,
while just making sure it's on a RAID array and backups are run is
typically much easier while at the same time satisfying most data
integrity requirements.

Backups and RAID are usually my answer to MRTG High availability, but as I
said, your situation may be different.

Tony


On Tue, 23 Apr 2002, Jason Signalness
wrote:

>
> Hello,
>
> I've been working with MRTG for some time now, and we've come to rely on
> the output it produces.  I've now been asked to move MRTG from one
> server onto two for high-availability reasons.
>
> Basically, I'm wondering if anyone has developed any sort of setup
> involving failover.  i.e.: if one server running MRTG fails, another one
> takes up the slack.  If anyone has a suggestion, I'm all ears.
>
> Thanks,
>
>

-- 
-------------- -- ---- ---- --- - - - -  -  -- -  -  -  -   -     -
Tony Bourke				tony at vegan.net 






--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe 
Archive     http://www.ee.ethz.ch/~slist/mrtg 
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org 
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi 



--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi