La solution PaaS de VMware, Cloud Foundry - qui est encore en version bêta - a subi une interruption de service pendant deux jours la semaine dernière (les 25 et 26 avril), peu de temps après la panne plus connue et médiatisée qui a frappé Elastic Compute Cloud d'Amazon. Le premier incident  était du à une panne de courant dans une armoire de stockage. Les applications en ligne n'ont pas été affectées, mais les développeurs n'ont pas été en mesure d'effectuer certaines tâches, comme s'authentifier ou créer de nouvelles applications. La panne a duré près de 10 heures et a été réparée dans l'après-midi.

Mais le lendemain, les responsables de VMware ont accidentellement provoqué une deuxième coupure de courant, en élaborant un plan de prévention pour résoudre la panne initiale. Dekel Tankel, porte-parole de VMware a expliqué que la première panne d'électricité du 25 avril est « quelque chose qui arrive de temps en temps », et que l'éditeur veille à ce que ses logiciels de surveillance et les pratiques opérationnelles soient suffisamment robustes pour éviter que ces coupures d'électricité rendent  inopérants le service des clients. Dans cet esprit, VMware a commencé à élaborer « un guide complet d'instructions pour la détection, la prévention et la restauration » dès le lendemain.

De Charybde en Scylla

« A huit heures le 26 avril, ce travail a fourni plusieurs instructions que les équipes opérationnelles et d'ingénierie devaient appliquer à midi », précise Dekel Tankel et d'ajouter « malheureusement, à 10h15, l'un des ingénieurs a fait une mauvaise manipulation, ce qui a eu comme conséquence une coupure complète de l'infrastructure du réseau de Cloud Foundry. Les équilibreurs de charge, les routeurs et les pare-feu ont été inopérants. Par ailleurs, notre infrastructure DNS interne a été partiellement touchée par la panne  et a entraîné une perte complète de la connectivité externe à Cloud Foundry ». Le système a été rétabli à 11h30, apparemment sans que les développeurs soient impactés.

Cette seconde panne illustre l'élément « erreur humaine » dans les réseaux clouds, tout comme l'analyse des causes de la défaillance du cloud d'Amazon. Sur ce dernier, il s'agit d'une erreur commise lors d'une mise à jour du système et qui n'a été réparé qu'au bout de plusieurs jours. Certes Cloud Foundry est encore balbutiant et l'impact sur les clients des défaillances n'ont pas été du même niveau que celles d'Amazon, mais VMware découvre ainsi un avant-goût des problèmes que peut rencontrer un fournisseur de services cloud.