Bulletproof Sessions for IIS Web Farm

Question

Good afternoon, all.

We're currently making the jump from one web server to two and in order to provide seamless failover to our users we need to do something about the session.

Currently, we're investigating three different methods.

1. Make use of a state server
2. Make use of SQL server
3. Chuck everything into hidden fields

I, personally, would like to see option number one go into place as we don't have a dedicated database for option number two and option number three seems like a messy hack.

The problem I currently face is that my manager is not happy with the single point of failure provided by a state server (our SQL server is replicated, so no troubles there).

Is there something that can be done about replicating the state server or somesuch?

Thanks in advance, Matt

Answer 1

To my knowledge there is no way to back up or replicate your StateServer service. Another issue when using StateServer in a web farm is if your cluster allows for the same browser to reach different machines on different requests they could have different session data on each request! (edit: Martin pointed out below that you can fix this by sharing a single StateServer instance among multiple web servers). For your purposes option 2 or 3 would be more fault tolerant, and I will throw in another idea: for small pieces of data try using cookies for session storage.

Answer 2

Also make sure that you aren't using SQL Server to store session state that just comes from the database anyway. If so, you might as well just call the database each time.

Answer 3

I think that you are moving to another arquitecture: more than one Front End IIS.

Are you going to use NLB?

• If so, your best option is to use a state server, it will play as an application server in concept.

Here in my company we are migrating .NET app to two IIS with Network Load Balancing, and the applications use to have Session managment in proc.

We've investigated that there was another alternative:

• using client affinity in the NLB configuration, allowing the postback to go back to the IIS where the process was generated, the price was to loose all the NLB...

After Microsoft advisory, the best option was the State Server :)

Hope it helps!

Best Regards!

Answer 4

It can be a pain, but I've decided to turn off Session and deal with the consequences. So far nothing insurmountable has come up.

Answer 5

After some more investigation we've decided to go with the StateServer option. We're still looking to see how to overcome the single point of failure on the StateServer and we've turned up two further avenues of investigation.

Our first option is to use a third party program to handle the sessions. The one we're looking at right now is called nCache: I think there's another called ScaleOut that we also may take a look at.

Option number two is to use session state paritioning and we're currently looking into this option as well: http://msdn.microsoft.com/en-gb/magazine/cc163730.aspx