|
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..
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!
|
