views:

67

answers:

5

Hi,

We've currently got the current server set up for a site:

  • Server 1: Admin System & Database
  • Server 2: Public site
  • Server 3: Public Site

Server 2 and 3 are managed using the Windows Network Load Balancing system. They are both running copies of the public site code.

The sites rely heavily on sessions because they work with user logins, my question is this:

How do I retain state between servers?

The web.config for the public sites currently look like this:

<sessionState mode="StateServer" cookieless="false" timeout="40" stateConnectionString="tcpip=localhost:42424"/>

Surely it's just a case of changing "localhost" to the I.P of where I want to store the session? I'm thinking of using the Database server to store session, so it would look like this:

<sessionState mode="StateServer" cookieless="false" timeout="40" stateConnectionString="tcpip=databaseserverIP:42424"/>

Would this be wise?

I've found lots of conflicting documentation on the subject and would appreciate anyone giving an insight into how they've done it before/ would do it.

Also (while I'm here!), the admin system allows you to upload images for articles. I was thinking of setting up a virtual directory on servers 2 and 3, which would point to a network share mapping to the upload directory on the admin site, is there any reason why this would be frowned upon?

Apologies for my ignorance, this is uncharted territory for me!

Thanks, Sean

+2  A: 

You should use a SQL database to store the session. Set the mode="SqlServer" and go run aspnet_regsql to add the session tables to your database.

Also, you'll need to make sure that any objects you are storing in the session are marked as [Serializable]

matt-dot-net
@matt-dot-net we originally used SQL Server before we implemented load balancing, then changed to StateServer because we found it to be much quicker. Would make sense to keep it as StateServer if it's quicker? Seeing as we are going for optimum performance here, I'd be more inclined to keep it as StateServer.
seanxe
@seanxe. Spot on.
RPM1984
You could use state server, but there is no technology that I am aware of to handle state server failure/failover. This is easy to do with SQL server. If you aren't willing to setup SQL clustering/failover, then state server will be fine.
matt-dot-net
+3  A: 

Depends on what State Service you are wanting.

Generally in a load-balanced scenario, you'd go for SQL Server Session, or ASP.NET State service.

Each has its pro's/con's (SQL Server Session requires serialization/deserialization, but maintains state if the server falls over, ASP.NET State does not maintain state if the server fails over but is much faster due to no serialization/deserialization).

Regardless, consider hosting the service on a seperate, independant machine - so its not fighting for resources with other processes.

A discussion on the two needs further research on your part - as you whether availability or speed is your primary concern.

Keep in mind if you want to share session between web servers (ie a webfarm), you'll need to update the machineKey settings for each server to be identical.

Here's a good article on ASP.NET Session State (and the machineKey issue i mentioned).

RPM1984
@RPM1984 - thank you. the application is very dependant on session so I think we'll go for StateServer for now because it seems to be the faster method. It will be pointed toward a separate server so resources aren't really a problem for now. I found the article you referenced about 10 minutes before this reply, nice to see it has some credibility! Thank you.
seanxe
A: 

Another approach to consider is that of "sticky" sessions.

This is where you configure your load-balancers to always direct a given "session" to the same box. Most, if not all, commercial load-balancers support this. Basically they insert their own session cookie or http header that is used to identify a given user session. This session will then always be routed to the same box (unless it goes down).

The pro of this approach is you can continue to use plain session state and so it simplifies you server configuration and setup.

The cons are that you have no fail over redundancy because a loss of a single server will still result in a loss of all the sessions on it, plus it impair overall load balancing performance as it can't adjust dynamically in the same way if one server starts getting overloaded (it can route new sessions to another server, but must keep sending existing sessions to the same one.)

Rob Levine
@Rob Levine - the only problem I can see from this solution is that we will be taking servers offline to deploy upgrades. Using this method would require us to wait until the server in question has no users on it, and given the nature of the application, this could take quite some time. Thank you for the reply though! Always useful to hear of other alternatives that I haven't considered.
seanxe
@seanxe. Absolutely yes - this is a definite weakness with this approach. I'm not really a great fan of sticky sessions myself, (hence me being explicit about the downsides), but thought it would be useful to throw in the mix!
Rob Levine
A: 

Save your session in a distributed cache. NCache and Microsoft AppFabric caching allow you to make your sessions distributed with failover (via replication) and minimal configuration.

You just have to plugin the session state store provider of your distributed cache vendor.

Hasan Khan
@Hasan Khan - will look into this but only have a limited time to get this new setup running (gotta love clients!) - will definitely research into for future reference!
seanxe
A: 

If you want availability (ie sessions are available on any server irrespective of server failure) then the SQL route is the way to go but you could also look at ScaleOut SessionServer (http://www.scaleoutsoftware.com/pages/products/scaleout-sessionserver.php)

Cheers

The Cat

Cheshire Cat
@Cheshire Cat - it's not so much availability we're after, more speed and performance. We have a pretty robust system setup to handle down time (admittedly not perfect, nothing is), so at the moment I want to increase load time/ performance on the web site, then we can start thinking about 100% uptime. Thanks for the link though, will look into it.
seanxe