|
Hello,
On Tue, 2 Jan 2001, ratz wrote:
> Hi,
>
> > > In Apache http.conf we can specify a LISTEN port and run a separate
> > > daemon for HTTPS on port 443 for example. If this https daemon or daemons
> > > dies, or fails to start (because we have it configured to prompt for our
> > > security certificate password at startup) we wouldn't want to make
> > > assumptions about the health of the daemons listening on port 80 right?
>
> IMHO you have three possibilities to overcome the INADDR_ANY bind problem:
>
> 1.) configure the application to listen to localhost as normal and to a VIP
> only for healthchecking.
> 2.) ipchains is your friend, man! Do an ipchains -A input -j REDIRECT for
> packets
> coming from the DIP with destination VIP. You redirect it to the loopback
> and get your response. You may even first mark the incoming packet and
> redirect it accordingly.
Hm, is there an easy way to send packets with saddr=DIP and
daddr=VIP and they to leave the director ignoring the ip rule:
0: from all lookup local
and the route from the local table:
local VIP dev eth0 proto kernel scope host src VIP
May be with VIP defined not in "local" table using
ip rule add prio 100 iif eth0 table 100
ip route add table 100 local VIP dev lo
But I'm not sure if these rules will help. May be there is no way,
such packets are always delivered locally when daddr=local_address.
At least, the replies from the real server will be treated as source
martians in the director.
Of course, there is no problem in the real server to accept
and reply to packets with daddr=VIP and saddr=DIP
> 3.) Write a user space daemon maybe even with tcpd support that listens to a
> unused port and does the check locally and sends 0 if ok and 1 if nok.
Something like this, get the weight from RS:
#! /bin/sh
jiffies=100
function cpuidle() {
sed -n "s/^cpu .* \([0-9]*\).*/\1/p" /proc/stat
}
a="`cpuidle`"
sleep 1
b="`cpuidle`"
c="$[($b-$a)*100/$jiffies]"
[ $c -gt 100 ] && c="100"
echo $c
Don't use this in production. The returned value is not correct
when the RS is loaded.
>
> pros: It's working and it's cool.
> cons: the solutions are not 100% cross-compatible. f.e [1] will work on all
> nodes, [2] only on unices that either have support for ipchains or ipfw
> and [3] finally needs some coder and is the hardest to maintain.
>
> > Yes, even when we have one httpd for two domains may be we want to
> > check different cgi or database calls with L7 HTTP checks. But the L4
> > check can be one, of course, configured from the user: bind to 0.0.0.0:80.
>
> The healthcheck is based on the VIP and not on the RIP, so as long as we
> don't have L7 support in LVS this is not an issue since for every new service
> needs a new VIP.
>
> > > Many thanks to Alexandre Cassen for the great contribution... I plan to
> > > test it further in the lab ASAP.
>
> Me too. I hope Julian and Alexandre can merge their work.
I have some things ready for CVS:
- resource information for Linux 2.2/2.4
- indepenent lvs.o module to access LVS via setsockopt, for 2.2,
soon for 2.4 too
- expression processor, needs to be extended to generate pseudo code
for faster calcs
> Regards,
> Roberto Nibali, ratz
Regards
--
Julian Anastasov <ja@xxxxxx>
|
