Résumé
Entre le 29 octobre et le 1er novembre 2024, quarante et un disques NVMe d'entreprise répartis sur quatre sites ont cessé d'accepter des commandes à un nombre fixe d'heures de fonctionnement, un défaut de firmware dans un lot de fabrication. La mise en miroir a absorbé trente-neuf de ces défaillances sans impact client. Un nœud à Varsovie a perdu les deux moitiés d'un miroir en quarante minutes, car les deux disques provenaient du même lot et étaient montés le même jour. Deux instances sur ce nœud ont perdu des données. Cette deuxième partie était de notre faute, pas de celle du fournisseur.
Chronologie
Toutes les heures sont en UTC.
| Heure | Événement |
|---|---|
| 29 oct. 03:11 | Un disque se déconnecte du bus sur un nœud de Varsovie. Le miroir se dégrade, le disque de secours à chaud commence la reconstruction. Routine, pas d'alerte. |
| 29 oct. 03:49 | Un deuxième disque du même miroir se déconnecte. Le nœud perd son pool racine et s'arrête. |
| 29 oct. 03:52 | L'alerte se déclenche. L'ingénieur de garde se connecte à 03:55. |
| 29 oct. 04:20 | Le nœud est déclaré irrécupérable sur place. La reconstruction à partir du disque de secours à chaud est impossible ; le disque de secours était en cours de reconstruction à partir d'une source qui ne répond plus. |
| 29 oct. 05:40 | Un ingénieur examinant les journaux des disques remarque que les deux défaillances sont distantes de dix-huit heures de fonctionnement, pas de dix-huit mois. Les soupçons passent de la malchance à un lot. |
| 29 oct. 06:15 | Requête sur toute la flotte par identifiant de lot et heures de fonctionnement. Deux cent six disques appartiennent au lot concerné. Trente et un ont déjà dépassé le nombre et ont échoué ; les autres sont entre quarante et neuf cents heures de ce nombre. |
| 29 oct. 07:30 | Fournisseur contacté. Défaut confirmé en quatre heures : un compteur dans la télémétrie d'usure uniforme (wear-leveling) déborde à 1 536 heures de fonctionnement et bloque le contrôleur. Une révision du firmware corrigeant le problème avait été publiée, discrètement, six semaines plus tôt. |
| 29 oct. 09:00 | Mise à jour du firmware en continu, prioritisée par heures restantes. |
| 30 oct. 22:40 | Dernier disque du lot mis à jour ou remplacé. |
| 1er nov. 14:00 | Instances clients concernées restaurées ou remboursées. |
Cause racine
Deux causes, et une seule appartient au fabricant de disques.
La leur : un compteur de télémétrie a débordé à un nombre fixe d'heures de fonctionnement et a bloqué le contrôleur. Le disque survit à un cycle d'alimentation, revient, et se bloque à nouveau en quelques minutes. Les données sur le plateau sont intactes et inaccessibles, ce qui est la pire combinaison pour quiconque essaie de diagnostiquer à quatre heures du matin.
La nôtre : nous avons construit des miroirs à partir de disques arrivés dans la même livraison. Un miroir est censé être deux domaines de défaillance indépendants, et deux disques d'un même lot, montés le même après-midi, alimentés dans la même heure, ne sont pas indépendants dans un sens qui compte. Onze miroirs à travers la flotte ont été construits ainsi. Dix ont eu de la chance en ce que le disque de secours à chaud a terminé la reconstruction en premier. Un non.
Nous savions cela en principe depuis des années. Personne ne l'avait écrit dans la procédure de construction, et la procédure de construction est ce que les gens suivent à deux heures du matin sous une date limite de livraison.
Impact
- Trente-neuf défaillances absorbées par les miroirs sans effet visible pour le client.
- Un nœud hors ligne pendant neuf heures et dix-huit minutes.
- Quatorze instances sur ce nœud restaurées à partir de sauvegardes hors nœud, perdant au plus onze minutes d'écritures.
- Deux instances sans sauvegarde d'aucune sorte. Toutes deux ont tout perdu sur le nœud.
Ce que nous avons changé
- Les lots d'achat sont répartis. Aucun deux disques du même lot ne peuvent former un miroir, et le disque de secours à chaud protégeant une paire provient d'un troisième lot. Appliqué par l'outillage de construction, pas par un document. Fait le 4 novembre.
- Alertes de cohorte sur les heures de fonctionnement. Nous alertons désormais lorsque plus de quatre disques partageant un identifiant de lot sont à moins de cent heures les uns des autres et approchent un nombre rond d'heures. C'est une heuristique grossière et elle aurait attrapé celle-ci dix-neuf jours plus tôt.
- Immersion du firmware avant production. Une nouvelle famille de disques subit deux mille heures de fonctionnement dans un rack de test avant de transporter des données clients. Ce défaut serait apparu à 1 536.
- Nous lisons désormais les notes de version du firmware du fournisseur selon un calendrier. Le correctif existait six semaines avant que nous en ayons besoin. Personne n'était assigné pour regarder, donc personne n'a regardé.
Ce que nous n'avons pas changé, et pourquoi
Nous n'avons pas changé de famille de disques ni de fournisseur. Le défaut était réel et la divulgation était mauvaise, mais notre perte provenait de lots corrélés, ce que nous aurions reproduit avec n'importe quel fabricant. Changer aurait semblé décisif et n'aurait rien corrigé.
La sauvegarde hors nœud reste une option à neuf euros pour cinq cents gigaoctets. La rendre universelle signifie facturer à chaque client un service que la plupart répliquent eux-mêmes, et nous n'allons pas facturer les gens pour l'apparence de sécurité. Ce qui a changé, c'est le formulaire de commande, qui indique désormais clairement que le stockage d'instance est en miroir et que le miroir n'est pas une sauvegarde, et l'étape de confirmation ne permet plus que cette phrase soit ignorée en silence.
Nous ne sommes pas passés à la triple mise en miroir. Cela coûte un tiers de plus par gigaoctet et ne résout pas les défaillances corrélées, qui étaient le mécanisme réel ici. Deux domaines indépendants valent mieux que trois dépendants.
Les deux clients
Les deux ont été remboursés intégralement pour la période concernée, dans l'actif qu'ils avaient payé, sans qu'on leur demande de justifier quoi que ce soit. L'un est parti. L'autre est resté et achète désormais l'option de sauvegarde, ayant lu la même phrase sur le formulaire de commande qui avait été là sous une forme plus faible depuis le début.
Aucun de ces résultats n'était en notre pouvoir. La seule chose qui était en notre pouvoir était de construire correctement le miroir, et nous ne l'avons pas fait.