Post-mortem de l’incident survenu sur une unité de stockage hosting à LU-BI1, le 8 janvier 2020

Le 8 janvier 2020 à 14h51 UTC, 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.

Nous avons réussi à restaurer les données et à remettre les services en ligne le 13 janvier au matin.

L’incident a touché – au maximum – 414 clients hébergés sur le site luxembourgeois.

• Nous allons tout d’abord recontextualiser la situation.
• Dans un deuxième temps, nous reviendrons sur le déroulé technique des événements.
• Troisièmement, vous trouverez le post mortem de l’incident.

1. La situation et notre introspection

Gandi fournit des services IAAS et PAAS.

Pour stocker vos données, nous utilisons un système de fichiers appelé ZFS [lien en anglais].

Nous utilisons Nexenta ou Freebsd comme systèmes d’exploitation. Nexenta est utilisé sur l’ancienne version de notre stockage dont la migration est prévue.

Pour sécuriser vos données contre les pannes de disque dur, nous utilisons ZFS avec un triple miroir. Cela signifie que nous pouvons perdre jusqu’à deux tiers des disques sur l’ensemble de l’unité.

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.

Mais 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.

Durant l’incident, nous nous sommes efforcés de communiquer au plus près de l’événement pour tenir informés nos clients.

La page https://status.gandi.net/ a été mise à jour à chaque étape et partagée via nos comptes Twitter gandinoc, gandi_net et gandibar.

Parallèlement, une mise à jour de la situation a été publiée sur notre blog news.gandi.net le 9 janvier, puis mise à jour les 10 et 13 janvier.

Nous avons identifié des axes de progression en interne pour être encore plus fluide et réactif en quasi temps réel.

2. Déroulé technique

L’unité de stockage concernée utilise ZFS sur Nexenta (noyau Solaris/Illumos).

– 8 janvier 14h51 UTC : une de nos unités de stockage hébergée à LU-BI1 tombe en panne.

– 8 janvier 14h52 UTC : nous engageons une procédure de basculement.

– 8 janvier 15h00 UTC : la procédure habituelle ne permet pas la récupération du service, le pool est FAULTED, indiquant une corruption des métadonnées. Nous investiguons.

– 8 janvier 16h00 UTC : le problème est peut être lié à un problème matériel, une équipe est envoyée sur place.

– 8 janvier 17h00 UTC : nous changeons le matériel. Aucune amélioration.

– 8 janvier 17h15 UTC :    

• zpool import -f <pool> ne fonctionne pas.
• Nous essayons zpool import -fFX <pool> pour que ZFS trouve un bon groupe de transactions successives (txg) (Signification : trouver un état cohérent du pool).

– 8 janvier 17h30 UTC : l’importation de zpool import -fFX <pool> fonctionne mais lentement. À ce rythme, il faudra des jours.

– 8 janvier 17h45 UTC : l’équipe américaine se connecte et jette un nouveau regard sur le problème.

– 8 janvier 19h00 UTC : nous décidons d’arrêter l’importation pour voir s’il y a un moyen de l’accélérer.

– 8 janvier 20h00 UTC : nous ne trouvons pas de solution, nous relançons l’importation. Comme les disques sont lus à 3M/s, nous estimons la durée à 370 heures. Nous continuons à essayer de trouver des solutions alternatives.

– 8 janvier 22h35 UTC : nous n’avons aucune garantie sur la restauration des données ni sur la durée du processus. Nous avertissons les clients qu’ils devraient utiliser des sauvegardes s’ils en ont.
L’option d’importation avec « rewind » est toujours en cours.
En même temps, nous recherchons la documentation disponible et regardons le code.
Nous identifions que nous pouvons modifier certains paramètres liés à l’importation zpool import -fFX <pool>. Nous décidons de modifier certaines valeurs, en utilisant mdb, liées à spa_load_verify*.
Mais notre version de ZFS est trop ancienne et le code n’implémente pas ces options.
Nous essayons de trouver le bon txg manuellement mais cela ne résout pas la durée du scan du pool.

– 9 janvier 15h00 UTC : 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. Nous préparons un échange du serveur qui gère le JBOD avec celui qui utilise ZOL.

