|
thanks for the replies.
yeah i didn't think it would work to have a virtual as a fallback - if the
fallback is added to the pool, it would seem to mean reentrance of ipvs.
good to note the RH mystery patch and 2.4 vs 2.2 source addr selection
behavior. it seems to work so i'll just keep my fingers crossed. i would
guess that ip would decide the source addr if the app had specified wildcard
on the socket, and i think the way i'm running apache and tux the sockets
are explicit. but i don't know; it does work ;)
so muliple fallback:
since the webapp is none too savvy at detecting it's own failure, i am
forced to rely on another way to throw a nice error page when the app is
failed. i use a cgi health check to expose this to ldirectord. but w/o
modification ldirectord supports only one fallback. the fallback reals just
serve out a nice error for any uri. i feel the problem with one fallback is
not cpu or memory or bandwidth but rather max sockets.
it seems another approach is to use weighting, to add fallback reals with
weight 1 and raise the webapp reals to maxweight-1. the fallback reals (now
realserver, not fallback in ldirectord conf) will always succeed health
check and will always be in the pool, but as long as the webapp reals
succeed health check they will be directed traffic using wlc. i've used this
type of weighting scheme on a hardware load balancer solution, as perscribed
by vendor. can anyone comment on this idea with LVS?
----- Original Message -----
From: "Horms" <horms@xxxxxxxxxxxx>
To: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, October 16, 2002 3:12 AM
Subject: Re: multiple fallbacks?
: 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
:
:
: _______________________________________________
: LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
: Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
: or go to http://www.in-addr.de/mailman/listinfo/lvs-users
:
|
