Bon, ne vous fiez pas au titre de ce blog post : la fonctionnalité que je vais vous présenter n’a jamais disparu de Windows Azure, c’est juste qu’elle était jusqu’à présent restée abritée bien au chaud dans l’ancien portail (celui en Silverlight). Je vais donc profiter de sa toute fraiche migration dans le nouveau portail pour présenter ce service peu connu mais fort utile de Windows Azure : le traffic management ! Amis de la recherche de la performance extrême en Web, ce service est pour vous !

A quoi cela sert?

A titre d’indice sur le rôle de ce service, il a déjà une première particularité : c’est un des rares services Azure qui est multi-datacenter, alors que pour la quasi-intégralité des services Azure, la première action  lors de la création consiste à choisir le datacenter.

La raison: le Traffic Manager permet tout simplement de regrouper plusieurs services hébergés dans un ou plusieurs DataCenters derrière une seule URL, et de permettre du coup des scénarios de répartition de charge multi-datacenters ! L’administrateur va ainsi pouvoir sélectionner dans le portail d’administration plusieurs services déployés derrière des URL http://*.cloudapp.net et les regrouper sur une seule adresse de type http://*.trafficmanager.net . C’est ensuite le service de Traffic Management qui va s’occuper de rediriger la requête de chaque utilisateur vers le bon DataCenter, en fonction des règles de configuration choisies.

Les différents modes de load balancing

Le Traffic Manager propose 3 types de répartition de charge pour autant de scénarios différents :

• Performance :
• Dans ce mode-la, les requêtes émises par les utilisateurs de l’application déployée dans Azure vont être redirigées vers le DataCenter le plus proche, pour minimiser la latence.
• Par exemple, si le TrafficManager regroupe le même service déployé sur 1 Datacenter en Europe et sur un 1 aux états unis, et que l’utilisateur se situe au Canada, les requêtes seront automatiquement redirigée sur celui des états unis, qui est le plus proche géographique (et d’un point de vue réseau).
• Round Robin :
• Avec cette configuration, les requêtes vont être distribuées de manière égale entre les différents services sélectionnés.
• Ceci permet par exemple de faire de la répartition de charge sur plusieurs services déployés dans un même DataCenter, ou bien de repartir une charge de manière équitable entre deux DataCenters d’une même plaque géographique tels que Dublin et Amsterdam.
• Failover :
• Ce dernier mode offre la possibilité de maximiser la disponibilité d’un service hébergé dans Azure, même en cas de défaillance d’un Datacenter, en publiant l’application sur plusieurs DataCenter avec une notion de mode Actif / Passif.
• Par exemple, si une application est déployée à Dublin (en primaire) et à Amsterdam (en secondaire), avec le TrafficManager configuré, et que le DataCenter de Dublin tombe en défaillance, les requêtes seront automatiquement redirigées et traitées par celui d‘Amsterdam qui deviendra actif jusqu’à la reprise d’activité de celui de Dublin. Ce mode permet également de gérer des scénarios de déploiement sans interruption de service (mise à jour d’un service en mode inactif, puis rebascule une fois que celle-ci est effectuée).

Dans tous les cas, pour assurer une continuité de traffic, Le Traffic Manager se charge automatiquement de surveiller la disponibilité des services qu’il regroupe. Il ne redirigera ainsi jamais une requête sur un service défaillant. D’un point de vue configuration, il suffit pour cela de lui donner une URL à surveiller, si celle-ci devient inactive, la balance s’effectuera automatiquement.

Configuration

A la création d’un EndPoint du TrafficManager, il est demandé de spécifier :

• Une URL (qui pourra bien sur être masquée derrière un alias DNS CNAME)
• Le nom de l’abonnement à utiliser
• Le type de répartition de charge à utiliser
• La liste des services hébergés dans Azure à regrouper

A l’exception de l’URL, chaque élément  de configuration peut être modifié une fois le service activé. Il est ainsi possible sans soucis d’ajouter des services (endPoints) ou de modifier le type de répartition de charge après coup.

Conclusion

Encore un service à utiliser sans modération pour les applications Web à fort trafic !