Hello,
[Maybe we should discuss this in private, it doesn't have a lot to do
with kernel development anymore.]
> Because when you have to deal with thousands of session per second, NAT is
> really a pain in the ass. When you have to consider security, NAT is a pain
Not with a HW LB, and with a SW LB (LVS-NAT) you can very well sustain
20000 NAT'd load balanced connections with 5 minutes of stickyness
(persistency) with 1GB RAM and a PIII Tualatin with 512 kb L2 cache. I'm
not sure if you meant this when mentioning pain.
> too because it makes end to end tracking much more difficult when you deal with
> multiple proxy levels. And last but not least, there are protocols that don't
Security mustn't rely on the LB with such a high volume traffic service.
You need a carefully designed firewall framework. At least in the setups
I've been dealing with LBs (a couple dozen) this was the case. Load
balancing a service with multiple proxies doing NAT certainly imposes an
additional problem when doing proper end-to-end healthchecking, but is
nothing that couldn't be solved or would be extremely difficult.
> like NAT. Simply think about a farm of FTP servers. It's really easy to
> load-balance internet clients on it with redirection (call it as you like) using
> a hash algorithm. NAT would be more difficult.
I agree completely with this one. Don't get me wrong, I also most of the
time deploy a LB using the redirection method.
> I personnaly suggested and used both NAT and redirection at a big customer's
> site. NAT was there only to be compatible with broken systems that would never
> handle redirection right, in the event we would have to use them. But at the
HP/UX < 11i is such an example of horribly broken system. It can still
be solved with direct routing (redirection, triangulation) but you need
additional NICs.
> moment it's already the first source of architectural problems.
Best regards,
Roberto Nibali, ratz
-- echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Dec 07 2002 - 22:00:31 EST