Il y a trois semaines une unité de stockage de Gandi tombait en panne. Il faudra attendre 5 jours pour un retour à la normale. La société vient de publier un post-mortem complet sur cet incident qui a touché 414 clients. Des explications qui seront utiles tant aux professionnels qu'aux utilisateurs de services en ligne. 

Des pannes peuvent survenir chez tout le monde, aucune société ne peut se prétendre à l’abri de gros incidents matériels et/ou logiciels. Elles peuvent par contre avoir des répercussions plus ou moins graves sur la disponibilité des services et, même si on pense avoir pris toutes les précautions, un petit grain de sable peut vite gripper l’ensemble des rouages. 

Dans ce genre de situation, plusieurs réactions sont possibles : essayer de glisser l’incident sous le tapis, le minimiser, ou communiquer largement et ouvertement… quitte parfois à même en faire presque trop. On se rappelle de la panne des 50 000 sites mutualisés d’OVH en 2017, à qui on ne pouvait pas reprocher un manque de transparence.

• Mutualisé : OVH s'explique sur la panne de 50 000 sites et annonce un geste commercial
• Derrière les plantages d'OVH, la question de la transparence dans la communication

Gandi, comme OVH, a opté pour une communication très active pendant la crise (via différents canaux) et un retour détaillé – à froid – sous la forme d’un post-mortem. Un exercice technique peu aisé, mais ô combien utile pour la communauté qui peut prendre ses dispositions pour éviter un drame du même genre. Cela permet également aux clients de travailler à leurs propres solutions de sauvegardes/replis qu’ils ont – ou non – mises en place.

La panne de Gandi – qui a touché 414 clients hébergés sur le site luxembourgeois – est presque un cas d’école sur ce dernier point, et l’occasion de rappeler qu’il faut toujours disposer de sauvegardes, dans des lieux différents et vérifier que l’on est bien en mesure de les restaurer dans un délai convenable en cas de problème. 

Une unité de stockage tombe en panne… et c’est le drame

Tout commence le 8 janvier 2020 à 14h51 UTC (15h51 en France) : « une de nos unités de stockage utilisées pour nos services d’hébergement hébergés à LU-BI1 (Luxembourg) est tombée en panne ». Jusque-là, rien de bien exceptionnel, ce sont malheureusement des choses qui arrivent. Une minute plus tard, une « procédure de basculement » est mise en place.

À 16 h par contre, la situation s‘aggrave : « la procédure habituelle ne permet pas la récupération du service, le pool est FAULTED, indiquant une corruption des métadonnées ». Gandi utilise le système de fichiers ZFS avec un triple miroir : « Cela signifie que nous pouvons perdre jusqu’à deux tiers des disques sur l’ensemble de l’unité ».

Comme avec un RAID sur un NAS, cela protège donc – dans une certaine mesure – de pannes sur les disques, mais pas sur l’unité en elle-même. La société rappelle au passage que « ZFS permet aux clients de faire des snapshots qui sont des images instantanées de leur disque à un moment donné. Il permet aux clients de revenir en arrière en cas d’erreur, comme la suppression d’un fichier, par exemple ».

Une importation est lancée, mais elle prendra des jours

Puisque la procédure automatique ne fonctionne pas, une équipe est dépêchée sur place à 17 h. Gandi pense alors que « le problème est peut-être lié à un problème matériel » ; un changement est effectué à 18 h, sans « aucune amélioration ».

L’équipe se décide alors à lancer une importation du « pool », une procédure qui finira par fonctionner… « mais lentement. À ce rythme, il faudra des jours », pense alors la société. Nous sommes toujours le 8 janvier et il est 18h30, la panne dure donc depuis déjà plus de 2h30. Avec le jeu des fuseaux horaires, l’équipe européenne de Gandi est rejointe par celle des États-Unis qui « jette un nouveau regard sur le problème », mais n’apportera finalement rien de plus.

Face à la lenteur de l’importation des données, la société décide d’interrompre la procédure à 20 h « pour voir s’il y a un moyen de l’accélérer ». Elle fait chou blanc. 

Une sauvegarde ? Quelle sauvegarde ?

