On Fri, 14 Jul 2000, Paul Lussier wrote:
> Yeah, the Kimberlite stuff is far more robust.
>
> Heartbeat pretty much depends upon ethernet pinging, which, if you have an I/O
> problem and the primary system doesn't respind to the passive, the passive
> may try to take over, even though the primary isn't really dead. In that
> scenario you end up with 2 systems telling the router that they are the the
> same IP address.
>
> Kimberlite has 3 "hearbeat" mechanisms:
>
> serial line
> ethernet
> shared scsi disk
>
> It is entirely possible that your network I/O can be lost, but your disk I/O
> not be. In this case the failover knows the primary is still alive and to
> leave it alone to deal with it's ethernet I/O problem.
I agree with Paul that kimberlite is more robust, but I'm prejudiced
because our company wrote/maintains it. I would highly recommend it.
But, last I'd been paying attention, heartbeat does allow heartbeat over
serial and ethernet simultaneously, and Alan (Robertson) was thinking
about adding other methods. It's true that shared SCSI is not supported
by heartbeat, but that probably doesn't matter much in a firewall scenario
since you're not concerned about shared storage.
It's also true that heartbeat doesn't (currently) do STONITH, but in a
firewall situation, I personally think it's unlikely that this is a worry
since all of the work the firewall is doing is in the kernel, and mostly
in the TCP/IP stack, so the likelyhood of a component hanging the kernel
for a short period of time seems relatively low... if the Node dies, it's
probably dead, and there won't be data inconsistencies, since there's no
shared data, so there's no need to Shoot the Node In The Head.
All that said, Kimberlite has more nice stuff... it has a cool
command-line configuration tool, as well as a configuration checking
script to make sure stuff is working properly, and even a web-based GUI!
Last I checked, heartbeat had none of this stuff.
Give kimberlite a try! Get it at
http://oss.missioncriticallinux.com
:)
--
Derek Martin
System Administrator
Mission Critical Linux
[EMAIL PROTECTED]
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
