Un datacenter en container Made by Microsoft for Azure

Wired vient de publier quelques (trop) rares photos d’un DataCenter Windows Azure à base de container : http://www.wired.com/wiredenterprise/2013/02/boydton/ . Il s’agit du datacenter de Boydton en Virginie (USA) ouvert l’an dernier.

Chaque container est bien un “mini DataCenter in a box”.

Cette vision des datacenters à base de container est très bien expliquée dans la petite vidéo suivante :

 

D’autre Datacenter Azure sont d’une architecture plus classique. Ainsi, en Europe, les datacenters reste des équipements d’architecture plus ‘classique’ :

le datacenter Windows Azure de Dublin (Irlande).

Azure : le bug du 29 février expliqué dans le détail !

L’équipe Windows Azure à publier un excellent article technique expliquant l’origine du bug du 29 février qui a perturbé le fonctionnement d’Azure pendant plus de 12 heures. Azure Storage et SQL Azure n’ont pas été impacté par ce soucis. ACS et le Service Bus ont été affecté indirectement par cet évènement.

http://blogs.msdn.com/b/windowsazure/archive/2012/03/09/summary-of-windows-azure-service-disruption-on-feb-29th-2012.aspx

Voici un résumé simplifié de l’explication technique fournit dans le billet :

L’origine du soucis est lié à un problème de date d’expiration de certificats utilisé pour sécuriser les échanges de données sensibles entre les machines virtuelles (VM) exécutant vos applications et le système de gestion des ressources des datacenter : les Fabric Controler (FC).

• Le certificat est généré/regénérer lors du démarrage des VM (après une mise à jour, un changement de nombre d’instance, un re-création d’image, … ) ou dans certains cas particuliers), afin de permettre le dialoguer enter les logiciels agents du FC tournant dans la VM et le FC lui même. Ce certificat à une durée de vie de 1 an. La génération de la date de fin se fait a partir de la date du jour (à 00h00) et à laquelle on ajoute 1 à l’année en cours. ==> Les tentatives de génération des certificats ayant lieu le 29/02/2012 UST demandaient donc une date d’expiration le ‘29/02/2013 00:00’ ce qui est une date invalide –> La génération du certificat échouait. Ce bug à commencé à se produit le 28 février à 16h00 PST (29 février 00h00 UST).
• Si, au bout de 25min, l’ agent du FC n’a pas reçut le certificat d’une VM il la considère comme problématique et déclenche la création d’une nouvelle VM de remplacement. Le phénomène se reproduit de nouveau car la création de certificat échoue à chaque fois.
• Au bout de 3 tentatives d’affilée de re-création de VM qui échoue, le FC considère le serveur physique hébergeant les VM comme problématique et retire ce serveur du pool de serveurs disponibles en le marquant comme nécessitant une intervention humaine de maintenance (HI : Human Investigate).
• Le FC va alors affecter d’autres serveurs disponibles dans le cluster (un ensemble d’environ 1000 machines) pour re-créer de nouvelles VM … sur lesquels le bug du certificat va se reproduire.
• Au fur et à mesure, de plus en plus de serveurs physiques sont marqués “HI”. Le FC déclenche une sécurité qui bloque ces automatismes quand la quantité de serveur marqué HI atteint un seuil anormal. Cette sécurité à empêcher la mise hors service de l’ensemble des serveurs des cluster mais à aussi stoppé les processus de mise à jours en cours; ce qui eu pour conséquence de laisser parfois des applications dans des états instables ou dégradées.
• Le déclenchement de cette sécurité par le FC a entrainé l’alerte des opérateurs de surveillance des DataCenter pour signifier un problème insoluble par les automatismes et nécessitant une intervention humaine urgente (17h15 PST).
• En parallèle, une mise à jour des logiciels internes du datacenter (FC et ses logiciels agents) se déroulait. Cette mise à jour déclenchait la régénération des certificats d’échanges entre les VM et les agents du FC, ce qui à eu pour conséquence de déclencher le bug dans des VM qui fonctionnait correctement, accentuant ainsi l’effet du bug en forçant la réinitialisation de VM saine. Ceci explique pourquoi des clients n’ayant demandé aucune mise à jour de leurs applications durant cette période ce sont quand même vu impacté par le bug. Les cluster non concerné par cette mise à jour interne ont été moins impacté par le bug. L’augmentation anormale du nombre de cluster en cours de mise à jour avec un seuil HI atteint a entrainé l’alerte des équipes de développement du FC et des ses agents (18h38 PST).
• A ce moment là pour éviter une aggravation de la situation par des clients voulant re-déployer des mise à jour ou forcer des redémarrages pour résoudre les soucis constaté, le service de Management (utilisé par le portail d’administration) a été arrêté pour maintenir un statu-quo (18h55 PST). Il s’agit de la première fois que ce seuil d’intervention à été atteint.
• Les équipes de développement ont codé un correctif, qui fut testé dans un premier cluster de test à 01h50 PST le 29/02, ainsi que sur un cluster de production d’application interne à Microsoft.
• Après une validation sur un cluster de production, la diffusion générale du correctif à été lancé sur tous les clusters problématiques. A 5h23 PST, Microsoft annonce la restauration du service de management.

 

