Layer 4 vs Layer 7 Load Balancing

Question

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?

Solution 1

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.

Solution 2

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.

Comments

[Scrivener]

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]

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]

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?

[mfinni]

@Scrivener - you shouldn't, no. round-robin DNS can take care of that I believe, unless I'm misunderstanding your question.

[Ernest Mueller]

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?

[Scrivener]

@mfinni: The global geographic DNS will be able to point to one IP per datacenter. I need something to respond to that IP.

[mfinni]

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.

[Scrivener]

I can do it with LVS. But then I'm using a L4 load balancer in front of an L7 load balancer instead of just using the L4 load balancer in the first place....

[Scrivener]

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.

[mfinni]

As I said, there is clustering technology that doesn't require additional hardware. If you're going to use HAproxy and LVS, why not build them on the same hardware?

[Scrivener]

Thank you for your advice. I'll go with what I know best. I'm just glad I didn't lose sight of any major things. I was going up the wall, sure that I was missing something.

[Ernest Mueller]

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.

[Makotosan]

With an advanced Layer 7 load balancer, you can also monitor the servers and automatically take out a server if for example a page returns a status 500. It can also cache resources, and offload encryption.

[Adam Thompson]

Don't L4 load balancers offer sticky sesions as well? In this case based on TCP attributes (e.g. IP address) but isn't it just as useful as relying on cookies at L7 level?