Microsoft a décidé d'offrir des compensations à ses clients suite à la panne dûe à un bogue logiciel qui a perturbé son service cloud Azure le 29 février dernier. Le fournisseur offre un crédit temps de 33% aux clients affectés. Microsoft précise sur le blog de Windows Azure que la concomitance de deux évènements est à l'origine du problème : d'une part, dans le calendrier, la date du 29 février ne se produit que tous les quatre ans, et d'autre part, quand Azure initialise ses machines virtuelles pour installer les applications de ses clients, le service délivre un certificat valable pour la durée de l'abonnement. A partir de 16h le 28 février, les certificats délivrés sur la côte est des États-Unis portaient une date de validité courant jusqu'au 29 février 2013. Or, en 2013, le mois de févier ne comportera plus 29 jours et ces certificats ont donc été considérés comme non valides.

Cette défaillance a déclenché des séries de requêtes provoquant des erreurs successives et répétées, si bien que le système en a déduit que le matériel sur lequel tournaient les machines virtuelles était lui-même défaillant. Du coup, le système a entrepris de migrer les machines virtuelles concernées vers un autre serveur dans le même cluster Azure, lequel comporte environ 1 000 serveurs physiques.

Une fois la migration effectuée, les machines virtuelles n'ont pas pu davantage s'initialiser pour cette même raison liée à la date du certificat, et toujours plus de hardware était diagnostiqué comme défaillant par le système. Jusqu'à ce qu'un seuil soit atteint, qui a mis fin à toutes les tentatives de déplacer encore et encore les machines virtuelles des clusters faussement soupçonnés. Selon le blog, l'activité des clusters a été réduite mais maintenue. Azure a également fermé sa plate-forme de service de gestion de la clientèle, pour éviter que les clients puissent ajouter ou étendre les capacités de leurs applications et générer ainsi des machines virtuelles supplémentaires. « C'est la première fois que nous prenons une telle mesure, » indique le blog. Mais les clients ont pu continuer à faire tourner leurs applications de manière normale.

Une réparation épineuse

Il a fallu 13 heures et 23 minutes pour réparer le bug dans tous les clusters Azure, sauf sept, pour la simple raison que ces serveurs étaient en cours de mise à jour logicielle, et posaient un problème distinct. En l'occurence, la question a été de savoir s'il fallait mettre à niveau les clients hôtes et les clients invités échangeant des certificats invalides vers des versions corrigées ou s'il fallait restaurer les anciennes versions et les patcher ensuite. Finalement, le service a opté pour cette seconde solution, mais la manipulation n'a pas fonctionné, parce que les administrateurs n'ont pas restauré aussi le plug-in réseau qui permet de configurer le réseau de la machine virtuelle. Le plug-in réseau était incompatible avec les anciens clients hôtes et invités.