Multiple affinity cookies

1
votes

I have multiple azure websites with the following characteristics

  • each website run on its' own webserver (app-service plan)
  • they are running multiple instances
  • they have their own subdomain under a shared domain
  • they have ARR enabled (purposefully)

One of these sites is the primary site, and uses the domain, without subdomains as its' hostname. This is the root cause of my problem.

Visiting sub.domain.com and domain.com respectively (two different websites, in different app-service plans) will set an affinity cookie for each of those sites.

The cookie spec states that cookies should be included in requests to any subdomain, of the cookies' domain property. That means, if I now visit sub.domain.com, the browser will include both affinity cookies, since it's technically a subdomain of domain.com.

Azure's loadbalancer apparently only looks at the first included affinity cookie. And if this happens to be the one that belongs to domain.com it will contain an invalid value, and the loadbalancer round robins the request to a random free instance. The response will contain a set-cookie header with a valid affinity cookie, but this will be included as the second cookie in subsequent requests anyway, and the issue remains. This effectively completely disables ARR for all subdomains, for as long as the domain.com affinity cookies lives, along with sticky sessions, which our sites depend on.

For now, I've disabled ARR on the domain.com website, since it only runs in a single instance. But this is only possible because we are in preproduction. At some point in the near future, I will need to scale out to at least two instances, as it is required for the azure SLA to be in effect.

The problem can be solved by migrating the site on domain.com to a subdomain (f.ex.: www.domain.com) but I would really prefer not to.

Ideally I would like the loadbalancer to examine all included affinity cookies, rather than just the first. But untill that is fixed, I would love to know of any workarounds. As far as I can discover, the only aspect of ARR I can control is whether is should be enabled or not.

1
azureazure-web-app-servicearr
Wow, never actually thought of this scenario. Have you submitted a support ticket to Azure? Also, having your app reliant on ARR working is always a little bit dangerous as then if an instance goes down for whatever reason you will get problems. I do understand certain legacy apps require it. – juunas
Got an active ticket as we speak, I'll report back here on it's outcome. Also, I completely understand and agree with your point. – Mikal Schacht Jensen

1 Answers

0
votes

Here's the reponse from the Azure support team regarding the issue:

I wanted to let you know the status of the issue. The product team has analyzed the issue and they will look into it. They have agreed that the best solution is for ARR to iterates thru all cookies.

Unfortunately right now we don’t have any ETA so for now the best workaround, as you said, is adding the www to your naked domain.

To be honest I think this is the best possible outcome. Azure has recognized the problem, and is committed to correcting it. Untill then, the possible workarounds, if you need sticky sessions, is to either

  • Not use both the naked domain and subdomains on sites that don't share an app service plan
  • Use shared sessions across website instances, and thus elliminate the need for ARR entirely. In ASP.NET it is easy to set up a different sessionsstate provider, using SQL, Redis, Azure Storage or something else as session storage.