|
On Mon, Nov 13, 2006 at 10:09:52AM +0100, Roberto Nibali wrote:
> >>>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.
I'm not sure how far it would scale, but something like what you
mention above is what I had in mind at the time.
>
> >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.
That makes sense. To be honest I haven't looked into what diffuculties
2.6 would pose. In any case, using netfilter (and heartbeat for that
matter) was really just a convenience. It may be better to implement
things an entirely different way.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
|
