none
Will Azure Load Balance correctly and avoid a problem that App Harbor had to patch for me?

    Question

  • I have a somewhat unique scenario:

    All of my traffic will be coming via a proxy server and thus appear as a limited set of IP address
    representing traffic from hundreds of thousands users.

    I had 10 App Harbor instances and when i hit traffic of 80,000 users in 60 mins everything died because the load balancer was using sticky sessions and not spreading load to the other 9 instances.

    AppHarbor very quickly and efficiently changed the way nginx does load balancing to switch off the `ip_hash` nginx directive and after I experienced problems, they disabled this for all sites on App Harbor.

    I am now looking at moving to Azure, and I cannot have this issue again. Prior to me doing the effort
    of changing to Azure I would like to know the answer to this.

    Prompt response appreciated please.

    Friday, June 22, 2012 10:58 AM

Answers

  • Windows Azure Web Sites runs a set of proxy servers using ARR that sit behind the Windows Azure load balancers.  These ARR servers have sticky load balancing turned on and as a result every website hosted in Windows Azure Web Sites will get sticky routing.

    You can see this happening when looking at the raw HTTP request/responses.  There will be a cookie sent by ARR for newly established HTTP connections that looks something like:

    Cookie: ARRAffinity=7c8597a1c1f43f6bbf23e7c591483378b0bc7e62a6ea5da8fe4fc0065d446e1d

    Already established HTTP connections from browsers (or user agents) that send this cookie along on subsequent requests, will be routed back to the same web server.

    Sunday, June 24, 2012 6:01 PM
    Moderator

All replies

  • Well I am very impressed with Azure websites and virtual machines...

    The support or ability to get support however is pie in the sky. Can someone answer the above question please.

    I'm setup and ready to move to Azure...

    Friday, June 22, 2012 1:10 PM
  • HTTP connections from new clients will get load balanced across all of the reserved instances running a website.

    HTTP connections from an existing client will get routed back to the same web server since we do turn on sticky load balancing.

    Note though that in this case "sticky" means when User A makes a second request to a website, they get routed back to the same VM.  However a new client coming along (i.e. User B) will get routed randomly to any of the available VMs running the website.

    Friday, June 22, 2012 6:00 PM
    Moderator
  • The definition of a new client is critical then. my app is stateless and has no cookie or session dependancies as the "gateway app" provides identifying info in http headers so i dont require stickyness at all. please provide what identifies a new client/connection as new.
    Friday, June 22, 2012 6:42 PM
  • Stack exchange and other blogs all state Azure uses round robin contradicting what you have said

     eg http://coderead.wordpress.com/2011/09/12/sticky-sessions-and-windows-azure/

    Friday, June 22, 2012 7:12 PM
  • Windows Azure Web Sites runs a set of proxy servers using ARR that sit behind the Windows Azure load balancers.  These ARR servers have sticky load balancing turned on and as a result every website hosted in Windows Azure Web Sites will get sticky routing.

    You can see this happening when looking at the raw HTTP request/responses.  There will be a cookie sent by ARR for newly established HTTP connections that looks something like:

    Cookie: ARRAffinity=7c8597a1c1f43f6bbf23e7c591483378b0bc7e62a6ea5da8fe4fc0065d446e1d

    Already established HTTP connections from browsers (or user agents) that send this cookie along on subsequent requests, will be routed back to the same web server.

    Sunday, June 24, 2012 6:01 PM
    Moderator
  • Holy Smokes! Does this mean that Azure Websites officially support a sticky-IP load balancing scheme? Is the plan to maintain this behavior moving forward?

    I understand the argument that applications should be stateless for the sake of elastic scaling, but legacy applications often depend on session state heavily. Dealing with this using webroles has been a mess and SEVERELY limits the ability to host legacy applications on Azure.

    Saturday, March 02, 2013 12:18 AM