On Fri, Jul 01, 2005 at 08:18:25PM +0200, krimo wrote:
Purcocks, Graham a écrit :
Whats the output from
Ipvsadm?
Here is the output of ipvsadm command:
TCP 10.16.0.44:www rr
-> 10.16.0.41:www Route 1 0 0
It seems to be OK no? (I'm testing only with one real server at the moment)
There are a number of different things that have to take place for
your load balanced connection to be successful. And LVS-DR is the most
tricky in regards to this.
1. You need to make sure that packets for the VIP arrive on the
Linux director and are treated as packets that need local delivery.
This typically means adding the VIP to an interface on the Linux
director, and surpressing ARP advertisments for the VIP from other
hosts (only needed for LVS-DR).
2. You need to make sure that once packets are forwarded by LVS,
the real server can handle them. For LVS-DR, this usually
means establishing the VIP on the lo interface of the real
servers and surpressing arp advertisments of the VIP.
3. You need to make sure return packets make it back to the
end-user. For LVS-NAT this means making sure the return path for
packets goes through the Linux Director. For LVS-DR it means
making sure that the don't.
Unfortunately you are stuck at 1. It doesn't matter that you haven't
handled ARP on the real servers because the VIP isn't there. And that
doesn't matter, because packets aren't being forwarded to the real
servers at all.
Assuming that you don't have some crazy iptables or policy routing foo
going on, if the VIP belongs to the Linux Director, and your LVS table
looks like the above, the packets should get intercepted by LVS and sent
to 10.16.0.41. You should see the active or in-active connection count
increment (one of the trailing two 0's above). Your connection might
not succeede, but in this case your problem would lie in 2 or 3.
The one caveat to all of this is, that with LVS-DR, unless you do
something really special, neither the linux director can act as clients
of the VIP. In both cases connection will, go to the local process, if
there is one. I suspect that you are connecting to the cluster from the
linux director, try a host that is neither the linux director, nor a
real server. It can either be the same network (this wouldn't work for
LVS-NAT) as linux director or a different network that has access to the
VIP.
