Session state on a network load balance scenario_问答_开发者

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 h开发者_开发技巧ere!), 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

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).

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]

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.)

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