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.
Related
on upload.aspx page i have
conn1.ConnectionString = "Data Source=.\ip-of-remote-database-server;AttachDbFilename=signup.mdf;Integrated Security=True;User Instance=True";
and all the queries are also on same page ,only database on another machine..
so is this the correct way of implementing ?? or i have to create all queries on another machine and call them by application??
Any given query query might originate from the client code (such as ASP.NET), or it might be stored a-priori in the DBMS itself as a VIEW or a stored procedure (or even a trigger).
But no matter where it originated from, the query is always executed by the DBMS server. This way, the DBMS can guarantee the integrity of data and "defend" itself from the bugs in the client code.
The logical separation of client and server is why this model is called client/server, but that doesn't mean they must be separate physical machines - you'll decide that based on expected workload1 and usage patterns2.
1 Distributing the processing to multiple machines might increase performance.
2 E.g. you might need several "fat" clients around the LAN (communicating with the same database server) to reach all your users. This is less relevant for Web where there are additional layers of indirection between users and the database.
It depends on your infrastructure. If you have got Sql Server locally you can use it. I assume that it is a school project so it does not matter. In real life it usually a good idea to separate web server and database server
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.
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.
I'm wondering if there exist any distributed ASP.Net State Service alternative.
Session can be stored in InProc, StateService or SQL. You can also write custom storage providers. For load balancing (without any form of sticky IP) only SQL/Custom will work.
Are there any alternative ASP.Net State Services that is distributed? I'm thinking so each server can synchronize with the others.
Edit: In response to answers: I am looking for Session() storage. Distributed cache is not a problem, Velocity will do fine for distributed caching. :)
Edit2: In response to Oded: State server has the problem of single point of failure. SQL server may not be directly accessible because of the model chosen (i.e. 3-layer), it is only accessible through the middle layer.
I thought thats what "velocity" was going to be bringing to the table? You might want to check out Microsoft AppFabric for your needs.
Edit:
Maybe I'm missing something about your post and your edit, but I'm still pretty sure AppFabric is what you need for your Session() storage. Maybe I'm wrong, but it sure seems dead on to me.
I would look at Memcache for .net
Take a look at this:
http://technet.microsoft.com/en-us/library/cc725582(WS.10).aspx
I'd recommend to stay with SQL server since it will be the easiest to implement.
Make sure the classes you store in session are marked as [Serializable] or you will get runtime errors.
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.