Many high-traffic ASP.NET applications in Microsoft Azure are deployed over multiple dedicated regions to handle geographically separated traffic. In these situations, the load balancer sends traffic to the region closest to the user for faster response times. In this scenario, you may run into a situation where you have to redirect some of your traffic to and from one Microsoft Azure region to another. This situation may occur because you have too much traffic in one region and another underutilized region. Another reason may be a region down for maintenance. When you redirect traffic, users normally lose their ASP.NET sessions because Session State is unavailable in the other region, interrupting users. In Microsoft Azure, the only way you can avoid such interruptions is if you keep a common ASP.NET Session State storage across multiple Microsoft Azure regions. However, this option has severe performance issues because there is likely to be a large percentage of ASP.NET sessions being accessed across the WAN.
NCache in Azure
NCache is an extremely fast and scalable distributed cache for .NET applications in Microsoft Azure. It provides intelligent multi-region ASP.NET Session State support for your ASP.NET applications deployed in multiple Microsoft Azure regions.
The benefits of this configuration are as follows:
- Use the cache from any Microsoft Azure/AWS application and website.
- Share the cache across multiple Microsoft Azure applications and even to other platforms like AWS, Google Compute Engine, Rackspace, your private cloud, and more.
- Share the cache across multiple locations for the same or different applications.
Move ASP.NET sessions from one Microsoft Azure region to another
NCache in Azure intelligently detects and then automatically moves your ASP.NET sessions from one Microsoft Azure region to another when a user request is redirected. All subsequent requests are served from this new region. This is possible as ASP.NET application seamlessly shares sessions across Microsoft Azure regions without impacting performance or causing data loss.
NCache allows you to achieve multi-region ASP.NET Session State capability by defining primary and secondary caches in each location. Additionally, you must also specify the “sid-prefix” attribute. This helps the NCache for Azure SSP module identify which sessions belong to which region. It also helps establish whether to redirect various ASP.NET sessions to another region.
- To do so you must first create a ASP.NET Web Project and install the AspNet.SessionState.NCache NuGet package by executing the following command in the Package Manager Console:
1 |
Install-Package AspNet.SessionState.NCache |
- After the NuGet is successfully installed, You can verify it’s installation by checking if an assembly and provider similar to the following are available in your web.config:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
<add assembly="Alachisoft.NCache.SessionStoreProvider, Version=x.x.x.x, Culture=neutral, PublicKeyToken=CFF5926ED6A53769" /> … <sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20"> <providers> <add name="NCacheSessionProvider" type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider" exceptionsEnabled="true" enableSessionLocking="true" emptySessionWhenLocked="false" sessionLockingRetry="-1" sessionAppId="NCacheTest" useInProc="false" enableLogs="false" cacheName="democache" writeExceptionsToEventLog="false" AsyncSession="false" useJsonSerialization="false" /> </providers> </sessionState> |
- Next, you will need to add a <configSections> tag (similar to the following snippet) to the web.config. This tag must be the first child of the <configuration> tag:
1 2 3 |
<configSections> <section name="ncache" type="Alachisoft.NCache.Web.SessionStateManagement.NCacheSection, Alachisoft.NCache.SessionStateManagement, Version=x.x.x.x, Culture=neutral, PublicKeyToken=CFF5926ED6A53769"/> </configSections> |
-
- You must add the following custom ncache section immediately after, to identify your session caches for the various Microsoft Azure Regions:
1 2 3 4 5 6 7 |
<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> |
Redirecting Microsoft Azure Region Requests Using Session ID
All ASP.NET sessions originating from a Microsoft Azure region are originally stored in the primary cache in that location. However, when a request from another region is redirected to the current one then the multi-region SSP module detects whether the ASP.NET Session State resides in one of the other Microsoft Azure regions using the “sid-prefix” (ASP.NET Session ID). After which it automatically contacts the corresponding secondary cache in a remote region and moves it to the primary cache in the current region. All subsequent requests are then served from this new location.
For example, you have defined London_Cache to be your primary cache. On the other hand, NewYork_Cache and Tokyo_Cache are secondary caches for the London site. You also specify “LDC”, “NYC”, and “TKC” as sid-prefix attached to each session-id corresponding to London_Cache, NewYork_Cache, and Tokyo_Cache sessions, respectively. Now, all the ASP.NET sessions from the London region have “LDC” attached as a prefix to their ASP.NET Session IDs and are stored and served from London_Cache. This is a primary cache for the London region.
If a request is redirected from another region such as New York or Tokyo to the London region then this Session State is immediately identified based on sid-prefix. It is then it is transferred from NewYork_Cache or Tokyo_Cache to London_Cache. All subsequent requests are served from London_Cache locally once ASP.NET Session State is moved to the London region.
Conclusion
NCache for Azure supports multi-region ASP.NET Session State. It also allows you to have your applications in two or more active Microsoft Azure regions. It lets you redirect traffic between multiple locations to handle traffic overflows and site maintenance.