– 9 janvier 16h00 UTC : nous démarrons l’import en utilisant zpool import -fFX <pool> avec la possibilité maintenant d’éviter le scan complet du pool : echo 0 > /sys/module/zfs/paramètres/spa_load_verify_metadata.

Pour accélérer le « scrub », nous modifions les variables ci-dessous

echo 2000 > /sys/module/zfs/paramètres/zfs_vdev_scrub_max_active

/sys/module/zfs/paramètres/zfs_vdev_async_read_max_active

/sys/module/zfs/paramètres/zfs_vdev_queue_depth_pct

/sys/module/zfs/paramètres/zfs_scan_mem_lim_soft_fact

/sys/module/zfs/paramètres/zfs_scan_vdev_limit

– 9 janvier 17h30 UTC : l’importation se fait en « lecture seule » afin de ne pas altérer les données récupérées. Mais ce faisant, on ne peut pas faire de snapshots. Nous refaisons alors une importation sans l’option « lecture seule ».

– 9 janvier 20h00 UTC : la deuxième importation est terminée. Nous faisons un snapshot global du pool que nous copions sur une autre unité de stockage pour le conserver.

– 9 janvier 20h30 UTC : nous rencontrons quelques erreurs lors de la copie des données, nous devons donc procéder manuellement.

– 9 janvier 21h30 UTC : nous transférons le snapshot avec un script. Nous estimons que cela prendra 33 heures. Pendant la nuit, l’équipe américaine surveille le transfert et est prête à redémarrer si nécessaire.

– 10 janvier 11h15 UTC : nous avons transféré la moitié des données.

– 10 janvier 16h00 UTC : le transfert est toujours en cours mais il est plus lent que prévu.

– 10 janvier 23h00 UTC : le transfert est effectué mais 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.

– Du 11 au 12 janvier 13h00 UTC : le transfert de données est en cours.

– 12 janvier 13h00 UTC : le transfert manuel est effectué. 

– 12 janvier 13h15 UTC : nous lançons un contrôle d’intégrité sur le pool.

– 12 janvier 20h25 UTC : le contrôle d’intégrité est ok.

– 12 janvier 23h00 UTC : tout est presque prêt pour mettre les données en ligne. Nous appelons les équipes infrastructure/hébergement/support client pour qu’elles soient prêtes à 07h00 UTC le 13 janvier.

– 13 janvier 07:00 UTC : nous commençons la procédure de mise en ligne des données.

– 13 janvier 08:30 UTC : les données sont en ligne.

– 13 janvier 09:30 UTC : nous démarrons les instances PAAS.

3. Postmortem : que s’est-il passé ?

Nous avons exclu l’origine humaine d’après les logs et l’historique des commandes systèmes effectuées avant le crash.

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.

Le principal problème est la durée de l’incident.

1) Pourquoi une unité de stockage était en panne ?

En raison d’un crash logiciel ou matériel entraînant une corruption des metadata et une longue interruption des services.

2) Pourquoi une unité de stockage est-elle restée en panne si longtemps ? 

Nous n’avons pas pu importer le pool.

3) Pourquoi l’importation du pool n’était-elle pas possible ?

En raison d’une corruption des metadata, la procédure à appliquer pour récupérer les données était impossible en peu de temps.

4) Pourquoi l’importation n’a-t-elle pas été possible dans un délai aussi court ?

La version de ZFS que nous utilisons sur ce filer n’implémente pas l’option permettant d’éviter un scan complet du pool. Pour des raisons de sécurité, nous avons choisi de dupliquer les données.

5) Pourquoi cette option n’a-t-elle pas été implémentée ?

Cette version de ZFS n’inclut pas cette option.

6) Pourquoi la version de ZFS de ce filer est-elle trop ancienne ?

Parce que l’unité fait partie du dernier lot de filers à migrer vers une version plus récente.

Plan de mesures correctives à moyen terme

• Mettre à niveau la version ZFS des unités de stockage restantes – prévu au cours de l’année 2020.
• Documenter avec précision la procédure de récupération des données en cas de corruption des métadonnées.