RE: Internal virtual IP failure scenario

"Bryn Moslow" <[email protected]>
Newsgroups gmane.linux.highavailability.ultramonkey
Message-ID <BC2A76AABABF8741A8ADEE62DB1350F8015EB87A@exchange2.valvesoftware.com>
Thanks, yes I am pinging the router on the public IP side for ipfail in
my setup. I was hoping to not need to use a Real Server as a ping test.
If the Real Server dies, I believed this would simply result in
ldirectord taking the unreachable Real Server out of the equation but no
fail over. Is this correct, or will the setup be smart enough to see
that the inactive Director is able to reach the Real Server in question
and trigger a fail over?

It just struck me squarely between the eyeballs that I guess I can fire
the cluster back up and test this on my own. "Duh" for lack of a better
expression...

Maybe this would be a good/better use of ping_group as well, just adding
the list of Real Servers there.

-----Original Message-----
From: Horms [mailto:[email protected]] 
Sent: Monday, July 03, 2006 3:25 AM
To: [email protected]
Cc: Bryn Moslow
Subject: Re: Internal virtual IP failure scenario

Bryn Moslow  wrote:
> [-- text/plain, encoding quoted-printable, charset: us-ascii, 37 lines
--]
> 
> Using the diagram at
> http://www.ultramonkey.org/3/topologies/ha-lb-eg.html for reference I
> seem to have run into a failure scenario that doesn't have an elegant
> solution.
> 
> I've set up a 4 machine cluster almost identical to the diagram and it
> works wonderfully except if I pull the cable that would be connected
to
> the 192.168.7.2 (or 192.168.7.3) interface in the example. If this
> interface loses connection there is no failover to the slave. I'm
> guessing this is for lack of a ping test to the Real Server network?
(I
> *am* using a ping test on the External Virtual IP interface to the
> gateway.)

Are you using ipfail in your heartbeat setup, it should be the elegant
solution to this problem.

http://www.ultramonkey.org/3/ipfail.html

-- 
Horms                                           
H: http://www.vergenet.net/~horms/          W:
http://www.valinux.co.jp/en/



-- 
Ultra Monkey - http://www.ultramonkey.org/
To UNSUBSCRIBE, email to [email protected], with a body:
unsubscribe ultramonkey-users [email protected]
where "[email protected]" is YOUR email address.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.