I've used them all fairly heavily, except the Foundry gear. Alteon's my personal fave. Biggest problem with the F5: hard drive. In my book, that means you instantly need two, doubling the price.
Same thing with the Cisco CSS. Even without a hard drive, you should have 2 of them anyway. How do you plan to do software upgrades or other certain types of maintenance without an outage if you don't have a second one? I've seen them flake out too, either by not passing traffic or by load balancing getting messed up somehow. In most of these situations, a failover to the standby unit fixed the problem (this was with F5 gear). -jay
Using outboard appliances for "server load balancing" is unnecessary, and it adds more powered boxes (thus decreasing theoretical reliability). If your upstream router can speak OSPF and is made by either Cisco or Juniper then it will implement ECMP (equal cost multipath). If you put your "service address" on lo0 as an alias, and you run Zebra or GateD on the "service hosts" which possess that alias address, then each such host will appear to be a router toward the service address as a "stub host" and your upstream routers will dtrt wrt flow hashing for udp or tcp traffic (that is, the udp/tcp port number will figure into the hash function, so you won't multipath your tcp sessions.) This is how f-root has worked for years. Look ma, no appliances. -- Paul Vixie
If you go out and spend a few thousand you can also get Allied Telesyn L2-L4 products that now support Load Balancing. Actually the rapier 24i is about $2000 Canadian. (I'd have to check the VAR pricing) Jason On 6 Aug 2003 at 22:59, Paul Vixie wrote:
Using outboard appliances for "server load balancing" is unnecessary, and it adds more powered boxes (thus decreasing theoretical reliability).
If your upstream router can speak OSPF and is made by either Cisco or Juniper then it will implement ECMP (equal cost multipath). If you put your "service address" on lo0 as an alias, and you run Zebra or GateD on the "service hosts" which possess that alias address, then each such host will appear to be a router toward the service address as a "stub host" and your upstream routers will dtrt wrt flow hashing for udp or tcp traffic (that is, the udp/tcp port number will figure into the hash function, so you won't multipath your tcp sessions.)
This is how f-root has worked for years. Look ma, no appliances. -- Paul Vixie
jason@ifuture.com ("Jason Robertson") writes:
If you go out and spend a few thousand you can also get Allied Telesyn L2-L4 products that now support Load Balancing. Actually the rapier 24i is about $2000 Canadian. (I'd have to check the VAR pricing)
how much would i have to pay to not have that extra powered box between my data and my customers? oh, i forgot, it's zero, isn't it? re:
Using outboard appliances for "server load balancing" is unnecessary, and it adds more powered boxes (thus decreasing theoretical reliability).
If your upstream router can speak OSPF and is made by either Cisco or Juniper then it will implement ECMP (equal cost multipath). If you put your "service address" on lo0 as an alias, and you run Zebra or GateD on the "service hosts" which possess that alias address, then each such host will appear to be a router toward the service address as a "stub host" and your upstream routers will dtrt wrt flow hashing for udp or tcp traffic (that is, the udp/tcp port number will figure into the hash function, so you won't multipath your tcp sessions.)
This is how f-root has worked for years. Look ma, no appliances. -- Paul Vixie
On 7 Aug 2003, Paul Vixie wrote: > > If you go out and spend a few thousand you can also get Allied Telesyn > > L2-L4 products that now support Load Balancing. Actually the rapier > > 24i is about $2000 Canadian. (I'd have to check the VAR pricing) > > how much would i have to pay to not have that extra powered box between > my data and my customers? > oh, i forgot, it's zero, isn't it? Yup, ah've allus been a mite suspicious of products fo' which the competitive upgrade is a patch-cord. -Bill
On Thu Aug 07, 2003 at 12:14:43AM -0700, Bill Woodcock wrote:
On 7 Aug 2003, Paul Vixie wrote: > > If you go out and spend a few thousand you can also get Allied Telesyn > > L2-L4 products that now support Load Balancing. Actually the rapier > > 24i is about $2000 Canadian. (I'd have to check the VAR pricing) > > how much would i have to pay to not have that extra powered box between > my data and my customers? > oh, i forgot, it's zero, isn't it?
Yup, ah've allus been a mite suspicious of products fo' which the competitive upgrade is a patch-cord.
Likewise. I have a bit of a dislike of putting a single "port 80 terminating" box in front of the 10's of servers I've just put into the webfarm. I've built all this redundancy into the server side of things, and then I have to funnel all the port 80 traffic through a single box (well, 2 for redundancy). We currently use DNS load-balancing for both global and local loadbalancing, and it works well, apart from not being able to immediately drop a box out of load-balance. The gated solution sounds interesting, but doesn't automatically have the feedback loop of stopping advertising itself when apache stops responding, but the box is still up (which is a fairly common occurence in our Apache2 testing). Simon -- Simon Lockhart | Tel: +44 (0)1628 407720 (x37720) | Si fractum Technology Manager | Fax: +44 (0)1628 407701 (x37701) | non sit, noli BBC Internet Services | Email: Simon.Lockhart@bbc.co.uk | id reficere BBC Technology, Maiden House, Vanwall Road, Maidenhead. SL6 4UB. UK
> The gated solution sounds interesting, but doesn't automatically have the > feedback loop of stopping advertising itself when apache stops responding, > but the box is still up (which is a fairly common occurence in our Apache2 > testing). Most folks tie Big Brother or Netsaint or just an expect script into the loop, and withdraw the advertisement and sound an alarm when a service is offline. -Bill
--On 07 August 2003 08:29 +0100 Simon Lockhart <simonl@rd.bbc.co.uk> wrote:
The gated solution sounds interesting, but doesn't automatically have the feedback loop of stopping advertising itself when apache stops responding, but the box is still up (which is a fairly common occurrence in our Apache2 testing).
It seems like a fairly trivial hack to put together a script which polls HTTP requests to port 80 and drops the loopback service address if it is consistently failing. Then you've just got your BGP convergence time and unequal load balancing effects to worry about. Whilst I'm not knocking Paul's solution in an application like running a root NS for which it is perfect, I'm not so sure it's necessarily best for every kind of service load balancing. I've used both the route hack based and commercial NAT load balancers, and they both have their place. Commercial NAT based load balancers are able to do things like distribute requests according to actual measured server response characteristics. This is great if you have clusters of servers with different specs but want to extract the best performance under peak load from the whole cluster. It also helps if you are running complex services where individual servers can develop a pathological slow but not failing response for some reason. They are also able to do the kind of service polling as above and react quicker to a down server than one which relies on routing protocols. Neither of the above are much advantage if you are running a cluster of BIND servers who's performance is equal and deterministic and where dropping a proportion of requests for a second or two if a server ever dies is no big deal. If you are running complex web services (think expensive per server sw licences etc) then the investment in a pair of redundant load balancers for the front end to give more consistent performance under load as well as resilience can look very sane indeed. -- Rob.
Rob Pickering said:
I've used both the route hack based and commercial NAT load balancers, and they both have their place.
Yes, one size does not fit all.
Commercial NAT based load balancers are able to do things like distribute requests according to actual measured server response characteristics. This is great if you have clusters of servers with different specs but want to extract the best performance under peak load from the whole cluster. It also helps if you are running complex services where individual servers can develop a pathological slow but not failing response for some reason.
They are also able to do the kind of service polling as above and react quicker to a down server than one which relies on routing protocols.
Quite true. A product not mentioned in previous posts would be the Radware WSD, which has been great for my applications. See it at www.radware.com These come in distrubted flavors too. Also not mentioned previously would be the Netscaler, www.netscaler.com
If you are running complex web services (think expensive per server sw licences etc) then the investment in a pair of redundant load balancers for the front end to give more consistent performance under load as well as resilience can look very sane indeed.
Oh, yes. They make a lot of sense in large streaming environments. -John
On Thursday, 7 August 2003, at 07:28AM, Rob Pickering wrote:
Then you've just got your BGP convergence time and unequal load balancing effects to worry about.
Whilst I'm not knocking Paul's solution in an application like running a root NS for which it is perfect, I'm not so sure it's necessarily best for every kind of service load balancing.
We're using the technique Paul used in local clusters with OSPF; the convergence time in an OSPF area which contains only a small number of server and a couple of routers in a single area is pretty small. There's no BGP convergence issue in this application (there's no BGP within the server cluster). We're using another anycast technique in the wide area, using BGP to advertise covering supernets for services which are offered autonomously in multiple locations. BGP is involved in this one, but we are mitigating the potential for flap damage or transient convergence loops by offering service from remote nodes to a local community only, and not the whole Internet (i.e. the service supernet is offered as a peering route, with restricted propagation, and not for global transit). The general approach we're taking with the wide-area, global service distribution technique is described here: http://www.isc.org/tn/isc-tn-2003-1.html http://www.isc.org/tn/isc-tn-2003-1.txt
I've used both the route hack based and commercial NAT load balancers, and they both have their place.
It's not really that much of a hack; it's just anycast over an IGP coupled with routers which can populate the FIB with multiple equal-cost routes with different next-hops, with some manner of flow hash to keep traffic from a s single session pointing at the same server.
If you are running complex web services (think expensive per server sw licences etc) then the investment in a pair of redundant load balancers for the front end to give more consistent performance under load as well as resilience can look very sane indeed.
I've deployed services behind foundry layer-4/layer-7/content/SLB/buzzword-du-jour switches before, and they worked very well; from the brief time I spent with them, they seemed well-designed and feature rich. However, the foundries still suffered from the (near) single point of failure problem. It only takes one person to mess up the switch config whilst modifying a service or adding a new one, or a firmware upgrade that goes bad, and you lose all your services at once. As Paul mentioned, the advantage of using local-scope anycast with an IGP to build a cluster is that there are no additional components, and hence no additional points of failure. Joe
participants (8)
-
Austad, Jay -
Bill Woodcock -
Jason Robertson -
Joe Abley -
John Ferriby -
Paul Vixie -
Rob Pickering -
Simon Lockhart