Session providers for advanced load balancing

Question

5.00/5 (2 votes)

See more:

Hi,

I'm interested in finding out user experiences with custom session state providers for ASP.Net.

The requirement is to transparently change the session state provider for our ASP.Net applications so there is no stickiness/affinity between the users session state and a specific web server within our NLB cluster.

Using ASP.Net's default session state providers, if you remove a node from the NLB cluster, all users on that node are forced to log back in as they lose their session when moved to a different server.

Ideally I want to be able to replace the session state provider with a custom one which does not stick the session to specific web server, allowing me to switch the NLB to a round robin instead of network affinity.

All comments and advice would be appreciated.

Regards,

Steve

Posted 26-Sep-12 1:07am

Stephen Hewison

Add a Solution

2 solutions

Solution 1

ASP.NET offers 2 Session State providers that don't store the data on the local server, one involves a specific session state server, the other a SQLServer database.

In the article here you can read more about them: http://msdn.microsoft.com/en-us/library/aa478952.aspx[^]

I have tried using the SQLServer based solution once, but found it too slow and network intensive for my needs, which made the trade-off not worth it.
This was however a while back, so they might have implemented some more performance tweaks since then.

Interested to hear what other people have to say.

Posted 26-Sep-12 11:53am

Christiaan Rakowski

Comments

Stephen Hewison 27-Sep-12 2:59am

Hi Christiaan, thanks for the feedback. I've used both State Service off the web servers and SQL session state. Both methods are sticky to the server. So if I take a node out the NLB, the clients on that server lose their session state. It's because the session cookie is a http only, session cookie. When you switch web servers the cookie can't be accessed and the session is lost.

Christiaan Rakowski 27-Sep-12 4:22am

Ah, so you are trying to rotate the Session State servers around, not just the web servers. The question just got even more interesting :-)
I did some Googling just now and came across some interesting articles.

Microsoft Azure uses a distributed system, which they talk about here: http://msdn.microsoft.com/en-us/library/windowsazure/gg278339.aspx
I was unable to find any more details, but it might help you, or others, search for more information.

You could try implementing your own Session State Provider, this does require some work but could be a valid option. You can read more on that here: http://msdn.microsoft.com/en-us/library/ms178587(v=vs.100).aspx
It might be possible, and profitable, to build this upon a distributed Velocity cache with userid based keys. Or using a mirrored SQLServer setup.

There were also some that talked about load balancing the SQLServer, for example by DNS.

I have not tried any of these things myself yet, but they all sound quite interesting and might be worth taking a look at.

Stephen Hewison 27-Sep-12 4:36am

Yeah, I'm thinking about writing my own. I'm thinking about building a best of both worlds scenario, so build something like the state service which runs on a active/passive cluster behind the NLB cluster, which writes data to SQL but persists state in memory. That way if the active/passive cluster falls over it can rebuild the session state from SQL but for normal operations it uses the servers RAM (I believe it takes approximately 33% longer to load the data from SQL each time). Then use a time limited cookie, instead of a session cookie, which is refreshed with a new expiry with each page cycle and can be accessed by all of the web servers. This would enable a sliding session expiry similar to the sliding expiry of forms authentication. My only concern with this is that does configuring the cookie this way enable someone to hijack another persons session?

Christiaan Rakowski 27-Sep-12 5:14am

As far as I know it is always possible to hijack a session somehow, you just need to figure out how the system works and (ab)use it in the right way.
The easiest way to make it a lot harder would be to use some kind of endpoint checking, for example IP based, but that could cause problems if the user's ISP decides to change it right when the user is busy. Though it is only a very small chance that this will ever happen, it is something to keep in mind.

You could use a system like this, but you will need to properly secure the cookie to make tampering as hard as possible. There are many articles around that explain how to go about doing that.

If you go about building this system, I think it will prove an interesting project. I wish you good luck, and look forward to your results.

Stephen Hewison 27-Sep-12 5:25am

With none NAT IP addresses, you should never get an IP switching in anything other than the class D range. That's why network affinity in NLB binds to the class C address. I don't think any approach that would persist someone's state after a class C address switch would be secure. We have clients which use load balanced proxy servers so class C would far into the IP address as I could go in terms of securing the session. But yes, some kind of encryption in the cookie using the class C as the key/salt would help stop session hijacking from outside the users original network. We have to use secure cookies anyway as a non secure session cookie is a penetration test failure.

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Stephen Hewison · Accepted Answer · 2013-08-14T05:23:00

Hi,

I thought I should update this as there have been a few developments in the realm of ASP.Net application infrastructure. Namely...

App Fabric[^]

This is, amongst other things, an ASP.Net session state provide which works by distributing session state across multiple servers in a cluster.

But it also supports safe shutdown of cluster nodes as it will automatically migrate session data to other nodes. So you can get rid of stick sessions.

It is an in process session state provider. But within it's own process, so it supports web gardening.

It also has an optional repository database schema you can implement should you want state/process information to persist beyond an individuals session.

AppFabric can write any serialisable object away to it's database without having develop a custom process.

It also has some amazing features for IIS hosted WCF & WF services (a.k.a Workflow Services) but I'll leave those for another day.