LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: multiple fallbacks?

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: multiple fallbacks?
From: Horms <horms@xxxxxxxxxxxx>
Date: Wed, 16 Oct 2002 19:12:29 +0900
On Wed, Oct 02, 2002 at 05:04:07PM -0700, Tim Lynch wrote:
> i've browsed through the archives a bit, but i haven't found an answer...
> 
> such thing as multiple fallbacks? on my setup, rh7.3 and heartbeat 0.4.9,
> the single fallback is the last defined fallback
> 
> like others i'm balancing a webapp. i need loooong persistence for http and
> https, so i'm using fwmk.
> i use a `deep' health check that tests a real server's visibility of the
> backend database. works great; the health check covers a lot of ground and
> detects a wide range of possible failures. from reading the archives this
> seems to be a popular topic, and i recommend crafting a cgi that allows the
> real server to expose it's health in this way.
> 
> also instead of monkeying (haha) around with the loopback interface on the
> real servers, i used this on the real servers to get them to accept the
> virtual ip:
> iptables -t nat -A PREROUTING -d virtualip -j REDIRECT
> which is not my own brilliance, but rather someone else mentioned it on some
> list somewhere. is there something wrong with that, it was too easy, versus
> ipforwarding (big no-no, multihomed to backend), hidden device, etc..

Personally I like that method of doing things too (after all, someone
who is not me named it Horms' method :). However, it doesn't always work
as the source address of reply packets may be set to the IP address of
the interface that the packet was sent out of, rather than virtualip.
Clearly this is not good.

This behaviour seems to be consistent across the 2.4 kernels.  However,
while playing around with red hat (read heavily patched) kernels
recently, I noticed that the iptables REDIRECT behaviour was the reverse
of what I described above. That is the replay packets had the source IP
address set as virtualip.

I didn't investigate this thorougly, but I suspect that Red Hat is
adding a patch to give this behaviour - which was the way things worked
in 2.2 kernels.

If someone has isolated this patch it would be a good addition
to the linuxvirtualserver.org web page.

> ideally i would like some recursive action where the fallback is again a
> virtual, so that a virtual fallback will be balanced and health checked
> among various real fallbacks. i tried this: webapp virtual is fwmk 1,
> fallback is fallbackip on the ipvs host.  virtual fwmk1 has a fallback that
> is fallbackip, virtual fallbackip has some real servers. well it doesn't
> work..
> 
> virtual=1
>         real=63.211.143.117:0 gate
>         real=63.211.143.118:0 gate
>         fallback=63.211.143.115:8088
>         service=http
>         checkport=80
>         checktype=6
>         request="ping/ping.php"
>         receive="connected..hello"
>         scheduler=wlc
>         persistent=7200
>         netmask=255.255.255.255
>         protocol=fwm
> 
> virtual=63.211.143.115:8088
>         real=63.211.143.117:8088 gate
>         real=63.211.143.118:8088 gate
>         service=http
>         checkport=80
>         checktype=connect
>         scheduler=wlc
>         protocol=tcp
> 
> okay i know, get the latest from CVS!

I am pretty sure that won't work as you are setting a virtual service as
the real server for another virtual service. This is really a special
case and I am pretty sure that the LVS kernel code doesn't (shouldn't)
handle this.

However, it would be possible to achive what you want to do by modifying
ldirectord. You would need to allow it to have multiple fallback
statements _and_ make sure that it checks the health of the
failbackservers.

The latest (and of course best) version of ldirector can 
be found in the heartbeat cvs tree.

http://cvs.linux-ha.org/viewcvs/viewcvs.cgi/linux-ha/ldirectord/


Please send any patches either to this list, or directly to me.

Thanks

-- 
Horms
        


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