Using In-Role Cache in Azure Government

Art Rask

May 11th, 20150 0

When planning the deployment of a web application to Azure Government, it is important to consider the Azure services that are currently available in Azure Government and to select the platform components your application will use accordingly. ASP.NET web applications are, of course, a common deployment scenario.

These applications, especially when used for line-of-business solutions, will often use session state. It is a given that an enterprise-grade deployment will use multiple, load-balanced web servers (the Azure availability SLA requires it) and therefore session state will need to be shared among these web servers.

Each web server should hold no state across requests; any active user session should be rehydrated by a front-end server from a storage mechanism shared across the web farm. The ASP.NET session management framework has always supported this by allowing a session provider to be plugged in via the web configuration file. Common storage locations include SQL Server or a distributed cache.

For deployment of web applications in Azure Government, the preferred choice is usually Azure Web Roles (aka, Cloud Services). Web Roles provides the ability to deploy a web front-end and although there is the option of deploying virtual machines running IIS or Apache, this should not be your first choice given that Cloud Services help reduce server and patch management overhead. Cloud Services allow you to focus on your application, and Microsoft and the Azure Fabric can manage the underlying infrastructure.

One of the features of Cloud Services is In-Role Cache. In-Role Cache provides a fault tolerant, distributed in-memory cache for use in both Web and Worker roles of Cloud Services. You have the option of hosting the cache co-located with your web role (i.e., in memory on the same instance as the running web app) or in a dedicated worker role. In-Role Cache is a multi-purpose caching mechanism and, although we are focused on ASP.NET session for this post, is certainly not limited to use for web session state.

Full discussion of the In-Role Cache feature can be found here. There is also information at this link about integrating In-Role Cache into your Cloud Services solution and configuring the ASP.NET session provider for Cache. Those details are not the purpose of this post, however. Instead, this post details the configuration you need to be aware of for running In-Role Cache in the Azure Government cloud.

In-Role Cache uses a small amount of Azure blob storage for its own configuration and state information. Mostly this is related to the node membership of the distributed cache cluster and the maintenance of high availability across the cluster as nodes join or exit. Ensuring the cache points to a valid storage location for this configuration information is required for the cache to initialize. That means that for an Azure Government deployment you will need to point to custom endpoints. Fortunately, this is easy to do using the tools in Visual Studio 2013!Assuming you already have a Visual Studio 2013 solution containing your Web Role, here are the steps you will take to correctly configure In-Role Cache.

In Solution Explorer, select the Web Role within your Cloud Service project. Right-click and click Properties on the context menu.

In the Web Role Properties editor, select the Caching tab from the list along the left side. The Caching options page will appear. You will probably want different configuration for cache based on your deployment environment (e.g., Local, Cloud, Test, etc.), so select the appropriate configuration from the drop down list at the top of the page. Check the Enable Caching option to enable In-Role Cache. Select the option of co-located cache or dedicated worker role for hosting your cache. The best choice here really depends on your workload, how heavily your app uses session, etc.

The key detail is configuration of the credentials and endpoints for the cache cluster’s configuration storage. To edit this, click the ellipsis button next to the storage connection string. The Create Storage Connection String dialog will appear.

Select “Manually entered credentials” from the option buttons at the top of the dialog. In the Account name field, select or type the name of your storage account in the Azure Government cloud. In the Account key field, paste the Storage Account Key for this account.

In the Connection options, select “Specify custom endpoints”. This is the essential detail you need to get right. As shown in the screen shot of this dialog, enter the Azure Government storage endpoints, as follows:

Blob URL: https://<yourstorageacct>.blob.core.usgovcloudapi.net

Table URL: https://<yourstorageacct>.table.core.usgovcloudapi.net

Queue URL: https://<yourstorageacct>.queue.core.usgovcloudapi.net

Click OK to close the dialog.

In the bottom of the page, under Named Cache Settings, set options appropriate for your use of ASP.NET Session State. The settings in the above screen shot are a representative example.

When you save these changes to the Web Role Properties editor, Visual Studio will persist your settings to the appropriate .cscfg files in your solution and, when you package the solution for deployment to Azure Government, this Service Configuration will be deployed along with your binaries.

With that, your ASP.NET web application will be able to leverage In-Role Cache for performant and fault-tolerant storage of Session State.

Note that there are other options available for storing ASP.NET session state in Azure Government. These include Azure SQL Database, SQL Server running in Azure virtual machines, or even your own Redis Cache deployment running in Azure virtual machines. A full discussion of pros and cons of these choices in beyond the scope of this post. Among these options, In-Role Cache has the benefit of excellent performance and nicely integrated tool support. Last but not least, keep your eyes out for future service enhancements to Azure Government that will provide alternative caching options.