On Tue, 28 Nov 2006, Olle Ö~Vstlund wrote:
1) LVS/DR is an exotic technique which somewhat violates the
network-protocols involved. In itself this does not have to be a
problem, but it is very likely we are executing kernel logic which has
not been used/tested much compared to the logic executed when receiving
NAT packets for example.
it's been very well tested and is the most often implemented
type of LVS setup. Admittedly having two machines handling
one connection requires some thinking about tcpip, but when
you consider the two machines as a black box, it functions
as a single box.
2) The director's ipvs connection-table gives a very bad picture of the
real world's connection-situation when using LVS/DR.
It's an estimate, usually within a factor of 2. Your setup
has problems, but we don't know what yet.
Our "conclusion" at this stage is that our kernels are leaking some
fundamental communication (tcp/ip?) primitives due to the "exotic" logic
executed when receiving LVS/DR-packets.
afraid so
We will most likely look into switching to LVS/NAT, which adhere better
to network protocols and which kernel-logic may be less exotic. Whether
it is more used/better tested I don't know? What do you think?
you want something that works. You don't care what the
problem is. If LVS-NAT works for you and LVS-DR doesn't,
then that's all that counts.
A question. Is it possible to use DR and NAT at the same time in the
same system? We will have to test LVS/NAT and I'd really like to do it
on our production platform (well, we only hav one LVS, and setting up
another one....well).
I'd hate to have to debug a working machine...
yes. Have the server on the realserver listen on the RIP
(for LVS-NAT) as well as the VIP (for LVS-DR). Then add a
set of LVS-NAT ipvsadm rules.
Joe
--
Joseph Mack NA3T EME(B,D), FM05lw North Carolina
jmack (at) wm7d (dot) net - azimuthal equidistant map
generator at http://www.wm7d.net/azproj.shtml
Homepage http://www.austintek.com/ It's GNU/Linux!
|