If you wish to use AppFabric in high availability mode then you need to ensure that all of your cache servers are running Enterprise edition of Server 2008. This isn't possible for us in our environment.
We currently use a single machine acting as a state server for our web farm. Obviously this leaves us open with a single point of failure.
On investigating AppFabric I found that it was able to handle session state. We are looking at introducing it anyway in our caching layer.
The problem with not running it in HA mode is that if a node goes down you lose the sessions hosted on that box.
I wondered if anyone had implemented a custom state provider which supported AppFabric and asynchronously backed the state off to a SQL Server so that in the event of a server going dark for whatever reason the state could be rebuilt.
I have put no development time into in my idea yet but thought I would float the idea past some clever devs to see if it has been attempted,considered or there are any glaring holes in my idea.
i found here http://netpl.blogspot.fr/2007/06/wrapped-inprocsessionstatestore.html, a solution for having a generic wrapper, but it does not seems quite robust.
Maybe it is possible to switch between providers based upon a particular event or variable.
Related
The ASP.NET SQL SessionState provider seems excessive for my requirements. SQL Server has to be 'configured' to support it and I have questions about how optimized it is (i.e. is there one db hit to fetch the whole session or one for every session item requested?).
I think I could implement a custom solution very easily that I would understand and easily redeploy to other projects. Is there something fundamental I haven't considered here and an obvious reason why the built in SessionState handler is the 'best' way to go?
Just to clarify, our applications run on single servers at the moment. My main motivation for doing this is to enable Session to persist across IIS restarts and therefore provide more reliability for users.
you could use StateServer mode.
StateServer mode stores session state in a process, referred to as the ASP.NET state service, that is separate from the ASP.NET worker process or IIS application pool.
Using this mode ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
more info at http://msdn.microsoft.com/en-us/library/ms178586.aspx
It takes just minutes to setup SQL session state server (assuming you have SQL server already running). I can't imagine that you can write anything in less time than it would take to at least try out what already exists and is free and supported by MS.
A proven, built-in/off-the-shelf solution is always better place to start than custom. You may still end up with a custom solution, but don't pick it because you didn't bother to test what is already available to you.
I am moving a site from a single server to a server farm consisting of three web servers behind a load balancer. It seems easy enough to handle session management - just make sessions "sticky" at the Load Balancer (we evaluated SQL-based session management but have decided to continue using InProc session management for efficiency).
However, we also use a sizable configuration object that we keep in the Application space (e.g. Application[ObjName]). Since the config object is loaded from memory, we have no problem until someone makes a change to the configuration. At that point, the application on the hosting server will have the change and the database will have the change. However, the other two servers won't have the change. We've debated having a "once a minute" polling rule (e.g. on new sessions), keeping information in the session instead (not very efficient), etc. All have serious drawbacks. I am wondering what other people do. Is it possible to keep the Application space on SQL Server but the Session space inproc? Any help or insight about how to handle this would be appreciated!
Application[] is always going to be local memory based, so no matter what you've going to have some code changes to make. So put it somewhere else, like a distributed cache, AppFabric, NCache, memcached.net etc. When someone makes a change to the configuration update the cache, when you need to read the settings read from the cache. Propogation/Sync is taken care of by the cache itself.
We currently decided to use NCache as we have got 4 web servers for our web farms. This third party caching tool can work perfectly with load balancer and is easy to configure(just the Express version of it is free. For Professional and Enterprise version, only Developer Machine is out of charge). It is also really fast and stable. You must setup the NChache on each server and set the load balancer to work with all of them. Hope it helps.
This may be a dumb question, and based on the fact that googling has failed me I'm betting the answer is "no", but I thought I'd ask in case someone else has figured it out.
We're finally putting our website on a server farm, which means we can't use InProc session management. We're using SQLServer mode instead, but we had a situation where our SQL Cluster crashed. During this time, none of our newer web apps were able to load because of an inability to connect to the session database.
So here's the question: Is it possible to automatically fall back to a different session management (StateServer for example) or dynamically change the connectionstring so that we can use a backup Sql Server?
For now, our plan is to use DNS and if the main SQL Cluster fails, simply switch the DNS to a backup, but that's a manual task, and takes some time. We were hoping to have some sort of automatic failover.
I am afraid that there is no way. Also switching the session state mode would also make your application crash because users won't be able to find the data that was stored in their sessions. So an advice I can give you is the following: use a dedicated SQL server for the sessions, don't use the same server as the one serving your application data. And if you can, progressively start to update your application so that it uses less and less sessions, store very small amounts of data until you completely get rid of it. Make it stateless. Then your application will become very scalable.
In my current project, we have to create a website (ASP.NET MVC) which is likely to have sufficient load to demand a server farm. I understand that if server farm is used, session states must be stored on somewhere else such as SQL server database or state server.
After some experimentation, we are inclined to use the state server mechanism but the fact that it will have single point of failure, makes me nervous. Is there any method by which we can avoid "single point of failure" when using state server?
There is something called session state partitioning that you could use, in order to avoid a single point of failure. If this still doesn't suit you, then you might consider trying the ASP.NET Velocity project, which it looks promising even though it is in CTP stage only.
If you want full scalability and redundancy, then you should probably use a SQL Server Cluster.
sharedcache (http://www.sharedcache.com or http://sharedcache.codeplex.com) has an implementation for sessions, it's not released so far but people are using it.
You could set up SQL Server replication to another machine or use a failover cluster.
This could potentially be expensive but would make your database component more robust.
Technically, your web server equipment room is a single point of failure, as well as your network, etc. I wouldn't necessarily be more nervous about session state than any of those.
First of all to give you a bit of background on the current environment. We have a number of ASP.NET applications, all of which use session for certain aspects. We are "Load Balanced" over multiple servers due to traffic levels, however, our load balancing is set to use "Sticky Sessions" as currently all web applications are set to use "InProc" for session state.
We are looking at being able to remove the "Sticky Sessions" configuration on our load balancer, as due to our traffic loads servers can and do get overloaded. We want to go with a more balanced approach, but must be able to use session.
I know that SqlServer for session state will work, but for reasons beyond our control, we cannot use SqlServer to store our state. In researching it seems that StateServer is our best bet. We have an additional server, with loads of memory sitting around. This server could be our StateServer for the entire Web Cluster. We just want to know the following things.
1.) Besides any potential serialization issues with the switch from InProc to StateServer, are there any major known issues with losing session objects or generating errors with the above listed environment?
2.) Aside from the single point of failure, and slighly slower performance are there any other gotchas that we need to be aware of with using StateServer.
3.) Are there any metrics that show the performance differences between the three types of state storage?
Here is a decent FAQ on asp.net state: http://www.eggheadcafe.com/articles/20021016.asp
From that Article, here is some information on StateServer:
In a web farm, make sure you have the same MachineKey in all your web servers. See KB 313091 on how to do it.
Also, make sure your objects are serializable. See KB 312112 for details.
For session state to be maintained across different web servers in the web farm, the Application Path of the website (For example \LM\W3SVC\2) in the IIS Metabase should be identical in all the web servers in the web farm. See KB 325056 for details
I have only used sql and in-proc. But these 3 that apply when using sql server apply as well:
Avoid storing too much information in the session, as it affects both in serialization and data transmitted over the network.
Make sure you don't have anything that depends on the Session_onEnd. This is just not available for out of process sessions.
Turn off session on pages that doesn't uses it. This don't make a difference for in-process session, but for out of process it will save you a lot.
Make sure your server etag ids are synchronized across the web farm otherwise caching at client browsers will be upset.
Have you reviewed your code in detail to make sure everything can be serialized out of process and across a LAN efficiently?
Are you solving the main performance problem within your system? I ask because the database is the typical source of contention.
My main motivation for moving away from sticky sessions was operational flexibility i.e. cycle down a problematic server or to deploy a software upgrade. So having implemented a central session state service make sure you take full advantage from an operational stand point.
In my experience we've found out that native state server or even using SQL Server for sessions is a very scary scenario as both have issues (mainly performance). By the way, we are also using sticky sessions.
I think you can explore other products for this to achive the absolute best. A free option would be Velocity but it is still not released.
And another comprehensive but proven product will be (Very expensive actually) NCache. THis will even help in your serilizations with less cost, If you use their API's it will be even better results.
Take a look and see which looks best for you.
About SQL Server, you server will die very soon if you have enough number of hits coming in (I belive you have some hits already which yielded you to do Web Farm or you do it just for the sake of redundancy)
Bottom line: We are evaluating Velocity because NCAchce is really expensive. However advantages are huge.
We are using StateServer for a very small web farm with only two nodes for a few hundred users.
I'm not responsible for its operation but I remember only two issues in two years where the service had to be restarted because it crashed.
I would like to another one more point to the accepted answer:
Make sure the version of framework dlls is the same.
In my case the System.Web dll versions were different as a few windows updates were skipped on one of the servers of the farm.