Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am trying to decide between using a layer 4 load balancing solution for my datacenter or a layer 7 solution. Unfortunately (for my sanity, that is), my use case is simple enough that both solutions would work well, avoiding most of the weaknesses and not really utilizing the strengths on the other. Whatever solution we end up using, it has to have high availablity and high throughput. But we are only planning to use it to load balance over a cluster of web servers, none of which have any requirements for "sticky" session management (cookie or IP), complex rewrite rules - or, for that matter, any rewrite rules at all.

The load balancers will be connected to two switches, both with an independent connection up to the datacenter aggregation layer and merged together using Rapid Spanning Tree and whatever proprietary protocol that the switches use for virtualizing. The load balancers will also be cross-linked to each other over a crossover cable. All of the servers in the cluster are connected to both switches. All that the load balancers have to do is point the traffic over them.

Since it's just HTTP, I can use a layer 7 load balancing solution like HAProxy or nginx. But I could also use the LVS project with ldirectord or keepalived or whatever.

I've tried to break up the pros and cons as I see them, but it just ends up in a wash. What would you recommend and why? Am I missing something?

share|improve this question

3 Answers 3

up vote 5 down vote accepted

One useful benefit of "L7" like haproxy is being able to use cookies to keep the same browser hitting the same backend server. This make debugging client hits much easier.

L4 balancing may bounce a single user around on several backend servers. (which in certain cases may be advantageous, but in a debugging/profiling sense, using "L7" is much more valuable.)

EDIT: There's also a potential speed advantage of using HTTP balancing. With keep-alives clients can establish a single TCP session to your balancer and then send many HITs without needing to re-establish new TCP sessions (3-way handshake). Similarly many LBs maintain keep-alive sessions to back end systems removing the need to do the same handshake on the back end.

Strict TCP load balancing may not accomplish both of these as easily.

/* FWIW: I wouldn't say "L7" or "L4", I would say HTTP or TCP. But I'm a stickler for avoiding using the OSI to describe things it doesn't match up with well. */

I think fundamentally if you're not sure what to deploy, go with what feels simple and natural to you. Test it (use apache bench?) and make sure it works for your needs. To me HTTP LB is more natural.

share|improve this answer
    
Stickiness, cookie based or IP based, is certainly an advantage of L7 switching. But it's not one that our application would be able to particularly make use of. –  Scrivener Feb 9 '11 at 17:22
    
Wouldn't one disadvantage of HTTP level load balancing be that you would have to have a TCP level load balancer in front of the HTTP balancers to enable the failover between the two? –  Scrivener Feb 9 '11 at 18:05
    
@Scrivener - you shouldn't, no. round-robin DNS can take care of that I believe, unless I'm misunderstanding your question. –  mfinni Feb 9 '11 at 18:19
    
@mfinni: The global geographic DNS will be able to point to one IP per datacenter. I need something to respond to that IP. –  Scrivener Feb 9 '11 at 18:43
    
I see. Well, it depends on the capabilities of your device(s). You can probably find a L7-capable device that can work in pairs with a single cluster VIP that wouldn't require a hardware TCP/IP load-balancer. If IIS and MS Windows NLB can do it, I imagine most other commercial products can do it. –  mfinni Feb 9 '11 at 18:47

Given the lack of advantage to you from doing L7 balancing, I'd settle on L4 balancing instead. I'm a big fan of keeping it as simple as possible, without sacrificing too much.

L7 requires the balancers to inspect the http headers in the packets that are going through them for appropriate routing, adding additional overhead and a marginal increase in latency for the end user. It seems a pointless expense to me if you'll gain nothing by it.

share|improve this answer

Some DNS providers have simple failover functionality. You've mentioned what your requirements are not and not what they are, but if all you need is round robin with failover if something's down, then you could use e.g. zoneedit.com's Failover. Depending on your HA needs that may be good enough and you get to skip a whole tier in your architecture.

share|improve this answer
    
I wish it was that simple - we need something more like round-robin with fail-over, plus geographic separation. All of that is not in the question, however, because it's being done by an outside company. –  Scrivener Feb 9 '11 at 18:04
    
What do you mean - I guess I mean DNS being done by an outside company too, and some of them support both geo-load balancing and failover as a DNS service - or you mean there's some additional third party between you and the DNS provider, or that you just don't have direct say over the DNS? –  Ernest Mueller Feb 9 '11 at 18:42
    
The former - we're already doing DNS with an outside company that's doing failover and geographic load balancing to the different datacenters. I just need to load balance it inside the datacenter. –  Scrivener Feb 9 '11 at 18:49
    
You can use the same round robin for server by server on the front end, right? DNS for round robin load balancing is often used for a single data center; multiple geolocations is a big boy requirement atop that. –  Ernest Mueller Feb 10 '11 at 5:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.