Load balancing based on session cookie?

Question

I have a web app that is going to run on multiple servers. I'd like to make sure, that requests using the same session (HTTP cookie header with value JSESSIONID=x) always communicate with the same server. That is, until the session "moves" to a different server in certain circumstances (not only when the server fails, but also due to some server side caching and performance strategies).

My web app works well with that scenario, but what kind of load balancer should I use? Obviously, I could load balance on application level, but I'm looking for something more efficient. Maybe specialized hardware (maybe not)? I can't spend a lot of money...

Update

Thanks for your answers so far: I found out now, that Pound and HAProxy can be configured to look for certain cookies. I couldn't find out yet, if they also allow to update the mapping dynamically (when the session "moves" to a different app server)?

And are there (inexpensive) hardware solutions, which can do that, too? (Would that cost less than an extra load balancing server?)

Solution 1

I just read the article Making applications scalable with Load Balancing by the HAProxy author Willy Tarreau, and it contains all the answers I needed.

Here's my personal summary of what I learnt:

• "Cookie learning" and "Cookie insertion" seem to be usual features of load balancers.
• You need a level 7 load balancer to inspect cookies, but some hardware load balancers "approximate" this on the packet level (which sometimes even leads to corrupted data!)
• Other level 7 load balancers use a full TCP/IP stack, and work correctly, but they require much more processing power. In that case, a server with a strong CPU might be faster than a hardware load balancer (?)

The article is from 2006, some things may have changed since.

Solution 2

Using "sticky (persistent) sessions" is generally not advised. If you do this, you lose a lot of the benefits of load balancing. The load will not be balanced and you will lose high availability, as certain clients will be unable to access your application in case of failure.

You want your session to be dynamic. With Java, it's typically stored in memory and clustered to all servers via multicast. More commonly, the session will be stored in a database.

If your Web application requires sticky sessions, your architecture may need improvements.

As far as load balancer solutions, there are many out there and the subject has been covered extensively here. I like LVS. Others like nginx. Foundry Networks, which was acquired by Brocade, makes some solid commercial products. They're the main commercial solution for hardware load balancers. Barracuda also has a Linux/OSS-based "appliance" that can be used for Load Balancing.

Solution 3

Before to spend money....take a look of software open source load balancer like Pound or HAProxy.

I agree with suggestions of Warner and Stu.

Solution 4

A couple of solutions for you then.

Write a session storage method that uses a database to store session information and if its on multiple servers you could cluster the db. It really depends on how you're deciding to organise things and other idea is to use a server with memcache on behind the webservers and store the sessions in there.

That way you have sessions in a single place and it no longer matters which web server the client is directed to.

View more solutions

Comments

[Franklin Yu]

(note to myself) I was searching for the same thing and didn't know it's called "sticky session". Commercial load-balancing solutions seem to provide this as service, such as AWS ELB. GCE has Session affinity which is similar but not quite the same thing (for example, it does not roam for mobile client).

[user3745402]

My app has some very special characteristics, that make this kind of approach the ideal solution (I know, that for a general app, it's not). Failure is covered: The session data (basically acting as a cache) can be reconstructed on a different server - but it's too expensive to do that all the time. I can't go to the database every time (way too many read requests). Clustering would be much too slow, too.

[user3745402]

As for the load balancers: Can they load balance based on the HTTP cookie header? Can I update their mapping table dynamically from my application server(s)?

[user3745402]

Wouldn't I need a separate server machine to run a software load balancer? I hoped, that I could save some money by using a cheap hardware load balancer.

[Warner]

Have you considered using a MySQL cluster for sessions? That would porbably be ideal. LVS is a layer 3 load balancer, I can't say if it supports that feature.

[user3745402]

@Warner: The amount of data my app will generate could grow to enormous amounts, and it will require joining tables. So a database query is very expensive, whereas taking the values from Java objects in memory is very cheap. This is a typical problem for some types of web apps (think social networks for example, see e. g. this very interesting article. I've written "standard" clustered apps before (didn't administer the servers though), but what I'm currently doing is a different beast :)

[Warner]

MySQL cluster is a memory based storage engine. (NDB)

[user3745402]

@Warner: Ok, I didn't know that - sounds interesting, and I'll have a look at it! I have the feeling though, that I'll need more specilized optimization than a more or less generic solution can provide. Ideally, a read operation should just perform a really quick memory lookup (objects already prepared before the requests come in), and "instantly" return a really small AJAX response, causing almost no CPU load. Then again, I'd love to use a more generic solution, if it turns out to be possible at all. Thanks for the valuable suggestion!

[Jiang YD]

"sticky (persistent) sessions" also has some benefits. fix problem at more beginning take less costs.

[Franklin Yu]

Link dead. New link is here.