On Mon, May 16, 2011 at 6:37 PM, William Cooper <wcooper02@gmail.com> wrote:

S/W vs H/W is really a question rooted in performance and feature needs vs cost... weigh your options carefully.

Load balancers are _both_ hardware and software. There's really no such thing as a load balancer solution that is just hardware or one that's just software (aka Firmware); it does not exist -- real load balancers are both hardware and software. And all software has bugs; some of which might (some day) disrupt the intended operation. There are packaged solutions that are integrated hardware and software sold as a product. There are do-it-yourself solutions that are off-the-shelf hardware, and software of your choice, including open source options on commodity hardware, that require manual selection of the software programs used to facilitate load balancing functions, and maintain them in case of exceptions, hardware failures, or other unexpected exceptions. Both packaged and custom built have their own advantages and disadvantages, there are tradeoffs, and no universal best; they both meet different sets of requirements. Devices packaged by a load balancer manufacturer; usually have things like user interfaces, instruction manuals, configuration guidance, and warranty/support for the entire device, both hardware and software. In addition, the whole thing is tested by the manufacturers as one product, and there may be specially integrated hardware functions supported by the load balancer, that are not found in commodity hardware (e.g. specialized crypto processors for RSA/AES/SSL acceleration, ASICs, etc). The manufacturer's work to deliver their product comes at a high price, so taking a do-it-yourself with open source software will have much lower prices paid to the vendor: instead of paying a manufacturer for a product. Except, if you actually went through the same effort as the manufacturer of the product, it might be more expensive than buying the product, so chances are you will do less, and have a less refined result. Building a load balancer with cheap hardware and open source software, puts you in the manufacturer's seat. This provides a huge amount of flexibility, but also adds complexity, and gives you a lot of choices about what software to put in the box, and how to set up each package. Your engineering team may need a great deal of familiarity with both the software and hardware, and a lot of patience to achieve performance equivalent to an integrated unit. Your exact choices of software and package versions for load balancing or high availability, might (or might not) have been tested by someone with a similar scenario, on similar hardware. In case something goes wrong, you won't be getting a replacement unit overnighted in by the manufacturer, ready to plug in and load a 5kb config. You have only the troubleshooting and configuration guidance you yourself developed, before/during use of that, so if an unexpected condition arises, chances are you won't have as much guidance for troubleshooting or likely causes, as a vendor would. Requiring different procedures for dealing with a failure or malfunctioning of the load balancing. In case you do have hardware/software support, for a commodity hardware solution, you may find your vendors pointing fingers at one another. -- -JH

On Tue, 2011-05-17 at 11:03 -0600, Michael Loftis wrote:

On Mon, May 16, 2011 at 5:15 PM, Welch, Bryan <Bryan.Welch@arrisi.com> wrote:

...

Greetings all.

I've been tasked with comparing the use of open source load balancing software against commercially available off the shelf hardware such as F5, which is what we currently use. We use the load balancers for traditional load balancing, full proxy for http/ssl traffic, ssl termination and certificate management, ssl and http header manipulation, nat, high availability of the physical hardware and stateful failover of the tcp sessions. These units will be placed at the customer prem supporting our applications and services and we'll need to support them accordingly.

Now my "knee jerk" reaction to this is that it's a really bad idea. It is the heart and soul of our data center network after all. However, once I started to think about it I realized that I hadn't had any real experience with this solution beyond tinkering with it at home and reading about it in years past.

Can anyone offer any operational insight and real world experiences with these solutions?

Honestly I think to get *all* those features you're much better off with commercial solutions like the ones you're already using from F5, or something from Cisco, Coyote Point, Brocade, or others. You can absolutely put together a solution based on any number of open source products, but you won't get the single integrated front end for management and configuration that any of the commercial options will provide, you may be missing features, and ultimately, you're on the hook for making it work. In particular the stateful failover has been problematic in open source solutions in my experience. They've come a VERY long way, but it is a hard problem to tackle.

+1. I think the list of features covers more than just one FOSS project. Whilst I've had no end of good experiences using LVS (as some others have mentioned), I wouldn't expect it to do all that is requested in the original post. At least, not by itself.

I've worked with open source and commercial solutions, and while the open source systems were almost always far more flexible, and cheaper up front, they certainly required more work to get going.. Once setup and running though both types of solutions had pretty equal amounts of maintenance, with the commercial solutions requiring somewhat less time/babysitting for upgrades and to enable or use new features or functionality.

