Affinité de session sur Azure avec ARR –Session Affinity on Azure with ARR

Artikel
03/25/2011

Français

English

Le répartiteur de charge d’Azure n’a pas d’affinité de session ce qui peut poser problème pour des applications existantes qui ne supportent pas l’hébergement en ferme Web sans que l’affinité de session soit disponible, i.e. dans un environnement où un utilisateur peut avoir une requête servie par un serveur de la ferme Web et une autre requête de ce même utilisateur servie par un autre serveur de la ferme Web. L’Application Request Routing d’IIS est capable de gérer l’affinité de session. L’idée est donc d’avoir une ferme entre le load balancer Azure et le Web Role.

Azure load balancer does not have session affinity which may be an issue for some existing application that don’t completely support Web Farm hosting when no session affinity is available, i.e. in an environment where one user may have a request served by one server in the web farm and another request for that same user served by another server in the farm. IIS’ Application Request Routing (ARR) is capable of implementing session affinity. The idea is to have a farm between Azure load balancer and the Web Role.

Dans ce billet, on essaie d’implémenter ARR dans Azure sans l’automatiser. Cette première étape a pour but de tester l’implémentation manuellement. Mise à jour le 30-MAR-2011 L’automatisation est disponible ici ARR est un composant d’IIS. On doit décider si cette ferme ARR devrait être implémentée sur un VM Role, un Worker Role ou un Web Role. Un VM Role est un bon choix seulement quand ni le Web Role ni le Worker role ne conviennent puisque moins on gère l’OS mieux on se porte. A la fois le Worker role et le web role ont IIS déjà installé. La différence principale est que le Web Role a déjà un site Web par défaut démarré et opérationnel avec l’application Web (ASP.NET, PHP, …) que vous forunissez. Dans notre cas, on n’a pas d’application Web à fournir pour la ferme ARR donc le Worker role devrait être le bon choix. On utilise le dernier SDK disponible qui est la V1.4. De façon à tester, on aura besoin d’accéder aux machines Azure via Remote Desktop. Pour cela, créons une application cloud avec un worker role et un web role.

In this blog post, w'e’ll try implementing ARR in Azure without automating it. This first step is to try implementing it manually in order to check that it can be implemented. 30-MAR-2011 UPDATE Automation is available here ARR is a component of IIS. We have to decide whether this ARR farm should be implemented as a VM Role, a Worker Role or a Web Role. A VM Role is a good choice only when Web role or Worker role don’t make it because the less you have to manage the OS the better. Both Web role and worker role have IIS already installed. The main difference is that a Web Role already has a default web site up and running the Web application (ASP.NET, PHP, …) you provide. In our case, we don’t have a web application to provide for the ARR farm so the worker role would be a better choice. We use the latest SDK available which is V1.4. In order to test, we’ll need the Azure machines acessible thru Remote Desktop. For that let’s create a new cloud app with a worker role and a web role

Configurons la solution pour que l’application Web indique quel serveur dans la ferme a servi la requête.

Let’s configure the solution so that the Web Application displays which web server in the farm is currently serving the request

 using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace WebRoleWebApp
{
    public partial class _Default : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            lblMessage.Text = string.Format("Current Web Server machine name = '{0}'", Environment.MachineName);
        }
    }
}

Configurons également le projet de façon à ce que le Web Role soit sur le port 8080 pour laisser le Worker Role ARR frontal répondre sur le port 80 par défaut du protocole HTTP.

Let’s also configure the project so that the Web Role have its endpoint configured to port 8080 instead of 80 and the worker role has an HTTP endpoint on port 80.

Pour tester, on a besoin de 2 instances dans le web role et 1 instance dans le worker role, puisque le worler role sera configuré manuellement. ARR utilise les cookies pour garder l’affinité de session et donc si cela fonctionne pour une ferme ARR d’une instance, il y a de bonnes chances que cela fonctionne également avec une ferme de 2 serveurs ARR (ce sera tout de même testé par la suite). La configuration est donc

While testing, we need a 2 instance web role and a 1 instance worker role, because the worker role will be setup manually. ARR uses cookies to have sticky sessions so if it works with a 1 instance ARR farm, there are good chances that it also works with a 2 instance ARR farm (this will be tested afterwards). So the configuration is

Demandons Windows Server 2008 R2 (au lieu de Windows Server 2008 SP2)

Let’s require Windows Server 2008 R2 (instead of Windows Server 2008 SP2)

Déployons maintenant avec Remote Desktop (les détails exacts sont en dehors du sujet de ce billet)

Let’s now deploy this with Remote Desktop configured (the exact details of this are out of the scope of this blog post)

Connectons-nous maintenant à l’instance de worker role à travers Remote Desktop

Let’s now connect thru Remote Desktop to the worker role instance

On devra accéder à Internet avec IE, on configure donc Internet Explorer pour cela

We’ll have to access the Internet thru IE, so let’s configure Internet Explorer to allow that

Installons Web Platform Installer depuis https://www.microsoft.com/web/downloads/platform.aspx

Install Web Platform Installer from https://www.microsoft.com/web/downloads/platform.aspx

