Il existe dans l’informatique une loi fondamentale, qui se vérifie régulièrement bien que ne reposant sur aucune base scientifique : « un emmerdement suivant un autre emmerdement est souvent plus ennuyeux que s’il était seul, et la somme de ces deux emmerdements tend vers une courbe exponentielle ». Vous aurez reconnu la définition de la loi de l’emmerdement maximum, variante francophone de la célèbre loi de Murphy. Voilà pour le contexte de cet incident atypique, qui a débuté le 29 juin 2017 à 18 h 48 au sein de notre datacenter parisien P19. Cet incident a uniquement touché une partie de notre service d’hébergement web, à savoir 4,3 % du trafic généré par ce service (soit plus de 50 000 sites sur 3 millions). Comme nous nous y sommes engagés, nous allons faire toute la lumière sur le déroulement de cet incident. Car, si cette panne est le fruit d’un enchaînement malheureux de circonstances particulières, OVH en assume pleinement la responsabilité. Et en tirera tous les enseignements.
Le contexte
Les offres d’hébergement web proposées par OVH sont principalement destinées à l’hébergement de sites vitrines et blogs à trafic modéré. Les utilisateurs affectés par l’incident du jeudi 29 juin sont facturés au prix moyen de 4 euros HT/mois pour ce service. Il s’agit essentiellement d’offres d’hébergement d’entrée de gamme, mais cela est sans conséquence sur les efforts qui ont été fournis pour résoudre l’incident.
En parallèle de ces offres, nous proposons un large panel de solutions de cloud computing, assorties d’engagements sur le niveau de service (SLA) compatibles avec l’hébergement d’applications dont la disponibilité est critique (applications métiers, sites e-commerce, etc.). Ces services destinés aux entreprises, qui ne reposent pas sur les mêmes briques technologiques, n’ont pas été perturbés par l’incident du jeudi 29 juin.
La plateforme technique des offres d’hébergement mutualisées est répartie au sein de deux datacenters : Paris (P19) et Gravelines (GRA). C’est à P19, là où l’histoire d’OVH a commencé, que la plateforme fut historiquement déployée. C’est également sur ce site que fut développée la technologie de refroidissement liquide des serveurs (watercooling), perfectionnée au fil des ans et aujourd’hui généralisée dans l’ensemble des datacenters d’OVH. Combiné au freecooling (refroidissement des machines par l’air extérieur, qui une fois réchauffé est évacué des salles par des extracteurs), le watercooling permet de dissiper la chaleur des composants des serveurs sans recourir à la climatisation électrique, dont le fonctionnement est très énergivore.
Le site P19 présente une configuration unique, en comparaison des datacenters ultérieurement aménagés par OVH. Les salles étant situées en sous-sol, le procédé du freecooling n’a jamais pu y être implémenté. Ainsi, les 30 % de chaleur non dissipés par le watercooling sont refroidis par des modules de climatisation. P19 présente également la particularité d’offrir différentes typologies de salles, certaines pouvant accueillir des équipements spécifiques comme des baies de télécommunication et autres équipements propriétaires. En 2012, des travaux de rénovation ont été entrepris dans ces salles pour en moderniser les modules de climatisation.
Au début des années 2010, l’hébergement web a connu une évolution sensible des usages avec la démocratisation des sites dynamiques. Cela a nécessité de revoir à la hausse les performances des serveurs de stockage de bases de données, lesquelles étaient de plus en plus sollicitées. En 2012, pour répondre à ce besoin de performances accrues, notre équipe de R&D a testé plusieurs technologies propriétaires et a retenu, après des études poussées, la technologie EMC. C’est dans ce contexte qu’OVH a fait l’acquisition de plusieurs baies de stockage de type VNX 5400.
Cet équipement est composé de deux storage processors (des « têtes de lecture » ou « contrôleurs ») en mode actif/actif, capables de prendre le relais l’une de l’autre en cas de défaillance. Ces deux contrôleurs gèrent 96 disques SSD répartis sur 3 étages et configurés en RAID, ainsi que 15 disques supplémentaires à plateau, destinés à la sauvegarde locale des données. Cette architecture est prévue pour garantir, localement, la disponibilité des données et tolérer les pannes à la fois des contrôleurs et disques de données.
Plusieurs de ces baies ont été mises en production en 2012 au sein de la plateforme technique de l’hébergement web. Néanmoins, nous avons toujours continué notre R&D sur le sujet du stockage et avons entre-temps développé plusieurs solutions, basées sur du hardware standard et des logiciels open source (Ceph, ZFS…) ou ceux proposés par VMware. C’est pourquoi nous avons engagé une migration des baies de stockage propriétaires au profit de solutions made in OVH. Cette migration, complexe étant donné les volumes concernés et la volonté de garantir la continuité de service à nos utilisateurs, était en cours. C’est également dans ce cadre que les hébergements web créés depuis juillet 2016 sont provisionnés dans le datacenter de Gravelines.
Le jeudi 29 juin, au moment de l’incident, seules deux baies de stockage équipées de hardware propriétaire étaient encore en fonctionnement chez OVH. Toutes deux à P19, pour y héberger une partie des bases de données du service d’hébergement web.
Il faut savoir que l’infrastructure sur laquelle s’appuie l’hébergement web d’OVH repose sur une architecture massive, composée de milliers d’équipements, répartis comme suit :
– des serveurs physiques utilisés en tant que frontaux web, qui servent les pages web aux internautes ;
– des ensembles de stockage conçus par OVH (FilerZ) contenant les fichiers des sites (fichiers HTML/images/CSS/PHP…) ;
– des serveurs de bases de données (contenant les données des pages dynamiques des sites, les informations liées aux utilisateurs, le texte des articles et commentaires dans le cas d’un blog…).
Les deux baies de stockage évoquées plus haut font partie du design de cette dernière catégorie. Leur migration était planifiée, à la fois dans un souci d’homogénéisation du parc et dans le cadre de notre politique de gestion de l’obsolescence.
Le déroulement précis de l’incident
À 18 h 48, le jeudi 29 juin, dans la salle 3 du datacenter P19, en raison d’une fissure sur un tuyau en plastique souple de notre système de watercooling, une fuite de liquide de refroidissement entraîne la présence de fluide dans l’une des deux baies de stockage propriétaires, lesquelles n’étaient pas refroidies par ce procédé mais se trouvaient à proximité immédiate. Cela a eu pour conséquence directe la détection d’un défaut électrique entraînant l’arrêt complet de la baie.
Même si les normes de fonctionnement de ces baies, fournies par le constructeur, nous autorisaient à installer ces équipements dans cette salle, en regard de la plage de température autorisée (entre 10 et 35 degrés), nous aurions dû les installer dans des salles isolées, pour les protéger de ce type d’incident. À leur mise en service, en 2012, les salles réservées aux équipements non refroidis par watercooling étaient en réfection, si bien que nous avons installé ces baies à proximité de serveurs refroidis par ce procédé. Cela ne nous semblait pas constituer un risque majeur, mais nous aurions dû déménager ces baies une fois les salles adéquates rénovées. Nous avons commis une erreur de jugement, car nous aurions dû apporter à ces équipements de stockage un niveau de protection maximal, comme c’est le cas sur l’ensemble de nos sites.
Nos datacenters sont équipés de diverses sondes. L’une d’entre elles est capable de détecter la présence de liquide dans une baie. Les alertes levées par ces sondes sont transmises aux techniciens présents dans le datacenter via différents canaux de communication. L’un d’eux est un outil baptisé MARCEL (l’acronyme de Monitoring Audio des Réseaux Composants Équipements et Locaux), qui permet de diffuser un message audio dans nos datacenters grâce à une voix de synthèse et à des haut-parleurs disposés dans chaque salle. C’est un moyen très efficace de prévenir nos techniciens d’un événement anormal présentant un caractère d’urgence, quand bien même ceux-ci sont déjà occupés sur une intervention telle qu’un remplacement de disque. Ils n’ont ainsi pas besoin de retourner en salle de contrôle pour s’apercevoir qu’un incident est en cours dans un autre endroit du datacenter. Un précieux gain de temps.
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, retardant sa prise en charge. Au lieu d’intervenir immédiatement, comme c’est le cas habituellement, le premier technicien est arrivé dans la salle 3 onze minutes après la détection de la fuite. Ce retard a très certainement accentué l’impact de l’incident.
Une fois le technicien sur place, à 18 h 59, celui-ci a mobilisé les équipes présentes dans le but d’enclencher les procédures adéquates. Une tâche travaux a immédiatement été créée. Les techniciens se sont occupés des composants touchés et ont tenté de redémarrer la baie de stockage.
À 21 h 25, l’ensemble des personnels d’astreinte sont mobilisés, et les équipes techniques sont restées pour leur prêter main forte. Il est décidé de mener deux actions en parallèle :
– plan A : poursuivre les tentatives de récupération des données sur la baie de stockage avec l’aide du constructeur ;
– plan B : lancer la procédure de restauration des données depuis les sauvegardes réalisées quotidiennement.
Concernant les équipes mobilisées sur le plan A :
Après avoir sollicité l’aide du constructeur de la baie peu après 20 h, les équipes poursuivent les tentatives de rallumer la baie, sans succès. 20 minutes après son démarrage, elle s’éteint sous l’effet d’un mécanisme de sécurité.
À 22 h 45, une baie de stockage de même modèle, stockée à Roubaix, est préparée pour être acheminée jusqu’à Paris. Notre idée est alors de remonter les disques sur un châssis dont les modules d’alimentation et les storage processors sont fonctionnels.
Concernant les équipes mobilisées sur le plan B :
OVH dispose pour le service d’hébergement web d’une sauvegarde journalière, conservée 7 jours glissants. Il s’agit d’une sauvegarde d’infrastructure globale, réalisée dans le cadre de notre PRA (plan de reprise d’activité), et non des snapshots des bases auxquels nos clients ont accès dans leur espace client.
Restaurer les données ne signifie pas seulement migrer les données de backup depuis un stockage à froid vers un espace libre de la plateforme technique de l’hébergement mutualisé. Il s’agit de recréer l’ensemble de l’environnement de production.
Il était donc nécessaire, pour restaurer les données de :
–trouver de l’espace disponible sur des serveurs existants à P19 ;
–redéployer un environnement complet pour supporter les services (à savoir les VM qui font tourner les bases, avec leur système d’exploitation, leurs packages et configuration spécifiques) ;
–migrer les données vers la nouvelle infrastructure hôte.
La procédure d’urgence, servant à exécuter cette série d’opérations existait et avait été testée. Mais pas industrialisée. Autrement dit, restaurer une table à partir du backup est trivial. Restaurer un très grand volume de tables, initialement réparties sur 99 VM, nécessitait davantage d’automatisation, sans quoi la restauration aurait nécessité plusieurs journées.
L’équipe en charge des backups a scripté, durant la nuit, la procédure, afin de pouvoir l’industrialiser. À 3 h du matin, le clonage des VM à partir d’un template source était lancé et les données étaient en cours de restauration. Il a été décidé de placer les bases restaurées en lecture seule, de sorte à alléger la charge sur l’infrastructure et à ne pas compromettre la possibilité de restaurer des données plus récentes, à savoir celles bloquées sur la baie de stockage.
À 4 h 30 le vendredi matin, la baie de stockage en provenance de Roubaix, de même modèle que celle qui refuse de redémarrer, arrive à Paris. À 6 h l’ensemble des disques ont été remontés sur le châssis fonctionnel. À 7 h, le système démarre, les disques sont à priori reconnus, mais les données restent inaccessibles. À 8 h, un second contact est pris avec le support du constructeur. Lors de ce contact, un premier diagnostic est fait, qui confirme que la baie semble active du fait qu’il est possible d’accéder à la console RemoteAnywhere exclusivement réservée au personnel habilité du constructeur. Il est convenu d’envoyer un technicien sur place en fin de matinée.
Le plan B se poursuit en parallèle et à 9 h, 20 % des instances sont remontées.
À 14 h 30, il est décidé de replacer les bases en mode lecture/écriture, car les chances de récupérer les données de la baie s’amenuisent. À 15 h, cette décision est effective.
À 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.
Un geste commercial sera accordé aux clients pour l’indisponibilité de leur service durant près d’une journée. Il nous est apparu légitime de dédommager nos clients, au-delà de la clause limitative de responsabilité présente dans nos conditions générales de service.
Le geste commercial consistera à prolonger gracieusement l’offre d’hébergement web des utilisateurs concernés de deux mois. Les modalités de ce geste, qui tient compte du caractère exceptionnel de l’incident, vous seront communiquées dans les prochains jours.
Concernant la baie défectueuse, nous constatons qu’il n’est pas possible de la remettre en fonctionnement, ceci malgré toutes les actions entreprises avec les équipes support constructeur.
Les enseignements
Cet incident a mis en évidence un certain nombre d’axes d’améliorations. Nous vous détaillerons ceux-ci dans les prochaines semaines via des mises à jour régulières de cet article. Les équipes techniques impliquées sont actuellement en train de mettre en commun leurs préconisations, avant de délibérer sur les mesures à adopter. Le constat a d’ores et déjà été fait qu’un principe essentiel chez OVH n’avait pas été respecté dans le cadre de l’exploitation de cette baie de stockage propriétaire : répartir le risque en multipliant les machines, ceci pour minimiser le domaine de panne. Nous finalisons donc actuellement la migration de la dernière baie de stockage propriétaire de notre parc.
D’une manière générale, cet incident nous conforte dans notre stratégie de privilégier l’exploitation de technologies sur lesquelles nous avons l’entière maîtrise du hardware, voire du software. Éviter de recourir à du hardware propriétaire nous permet d’optimiser l’ensemble de la chaîne de production, depuis la conception des serveurs jusqu’à la thermodynamique des datacenters que nous construisons selon un cahier des charges en adéquation avec nos besoins. De plus, nous souhaitons pouvoir effectuer, avec nos équipes, les opérations de maintenance, d’upgrade ou de dépannage des équipements utilisés, ceci pour optimiser les temps d’intervention. À cela s’ajoute le fait que nous préférons capitaliser sur quelques technologies, afin de mutualiser et développer les connaissances de nos équipes techniques.
En conclusion : exploiter des technologies propriétaires n’est pas toujours adapté à notre organisation, à notre volonté de maîtriser de bout en bout la chaîne de valeur. Si bien que — indépendamment de la qualité intrinsèque de ces technologies — elles représentent parfois un risque dans le contexte particulier d’OVH, en nous rendant dépendants d’équipes techniques externes et nous obligeant à ajouter des exceptions à nos procédures, quand notre volonté est l’industrialisation… et non la gestion de cas particuliers.
La communication durant l’incident
Il nous a été reproché une communication approximative, floue sur certains points et parfois même contradictoire au moment de l’incident et dans les heures qui ont suivi.
À propos de la confusion qui a entouré l’origine de l’incident — à savoir une fuite de liquide de refroidissement de notre système de watercooling — nous faisons notre mea culpa.
La raison de cette hésitation à révéler cet élément est relativement simple. Le watercooling est un procédé exploité en dehors d’OVH (la première mention du terme dans le secteur de l’informatique est liée à l’utilisation d’une technique de refroidissement liquide sur un super-ordinateur fabriqué par Cray… en 1985, et surnommé « Bubbles » en raison de cette particularité). Néanmoins, nous avons développé des technologies connexes, qui ont permis l’industrialisation à très grande échelle de ce procédé.
Aussi, il est difficile de communiquer sur les sujets entourant le watercooling sans prendre le risque de révéler, indirectement, des secrets industriels qui pourraient intéresser nos concurrents. Dans ces conditions, il est délicat de mentionner qu’un incident a pour origine le watercooling sans pouvoir donner plus de détails sur nos procédures dans ce type de situation et sur les mesures correctives apportées. Ce manque d’information pourrait amoindrir la confiance dans un procédé qui est pourtant parfaitement maîtrisé, et dont les niveaux de disponibilité de nos services dans le temps (contractuels et constatés) démontrent la totale fiabilité. Puisque la relation de confiance qui nous unit à nos clients prévaut sur le reste, sachez que nos équipes techniques sont préparées à ces cas, rares, de fuite de liquide sur des composants. Les baies sont conçues pour détecter ces éventuels dysfonctionnements et favoriser l’écoulement des fluides le cas échéant. De plus, la conception de nos datacenters permet d’isoler une baie du système de watercooling, comme cela se fait pour la distribution électrique au moyen des disjoncteurs. Voici un aperçu, très partiel, des mesures liées à l’emploi de ce procédé de refroidissement chez OVH.
Dans les faits, c’est un système qui comporte peu de risques, en comparaison avec une panne de climatisation occasionnant la surchauffe d’une salle et inéluctablement l’arrêt des équipements informatiques. Et les climatisations elles-mêmes peuvent fuir, comme nous l’avons vu par le passé, avec la formation de condensation… Reste que, dans l’imaginaire collectif, le liquide et les serveurs, c’est une alliance plutôt contre nature. D’où nos précautions, maladroites il faut le reconnaître, sur le sujet.
Concernant les réécritures successives du contenu de la tâche travaux liée à l’incident, voici l’explication. Historiquement, les tâches travaux sont créées par les techniciens mobilisés par un incident, sans validation préalable, avec la consigne d’être le plus transparent possible, conformément aux valeurs qui ont toujours été celles d’OVH. En l’occurrence, la tâche travaux liée à l’incident du jeudi 29 juin a été rédigée successivement par plusieurs équipes, rendant compte de la progression des différentes actions entreprises.
Vendredi 30 juin à 9 h, Octave Klaba a rédigé une nouvelle tâche travaux, sur la base des informations remontées par les différentes équipes. Ne mentionnant pas la fuite liée au système de watercooling à l’origine de l’incident, il laisse involontairement penser que la baie présente un défaut dont le constructeur pourrait être tenu responsable. Constatant l’interprétation faite de son message, il se ravise et modifie la tâche travaux pour mettre hors de cause le constructeur. Le fait de disculper le constructeur ne fait suite à aucune demande ou pression de sa part, et il faut noter que ses équipes support ont fait le maximum pour nous apporter de l’aide.
Cet épisode a révélé la nécessité de mieux coordonner les informations durant un incident, afin de fournir aux utilisateurs une explication qui ne soit pas seulement transparente, c’est le minimum, mais aussi cohérente, compréhensible par tous et régulièrement actualisée. Au-delà de la refonte prévue du site travaux.ovh.net, au profit d’une interface plus évoluée, et de la possibilité prochaine d’être alerté de façon personnalisée en cas d’incident impactant l’un de ses services, une équipe spécialisée sera mise en place pour délivrer aux utilisateurs une information dont la qualité est adaptée à ce type de situation.
Enfin, cet incident nous conforte dans la réflexion, déjà engagée, de refondre les offres d’hébergement web, en différenciant mieux les usages qui en sont faits. Nous envisageons ainsi d’apporter, à ceux qui en ont l’utilité, des garanties supplémentaires aux clients, justifiant par exemple l’existence d’un SLA contractuel. Les détails de cette refonte vous seront prochainement communiqués.
