|
Hi,
As the original author of the patch, it saddens me to say this, but
Vinnie is absolutely correct. I never received a satisfactory answer to
why the patch was never incorporated into the main LVS code.
I have posted several reasons for this in the past, some of which I can
list again here:
a) It's not part of a load balancer to do security.
b) If we start using the crappy netfilter state table we end up being
unnecessary slow for absolutely _no_ added value whatsoever. I have
shown that it is possible to fill up the conntrack table with bogus
packets in the current implementation. This is the biggest show
stopper and I would never accept it to be part of LVS.
c) It will most probably not work with the tcp connection tracking patch
which is about to be commited finally.
d) I'm still not so sure if the patch works with LVS-{DR,NAT,TUN}
e) The amount of changes that are still committed to the connection
tracking part to date are intimidating concerning the fact that
netfilter has been developed over the past 3 years!!
f) Lot's of duplicated work (regarding netfilter) will be needed to
support things like rate estimation schedulers because there is no
proper pps/bps counter callback in the nfnetlink infrastructure, hell
they still haven't finished the whole nfnetlink stuff.
That said I would certainly not oppose to having it a compile time
option for LVS. If Julian can make the code coexist friendly next to the
existing tracking table I do not care at all. And to recite again, speed
and "no added value" are the two most important points for me not to
include this patch. Besides, I cannot imagine that maintaining the patch
is too much of work.
It is not a large patch. Excluding comments, assertions, debugging
printk()s etc., it adds about 10 lines of real code to the kernel
itself, and about 50 lines to LVS for the main functionality. FTP
handling adds about another 75 lines.
Some of it was duplicated the last time I looked.
Also, I tried to explain very carefully exactly what it did and why.
This was the purpose of the README I sent in. So the keeper of the
official code would not have been 'blindly' incorporating a bunch of
random code.
That is not the point, your documentation was indeed very good. It's the
concept that doesn't work ;).
We gave it as much testing as we could at Antefacto, and Vinnie has been
using it successfully. I believe it's a stable piece of code.
I've asked a person in the past if he'd done tests regarding speed and
conntrack table fill-ups. The person said that they never had planned
for such a high throughput. I, however, do load balance 50-70 Mbit/s on
each of the 12-16 interfaces of my load balancer in different zones.
Ever saw the connection tracking table search crawl with such numbers?
It's simply not acceptable.
It seems there's enough of a demand for this functionality, so I'll ask
the maintainers: why are you reluctant to incorporate this patch into
the main codebase?
See above.
What's happening now was inevitable really. I cannot really keep the
patch up-to-date. It's unreasonable to expect Vinnie to take on the
maintainership. For somebody fairly familiar with the codebase, I would
guess it should be less than a day's work to produce a new patch. I
Correct.
don't have the time or equipment here to set up a development
environment, but I'm happy to answer questions as best I can if somebody
wants to take on the job. If another couple of kernel or LVS releases
Thanks.
go by without updating the code, it'll become much more difficult to do,
and in all probability the functionality will be lost. I think that
would be a shame, not just because I wrote it :-) but because it seems
useful and wanted.
Thank you for your work. I'm sure someone will keep it up to date. Even
if multiple releases pass by, it should still be feasable for a kernel
hacker to update your patch, so don't worry ;).
Best regards,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
| 