Load Balancers for Linux?

scales asks: "We currently use the Dispatcher component of IBM's WebSphere Edge Server as a load balancer on some Red Hat boxes where I work, and the boss has asked me to look into OSS alternatives. I've already been pointed at Linux Virtual Server and Ultra Monkey, and I was wondering if any readers have had any experience with these packages, or had any opinions they could offer about other products." Ask Slashdot last visited a similar topic way back in 1999, so I think it might be time for an update.

Comments

Ever had your load balancer fail?

[Neck_of_the_Woods]

If so did you call support? Who are you going to call if it is OSS? Make sure what ever you pick has at least some kind of level of support if this is a mission critical web farm. The last thing you want to have is a 24/7 web farm down and a manager standing behind you screaming.

No matter what anyone else here says, make sure you have support for this thing unless you are the one the wrote it, or it is just not that important to you to keep it up 24/7.

Re:Ever had your load balancer fail?

[Alethes]

No matter what anyone else here says...

That's rather disingenuous of you, actually, to basically assume that your thoughts on this subject should take precident before all others. In response, I would say that there are many more avenues for support in an OSS solution than would exist with a proprietary application.

1) groups.google.com is an infinitely valuable resource.

2) The Linux Documentation Project maintains a searchable list of man pages, HOWTOs and other documentation.

3) Just about every OSS application in existence maintains mailing lists for developers and users alike for you to be able to receive and provide support for that particular application.

4) There are many consulting companies and individuals out there that provide support on an as-needed basis should you be unable to find your answer elsewhere.

The fact remains, that with an OSS solution, many more people (including developers on the project) are likely to have a better understanding of the application that are willing and able to provide knowledgable support just because of its openness, if that's, indeed, what you want. You may not actually be able to use the phone, but instead, you can send an email to a group of people that are actually passionate about the application, instead of trying to get help from poeple who either don't care, can't understand the application as well as the designers, or who are there to get their $10/hour for a few hours before they go home to finish their homework. When my boss is breathing down my neck about a problem, I'd much rather let him know I'm discussing the issue with one of the guys that designed the application rather than a highschool kid that reads a script to meet his inbound call quota.

Re:Ever had your load balancer fail?

[gengee]

That's terrible advice. Do you really want to to be on the phone with a Level I tech while your entire website is down? If a service is truly critical to you, and you're basing your decision on the speed of support, you've done something wrong in the design of your network.

A much better solution would be to make everything redundant and failover automatically.

Re:Ever had your load balancer fail?

[unixbob]

I'd have to agree with this. Having used one of the big names in load balancing and having dealt with their support, my experience is that they are not quick and they are not responsive and my project is slipping because they don't understand their product well enough.

The problem with support is that you assume because you are paying a lot of money to the company who created the product that whomever you contact in that organisation knows the product inside out and can answer your problem instaneously.

The truth of the matter is that they are unlikely to understand you environment, and are likely to waste the first 30 minutes going through a set of basic questions which you have already tried anyway. It is a fallacy that telephone support is quicker because you are dependant on the skill and experience of the person you are calling. More specifically you are dependant on their skill and experience with the particular product you are calling about (no one is an expert on everything) and you are then subsequently dependant on the knowledge of other team members in the same room or the quality of the knowledge base that the support engineer is typing your problem into.

If you ever had to ring up support for the worlds number one database vendor you would recognise this situation as they tell you they are typing your details into the system to see how other people with the same problem resolved it.

It won't give your manager the same warm feeling of comfort but OSS and Google is just quicker and easier to support. As long as you choose a well supported project.

Re:Ever had your load balancer fail?

[Anonymous Coward]

That's why you use more than one load balancer. Little thing we like to call 'fault tolerance'. BTW, the linux virtual server rocks. The only thing I've seen that works better are the load balancers that NetScalar builds. They're FreeBSD boxes with a load balancing application that also off-loads the TCP connections, allowing your webservers to better utilize their memory, saving CPU cycles and extra network overhead.

Re:Try OpenMosix!

[justanyone]

I believe an OpenMosix cluster CAN help load balance and thus scale an Apache web farm. Follow my logic here: If your web application is serving very heavy requests, you can very easily be CPU bound, not IO bound (disk IO or comms IO). Take for example a web app that queries a database, grabs a large complex result set, parses the results, and creates a graph or PDF file, and thus takes 15 seconds at 100% cpu per request. On a normal Apache server, two simultaneous requests take 30 seconds and no one is happy (bigtime!).

On an openMosix cluster, the first heavy request uses all local CPU. The primary box (the only one running Apache) spawns a new process for the second, 3rd, 4th, etc. requests, which migrate automatically. They use the available custer CPU power, run to completion, migrate back, and the results returned as if the box was just very fast.

I've written several CPU bound web apps; they made me nervous about timeout (I had limited optimization possibilities). I could have solved this worry with openMosix had it been available then.

Please don't get me wrong, Joe Batt (and Thanks! to "benjamindees Alter Relationship"), this cluster concept will be entirely useless serving thousands of static HTML page requests. It wouldn't help a single bit. But with fewer, heavyweight requests, it could solve the problem rather simply.

OpenMosix seems to be an ideal solution where programming time is limited and CPU needs are large (fat requests). If programming time is less limited, you could do the standard 3-tier architecture of a web, application, and database layer. You would then need to build in a one-to-many web-to-application-server architecture, so the app servers did the CPU and returned results to the web server. This method needs much more programming than my openMosix simple solution. If I was architecting Sears.com (I helped there a bit on back-end stuff), I would do 3-tier with a specialized load balancer where I had a support agreement with Quality-of-Service guarantees and liability insurance.

But, if I was serving in-house queries of subsets of what-if scenarios from a data warehouse in PDF format, I'd probably want to use openMosix since the rest of the project would be so complex I'd want to cut down on complexity if at all possible.

Another workaround would be to move the CPU requirements from Server to Client, running a big Java app on the browser box to farm out computing power. Hmmm. This would also require Java programmers, which are fewer in number, expensive, and add a completely new layer to my design. Ug. This approach limits me - I could't cache results, and I could blame their CPU's for the delay. But, Java already adds overhead (and thus time), and I don't know if the libraries are there for everything I want to do (granted Java has lots of libraries but it's not omnipotent). No, I like OpenMosix better here, too.

Further, since adding more CPU is a simple matter of adding another box with a minimum of disk (or network boot), my project costs come way down even if all 14 VPs love my app and spend every morning from 7:30 to 9 running scenarios, I don't have to explain what "CPU Bound" means to them.

OpenMosix is at OpenMosix.org.