• 7 clusters venaient juste de commencer leur mise à jour (soit environ 7000 serveurs physiques) lors du déclenchement du bug, ce qui a laissé les couches logicielles Azure des VM et des serveurs dans des niveaux versions différentes et incompatibles entre elles. Ces 7 clusters ont donc été traités différemment : retour vers la version précédentes MAIS avec le bug du 29/02 corrigé. Habituellement cette procédure de mise à jour est progressive et prend plusieurs heures pour respecter les disponibilités des applications, mais dans ce cas exceptionnel, une mise à mise à jour simultanée de tous les serveurs a été forcées.
• Malheureusement une mauvaise version de couche réseau a été déployé ce qui a empêché le réseau virtuel reliant les VM de se configurer, privant ainsi toutes les VM concernées de connectivité (02h47 PST). Etant donné que les processeurs utilisé dans Azure ont 8 cœurs : potentiellement jusqu’à 56000 VM de type Small ont pu être impacté par ce 2e soucis (8 cœurs * 7 clusters * 1000 serveurs).
• Ces 7 clusters hébergeait majoritairement les fonctionnalités d’Access Control et du Service Bus, ce qui explique pourquoi ces fonctionnalités ont aussi été impacté par le bug ‘grâce’ à un effet cascade.
• Un correctif du correctif a été déployés sur ces 7 clusters, et à 08h00 PST la quasi totalité des serveurs était de nouveau fonctionnel.
• Un certain nombre de serveurs de ces 7 cluster étaient dans des états instables et/ou corrompus et ont du être restaurés manuellement.
• le 1er Mars à 02h15 PST l’ensemble des services était de nouveaux fonctionnels

Le post de blog d’origine décrit ensuite les conséquences de cet incident, et le plan d’actions que l’équipe Azure va mettre en place.

Investissement sur le Datacenter Azure de Dublin

Depuis plusieurs mois, lors des formations Windows Azure que je dispense, j’évoque souvent les datacenters Azure, dont celui de Dublin (Irlande) que j’ai eu la chance de visiter fin 2011.

Pour compléter mes propos (et les confirmer ), Microsoft vient d’annoncer un investissement très important sur la DataCenter de Dublin : http://blogs.msdn.com/b/windowsazurefrance/archive/2012/02/23/microsoft-investit-130-millions-de-dollars-pour-son-datacenter-de-dublin-en-irlande.aspx

L’article est très intéressant car il met en évidence certains choix effectués par Microsoft (notamment le refroidissement par exemple).

Quel datacenter Azure privilégier pour une application ‘française’

/* Ce billet à été corrigé pour tenir compte de la vision américaine de l’europe : L’irlande fait partie de l’europe du nord, alors que les Pays bas font partis de l’europe de l’Ouest */

 

Une des questions que j’entends très souvent concernant Windows Azure concerne le choix des datacenters pour déployer les applications.

Les quelques pistes que j’évoque ci-après sont basés uniquement sur des critères techniques, le cout financier n’est pas pris en compte (je vous rappelle néanmoins que les 2 datacenters asiatiques ont un cout de ressources un peu plus élevé que ceux d’Europe ou des USA).

