Windows Azure Traffic Manager (Cloud Cover Show 132)

Voici l’essentiel de l’épisode 132 du Cloud Cover Show paru il y a quelques jours.

Dans cet épisote, Chris Risner, Haishi Bai et Stephen Malone (Program Manager dans l’équipe Traffic Manager) nous présentent Windows Azure Traffic Manager.

Windows Azure Traffic Manager est un service de répartition de charge (Load Balancing) qui a pour but de répartir le trafic entre plusieurs instances d’une application sur Windows Azure, dans le but d’obtenir les meilleurs performances et/ou la meilleure disponibilité de service pour vos utilisateurs.

Contrairement au Load Balancer classique de Windows Azure qui vous permet de répartir la charge réseau entre plusieurs machines (ou instances) au sein du même service, Traffic Manager fonctionne en amont, au niveau DNS, pour rediriger les requêtes d’un domaine sur l’un des services Windows Azure associés, qu’ils soient dans le même Datacenter ou répartis sur plusieurs tout autour du globe.

Il existe actuellement 3 politiques de répartition différentes, en fonction de ce qui est recherché pour l’application :

Performances, qui choisit le service le plus proche, en terme de latence réseau, pour l’utilisateur qui souhaite accéder à l’application.
Tourniquet, ou “Round-robin”, où la charge est distribuée de manière équilibrée sur tous les services.
Basculement, ou “Failover”, où vous classez vos services par ordre de priorité, afin d’indiquer au Traffic Manager de rediriger vers le service le plus haut dans la liste, tant que celui-ci est disponible, et de passer sur le suivant en cas de problème.

Pour cela, Windows Azure Traffic Manager sonde lui même les services pour détecter d’éventuelles indisponibilités. Il n’y a rien de particulier à gérer pour votre application, un code retour 200 sur une page donnée suffira à satisfaire le système. Bien sûr, vous pouvez développer une logique particulière vous-même sur une telle page pour renvoyer le code 200 seulement si tous les voyants sont au vert au niveau applicatif, et pour indiquer à Traffic Manager de ne pas router d’utilisateurs sur le service si ce n’est pas le cas.

Au début de la 4e minute de la présentation, un point important est levé : le routage ne prend pas en compte d’éventuelles sessions utilisateurs. Dit autrement, Windows Azure Traffic Manager n’implémente pas de Sticky-Session.
Tant que l’enregistrement DNS résultant du choix du service est caché par le client, il utilisera le même service, mais il pourra être redirigé dès que ce cache expirera.
Bien sûr, c’est vous qui contrôlez le TTL (Time To Live) de ce cache DNS, qui est positionné par défaut à 5 minutes et qui peut descendre jusqu’à 30 secondes. Plus il est bas, plus vous aurez de chance de rediriger rapidement l’utilisateur vers un service qui fonctionne dans le cas d’une défaillance. Plus il est haut, plus vous vous assurerez qu’un utilisateur donné utilise le même service le plus longtemps possible.
Il est donc essentiel d’utiliser le Traffic Manager seulement sur des applications préalablement rendues “stateless”, où ce changement de service n’aura pas d’impact pour l’utilisateur final.

Il est essentiel de noter que pour le moment, Windows Azure Traffic Manager supporte seulement les services de type machines virtuelles (Windows Azure Virtual Machine) et les Web/Worker Roles (Windows Azure Cloud Services).

Les bénéfices de Windows Azure Traffic Manager sont les suivants :

Mise en place très simple et très rapide
Performance accrue si vos utilisateurs sont répartis géographiquement
Disponibilité de votre application améliorée

Les scénarios d’utilisation sont les suivants :

Développement d’applications hautes performances
Mise en place de stratégies de “Disaster recovery”
Mise à jour progressive de votre application

Ce troisième scénario est détaillé à partir de 14:50. Le principe est d’utiliser la capacité de Windows Azure Traffic Manager de sortir l’un des services du lot (en ne renvoyant plus la valeur 200 sur la page utilisée par la sonde et en attendant l’arrêt des requêtes sur celui-ci en fonction du TTL choisi), afin de pouvoir le mettre à jour, le tester, puis le remettre dans le lot une fois ces étapes terminées, et cela de manière successive sur chacun des services. Il est ainsi possible de mettre à jour une application distribuée sur plusieurs Datacenters, sans générer d’indisponibilité pour vos utilisateurs.

A partir de 17:10, Stephen se lance dans une une démonstration d’une application disponible à la fois en Europe, en Amérique du Nord et en Asie. Il en profite pour détailler le fonctionnement de la sonde et de l’impact d’un arrêt de l’un des services, où on apprend que la sonde va sortir le service qu’au bout de 3 échecs successifs, soit environ 2 minutes, à quoi vous devez ajouter le TTL choisi, soit une réaction en 2 min 30 dans le meilleur des cas, ce qui est largement plus rapide qu’une intervention humaine.

Si vous souhaitez tester cela par vous-mêmes et que vous n’avez pas encore de compte Windows Azure ni d’abonnement MSDN, ouvrez un compte de test gratuit, vous obtiendrez 150 € de ressources pendant 1 mois.

Vous trouverez ci-après quelques images de l’épisode.

Benjamin (@benjiiim)

Début de l’épisode, avec Stephen Malone, Program Manager dans l’équipe Traffic Manager, et irlandais de surcroit !

Proposition de valeur de Windows Azure Traffic Manager

Principe de Windows Azure Traffic Manager

Bénéfices de Windows Azure Traffic Manager

Scénarios d’utilisation de Windows Azure Traffic Manager

Illustration des bénéfices du mode Performance

Illustration de la capacité de Windows Azure Traffic Manager à rediriger l’utilisateur seulement vers les services disponibles, quel que soit le mode utilisé.

Illustration de scénario de mise jour d’une applicaiton distribuée sur plusieurs Datacenters, de manière progressive, sans indisponibilité pour les utilisateurs.