À 21 h, l’importation est donc relancée, avec une première estimation du temps nécessaire : « comme les disques sont lus à 3 Mo/s, nous estimons la durée à 370 heures », soit un peu plus de quinze jours en gardant la même moyenne. Nous sommes toujours mercredi 8 janvier et Gandi doit faire face à un épineux problème : « nous n’avons aucune garantie sur la restauration des données ni sur la durée du processus ».

La société va alors contacter ses clients par email pour leur demander d’utiliser une de leurs sauvegardes… s’ils en disposent évidemment :

« Un incident est survenu sur une de nos unités de stockage au sein d’un de nos centres de données situé au Luxembourg. Malgré les systèmes de réplication mis en place et les efforts combinés de nos équipes toute la nuit, nous n’avons pu récupérer les données sur l’unité de stockage atteinte.

Nous nous excusons sincèrement pour le désagrément que cette situation a causé. Ce type d’incident est d’une rareté extrême dans l’industrie de l’hébergement web. Dans le cas où vous disposeriez de copies de sauvegarde de vos données, nous suggérons que vous en fassiez usage pour la remise sur pied de votre serveur sur un datacenter différent ».

Le corollaire est donc que Gandi ne dispose pas de sauvegarde en interne, ce qui a surpris certains clients. Dans son post-mortem, la société reconnaît qu’elle n’a visiblement pas été suffisamment claire sur ce point : « Gandi ne fournit pas, par contrat, de produit de sauvegarde pour les clients. Cela n’a peut-être pas été expliqué assez clairement dans notre documentation V5 ». Désormais, la page dédiée à la présentation des snapshots a changé.

Sauvegardes vs snapshots

Le 9 janvier les snapshots étaient présentés comme : « sauvegardant automatiquement les fichiers de votre site Web à un intervalle régulier, que vous pouvez utiliser pour ramener le code de votre site Web à une version précédente si nécessaire ».

Le mot sauvegarde a disparu et le message est désormais : « Les Snapshots créent un instantané des fichiers de votre instance à intervalles réguliers, permettant de revenir à une version antérieure de votre site web si nécessaire ». Un avertissement a été ajouté : « Un snapshot est hébergé sur le même disque que les fichiers de l’instance, il ne doit pas remplacer une politique de sauvegarde avec une copie complète des fichiers de votre site vers une destination distante ». 

Version du 9 janvier puis celle du 28 janvier

La grogne était en effet palpable sur les réseaux sociaux, à l’image du mécontentement d’Andrea Ganduglia lorsque Gandi annonce qu’il n’est pas certain de pouvoir récupérer les données : « Donc vous avez perdu des données et interrompu nos services et maintenant, c'est notre travail de les récupérer depuis des sauvegardes ? Des snapshots sont-ils disponibles ? ».

Réponse de Gandi : « pas de snapshot », avant d’ajouter : « les snapshots ne sont pas des sauvegardes, donc oui ils sont sur la même unité ». L'hébergeur tente ensuite de se justifier, certainement pas de la meilleure des manières : « veuillez noter que cela pourrait arriver à n'importe quel hébergeur ». Un message maladroit, et ce n’était pas le seul, la société s’est en effet également excusée d’une réponse « surprenante » à l'un de ses clients.

Stephan Ramoin (PDG de Gandi) a reconnu que c’était une erreur, avant d’ajouter : « Perso, je préfère une boîte qui, sur Twitter (un média immédiat et où les gens font assez peu la part des choses) dit une connerie, mais le reconnait et fait ce qu'il faut, plutôt que le contraire. Et nous sommes en train de récupérer les données... ». Une histoire qui n’est pas sans rappeler la communication d’OVH et surtout d’Octave Klaba autour de l’incident de 2017.

Dans tous les cas, Gandi est conscient du problème puisque dans le billet de blog elle explique avoir « identifié des axes de progression en interne pour être encore plus fluide et réactive en quasi-temps réel ».

Le drame des mises à jour non faites

Revenons à l’importation des données lancée quelques heures après la panne. Pendant qu’elle suit son cours, l’équipe ne reste pas les bras croisés : elle plonge dans la documentation disponible et regarde le code pour tenter de trouver des pistes d’amélioration. « Nous identifions que nous pouvons modifier certains paramètres liés à l’importation zpool -fFX . Nous décidons de modifier certaines valeurs ».