Puis cherchons ARR et installons le

Then search for ARR and install it

De façon à avoir les deux adresses IP du Web Role, on utilise Remote Desktop et la console d’administration IIS. Sur chaque instance du web role:

In order to get the 2 web role instance IP addresses we’ll use the Remote Desktop and IIS administration console. On each web role instance:

dans notre exemple, on a Web Role instance 0 à 10.211.195.44:8080 et Web Role instance 1 à 10.211.201.230:8080 Configurons maintenant ARR de façon à ce qu’il répartisse la charge sur les deux instances du web role

so in our example, we have Web Role instance 0 at 10.211.195.44:8080 and Web Role instance 1 at 10.211.201.230:8080 Let’s now configure ARR so that it load balances the web role instances

Yes

L’accès depuis le worker role en remote desktop est OK

Accessing from Worker role remote desktop is ok

NB: comme j’ai écrit ce billet en deux fois, les adresses IP des machines changent à partir de maintenant. De plus, le service est à partir de maintenant déployé sur benjguin2.cloudapp.net au lieu de benjguin.cloudapp.net

NB: as I wrote this blog post in several steps, the IP address and names of the machines may differ before and after this note. Moreover, after this note, the service is deployed to benjguin2.cloudapp.net instead of benjguin.cloudapp.net.

Changeons l’application pool du site web par défaut

Change the Application Pool of the Default Web Site

Changeons le binding du site web par défaut

Change the binding of the Default Web Site

Navigons sur le service depuis noter machine

Browse to the service from our machine

Configurons l’affinité

Configure client affinity

Il est aussi possible de changer d’algorithme pour la répartition de charge (pour la première fois qu’ARR affecte un serveur à un client quand il y a de l’affinité)

It’s also possible to change the algorithms for load balancing (first time ARR chooses a machine for a request when there is client affinity)

Testons avec plusieurs sessions de navigateur, rafraichissons, etc…

Test with several browser sessions, refresh, and so on…

En rafraichissant, chaque session garde son propre serveur. Fiddler mintre les cookies générées par l’application ASP.NET du web role et par ARR dans le worker role

While refreshing, each session keeps its own server. Fiddler shows the cookies generated by the Web Role ASP.NET Application and by the ARR Worker Role

Tout marche. Ajoutons un second serveur dans le worker role ARR.

Everything’s OK. Add a second server to the ARR Worker Role

NB: les instances existantes continuent de tourner pendant que la nouvelle est ajoutée Quand le second serveur de la ferme ARR est dispo, on le configure exactement comme le premier. On teste à nouveau. Cela ne change rien dans le comportement, mais on a maintenant une configuration de production (à part l’automatisation) avec de la haute disponibilité. De façon à voir quelle serveur ARR envoie la requête, on change les en-têtes HTTP sur chaque instance ARR.

NB: existing instances continue running while the additional instance is provisioned When the second server in the ARR farm is available, configure it exactly as the first one. And test again. This does not change anything in the behavior, but you now have the same configuration as a production one (minus configuration automation) with high availability. In order to know which ARR server sends the request, we change the HTTP Response Headers on each ARR instance.

Preque la même chose sur l’autre noeud (WorkerRole1 au lieu de WorkerRole0)

nearly the same on the other node (WorkerRole1 instead of WorkerRole0)

Testons encore, utilisons Fiddler, ça marche!

Test again, refresh, use Fiddler, enjoy!

Rafraichissons, on a une autre instance ARR qui sert la requête, et on est toujours routé vers la même instance du web role pour cette session de navigateur

refresh, have another ARR instance serving the request, and still be routed to the same Web role instance for that browser session

Après quelques rafraichissements sur chaque instance, chaque session IE a toujours sa propre instance de web role

After a few refreshed on each instance, each IE session still has its own web role instance

Bien sûr, tout cela demande à être automatisé de façon à pouvoir être utilisé en production? Par exemple, quand une instance de la ferme ARR reçoit des notifications pour un changement de configuration de l’application, elle doit récupérer les adresses IP des instances du web role et reconfigurer ARR.

La documentation ARR peut être trouvée aux alentours de cette page: https://go.archims.fr/i1h69V

Of course, all this needs to be automated so that it can be used in production with Azure. For instance, when an ARR farm instance receives notifications that the configuration of the application changed, it must get the Web Role instances IP address and reconfigure ARR.

ARR Documentation can be found around this page: https://go.archims.fr/i1h69V

Smile

Benjamin

Comments

Anonymous
March 29, 2011
Hi Benjamin,Session affinity for ASP.NET in Azure is a very interesting topic. Could you also write about session affinity + WCF?Regards,Sandrino
Anonymous
October 11, 2011
Sorry for this very late response. For some reason, I didn't get an e-mail notification for that comment.For what kind of scenario would you like to have session affinity with WCF? For stateful web services (some argue that they shouldn't exist), combining WCF + WF would be the answer. A WF container in in Azure roadmap. cf channel9.msdn.com/.../SAC-867TregardsBenjamin

Freigeben über

Affinité de session sur Azure avec ARR –Session Affinity on Azure with ARR

Comments

Zusätzliche Ressourcen