Le 30 septembre 2020 à 05h38 UTC, une de nos unités de stockage utilisée par nos services d’hébergement en FR-SD3 est tombée en panne.
À 11h52 UTC, nous avons réussi à remettre en service l’unité de stockage.
Après cela, notre équipe a travaillé pour remettre en ligne tous les IAAS et PAAS touchés par l’incident de l’unité de stockage.
Chronologie
Toutes les heures indiquées ci-après sont en UTC.
30 septembre, 01h12 – Un pool ZFS est en état dégradé sur une unité de stockage à FR-SD3, dû à la perte d’un disque.
C’est une situation prévue, pas d’impact. Un pool dégradé signifie que le ZFS a retiré un disque en raison d’un trop grand nombre d’erreurs sur celui-ci.
30 septembre, 01h30 – L’admin de service remplace le disque défectueux par un disque de rechange pour permettre la reconstruction/restauration du raid.
30 septembre, 02h42 – Les alarmes commencent à sonner.
La situation n’est pas claire à ce stade. Les nodes commencent à charger, et les instances des clients ne répondent pas bien.
30 septembre, 03h12 – L’admin en charge escalade le problème auprès de l’astreinte pour avoir de l’aide.
30 septembre, 03h29 – Un diagnostic est effectué.
Le disque défectueux est un disque assurant la fonction de ZIL (ZFS Intent Log). Comme nous avions deux ZIL dans le miroir, avant de remplacer le disque, la situation était stable. En cas de panne de disque, les performances ne sont pas affectées puisque le disque restant continue de fonctionner normalement.
Cependant, le ZIL défectueux est un SSD spécifique conçu pour mettre en cache les écritures, et il a été remplacé par erreur par un disque mécanique.
Parce que les performances entre les deux types de périphériques ne sont pas les mêmes, et parce que lors de l’ajout d’un périphérique à un miroir, la vitesse du miroir sera celle du périphérique le plus lent, toutes les opérations d’écriture sur ce filer sont ralenties.
30 septembre, 03h47 – Après plusieurs tentatives pour supprimer le mauvais ZIL , les commandes zpool ont cessé de répondre. L’astreinte décide de se rendre sur place pour retirer physiquement le mauvais périphérique de l’unité de stockage.
30 septembre, 04h47 – L’astreinte est sur place.
30 septembre, 04h50 – Le disque défectueux est physiquement retiré de l’unité de stockage.
30 septembre, 05h00 – La situation pour les utilisateurs s’améliore, mais l’état de l’unité de stockage n’est pas sain.
30 septembre, 05h38 – Nous redémarrons l’unité pour la réinitialiser et nous assurer que tout va bien.
30 septembre, 05h45 – L’unité de stockage est de nouveau en ligne mais l’importation ne réussit pas car le deuxième ZIL est également défectueux.
Notre priorité est maintenant de remettre le pool en ligne.
Nous forçons l’importation, en ignorant le mauvais ZIL, mais l’importation est très lente.
Nous supprimons tous les dispositifs ZIL, mais nous n’avons plus de disque exactement du même type en réserve sur site. Les seuls disques ayant les mêmes spécifications sont trop petit par rapport au pool initial.
Nous n’avons donc plus de pièces de rechange, nous devons donc le prendre à notre bureau de stock à Paris.
30 septembre, 08h12 – Un autre admin se dirige vers le datacenter avec un des ZIL de rechange.
30 septembre, 09h30 – Les pièces sont sur place.
30 septembre, 09h51 – Les nouveaux ZIL sont en place. Nous devons attendre le rebuild du raid avant de prendre d’autres mesures.
30 septembre, 11h13 – Le rebuild est terminé. Nous avons redémarré et l’import des donnés est ok . Le service est de nouveau en ligne.
Analyse
Le problème était principalement dû à une erreur humaine, et non à un problème de conception du stockage.
La procédure habituelle de remplacement des disques n’était pas assez claire, provoquant le problème.
Par la suite, la résolution du problème auquel nous étions confrontés n’a pas été simple, et nous avons pris du temps pour éviter les erreurs et des risques de perte de données. Comme la plupart du processus de récupération est automatisé, nous avons essayé d’éviter toutes les actions hors procédure pour revenir à la normale.
Nous allons mettre à jours nos procédures pour tenir compte des problèmes que nous avons rencontrés.
Tagged in Nom de domaine
