|
Here is our situation:
We have a network block of public ip's that range from x.x.x.128 to
x.x.x.159.
We are wanting to setup LVS-TUN so we can distribute the load of our
website between two machines.
Which the first machine, the director, is going to be a local node.
gargamel: running with kernel 2.4.12, IP = x.x.x.155, running ipvsadm
software.
smurfette: running with kernel 2.4.5, IP = x.x.x.147
Both machines have been patched with linux-2.4.5-ipvs-0.8.1.patch.gz and
hidden-2_4_5-1_diff.
The first way we set it up was this:
Director Setup
gargamel# /sbin/ipvsadm -A -t x.x.x.155:80 -s wlc
gargamel# /sbin/ipvsadm -a -t x.x.x.155:80 -r 127.0.0.1 -i -w 1
gargamel# /sbin/ipvsadm -a -t x.x.x.155:80 -r x.x.x.147 -i -w 1
gargamel# echo 1 > /proc/sys/net/ipv4/ip_forward
gargamel# /sbin/insmod ipip
gargamel# /sbin/ifconfig tunl0 x.x.x.155 netmask 255.255.255.224 broadcast
x.x.x.155 up
gargamel# /sbin/route add -host x.x.x.155 dev tunl0
gargamel# echo 1 > /proc/sys/net/ipv4/conf/all/hidden
gargamel# echo 1 > /proc/sys/net/ipv4/conf/tunl0/hidden
Real Server Setup
smurfette# echo 1 > /proc/sys/net/ipv4/ip_forward
smurfette# /sbin/insmod ipip
smurfette# /sbin/ifconfig tunl0 x.x.x.147 netmask 255.255.255.224 broadcast
x.x.x.147 up
smurfette# /sbin/route add -host x.x.x.147 dev tunl0
smurfette# echo 1 > /proc/sys/net/ipv4/conf/all/hidden
smurfette# echo 1 > /proc/sys/net/ipv4/conf/tunl0/hidden
With this we have not been able to get either machine to pass back a web
page.
The way we think it works, is that the director receives a packet on
x.x.x.155:80, and schedules the packet for either itself or smurfette. At
that point we're not certain if LVS will encapsulate the packet itself and
then deliver to x.x.x.147, or if it will want to use an IP-tunneling
interface that we've already set up. One of the reasons we suspect that LVS
doesn't do the encapsulation step internally is because we haven't seen
anywhere that tells LVS if it is running in TUN or NAT mode, so we're
assuming that those distinctions are in the environment setup, and do not
affect LVS's internal operations. We're also not certain how such an
interface works, our background with ifconfig is limited to configuring an
ethernet adapter for more than one IP :(. We're not even sure how we'll
convince Smurfette to decapsulate the incoming packets.
One of the biggest reasons that we can't just tinker and figure these
things out for ourselves is that when the director isn't talking to the
realservers, we don't have a way to diagnose where the problem is (or if
it's the tunnel, whats the matter with it). I don't think we can set up
tcpdump to identify encapsulated packets for instance.
So I guess that outlines where our situation is. If anybody help us down
the path to enlightenment, it would greatly be appreciated :)
Jess and Jim
bend.com
|
