> can this be explained more? the balancer should open http requests, take
> out the cookies, parse them, and then send certain flags to a persistent
> real server?
Cookie-based persistence is where the load balancer reads the cookie
before handing an HTTP request off to a server. Often times it's required
that the same server handle an individual user's traffic, such as with a
In the past, the source IP has been used to diferentiate the users, but
with the AOL-mega proxy problem, it's possible 10,000 users can all come
from the same IP address. It's possible to have a situation where you
have 100 servers to handle 10,000 users, but with source IP-based
persistence, then all 10,000 users go to the same server.
Most of the installations I've dealt with would never consider a product
that didn't handle cookie-based persistence, even if they weren't using
that feature currently.
There are also other Layer 5-7 functions that are useful as well. Layer
5-7 can take a URL such as http://vegan.net/MRTG and send it to one group
of servers, while taking request for http://vegan.net/lb to another group.
This can be quite handy, although not widely implmemented at this point.
> > 4. Speed. F5 has spent a considerable amount of resources streamlining
> > their code from the looks of it, and the switch-based vendors have their
> > ASICs. All in all, the commerical products probably would be able to
> > handle quite a bit more traffic than the Linux stuff.
> there are plenty of reports of lvs outperforming f5.
> i could dig up a few...
> they might be on the web page somewhere too.
I'd like to see that. We've done some testing, but we havn't done
anything with lvs. I know F5 has spent quite a bit of resources on
optimization, as I'm sure the other PC-based load balancing vendors have.
> lvs allows for network balancing via nat, ip tunneling, or direct routing.
> it also has a variety of scheduling algorithms. dr is very efficient.
> it's the same sort of algorithm that ibm's netdispatcher first provided (i
> think someone just mentioned that on this list). balancer redirects
> packets to real servers without even rewriting the ip headers at all --
> return traffic bypasses the balancer completely and goes back out the next
> hop. basically infinitely scalable [up to the bandwidth of the network
> interfaces]. very fast. i've been told that f5 has been providing this
> sort of algorithm now as well, but i've never used it -- only its nat.
That's direct server return. Different vendors call it different things,
but it's direct server return. It requires setting up a special loopback
interface on the server, which works with most web servers, but may not
with other types of services.
> i think that has a lot to do with branding. ibm is a big name, cisco is a
> trustworthy name, so they must be good enough for us.
It's not just the name, Alteon, F5, and most of the other's have earned my
trust and respect over the years, in using them with high profile sites
and talking to other administrators using them (although horror stories
are quite common, load balancers get alot of blame)
> lvs is good enough for linux.com, sourceforge, themes.org, valinux,
Real.com is the only non-linux site I've ever heard of using lvs, so thats
another trust issue. I can name dozens of sites that use the various
commercial products, but none use lvs.
I think it's all about adoption, lvs is pretty new on the scene.
Companies that have embraced Linux as a platform still cringe at the
thought of using lvs as their load balancer. lvs still has alot to
proove. I suspect that will change as time goes by, but it's gotta earn a
rep and it's gotta do those Layer 5-7 features.
> but hey, lots of people don't like linux either. chuckle.
-------------- -- ---- ---- --- - - - - - -- - - - - - -
Tony Bourke tonyIZZATvegan.net
This archive was generated by hypermail 2b30 : Fri Feb 23 2001 - 00:20:33 EST