5

For a proof of concept paper, I collected facts about Windows Azure. There are 2 topics remaining I could not find a definitive answer for.

  1. Sticky sessions/sticky load balancing is not possible, am I right? Maybe there is a possibility with the help of Azure traffic Manager (WATM)?

  2. Can single instances of a deployment be addressed, or are they all behind this non-transparent wall of Azure? Or at least, can an instance at runtime determine its own id or something like that in order to write it into a log?

David Makogon
  • 69,407
  • 21
  • 141
  • 189
alapeno
  • 2,724
  • 6
  • 36
  • 53

3 Answers3

1

Please find the answers bellow:

  1. Sticky sessions/sticky load balancing is not possible, am I right? Maybe there is a possibility with the help of Azure traffic Manager (WATM)?

You are correct. There no sticky sessions with Windows Azure. And no, you cannot use Traffic Manager to help you about stickiness. Traffic Manager will only help you distribute load across Roles, not instances. Please do make a difference between Role and Instance. Take a look at this question for more info on Roles and Instances.

2. Can single instances of a deployment be addressed, or are they all behind this non-transparent wall of Azure? Or at least, can an instance at runtime determine its own id or something like that in order to write it into a log?

You cannot address a specific instance. All are behind Windows Azure Load Balancers and FireWall. But you can discover, from the code, which is your current role instance. Use the CurrentRoleInstance property of RoleEnvironment class. This will be an object of type RoleInstance, which has an ID property.

Community
  • 1
  • 1
astaykov
  • 30,768
  • 3
  • 70
  • 86
  • This thing claims to implement sticky sessions http://archive.msdn.microsoft.com/stickyrouter – sharptooth Nov 22 '11 at 09:38
  • Thanks for pointing this out. However this thing uses additional Worker Role. And although I'm a fan of optimizing and might put the "Worker code" in a "Web role", I still think this is unnecessary exercise. I would rather change my code to be stateless and stickyless oriented. – astaykov Nov 22 '11 at 09:49
  • Okay, thanks so far. Can anyone explain how this Sticky Session Router for Azure (sharptooths link) is able to work if it is not possible to address instances? – alapeno Nov 22 '11 at 09:51
  • As David points in hist answer, you are able to address instances internally - from within the same deployment (a worker role, or worker code within web role), via their direct IP addresses (or DIP). What you cannot do is **externally** access specific instance (and this is where your web site visitors come from). – astaykov Nov 22 '11 at 13:53
1

As pointed out by astaykov, role instances are always behind a firewall, and you have no ability to access a specific instance from outside your deployment.

The only way to accomplish sticky sessions is to build a request router. Once you have this running (e.g. in its own Web or Worker role, as in the example pointed to by sharptooth, within the same deployment), that role can then access internal endpoints of the other roles in the deployment.

While internal endpoints aren't load-balanced, the request router may enumerate all instances of an internal endpoint (getting ip:port for each) and then do its own load balancing or routing.

For an example of inter-role communication using internal endpoints, take a look at this msdn article.

David Makogon
  • 69,407
  • 21
  • 141
  • 189
0

There isn't a definitive answer yet, but the three best options are:

  1. State Server - This will allow you to get encrypted data from server to server even outside your network. You can do this by implementing a State Server on each instance of your web applications or servers.

  2. SQL Server (in memory, this only is available in 2014 and newer versions)

  3. Redis Cache on Azure

The three options have handled just about any session issue I've come across in the last three years.

Nathaniel Ford
  • 20,545
  • 20
  • 91
  • 102
jaxcoder
  • 46
  • 1
  • 10