I worry far more about upgrades to proprietary appliances (where it's often the whole system image), than I do about a few package updates on a Linux machine (followed by a service restart, or two). But still, pretty well worded. :) Tom

In message <BANLkTimxkNx5=__jXD9056FAO19V1zoKqg@mail.gmail.com>, Michael Loftis writes:

...

Greetings all.

I've been tasked with comparing the use of open source load balancing sof= tware against commercially available off the shelf hardware such as F5, whi= ch is what we currently use. =A0We use the load balancers for traditional l= oad balancing, full proxy for http/ssl traffic, ssl termination and certifi= cate management, ssl and http header manipulation, nat, high availability o= f the physical hardware and stateful failover of the tcp sessions. =A0These= units will be placed at the customer prem supporting our applications and = services and we'll need to support them accordingly.

Now my "knee jerk" reaction to this is that it's a really bad idea. =A0It= is the heart and soul of our data center network after all. =A0However, on= ce I started to think about it I realized that I hadn't had any real experi= ence with this solution beyond tinkering with it at home and reading about = it in years past.

Can anyone offer any operational insight and real world experiences with =

On Mon, May 16, 2011 at 5:15 PM, Welch, Bryan <Bryan.Welch@arrisi.com> wrot= e: these solutions?

Honestly I think to get *all* those features you're much better off with commercial solutions like the ones you're already using from F5, or something from Cisco, Coyote Point, Brocade, or others. You can absolutely put together a solution based on any number of open source products, but you won't get the single integrated front end for management and configuration that any of the commercial options will provide, you may be missing features, and ultimately, you're on the hook for making it work. In particular the stateful failover has been problematic in open source solutions in my experience. They've come a VERY long way, but it is a hard problem to tackle.

I've worked with open source and commercial solutions, and while the open source systems were almost always far more flexible, and cheaper up front, they certainly required more work to get going.. Once setup and running though both types of solutions had pretty equal amounts of maintenance, with the commercial solutions requiring somewhat less time/babysitting for upgrades and to enable or use new features or functionality.

Just make sure the DNS components return valid responses to AAAA queries as well as valid responses to A queries. Many load balancers get this wrong. They return NXDOMAIN instead of NOERROR, they drop AAAA queries, they don't return CNAMEs when the A response returns a CNAME, they return the wrong SOA record (doesn't match the zone delegated to the box). Better still would be for them to return AAAA records but until one is ready to do that the negative responses need to be correct. If they are returning AAAA queries check NS, SOA, TXT and MX responses for similar errors. AAAA is just more visible as browsers make AAAA queries and the others are done in the background. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On Tue, May 17, 2011 at 11:57 AM, LaDerrick H. <nanog@lacutt.com> wrote:

On Mon, May 16, 2011 at 04:15:45PM -0700, Welch, Bryan wrote:

...

Greetings all.

I've been tasked with comparing the use of open source load balancing software against commercially available off the shelf hardware such as F5, which is what we currently use.  We use the load balancers for traditional load balancing, full proxy for http/ssl traffic, ssl termination and certificate management, ssl and http header manipulation, nat, high availability of the physical hardware and stateful failover of the tcp sessions.  These units will be placed at the customer prem supporting our applications and services and we'll need to support them accordingly.

Now my "knee jerk" reaction to this is that it's a really bad idea.  It is the heart and soul of our data center network after all.  However, once I started to think about it I realized that I hadn't had any real experience with this solution beyond tinkering with it at home and reading about it in years past.

Can anyone offer any operational insight and real world experiences with these solutions?

I've used LVS and other Open Source solutions in the past.  As others have alluded to, these require knowledge and experience with the underlying OS and network stack that's often lacking in many organizations.  A good hybrid solution which implements all (I think) of your requirements is Zeus (http://www.zeus.com/)  It's a software solution which you can deploy on your own hardware.  It's been very solid in my experience.  You can deploy the software in a clustered configuration if needed, though I've only used it in an HA pair.

LaDerrick

...

TIA, replies off list are welcomed.

Regards,

Bryan

+1 for Zeus. Use it in our production network with great success. Magnitudes cheaper than a solution from F5, and doesn't hide the inner workings of the product if you want to do some things outside the scope of support. Zeus also does licensing just based on throughput, not arbitrary transactions per second like F5 does/did. If you're hardware can push the traffic, theres no limitations on the number of transactions or sessions. -- Brent Jones brent@servuhome.net

I've worked with everything over the years. BigIP, CSS, CSM, ACE (blows), NetScaler, say when. I've been thru a few RFPs and bake offs and also evaluated open source options. 1. If you are looking for simple round robin load balancing with decent load capabilities then there are several open source options in this thread that may work. As long as you understand that you are going to be expected to support them..... 2. If you are pushing features. SSL termination. Header rewrites. Payload inspection (NetScaler does application firewalling on the same appliance). Or other complexities and you are having to deal with enterprise traffic volume you might be better off with one of the big vendors. Applications these days are more and more complicated and a high end load balancer with a stable feature set can often rescue your AppDev team and make you a hero. Recommend: F5 and Citrix Netscaler. If you are looking to combine your L7 FW into your LB then you might lean towards NetScaler. If you are looking at seperating those duties you can look at F5. IRules (F5) are the bomb. -Hammer- "I was a normal American nerd." -Jack Herer On Wed, May 18, 2011 at 12:31 AM, matthew zeier <mrz@velvet.org> wrote:

I'll pile on here too - there's very little of Mozilla's web infrastructure that isn't behind Zeus.

...

+1 for Zeus. Use it in our production network with great success. Magnitudes cheaper than a solution from F5, and doesn't hide the inner workings of the product if you want to do some things outside the scope of support.