Hélas, la version ZFS utilisée par Gandi « est trop ancienne et le code n’implémente pas ces options ». Le lendemain (jeudi 9 janvier) à 16 h, Gandi tente une « transplantation » afin de mettre en place les pistes d’amélioration identifiées : « nous décidons d’utiliser une version récente de ZFS on Linux. Une équipe se rend sur place, nous avons déjà un serveur configuré pour utiliser ZOL [ZFS on Linux, ndlr]. Nous préparons un échange du serveur qui gère le JBOD avec celui qui utilise ZOL ». 

C’est un succès puisque, une heure plus tard l’équipe redémarre « l’import en utilisant zpool import -fFX avec la possibilité maintenant d’éviter le scan complet du pool ». Dans son billet de blog, Gandi détaille les variables et paramètres utilisés pour ceux que cela intéresse. 

Le transfert ne se passe « évidemment » pas comme prévu

À 20 h, l’importation est terminée et Gandi réalise alors un snapshot global, puis le copie dans une autre unité de stockage « au cas où ». La panne dure maintenant depuis près de 30 h. La suite a aussi été le théâtre de quelques surprises : « nous rencontrons quelques erreurs lors de la copie des données, nous devons donc procéder manuellement […] Nous transférons le snapshot avec un script. Nous estimons que cela prendra 33 heures », à ajouter aux 30 h déjà écoulées.

Finalement 24 h plus tard le transfert est terminé, mais mauvaise nouvelle :  « il manque beaucoup de snapshots. Les dépendances entre les snapshots et leurs origines empêchent beaucoup de transferts. Nous devons supprimer beaucoup de cibles de destination pour les retransférer ». C’est donc reparti pour un tour... et il faudra attendre 14 h le dimanche 12 janvier pour que le transfert manuel soit effectué. À 21h25, le test d’intégrité est « ok ».

Les équipes ont certainement poussé un « ouf » de soulagement, même si tout n’était pas terminé. Gandi se coordonne pour une mise en ligne des données le lundi 13 janvier à partir de 8h00, mais sans préciser si elles étaient toutes revenues ou si quelques pertes étaient à déplorer. 1h30 plus tard, elles sont effectivement en ligne et à 10h30 les instances PAAS sont redémarrées. Cinq jours plus tard, l’incident était donc enfin terminé.

Que retenir de ce post-mortem ?

Une question reste en suspens : pourquoi l’unité de stockage est tombée en panne ? Mystère et boule de gomme : « Nous n’avons pas d’explication claire du problème, seulement des théories. Nous pensons que l’incident est peut-être dû à un problème matériel lié à la mémoire vive du serveur ».

Dans tous les cas, l’erreur humaine a été exclue après consultation des logs et des historiques de commandes. Mais finalement, peu importe la cause première de cette panne, on juge surtout une société sur sa capacité à restaurer ses services le plus rapidement possible, idéalement de manière quasi invisible pour ses clients. Gandi fait amende honorable et reconnaît que « le principal problème est la durée de l’incident ».

Ce point découle de plusieurs facteurs, dont un manque de mise à jour : « La version de ZFS que nous utilisons sur ce filer n’implémente pas l’option permettant d’éviter un scan complet du pool ». Une mise à jour était en cours chez Gandi, mais cette « unité fait partie du dernier lot à migrer vers une version plus récente ».

Gandi prévoit évidemment de mettre à jour l’ensemble des unités de stockage restantes, une opération prévue « au cours de l’année 2020 » et aussi de « documenter avec précision la procédure de récupération des données en cas de corruption des métadonnées ».

Côté utilisateur, rappellons qu'il est important de toujours disposer de sauvegardes de ses données, peu importe finalement les promesses de l’hébergeur. Ne jamais mettre tous ses œufs dans le même panier prend tout son sens ici. Si 414 clients « seulement » ont été impactés, cette histoire doit être un coup de semonce pour l’ensemble des internautes.

• Et si, en 2020, on sauvegardait enfin nos données ?