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.
Advertisements
Using IIS Application Request Routing to load balance on Azure « Richard Astbury's Blog 1:29 pm on October 13, 2011 Permalink | Log in to Reply
[…] 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 | Log in to Reply
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 | Log in to Reply
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 | Log in to Reply
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
Cloud Architecture Patterns @ Book | Parroty's Blog 11:50 am on June 23, 2013 Permalink | Log in to Reply
[…] Windows Azure provides a way to use sticky session, but it’s not a great fit, and recommended to move to stateless architecture (Sticky Sessions and Windows Azure). […]
Java and Azure | Richard Astbury's Blog 12:40 pm on June 26, 2013 Permalink | Log in to Reply
[…] sessions are required, and the Azure load balancer in Cloud Services is round-robin (sort of). Sticky sessions aren’t very cloud friendly, but it’s difficult to make legacy application […]
kmmoussa 8:27 pm on March 8, 2014 Permalink | Log in to Reply
Reblogged this on Windows Azure Ultimate Guide and commented:
Thanks to Richard Astbury!