Sticky Sessions and Windows Azure
One of the problems that often crops up with moving legacy applications to the cloud is reliance of sticky sessions. The Azure load balancer works on a round-robin basis, so if your application has been designed to work on a sticky session basis, you may have some work to do.
Although it is possible to use Sticky Sessions in Azure (see this example) it’s not a great fit for cloud architecture, for these reasons:
- When you provision new instances, only new sessions will be routed to them. Depending on your load balancing logic, new sessions may also still be provisioned on the old instances. This results in it taking a long time (depending on the average length of your session) for load to be evenly distributed across your instances.
- Cloud solutions should be designed to fail. One of your instances may be removed at any time for patching, or hardware failure. With a sticky session scenario, the clients with a session on this instance will probably have to log in again, or may see an error page, depending on your load balancing logic.
- Unless your load balancer shares state in some way, it’s likely that you’re load balancing with a single instance (single point of failure) and not eligible for the Microsoft SLA.
So what options are there?
- Use the Azure AppFabric Cache to share ASP.NET session state across your instances. This walk through shows you how, by simply changing your Web.config.
- Ideally move to a stateless architecture, making use of cookies or the database where appropriate. Designing an application in this way will provide you with the best scaling potential, and allow you to get the most from the cloud.
Paul, and 1 other are discussing. 
Using IIS Application Request Routing to load balance on Azure « Richard Astbury's Blog 1:29 pm on October 13, 2011 Permalink |
[...] IIS Application Request Routing to load balance on AzureAs previously discussed, cloud applications should be written to be stateless, and use the standard Azure round-robin load [...]
Paul 9:22 am on January 23, 2013 Permalink |
Hi Richard, would you mind expanding on point #3 please? What is the single-point-of-failure in this case and how does that affect the SLA?
Richard 9:30 am on January 23, 2013 Permalink |
Sure, to achieve the 99.95% SLA, you must have two instances of every role. It you just have one, you get a 99.9% SLA.
However, as you can load balance with a cookie, you can set up several instances without having to share the state.
ARR does this quite well, I have a project here which sets it up as a sticky session load balancer in Cloud Services: https://github.com/richorama/AzureARR
Richard Weston 7:29 pm on January 24, 2013 Permalink |
Richard, great post on why moving away from relying on sticky sessions is a good idea.
One thing any of your readers should be aware of though. If you plan to use SharePoint 2010 with FBA or Claims then using sticky sessions is a requirement. Clearly Microsoft have not followed best practices when designing SharePoint 2010 and scalability!!!
See: http://blogs.technet.com/b/speschka/archive/2011/10/28/make-sure-you-know-this-about-sharepoint-2010-claims-authentication-sticky-sessions-are-required.aspx
Rich