Basically my question is i have a website which was developed around 3 years ago, while development it was proposed that this site will be used by few people on internet.
But now it seems like many users are accessing the website. So we have planned to create a Web sever Farm where we have multiple servers for our website.
major problem in development is old website used InProc Session state and now since we are upgrading to multiple servers we want to change InProc to Outproc i.e StateServer Session State.
Can you guide me on this upgrade and how can it be achieved in simple and easy way rather than changing the coding on each pages wherever sessions are used.
What you going to have here is that you move your site to many web servers and the actual issue here is "how to keep the same state for each user regarding the server".
There are two options.
First option is to setup the router that split the users to the server, to use the "Sticky option", meaning that each user is stick for his session to one server, and one only. In this case it did not matter if you use inproc or sql server session, as long as the router make good job. This is the case of course that you do not use any other database for common data.
Second option is to use an sql server and move the session to the server, but here the server must be on one server and the others server's gets his session data from this one. Also you setup on web.config the same key machine for all web servers.
So for this case you need.
To setup a common/shared SQL server on one server
To install on this the session database (actually run a script from asp.net)
Setup the web.config to use this database as session
Setup the web.config to have the same machine key.
In the case that you use a database for other data, then you place this database together with the session database, and you make a share connect to that database also. The point here is that the data must be live on one computer, and the other computers connect to this main one for the data.
Related
Azure website clarity regarding the instances, are these instances running on multiple machine like a web server farm environment where one client request (session) can be server by different server in the farm.
Issue with server farm asp.net application is that we can loose session variable if that is the case, for this issue to get around we add machine key in web.config that assure client session will always be server by same server so there wont be any lose of session variable.
How does Azure instance work. doesnt it mean we can have 10 websites under same plan let ex s1 Standard.
I am hosting asp.net webform based website on Azure I am confused how exactly instance work. there are lot of article on internet to create confusion.
The thing with PaaS is that you don't have to care about that. If you have a statefull site, you can use the ARR Affinity setting to ensure a client gets always to the same instance:
Adding to Martin Brandl's answer.
An App Service Plan can have multiple instances. These instances run all of the apps in that plan. So it is pretty much like a classic web farm. Except it is way easier to manage.
There is a better way of keeping session information in a web farm rather than relying on sticky sessions with ARR Affinity. Put the session data in a central place. For that you can use Azure Redis Cache or SQL Database. There are ready-made session state providers for these that you can just plug in to an ASP.NET application. That way your session state is not stored on the instances, so you don't need to care if clients hit the same server.
The problem I have with ARR Affinity, is that Azure does not guarantee your instances will remain running. A hardware failure could bring one down and you lose a part of your session data. If you use auto-scale, same thing.
Greetings,
What do I have to consider when you are coding an ASP .Net website in regards to if the application will run in a environment where there is a load balancer for the IIS?
All user sessions are running by them self with no shared data between sessions. Single connections to MSSQL. Images and files for download will be hosted on one single server.
Windows Server 2008's, C# and .Net 4.0.
The most obvious item is session state. If you are load balancing, multiple requests from the same user may move between servers. The default session provider for ASP.NET (in-proc) doesn't support this (the user would get a new session each time they moved). The easiest solutions are to move to a ASP.NET state server or SQL Server sessions.
FYI: Both of these solutions require that everything that you put into Session be [Serializable]. The in-proc provider doesn't have this requirement, so you may see some runtime errors and need to modify your code when you change providers.
You're going to need to move your session state into the session state service. Avoid keeping objects in session...if you must keep an object in session, make sure it's marked with the Serializable attribute (this is how it is stored, by serialization).
In general, avoid using Sessions. Keep in mind that ASP.Net Session != FormAuthentication. Chances are that your database will be a bottleneck long before the web server, depending on the nature of the application.
Is there a way to share session among asp.net balanced applicatiosn without saving session in DB (i.e. without using SQLServer sessionState)? Actually, could load balancers take care of that by themselves?
To share a user session, yes. You have two options:
User an ASP.NET state server and have the web servers point to that.
Enable sticky sessions on the load balancer, so that once a session is started on a particular machine, all further requests for that session will go to the same machine. (really this is the less ideal of the two as it can still have problems if the app pool resets etc.)
There are other applications from MS etc, that you can use to store state also.
Right now, my site is served by a single server, but I anticipate the need to increase my server capacity, soon. Instead of splitting my websites up among multiple servers and having to manage sessions across servers, I want to have multiple web servers all with the same code base on them and use router based round robin load sharing to distribute users to each server. And once a user hits a web server, have him stay with that web server throughout his/her whole session. To my knowledge, I don't need to have any special asp.net code to facilitate this.
Does anyone have any caveats or comments for this approach?
What you are talking about is called sticky sessions or session affinity. If your router supports this, then you are golden.
The only caviat is that the load balancing won't be perfect. If you have a few high-load users who all end up randomly on the same server, they will staty there until the sessions end.
I have implemented this kind of load balancing where I work, and it requires no special asp.net code to implement.
Most (perhap all) load balancers do have the ability to enforce "sticky" sessions where users on the same IP are directed to the same web server on every request. There is no code change required to accomplish this. There are two caveats that come to mind:
Using sticky sessions will mean that the traffic load will not be distributed as evenly as it would if you were not using sticky sessions. However, the distributionshould be"even enough" IMO.
There will be a very small percentage of users using proxy servers that may come in on different IPs on different requests. These users may experience "odd" behavior as they get passed to different servers.
Another characteristic of this configuration is that if one your servers go down the sessions of the users on that server will lose their session as well. I think this is one of the most commonly used setup since it does not require any development effort if the router supports sticky session or session affinity.
As others have mentioned, you should be able to turn on Sticky Sessions on your load balancer, that should take care of most of the "stay on one server" issues for you.
However you will want to ensure you have put settings in place to cope with a user landing on the wrong server mid session - Sticky Sessions are usually based on IP address, and users IPs can change mid session if you're unlucky, or a server may go offline, and the user will be directed to the other server.
You should make sure that your MachineKeys are the same across all servers - this will ensure that you can decrypt the viewstate correctly on all servers.
If you own the servers, you can do this in the machine.config, otherwise you can set it at the application level in the web.config, more details can be found in this how to:
Configure MachineKey in ASP.NET 2.0
There are some slight differences if you're running on IIS 7.5 - Tess Ferrandez has more details in a recent post "Forms authentication fails after installing IIS 7.5".
The other thing you'll probably want to do is move your sessionState from InProc to either Sql or StateServer.
We have 5 balanced web servers with various websites.
What I am trying to achieve is to ensure a single login.
i.e. the same user account cannot login to the same website more than once at any given time.
The method i'm considering for solving this, is to share session amongst the servers so I can control which session is assigned to which account. I can then have control over my logins. If a user logs in and there is already a session assigned to their user account, I can just expire the first session or reject the login.
I don't want to lose the benefit of the balanced servers, so using a single Sql Server as my session state server, or a single server to handle login is not an option.
Is distributed session (something like Scaleout Sofware) the correct approach to achieve this?
Or is there another mechanism to handle single login that i'm blissfully unaware of?
You have two set of problems here:
1) Allowing just one connected user in a web farm scenario
2) Detecting user logoff
To solve the first the only solution is a central storage for some kind of user state, using a central server to store the ASP.Net session or some other kind of centralized user state. This central storage can be SQL Server using the native management of session state (btw also Oracle, from Oracle 11, can support session storage), the AspState service or an external solution, like ScaleOut (as you said) or its open source alternative memcached (see https://sourceforge.net/projects/memcacheddotnet/). Or you can design a simple centralized web service that check active logins against a SQL Server database, this way you can also quickly create reporting tools about logged on users and so on.
Real problem, in my opinion, lies in the second part, that you need to maintain the different "wrong logoff" scenarios that are available in a web world (like closing the browser due to a crash or shutting down applications without logging off), giving you application some way to gracefully work with user that has an old session enabled (as you said simply expiring the first session can work).
Keep also in mind that using a state server like SQL server will not make you loose the balanced servers, if's the way of working to have a web farm environmet and sharing session, only problem lies in performance (if session state become large) and the cost involved in using SQL Server if you do not already have the proper license.