ASP.NET has become really popular for developing high traffic web applications. Many of these applications are deployed to multiple geographical locations. This is done either for disaster recovery purposes or for handling regional traffic by having the ASP.NET application closer to the end user. In case of disaster recovery, there is usually one active site and one passive site. The passive site becomes active as soon as the active site goes down for any reason. In other cases, two or more sites can all be active, but handling traffic closer to their region (e.g. New York, London, and Tokyo). ASP.NET keeps user specific information in ASP.NET Session State object on the web server. This ASP.NET Session State is created when the user first uses the ASP.NET application and stays active as long as the user is actively using the application. By default, after 20 minute of inactivity by the user, ASP.NET expires this session. ASP.NET Session State object is either stored in-memory on the web server (InProc), in-memory on any server (StateServer), in a SQL Server database, or in a third-party store by using ASP.NET Session State Provider (SSP) architecture. The third-party option usually is an in-memory distributed cache. An in-memory distributed cache like NCache is a great place to store ASP.NET Session State. The reasons are faster performance, greater scalability, and better reliability of ASP.NET Session State due to session replication. Below is an example of how you can specify a “custom” session storage option in web.config file, which results in NCache being used as ASP.NET Session State storage:
Active-Passive Multi-Site Deployment
But, if your application is running in a multi-site deployment, then the question you have to address is what to do about ASP.NET Session State storage. If your ASP.NET application is deployed in an active-passive multi-site configuration, then all your ASP.NET Session State is being created and stored in the active site. And, the passive site does not have any session data. So, if the active site goes down and all the traffic is redirected to the passive site, then all users will suddenly lose their sessions and will have to start over.
You can avoid this by using NCache Bridge Topology. Once you create a Bridge between the active and the passive sites, the active site starts submitting all adds, updates, and removes of ASP.NET Session State objects to the Bridge. The Bridge asynchronously replicates them across the WAN to the passive site. The nice thing about the Bridge architecture is that it doesn’t block the active site operations at all so you don’t see any performance degradation because of it. The only issue you have to keep in mind is that since the Bridge replicates asynchronously, there may be some sessions in the “replication queue” that won’t make it to the passive site if the active site abruptly shuts down. But, this is usually a very small number. Read more about NCache Bridge Topology and all the situations where you can use it.
Active-Active Multi-Site Deployment
If your ASP.NET application is deployed to two or more active sites simultaneously then I recommend that you not replicate ASP.NET Session State to all the sites to save on bandwidth cost. Additionally, most likely, each of your active site is geographically separated and it might make sense for you to keep its regional traffic to this site completely. However, you probably want the ability to route some of the traffic to other sites to handle overflow situations. Or, you may need to bring one of the sites down for maintenance without any interruptions for the users. In this case, you can use the multi-site ASP.NET Session State Storage feature in NCache that lets you handle these cases. It lets you specify in web.config to generate session-ids with a location prefix for this session’s “primary” site. Then, even if this session request is routed to another site, that site knows where to find this session. In this approach, the sessions do not move from their primary location even if the user request is routed to the other site. But, the other site is able to access this session from its “primary” site. Actually, each site specifies its “primary” and all others as “secondary” sites. Below are the steps you take to achieve this goal:
- Add entry in web.config. It is required to generate ASP.NET session-id in the same manner on all servers and sites. You can use the genmackeys utility available with NCache installation to generate the keys.
- To enable location affinity of a session-id, add configuration mentioned below:
- Specify custom session-id manager using the sessionIDManagerType attribute of the sessionState element in web.config.
Please note that in the above example, the <ncache> section in each site will be different, meaning each site will have its own “primary” and will consider all other sites as “secondary”. In the above example, you can see that ASP.NET is being asked to generate session-id in a specific format so the sid-prefix can be prepended with the session-id. Once this is done, it helps ASP.NET know where this ASP.NET Session State was actually created so the cache for that site is accessed. With this configuration, if you route any requests from one site to another for overflow, the other site fetches the ASP.NET Session State from its original “primary” site because this is part of the session-id as a location prefix. So, your WAN bandwidth consumption is minimized and you only pay for overflow traffic. The other situation is where you want to bring a site down. In this case, just redirect all of its traffic to other sites but don’t shut down the cache servers of this site; you can shut down the web servers. And, then wait for all existing ASP.NET Session State objects to expire after their users have stopped using the application. Once this is done, just shut down the cache servers as well. With this, your users will not feel any downtime. Take a look at how NCache helps you achieve this goal. Download a fully working 60-day trial of NCache.