LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: LVS-DR where Directors are also Realservers

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: LVS-DR where Directors are also Realservers
From: Horms <horms@xxxxxxxxxxxx>
Date: Tue, 26 Aug 2003 17:08:20 +0900
On Thu, Aug 21, 2003 at 12:00:32PM -0700, ken price wrote:
> > I don't know much about Ultramonkey, but since Horms is skiing in
> > Australia and probably won't be reading this posting for a while,
> > I'll have a go for what it's worth.
> 
> vacation?!?!  the nerve!  horms should be fired.

Sorry about that, but I can assure you that the head cold / cabin
pressure changes combination on the flight home was penance for my
ways. 

I will try and skip to the chase :)

The discussion revolves around using LVS where Linux Directors are also
real servers. To complicate  matters more there are usually two such
Linux Directors that may be active or standby at any point in time, but
will be Real Servers as long as they are available.

An example of this can be found at
http://www.ultramonkey.org/2.0.1/topologies/sl-ha-lb-eg.html 
UltraMonkey uses LVS so this should be applicable to anyone else using LVS.

The key problem that I think you have is that unless you are using a
fwmark virtual service then the VIP on the _active_ Linux Director must
be on an interface that will answer ARP requests.

To complicate things, this setup really requires the use of LVS-DR and
thus, unless you use an iptables redirect of some sort, the VIP needs to
be on an interface that will not answer ARP on all the real servers.  In
this setup that means the stand-by Linux Director.

Thus when using this type of setup with the constraints outlined above,
when a Linux Director goes from strand-by to active then the VIP must go
from being on an interface that does not answer ARP to an interface that
does answer ARP. The opposite is true if a Linux Director goes from
being active to stand-by.

In the example on ultramonkey.org the fail-over is controlled by heartbeat
(as opposed to Keepalived which I believe you are using). As part of the
fail-over process heartbeat can move an interface from lo:0 to ethX:Y and
reverse this change as need be. This fits the requirement above.
Unfortunately I don't think that Keepalived does this, though I would
imagine that it would be trivial to implement.

Another option would be to change the hidden status of lo as fail-over
occurs. This should be easily scriptable.

There are some more options too: Use a fwmark service and be rid of your
VIP on an interface all together. Unfortunately this probably won't
solve your problem though, as you really need one VIP in there
somewhere. Or instead of using hidden interfaces just use an iptables
redirect rule. I have heard good reports of people getting this to work
on redhat kernels. I still haven't had time to chase up weather this
works on stock kernels or not (sorry, I know it has been a while).

http://marc.theaimsgroup.com/?l=linux-virtual-server&m=103612116901768&w=2

-- 
Horms
<Prev in Thread] Current Thread [Next in Thread>