From: Paul Vixie (no email)
Date: Mon Jun 04 2007 - 10:32:02 EDT
> It depends on the length of those TCP sockets. If you were load-balancing
> the increasingly common video-over-http, it would be very unacceptable.
yes. i believe i said that my preferred approach works really well with UDP
and marginally well with current WWW. video over http is an example of an
application who wouldn't like its ECMP recalced many times per month (which
is the worst case; my actual experience is less-than-once-per-month.)
> ... The limits are anywhere from just 6 ECMP routes to 32 (though of course
> you could do staggered load-balancing using multiple CEF devices). I'm open
> to correction on the 32, but it's the highest I've yet come accross.
this is the more interesting scaling limit. i know of a company with ~150
recursive name servers all answering at the same IP address. ECMP won't help
at that level. i believe that even a hardware load balancer would have to be
multistage at that level, but once you've got multiple levels then the Powered
Boxes aren't Extra any more and i wouldn't prefer an ECMP design.
> ... This *is* possible with many load-balancers (plug: Including Apache's
> own load-balancing proxy), but with OSPF I'm forced to drop *all* sessions
> to the cluster 20 times (or yes I could do 10 nodes at a time, but you get
> the picture).
yes.
> I *like* OSPF ECMP load-balancing, it's *great*, and I use it in production,
> even load-balancing a tonne of https traffic, but in my opinion you are
> over-stating its abilities. It is not close to the capabilities of a good
> intelligent load-balancer. It is however extremely cost-effective and good
> enough for a lot of usage, as long as it's taken with some operational and
> engineering considerations.
or if, as in my case, the primary app is UDP based. your points are well
taken in the case of large scale TCP though.
|
|
|