ASP.NET is known for developing high-traffic web applications. Many of these applications are deployed to multiple geographical locations. This multi-site deployment is done either for disaster recovery purposes or for handling regional traffic by having the ASP.NET application closer to the end user.
In the 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).
NCache Details NCache Docs ASP.NET Session State Provider
ASP.NET keeps user-specific information in its Session State object on the web server. When the user accesses the ASP.NET application for the first time, its Session State gets created and remains there as long as the user is actively using the application. By default, after 20 minutes 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), on any server (StateServer), in a SQL Server database, or a third-party store by using SSP architecture.
The third-party option usually is an in-memory distributed cache like NCache, is a great place to store the 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 the web.config file, which results in NCache as ASP.NET Session State storage:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
<sessionState cookieless ="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="60" sessionIDManagerType="Alachisoft.NCache.Web.SessionStateManagement.CustomSessionIdManager, Alachisoft.NCache.SessionStateManagement"> <providers> <add name ="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" sessionAppId="demoApp" cacheName="demoClusteredCache" writeExceptionsToEventLog="false" asyncSession="false" enableLogs="false"/> </providers> </sessionState> |
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 you have deployed your ASP.NET application in an active-passive multi-site configuration, then all your ASP.NET Session States are being created and stored in the active site. The passive site does not have any session data. So, if the active site goes down and all the traffic redirects to the passive site, all users will suddenly lose their sessions and have to start over. You can avoid this by using the 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 Bridge architecture does not block the active site operations, so you do not see any performance degradation. 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 an insignificant number. Read more about NCache Bridge Topology and all the situations where it is beneficial for you.
NCache Details NCache Docs ASP.NET Session State Provider Properties
Active-Active Multi-Site Deployment
If your ASP.NET application is deployed to two or more active sites simultaneously, then you should avoid replicating ASP.NET Session State to all the sites to save on bandwidth cost. However, you probably want the ability to route some traffic to other sites to handle overflow situations.
Alternatively, 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. The feature lets you handle these cases and specify in the web.config to generate session ids with a location prefix for this session’s “primary” site. Then, even if this session request routes to another site, that site knows where to find this session.
The sessions do not move from their primary location even if the user requests a route to the other site. But the other site can access this session from its “primary” site. 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.
1<machineKey validationKey ="A01D6E0D1A5D2A22E0854CA612FE5C5EC4AECF24"decryptionKey ="ACD8EBF87C4C8937" validation ="SHA1"/> - To enable location affinity of a session-id, add configuration mentioned below:
123456<configSections><section name="ncache" type="Alachisoft.NCache.Web.SessionStateManagement.NCacheSection,Alachisoft.NCache.SessionStateManagement, Version=x.x.x.x, Culture=neutral, PublicKeyToken=CFF5926ED6A53769"/></configSections><ncache><sessionLocation><primaryCache id="London_Cache" sid-prefix="LDNC"/><secondaryCache id="NewYork_Cache" sid-prefix="NYKC"/><secondaryCache id="Tokyo_Cache" sid-prefix="TKYC"/></sessionLocation></ncache> - Specify custom session-id manager using the sessionIDManagerType attribute of the sessionState element in web.config.
12345678910111213141516171819202122232425262728293031<<sessionStatecookieless ="false"regenerateExpiredSessionId="true"mode="Custom"customProvider="NCacheSessionProvider"timeout="60" sessionIDManagerType="Alachisoft.NCache.Web.SessionStateManagement.CustomSessionIdManager, Alachisoft.NCache.SessionStateManagement"><providers><add name ="NCacheSessionProvider"type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider"sessionAppId="demoApp"cacheName="demoClusteredCache"writeExceptionsToEventLog="false"asyncSession="false"enableLogs="false"/></providers></sessionState>
Please note that in the above example, the section in each site will be different, meaning each site will have its own “primary” and will consider all other sites as “secondary”.
NCache Details NCache Docs ASP.NET Core Sessions
ASP.NET generates sid (session id) in a specific format so that the sid prefix can be part of session-id. This session id helps ASP.NET to know the origin of ASP.NET Session State so that 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. It minimizes your WAN bandwidth consumption, and you only pay for overflow traffic.
The other situation is when you want to bring a site down. You can redirect all of site’s traffic to other sites without shutting down the cache servers of this site; you can shut down the web servers. Then wait for all existing ASP.NET Session State objects to expire after their users have stopped using the application. Once traffic redirects, just shut down the cache servers. 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.