|
http://www.ultramonkey.org/papers/active_active/active_active.shtml
Downloaded and printed, will read this weekend. Although, if Horms
engineers something it's most likely flying anyway. So I just have to
understand how he cheated the TCP stack this time :). I see some
netfilter related stuff in it and I wonder if (from what I've seen)
his approach works for 2.6.x kernels with proper TCP state tracking,
TSO and USO? In 2.4.x where netfilter is mostly broken with regard to
TCP state tracking, such quirks might be possible.
It is only active-active for the linux-directors, and its not really
supposed to be active-active for a given connection, just for a given
virtual service. So different connections for the same virtual service
may be handled by different linux-directors.
I've read it now and I must say that you've pulled a nice trick :). I
can envision that this technique works very well in the range of 1-2
Gbit/s for up to 4 or so directors. For higher throughput netfilter and
the time delta between saru updating the quorum and the effective rule
being in place synchronised on all nodes might exceed the packet arrival
interval. We/I could do a calculation if you're interested, based on
packet size and arrival on n-Gbit/s switched network.
The real trick, is that it isn't a trick at all. LVS doesn't terminate
connections, it just forwards packets like a router. So it needs to
Yep.
know very little about the state of TCP (or other) connections. In fact,
all it really needs to know is already handled by the ipvs_sync code,
and that mainly just a matter of association connections with real
servers. Or in other words, the tuple enduser:port,virtual:port,real:port.
This is true, however you're setting rules for ESTABLISHED in your code
to accept packets by lookup of the netfilter connection tracking and
while the kernel 2.4 does not care much about window size and other TCP
related settings, 2.6 will simply drop the in-flight TCP connection that
is suddenly sent to a new host. There are two solutions to overcome this
problem for 2.6 kernel. One is fiddling ip_conntrack_tcp_be_liberal,
ip_conntrack_tcp_loose and sometimes ip_conntrack_tcp_max_retrans and
the other is checking out Pablo's work on netfilter connection tracking
synchronisation.
Cheers mate,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
|
