You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Klaus Wagner <kl...@it-austria.net> on 2006/08/07 13:48:15 UTC

Re: load balancer "cluster" set

> Load balancing really belongs at the network layer.
depends on your needs
> 
> IBM released free load-balancing software for linux and windows about
> 1997.  My former employer's integration group (about 3 people) got a
> fully redundant implementation running (on 4 pcs) in about 4 months.
ack
> 
> The company abandoned the free s/w version for hardware implementations
> on Cisco gear (and others) within about 6 months.  I'm sure the price
> for proprietary hardware has dropped substantially since then.

disagree the price is still at the same level (just the releases went 
up)

I also disagree when it comes to the point of Cisco has the perfect LB
solution. In fact they have not. The problem is not the distribution,
which is not able to provide a Load distribution in means of spreading
EQUAL load on some servers because

a) most applications need application stickyness
b) neither round robin nor other implementations manage to keep equal
load on servers because they can't measure the SERVERS load

But again problems are elsewhere. There are quite some methods
to provide stickyness. All fail in some kinds of uses. They can't watch
cookies 100% correctly and if they are told to introduce their own, they
mess up the protocol. IP stickyness has issues when upstream proxies are
used in a balanced way.

Finally ssl stickyness is not working correctly too (which is generally
a bad idea anyway).

But there is a solution: lose your capeablity of handling ssl and source
that out to cisco appliances completely.

Finally to clean up with myths: The loadbalancing in ciscos LBs is NOT
done in hardware. In fact they use multi purpose CPUs to do LB
decisions. Only when it comes to plain routing, that happens in
hardware.

On the other hand ... to be nice to cisco ... they have done a great job
to keep this thing stable. Servers crash far more often than these
appliances. And they have done a great job in means of failover from one
lb to another because they use routing protocols to announce the active
lb way faster that taking up an ip address on a server and starting a
software lb.

so ... there are reasons to use appliances and there are reasons not to
use them (flexible balancing, application layer stickyness, and so on)

regards klaus


Re: load balancer "cluster" set

Posted by Guy Hulbert <gw...@eol.ca>.
[ I had given up this thread but since I started it ... ]

Apart from minor details I agree with this comment anyway.

On Mon, 2006-07-08 at 13:48 +0200, Klaus Wagner wrote:
<snip>
> > on Cisco gear (and others) within about 6 months.  I'm sure the price
> > for proprietary hardware has dropped substantially since then.
> 
> disagree the price is still at the same level (just the releases went 
> up)

What do you mean "disagree" (this is a case of fact rather than opinion
--- i might be wrong but it's pointless to "disagree").  

The price in 1997 for a Local Director or PiX (h/w was same at that
time) was about $40K.  Either it's still at that level or not.  IIRC,
the Pix, at least, has come down quite a bit ... but there has been more
competition in firewalls than in load balancers so you may be right.

<snip>
> Finally to clean up with myths: The loadbalancing in ciscos LBs is NOT
> done in hardware. In fact they use multi purpose CPUs to do LB
<snip>

What "myths"?  Whether you call it h/w or s/w is semantics.

The LD and PiX used OTS h/w (Ppro, PC mobo) in 1997 (i opened one).  The
interesting piece was a proprietary daughter board but AFAIK, that ran
Cisco's own O/S (which, i understand, is derived from some version of
BSD).  I think they've merged all the functionality in s/w and any use
of non-OTS h/w is more likely for energy efficiency and cost than
performance.

I understood (5+ years ago) that Cisco was moving in the direction of
providing Pix functionality on their routers ... but speculation is
pointless ... I'm sure all the info is on their site.

--gh