active-active only works with kernel 2.4.26?

[Roberto Nibali]

>>> 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