Load Balancing And Session State Configuration are techniques for the Application Administrator to divide or distribute the workload evenly across various servers. When multiple servers use this type of environment it is known as Web Farms. So basically farming helps in avoiding overload on a single server thus helps in providing better performance, better resource utilization and maximizes throughput.
Load BalancerLoad Balancer is the single point for handling requests and is the key that decides which request needs to be forwarded to which server in the Web Farm Environment. Every request first arrives at the Load Balancer and then it is the role of the Load Balancer to forward the request to a specific server based on the current load and the state of the server.
In a Web Farm scenario, even if one of the servers stop working or crashes, the application will still work or respond, since other servers are still working, so the only point at which your application can go down is when the Load Balancer goes off.
There are various algorithms to define how the Load Balancer works, like "Round Robin" and "Least Connections" and so on.
For achieving this type of environment we need to take into consideration a few things like Session Management, Cache Management and the most important is the Database clustering (that is not usually taken care of by many). I will elaborate Session Management as keeping the scope defined; I will only be saying what changes you may need to make in your application or how to make your application work in a Load Balanced Environment. The configuration the of the Load Balancer is out of the scope of this article.
There are many tools available in the market for Load Balancing, you just need to do the configuration settings and if your application is ready for this environment, you are ready to go.
Sticky Sessions
So what are Sticky Sessions?
When a client makes a first request to the server, a session is created (by default or usually as In-Proc Sessions) in the server memory for that user, all the subsequent requests use the same session object. Now as I said, the session is created in the memory of the server handling the very first request, and in the Load Balanced environment we have more than one servers serving the requests, so what if the second request goes to another server that does not have that session object in memory, it will create a big mess, so that is the use of Sticky Sessions. To use Sticky Sessions we configure the load balancer to send the request for a specific session to the server that has served the first request. This can create a problem in the Load Balanced environment because it may be possible with Sticky Sessions that some of the servers are fully loaded and some are actually free at that time. But with In-Proc sessions we need to have Sticky Sessions in the load balanced environment.
Serializable Objects
As far as In-Proc Sessions are concerned that are maintained in the server memory, this is not a problem, but if some other technique for Session management is used, like maintaining sessions in SQL Server, then it will be a problem if the Objects that need to be in the Session are not serializable, this is very obvious since they all must know if something needs to travel on the network, if it does then it has to be serializable. Here we will store it on a separate server and all the servers that are part of the Load Balanced environment will access and update the session objects and put it into SQL Server.
Encrypting View State
Encrypting a view state can also create a problem because the encryption logic can vary from machine to machine, for this we need to update the Machine Key in "machine.config", and need to keep it the same on every machine.
Session Management
As of now there are three types of Session Management Techniques that are available:
Load BalancerLoad Balancer is the single point for handling requests and is the key that decides which request needs to be forwarded to which server in the Web Farm Environment. Every request first arrives at the Load Balancer and then it is the role of the Load Balancer to forward the request to a specific server based on the current load and the state of the server.
In a Web Farm scenario, even if one of the servers stop working or crashes, the application will still work or respond, since other servers are still working, so the only point at which your application can go down is when the Load Balancer goes off.
There are various algorithms to define how the Load Balancer works, like "Round Robin" and "Least Connections" and so on.
For achieving this type of environment we need to take into consideration a few things like Session Management, Cache Management and the most important is the Database clustering (that is not usually taken care of by many). I will elaborate Session Management as keeping the scope defined; I will only be saying what changes you may need to make in your application or how to make your application work in a Load Balanced Environment. The configuration the of the Load Balancer is out of the scope of this article.
There are many tools available in the market for Load Balancing, you just need to do the configuration settings and if your application is ready for this environment, you are ready to go.
Sticky Sessions
So what are Sticky Sessions?
When a client makes a first request to the server, a session is created (by default or usually as In-Proc Sessions) in the server memory for that user, all the subsequent requests use the same session object. Now as I said, the session is created in the memory of the server handling the very first request, and in the Load Balanced environment we have more than one servers serving the requests, so what if the second request goes to another server that does not have that session object in memory, it will create a big mess, so that is the use of Sticky Sessions. To use Sticky Sessions we configure the load balancer to send the request for a specific session to the server that has served the first request. This can create a problem in the Load Balanced environment because it may be possible with Sticky Sessions that some of the servers are fully loaded and some are actually free at that time. But with In-Proc sessions we need to have Sticky Sessions in the load balanced environment.
Serializable Objects
As far as In-Proc Sessions are concerned that are maintained in the server memory, this is not a problem, but if some other technique for Session management is used, like maintaining sessions in SQL Server, then it will be a problem if the Objects that need to be in the Session are not serializable, this is very obvious since they all must know if something needs to travel on the network, if it does then it has to be serializable. Here we will store it on a separate server and all the servers that are part of the Load Balanced environment will access and update the session objects and put it into SQL Server.
Encrypting View State
Encrypting a view state can also create a problem because the encryption logic can vary from machine to machine, for this we need to update the Machine Key in "machine.config", and need to keep it the same on every machine.
Session Management
As of now there are three types of Session Management Techniques that are available:
- In-Proc
- SQLServer
- StateServer
In-Proc Session
For configuring an In-Proc Session just make the following changes to the "Web.config" file:<sessionState mode="InProc" cookieless="false" timeout="100"/>
In this mode of Session state handling, all the session information is stored within the server memory (In-Memory) managed by an ASP.NET worker thread. This approach is good until the data that is stored in the session is not that heavy, but if you are going to maintain heavy data into it can create a mess for your application then the performance will decrease drastically. Also, the session data stored In-Proc will go off as soon as the application pool restarts.
As I discussed earlier in this article about sticky sessions, if we are using this mode for Session handling then we need to configure Load Balancer (in the case of Web Farms) for sticky sessions, because every server will maintain a session in its memory and if the subsequent request from a client is served by various servers then the application will not behave as it is supposed to. To solve all these problems, we can use SQLServer and StateServer techniques of Session handling.
SQLServer Session
In this mode of session state the session objects are stored into SQL Server instead of a processor or server In-Memory. The "Web.config" changes are as in the following:<sessionState mode="SQLServer" allowcustomsqldatabase="true" sqlconnectionstring="Data Source=<SERVERNAME>;Initial Catalog=<DATABASENAME>;User ID=<USERID>;Password=<PASSWORD>;"cookieless="false" timeout="100"/>
The benefit of using this technique is that all the data in the session will be stored together in a different location or you can say a centralized location in SQL Server, to get it working we just need to configure the SQLServer to store session data.
While configuring this mode in your application, one needs to consider that all the objects to be stored in a session should be serializable. So if you are currently using an In-Proc session state mode and intend that your application may require to have heavy sessions and you eventually need to shift it to SQLServer or the StateServer, then please take into consideration this "Serialization" issue from now on, because once the application is running and is the production environment, sometimes it is very difficult to make changes to session mode, because of these issues.
Configuring SQLServer to store Session data
Here I will show you how to configure SQLServer for storing session data in a custom database, although we also configure it to save session data in a temporary database, but this database goes off when you restart your SQL Server.
It is very simple by using the command line:
aspnet_regsql -d <SQLDATABASENAME> -S <SQLSERVERNAME> -U <USERNAME> -P <PASSWORD> -ssadd -sstype c
In this command "รข€“d" specifies custom database name, "-S" specifies SQL Server Name, "-U" specifies Username, "-P" specifies Password, "-ssadd" is an option specifying we need to add support for handling session in SQLServer and "-sstype" specifies the type of storage for Session State (if we need a temporary database or a custom database) and "c" represents the custom database.
As soon as you are done with it, you will get a message saying "Finished" with a notification for the settings you need to do in "Web.Config". So here we can see the message saying to configure the sessionState in "Web.Config" to allow session data to be stored in a custom database and we need to specify the connection string for it. You can also check the database created by accessing that server; it will look something like this:
With this we are done with configuring Session State in SQLServer mode.
StateServer Session
In this mode of session state the session objects are stored in a separate server handled by a Windows Service running on that server. The "Web.config" changes are the following:<sessionState mode="SQLServer" stateConnectionString="tcpip=<IPADDRESSOFTHESERVER>:42424"cookieless="false" timeout="100"/>
The benefit of using this technique is that all the data in the session will be stored together in a different location. In this case the server to be handled by the Windows Service is named "aspnet_state"; this will become the centralized location for session data. To get it working we just need to configure the StateServer to store Session data.
While configuring this mode in your application, one needs to take into consideration that all the objects to be stored in the session should be serializable. So if you are currently using the In-Proc session state mode and intend your application to possibly have heavy sessions and you eventually need to shift it to SQLServer or the StateServer, then please consider this "Serialization" issue, because once the application is running and is in a production environment, sometimes it very difficult to make changes to session mode, because of these issues.
Configuring StateServer to store Session data
Here I will show you how to configure StateServer for storing session data. Press "Windows + R" on your machine where you want to configure it, type in "Services.msc". Here you can see the service "ASP.NET State Service". Just start this service and you are ready to go with StateServer configuration, you can now see this service running in your "Task Manager".
As soon as you are done with it, we are good to go for using this mode of session state.
For configuring an In-Proc Session just make the following changes to the "Web.config" file:<sessionState mode="InProc" cookieless="false" timeout="100"/>
In this mode of Session state handling, all the session information is stored within the server memory (In-Memory) managed by an ASP.NET worker thread. This approach is good until the data that is stored in the session is not that heavy, but if you are going to maintain heavy data into it can create a mess for your application then the performance will decrease drastically. Also, the session data stored In-Proc will go off as soon as the application pool restarts.
As I discussed earlier in this article about sticky sessions, if we are using this mode for Session handling then we need to configure Load Balancer (in the case of Web Farms) for sticky sessions, because every server will maintain a session in its memory and if the subsequent request from a client is served by various servers then the application will not behave as it is supposed to. To solve all these problems, we can use SQLServer and StateServer techniques of Session handling.
SQLServer Session
In this mode of session state the session objects are stored into SQL Server instead of a processor or server In-Memory. The "Web.config" changes are as in the following:<sessionState mode="SQLServer" allowcustomsqldatabase="true" sqlconnectionstring="Data Source=<SERVERNAME>;Initial Catalog=<DATABASENAME>;User ID=<USERID>;Password=<PASSWORD>;"cookieless="false" timeout="100"/>
The benefit of using this technique is that all the data in the session will be stored together in a different location or you can say a centralized location in SQL Server, to get it working we just need to configure the SQLServer to store session data.
While configuring this mode in your application, one needs to consider that all the objects to be stored in a session should be serializable. So if you are currently using an In-Proc session state mode and intend that your application may require to have heavy sessions and you eventually need to shift it to SQLServer or the StateServer, then please take into consideration this "Serialization" issue from now on, because once the application is running and is the production environment, sometimes it is very difficult to make changes to session mode, because of these issues.
Configuring SQLServer to store Session data
Here I will show you how to configure SQLServer for storing session data in a custom database, although we also configure it to save session data in a temporary database, but this database goes off when you restart your SQL Server.
It is very simple by using the command line:
aspnet_regsql -d <SQLDATABASENAME> -S <SQLSERVERNAME> -U <USERNAME> -P <PASSWORD> -ssadd -sstype c
In this command "รข€“d" specifies custom database name, "-S" specifies SQL Server Name, "-U" specifies Username, "-P" specifies Password, "-ssadd" is an option specifying we need to add support for handling session in SQLServer and "-sstype" specifies the type of storage for Session State (if we need a temporary database or a custom database) and "c" represents the custom database.
As soon as you are done with it, you will get a message saying "Finished" with a notification for the settings you need to do in "Web.Config". So here we can see the message saying to configure the sessionState in "Web.Config" to allow session data to be stored in a custom database and we need to specify the connection string for it. You can also check the database created by accessing that server; it will look something like this:
With this we are done with configuring Session State in SQLServer mode.
StateServer Session
In this mode of session state the session objects are stored in a separate server handled by a Windows Service running on that server. The "Web.config" changes are the following:<sessionState mode="SQLServer" stateConnectionString="tcpip=<IPADDRESSOFTHESERVER>:42424"cookieless="false" timeout="100"/>
The benefit of using this technique is that all the data in the session will be stored together in a different location. In this case the server to be handled by the Windows Service is named "aspnet_state"; this will become the centralized location for session data. To get it working we just need to configure the StateServer to store Session data.
While configuring this mode in your application, one needs to take into consideration that all the objects to be stored in the session should be serializable. So if you are currently using the In-Proc session state mode and intend your application to possibly have heavy sessions and you eventually need to shift it to SQLServer or the StateServer, then please consider this "Serialization" issue, because once the application is running and is in a production environment, sometimes it very difficult to make changes to session mode, because of these issues.
Configuring StateServer to store Session data
Here I will show you how to configure StateServer for storing session data. Press "Windows + R" on your machine where you want to configure it, type in "Services.msc". Here you can see the service "ASP.NET State Service". Just start this service and you are ready to go with StateServer configuration, you can now see this service running in your "Task Manager".
As soon as you are done with it, we are good to go for using this mode of session state.
- In-process Session State + More than One Web Server: If you're using in-proc Session on ASP.NET, remember that the session has "affinity" with the server. That means that if www2.hanselman.com is the first server the user ever hits, the user will get an ASPSESSIONID cookie that is an index into the Cache object (the In-Proc Session is really just a key to a Hashtable-type structure inside the Cache/Application) that only exists in the memory of THAT ONE SERVER. So, since you're using Load Balancing (you have more than one server) it's important to ensure you're using "sticky connections" or node-affinity to guarantee the user gets back to his/her session on the next HTTP Request.
Note that it's often tricky to get a user back to the same box when dealing with "mega-proxies" of large corporations, ISPs, and AOL. That means that if your load-balancer (hardware or otherwise) is looking at various combinations of IP+VPORT+Whatever that these values MAY CHANGE if the ISP changes their source port or IP address. If you're using SSL, you can use the SSL ID to route traffic, but this can slow you down a smidge. You can also let the hardware loadbalancer add in a cookie of its own. Check your loadbalancer's FAQ for details. But, it's worth being aware of the things - Out-of-Proc (State Server) + More than One Web Server: If you are using the State Service, you might think about putting it behind your second firewall, in a different DMZ than both the Web Servers or the Database.
- Out-of-Proc State Server + ONLY ONE Web Server: Some folks use the Session State Service even if they have only one Web Server so the session state isn't lost when the ASPNET_WP.EXE process recycles. If you do this, make sure to lock down the state service to serve local requests only.HKLM\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\AllowRemoteConnectionsYou can also change the port that the state service listens on with the following key:HKLM\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters\PortIf you're using the state server in a web farm, it's important that you put it behind a firewall or otherwise prevent anything but the web servers from talking to it. [Early and AdopterEarly and Adopter]
- WebFarm Gotchas: When you're using either the State Service or SQL Server Session State, you're indicating that you don't want "session affinity" and you'll probably set your Load Balancer to Round-Robin dispatching of traffic. (It won't using any smarts or algorithms to get traffic, it will just go 1, 2, 3, etc.) When you do this AND you're using Forms Authentication OR you have EnableViewStateMAC set to protect your ViewState, remember to synchronize your <machinekey> between all machines in the farm. As users move around your site, each page could put served up from a different machine, meaning that not only are your encrypted forms-auth cookies passed around, but your ViewState (protected by the machinekey) may be sourced from one machine, and posted to another.
- Security: Remember to secure the crap out of everything you do.
No comments:
Post a Comment