|
At 02:58 PM 9/10/2001 +0200, you wrote:
>Hello Don,
>
>> NAT is not -bad-. The additional latencies are mostly irrelevant. The only
>> real issue is the sheer number of packets being handled by the network
>> interfaces (as pointed out by Joe already).
>
>Which can lead to extremely bad performance issues when having a lot
>of small packet requests (which they most of the time are)
>
>> All of the major commercial load balancers (Radware WSD, F5 BigIP, Alteon 180
>> series and Cisco LocalDirector) are NAT boxes. They work just fine. They also
>
>Cisco knows the triangulation more which can be looked at as the LVS_DR
>method.
>
>> all have optional gigabit interfaces. I worked at a company that was handling
>> 30mil pages/day (~4 megabytes/sec average outbound traffic) on 10 Sun 220Rs
>> behind Alteons. NAT was definately -not- an issue.
>
>Because NAT is handled in the RISC processors. OTOH, try NAT and sticky bit
>set on the Alteon ACEdirector3 and watch huge latencies in server takeout
>and packet dropping. The Cisco had a bug where approximately 10% of all packets
>weren't NAT under high traffic load (I cannot confirm this on the gigabit
>ones).
>
>> As far as I'm concerned, DR and TUN are nice toys, but not very useful. They
>> don't offer signicant advantages over NAT (in most applications) and they
>> require too much special handling to manage. I can see TUN -seeming to- have
>> an advantage in being able to balance across different datacenters, but
>> that's largely offset by the single point of failure. I.e., if the datacenter
>> where the directors reside goes offline, all the clusters distributed to
>> other datacenters won't be getting any traffic anyway, unless you change the
>> DNS to point to another director in the other datacenter. In which case, the
>> F5 3DNS, which does metrics, would be a better solution than tunneling.
>
>Agreed, but always with the deployed network architecture in mind.
>
>> DR also seems to offer an advantage, but the packets are coming in through a
>> router and switch. The return packets may be bypassing the director, but they
>> are almost certainly going back out through the same switch and router. The
>> difference added by having the outbound packet headers re-written by the
>> director isn't enough to justify the added complexity of the system.
>
>I intend to disagree on that one considering the fact that you can use
>one load balancer cluster to load balance for example 24 zones with 24
>NICs when using LVS_DR. This you cannot do with LVS_NAT because of interrupt
>latencies caused by interefering network drivers trying to jump into
>the network BH for NAT. For high performance and cheap & reliable solutions
>for datacenters, you don't have the choice.
>
>> The only real reason to even use DR is if the number of packets in/out
>> exceeds what a gigabit connection can handle. But at what point does that
>
>Or my case described above.
>
>> happen? I've personally seen a cluster of ~140 real-servers behind an F5
>> BigIP with gigabit interfaces that was handling > 20 megabytes/sec sustained
Do you know F5 BigIP is just a PC, used to be PII400 processor running
BSDI? What those commercial load balancer can do better than LVS just
the marketing propaganda from those "commercial" company, since they
have share holder's money to burn. If someone trying to sell those products
in this LVS discussion group, it will not help the sales.
>> outbound traffic, most of which was small packets. I don't know how many
>> pages/day this was, but I can probably safely assume that it was about 5
>> times the system that I used to manage, so I can guess that it was somewhere
>> around 150 million pages/day. This was with NAT, and with a lot of special
>> packet handling scripts due to the complex multi-tier configuration of the
>> cluster, and yet the site was very fast. NAT was not an problem.
>
>Thanks for this report. Can you tell me how long a request usually would
>be sustained? I assume you have dynamically generated pages. So if the
>db queries take very long, you might have a problem with NAT before having
>one with DR :)
>
>> I think that the HOWTO does a good job of pointing out the advantages of DR
>> and TUN, but it tends to give people the impression that they are superior
>> and that NAT is inferior, which it really isn't. DR and TUN are handy -if you
>> need them-. Do you need them? Probably not.
>
>Good point for the howto. Indeed, with nowadays Internet technology and
>computer technology we should not give the reader the impression that as
>soon as he wants to load balance a moderately surfed site he needs to
>choose LVS_DR.
>
>Thank you,
>Roberto Nibali, ratz
>
>--
>mailto: `echo NrOatSz@xxxxxxxxx | sed 's/[NOSPAM]//g'`
>
>_______________________________________________
>LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
>Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
>or go to http://www.in-addr.de/mailman/listinfo/lvs-users
|