D’autres part, les performances sont dépendantes du fournisseur d’accès de l’utilisateur (Free.fr dans le cas des mesures évoquées ci après), des conditions transitoires pouvant survenir (charge réseau, lien saturé, routage, …), mais aussi de la localisation géographique des utilisateurs (étant lyonnais, le nombre d’intermédiaires [routeur, nœud d’interconnexion, …], et le routage des mes paquets sont probablement différents d’un lillois ou d’un parisien).

 

Le premier niveau de choix est bien entendu le continent : il faut choisir un datacenter sur le continent où vont se trouver les utilisateurs. Si votre application est à cible continentale ou mondiale, l’utilisation du DNS dynamique (Azure Traffic Manager) avec une stratégie basée sur la performance d’accès permet de router les connexions de vos utilisateurs vers le datacenter le plus ‘proche’ (meilleur performance d’accès réseau).

Dans certain cas, par exemple pour les applications à destination d’utilisateurs irlandais ou hollandais, le choix est vite effectué : Europe de l’ouest (=Amsterdam, Pays Bas) pour les hollandais , et Europe du Nord (=Dublin, Irlande) pour les irlandais.

La question reste posée pour les pays à mi-chemin ou plus éloignés … comme la France par exemple.

Plutôt qu’une réponse théorique, privilégions la pratique !

J’ai déployé la même application ASP.NET basique sur les datacenters Azure d’Europe du nord (Irlande) et d’Europe de l’ouest (Pays Bas). Les 2 déploiements sont strictement identiques (même packaging de déploiement, même fichier de configuration).

Nous avons à notre dispositions 2 utilitaires Windows très pratique pour estimer la ‘performance d’accès réseau’ à un ‘datacenter’ :

• tracert.exe : permet d’obtenir une trace de tous les nœuds réseaux empruntés par nos paquets de données entre le poste de l’utilisateur et le datacenter cible
• ping.exe : permet d’estimer le temps de transit réseau des paquets entre le poste de l’utilisateur et le datacenter cible.

J’ai effectué plusieurs fois les test avant de prendre les captures écrans pour être sur que les requêtes DNS (ou autres services réseaux) ne viennent pas perturber les chronométrages.

Bien entendu, les mesures ci après ont été effectuées sans DNS dynamique.

Ping

: ce test n’est pas utilisable avec les datacenters Azure car le firewall intégré bloque les requêtes PING/PONG. Tant pis pour les gamers qui ne jure que par le ping

Tracert :

WEST Europe datacenter                        NORTH Europe datacenter

 

Le trajet suivi par nos paquets est le même jusqu’à un nœud appelé ‘ams-ix-2.microsoft.com’. Au delà le trajet est masqué pour le datacenter d’europe de l’ouest, et guère plus significatif pour l’Europe du Nord.

Quoi qu’il en soit , quel que soit le datacenter cible, nous passons par Amsterdam (ams-ix-2 est iplocalisé a Amsterdam) !

 

La logique technique pure et dure veut que le datacenter hollandais soit à privilégier du fait de sa proximité.
Ce choix semble d’autant plus judicieux que la route pour rejoindre le datacenter irlandais passe elle aussi par les Pays Bas !

 

Dernier test : le chronométrage de l’application à partir d’un poste utilisateur : on appelle la même page de l’application (about.aspx) sur les 2 datacenters, et on compare le temps nécessaire pour obtenir la réponse complète. Les machines virtuelles exécutant les applications Azure sont basées sur des matériels équivalents, la différence de chronométrage sera donc du fait de l’infrastructure réseau.

Le chronométrage a été effectué a l’aide de la “developper toolbox” d’IE9 (et confirmer par un test batch), avec le cache navigateur actif. Les 2 captures qui suivent correspondent à la moyenne des chronométrages observés :

WEST Europe datacenter                            NORTH Europe datacenter

 

Verdict :

      Europe du Nord (Irlande) :  ~300ms

      Europe de l’Ouest (Pays Bas) :  ~  90ms

 

Donc, dans les conditions de réalisation de mon test (à partir de Lyon, ADSL Free) , l’hébergement de l’application dans le datacenter hollandais d’Azure (c’est à dire dans la vision américano centrique , le datacenter « d’Europe de l’Ouest » me fournit un temps de réponse globalement au moins 3 fois meilleurs !!

Le datacenter Hollandais (d’Europe de l’Ouest) est donc à privilégier.