Baie EMC noyée : comment OVH a pris l'eau
Publié par La rédaction le | Mis à jour le
OVH raconte l'enchaînement des événements qui ont conduit à la panne d'environ 24 heures de son service d'hébergement mutualisé. Un concours de circonstances doublé d'erreurs d'exploitation.
Une nouvelle illustration de la loi de Murphy, aussi appelée loi de l'emmerdement maximum ? C'est ainsi qu'OVH présente la panne qui a touché son datacenter parisien P19 et provoqué une interruption de services allant au-delà de 24 heures pour certains des 50 000 sites concernés par l'incident. Tout est parti, le 29 juin à 18h48, d'une fuite de liquide de refroidissement sur le système de 'watercooling' d'OVH, une des marques de fabrique de l'hébergeur. Du liquide qui parvient à s'immiscer dans une des deux baies EMC présentes sur P19, baie qui n'était pas refroidie par ce procédé mais se trouvait à « proximité immédiate ».
Une proximité qui constitue une erreur évidente, ce que reconnaît d'ailleurs l'hébergeur roubaisien dans sa longue analyse post-mortem de l'incident, posté sur son site : « nous aurions dû installer [les baies EMC] dans des salles isolées, pour les protéger de ce type d'incident ». Et d'expliquer que le choix de cet emplacement résulte d'un malheureux concours de circonstances : les salles réservées aux équipements ne recevant pas le watercooling étaient en réfection au moment de l'achat des baies, en 2012. Manque de chance encore, les équipements EMC étaient tous voués à être remplacés par une nouvelle architecture maison, seules deux baies VNX 5400 restant en production chez OVH au moment de la panne, toutes deux hébergées sur le datacenter P19.
11 minutes qui changent tout
A ce concours de circonstances, s'ajoute un facteur aggravant : la mise à jour en cours d'un système d'alertes, basés sur des sondes, censé prévenir les techniciens par des messages audio lors d'événements anormaux (comme une fuite du liquide de refroidissement). « Dans le cadre de l'implantation à l'international de nouveaux datacenters, ce système de monitoring audio était en cours de mise à jour, afin que la voix de synthèse puisse diffuser les messages d'alerte dans plusieurs langues. En raison d'une malfaçon dans cet upgrade, réalisé le même jour, l'alerte audio n'a pas fonctionné correctement », écrit OVH. Retardant d'autant la prise en charge de l'incident.
Conséquence : le premier technicien n'est entré dans la salle touchée par la fuite que 11 minutes après son démarrage. « Ce retard a très certainement accentué l'impact de l'incident », reconnaît OVH. C'est ce qui explique peut être pourquoi la baie EMC aspergée est si gravement touchée. Malgré leurs efforts, les techniciens ne parviendront en effet jamais à la redémarrer. Tout comme seront inefficaces les efforts visant à remonter les disques de la baie touchée dans un second châssis, amené par la route depuis Roubaix.
OVH contraint à la restauration
En parallèle de cet acharnement thérapeutique sur la baie inondée, OVH s'est lancé dans la restauration des données depuis les sauvegardes quotidiennes effectuées sur le service d'hébergement Web concerné par la panne. Plus simple à dire qu'à faire. En effet, si la baie EMC comprend deux contrôleurs en mode actif/actif, assurant la redondance de l'équipement en cas de défaillance sur un module, la mise en panne du châssis oblige OVH à recréer l'ensemble de l'environnement de production des clients touchés, ici des bases de données de production. Soit trouver de l'espace libre sur les serveurs, puis redéployer les environnements supportant les bases (VM, OS, configurations spécifiques) et, enfin, migrer les données.
Sauf que la procédure d'urgence permettant d'enchaîner ces opérations n'avait pas suffisamment industrialisée, reconnaît l'hébergeur. C'est donc dans la nuit du jeudi au vendredi que les équipes d'OVH ont écrit les scripts permettant d'automatiser la procédure. « À 3 h du matin, le clonage des VM à partir d'un template source était lancé et les données étaient en cours de restauration », détaille la société. D'abord en lecture seule, OVH ayant alors toujours l'espoir de récupérer les données plus récentes, coincées dans la baie EMC et que l'hébergeur espère alors retrouver grâce au châssis envoyé en urgence depuis Roubaix.
Deux mois gratuits
Ces efforts s'avérant vains (la baie n'ayant pas pu être remise en service), l'hébergeur doit donc se résoudre, à 14h30 le vendredi, à lancer la restauration des bases en mode lecture/écriture. Tirant au passage un trait sur les données de ses clients enregistrées entre la dernière sauvegarde et la panne. « À 23 h 40, la restauration de la 99e instance prend fin, et l'ensemble des utilisateurs retrouvent un site fonctionnel, à l'exception de quelques utilisateurs, dont la base était hébergée sur des instances sous MySQL 5.1 et a été restaurée sous MySQL 5.5. Un effet de bord rapidement résolu », conclut OVH, qui face à cet événement exceptionnel à décider d'accorder 2 mois d'hébergement gracieux aux utilisateurs concernés (qui payent en moyenne 4 euros HT par mois).
Si OVH promet la transparence sur les améliorations qu'il compte apporter à ses infrastructures par la suite pour éviter de connaître pareille mésaventure à l'avenir, l'hébergeur reconnaît d'ores et déjà qu'un « principe essentiel » de son fonctionnement n'a pas été respecté à l'occasion de cette panne : la répartition du risque sur plusieurs machines. Pour la société co-fondée par Octave Klaba, cet épisode conforte également le choix de la société de privilégier les technologies maison, sur lesquelles la société a « l'entière maîtrise du hardware, voire du software ». OVH confirme ainsi qu'il va finaliser la migration de la dernière baie EMC VNX 5400 actuellement encore en production. Et ce, même si la technologie du fournisseur américain n'est pas responsable de la panne.
A lire aussi :
Le plantage d'une baie EMC met OVH à genoux
OVH emprunte 400 millions d'euros pour accélérer son expansion
Cloud : OVH lance des instances optimisées GPU