Windows Azure : les causes de la panne de l'année bissextile

L’offre de cloud computing Windows Azure de Microsoft a rencontré à la fin du mois de février une série de problèmes qui ont conduit à une indisponibilité des services pendant plus de douze heures. Une panne logicielle qui a généré une mauvaise presse pour l’éditeur, alors qu'Azure est un produit nettement mis en avant. Des explications supplémentaires ont donc été fournies et Microsoft a décidé de dédommager ses clients.

L'hôte mécontent de son invité indésirable

On sait donc précisément pourquoi de nombreuses structures hébergées sur Azure ont été inaccessibles pendant plusieurs heures. Premièrement, il faut comprendre comment fonctionne Azure. Tout ce qui tourne dans le cloud réside dans des machines virtuelles qui sont stockées sur des serveurs. Ces derniers sont regroupés en grappes dans des clusters de 1000 machines. Les clusters sont indépendants et chacun est géré par un Fabric Controller qui surveille dans les grandes lignes l’activité du cluster, notamment ce qu’y font les applications.


L’exploitation de la Platform as a Service (PaaS) passe par l’utilisation d’un Guest Agent (invité) dans l’image du système d’exploitation fonctionnant au sein de la machine virtuelle. Par opposition, le serveur lui-même dispose d’un Host Agent (hôte). L’Host et le Guest communiquent régulièrement pour plusieurs raisons, notamment pour des transferts de données de sécurité telles que les certificats SSL.


À chaque fois qu’une application a besoin de communiquer sur des données sensibles, le Guest Agent crée un certificat de transfert reposant sur une architecture de clés publique/privée. Il établit une connexion avec l’Host Agent et expose la clé publique du certificat. L’Host chiffre alors les données qui ne pourront être lues que par le Guest possédant la clé privée. Et le problème rencontré par Azure se situe au niveau de ce fameux certificat de transfert.

L'année bissextile et la propagation du bug

À sa création, le certificat obtient automatiquement une validité d’un an. Pour paramétrer la date de fin, Azure ajoute simplement « 1 » à l’année en cours. Comme vous le savez, le souci résidait dans la gestion de l’année bissextile. En effet, les certificats créés le 29 février dernier ont obtenu automatiquement une date de fin réglée au « 29 février 2013 ». Une date qui n’existe tout simplement pas.

Les communications engendrées par le Guest Agent ce jour-là ont engendré des erreurs et n’ont pu s’établir avec le l’Host Agent. Ce dernier dispose d’une fenêtre de temps de 25 minutes pour avoir une réponse du Guest. S’il ne l’obtient pas, il réinitialise le système de la machine virtuelle et le redémarre. Et c’est là que la cascade s’est mise en place :

1. L’Host redémarre la machine virtuelle
2. Le Guest retente une connexion, qui échoue une nouvelle fois
3. Au bout de trois tentatives, l’Host considère que le serveur a une panne matérielle
4. L’information est remontée au Fabric Controller
5. Le Fabric Controller prend le relai et passe le serveur en état HI (Human Investigate) pour analyse par des techniciens
6. La machine virtuelle est « réincarnée » sur un autre serveur sain
7. Sur le nouveau serveur, le Guest recommence à générer des erreurs

Voilà pourquoi, en quelques heures, le problème s’était propagé comme une trainée de poudre dans de nombreux serveurs. Cette propagation s’est faite grosso modo comme une onde créée par un galet dans l’eau, et Microsoft est donc repassé derrière les serveurs affectés en suivant « l’onde ».

La firme indique que ce type d’incident ne se reproduira pas et que des mesures ont été prises. En outre, un rabais de 33 % sera apposé à toutes les factures pour les clients abonnés aux services Windows Azure Compute, Access Control, Service Bus et Caching. En revanche, Windows Azure Storage et SQL Azure n’ont pas été touchés et ont donc continué à fonctionner normalement.