Analyse post-mortem de l’interruption du service Tarsnap

• Le serveur central de Tarsnap est tombé sur Amazon EC2 us-east-1 avec un failed system status check, entraînant une interruption de service d’environ 26 heures et 16 minutes à partir du 2023-07-02 13:07:58 UTC
• L’incident a été détecté à 13:10 UTC, mais après un redémarrage imprévu, la politique d’exploitation prévoyait de désactiver le démarrage automatique du code serveur afin qu’un contrôle humain soit effectué
• La restauration a été menée en lisant les en-têtes de métadonnées du système de fichiers structuré en journal sur Amazon S3, puis en rejouant localement les opérations dans l’ordre ; la première étape s’est terminée le 2023-07-03 01:49:49 UTC
• Pendant la reconstruction de l’état, un cas non validé du traitement machine re-owned écrit en 2014 ainsi qu’un oubli de réinitialisation dans la logique de reprise ont été mis en évidence, et une limite de débit disque a également ralenti la restauration
• Tarsnap n’a pas de SLA explicite, mais, selon sa politique d’accorder des crédits lorsqu’une panne est jugée équitablement compensable, a attribué le 2023-07-13 à tous les comptes un crédit de 50 % sur un mois de frais de stockage

---

Survenue de l’incident et réponse initiale

• Vers le 2023-07-02 13:07:58 UTC, le serveur central de Tarsnap est passé hors ligne dans la région Amazon EC2 us-east-1
  • L’état EC2 était failed system status check
  • Dans une machine virtuelle, cet état peut indiquer plusieurs causes, notamment une coupure de courant, une panne matérielle du serveur physique ou un incident réseau EC2
  • Aucun signal d’une panne EC2 généralisée n’a été observé au même moment, et l’hypothèse la plus probable était donc une panne matérielle isolée
• La supervision a détecté l’incident à 2023-07-02 13:10 UTC
  • La surveillance consistait à effectuer toutes les 5 minutes des écritures, lectures et suppressions d’archives depuis une autre région EC2
  • L’alerte SMS de 13:10 UTC n’a pas réveillé l’équipe, mais l’alerte téléphonique de 13:15 UTC a déclenché la réponse
  • L’enquête initiale n’ayant révélé aucune erreur transitoire évidente, le système a été considéré comme hors service et la préparation d’une instance EC2 de remplacement a commencé

Principe d’exploitation évitant le redémarrage automatique

• Vers le 2023-07-02 13:52 UTC, Amazon a redémarré le serveur en panne sur une nouvelle instance EC2
  • Cela s’est produit environ 45 minutes après le début de l’incident
  • Le système d’exploitation, FreeBSD, a bien démarré, mais le code serveur Tarsnap ne s’est pas lancé automatiquement
• Le démarrage automatique avait été désactivé afin de pouvoir vérifier manuellement l’état avant de recevoir du trafic après un redémarrage imprévu
  • Le principe d’exploitation donne la priorité à « éviter toute perte de données quand quelque chose casse » plutôt qu’à « maximiser la disponibilité du service »
• Après le redémarrage, les journaux du serveur montraient une corruption du système de fichiers
  • Il a été estimé que la cause de l’incident avait soit détruit le matériel, soit coupé la connexion entre le serveur et l’Elastic Block Store contenant le système de fichiers
  • La décision a été prise de poursuivre la configuration d’un nouveau serveur plutôt que de tenter de restaurer l’ancien

Structure en journal sur S3 et procédure de restauration

• Le service Tarsnap stocke les données dans Amazon S3 sous la forme d’un système de fichiers structuré en journal
  • Chaque objet S3 contient un en-tête avec les métadonnées de toutes les entrées du journal et, éventuellement, les données des entrées du journal
  • Une entrée de journal start write transaction ne contient qu’un en-tête identifiant la machine et le nonce de transaction, sans données de journal
  • Une entrée de journal store data block contient à la fois un en-tête identifiant la machine et le nom du bloc, ainsi que les données du bloc
• En fonctionnement normal, les métadonnées des entrées du journal sont mises en cache sur EC2 et ne sont pas relues depuis Amazon S3
  • Les lectures Amazon S3 n’ont lieu que lorsqu’il faut lire des données de bloc pour répondre aux requêtes des clients tarsnap
• La restauration de l’état de l’instance EC2 s’est déroulée en deux étapes
  • D’abord, lecture de tous les en-têtes de métadonnées depuis S3
  • Ensuite, rejeu (replay) de toutes les opérations en local
  • Dans un stockage structuré en journal, les entrées sont réécrites lors de la suppression de données afin de libérer de l’espace ; les deux étapes ne peuvent donc pas être effectuées en parallèle
  • Les entrées du journal possèdent des numéros d’ordre permettant un rejeu dans le bon ordre, mais elles doivent d’abord être triées après leur récupération

Défauts et goulots d’étranglement apparus pendant la restauration

• La première étape s’est déroulée sans problème et s’est achevée le 2023-07-03 01:49:49 UTC
  • Le processus de restauration était configuré pour envoyer 250 requêtes simultanées à Amazon S3
  • Cette valeur correspondait à ce qu’Amazon S3 pouvait supporter il y a 10 ans, et il est probable qu’elle aurait pu être nettement augmentée aujourd’hui
• La deuxième étape a échoué presque immédiatement
  • Une erreur indiquait que les entrées de journal rejouées enregistraient des données appartenant à une machine inexistante
  • La cause venait du code de transfert de compte machine écrit en 2014
  • Lorsqu’un utilisateur Tarsnap devait déplacer une machine d’un compte à un autre, le système enregistrait une nouvelle entrée de journal machine registration puis supprimait l’ancienne entrée
  • Des tests existaient, mais ils ne couvraient pas le cas où une machine avait été re-owned après l’enregistrement de données, puis où l’état du serveur était reconstruit
  • Comme le numéro d’ordre de la nouvelle entrée d’enregistrement de machine était plus élevé, le rejeu donnait l’impression que des données étaient stockées pour une machine qui n’existait pas encore
• Une fois la cause identifiée, cette « ceinture de sécurité » a été désactivée et la reconstruction de l’état a repris
  • Une erreur indiquant l’impossibilité de trouver des données dans Amazon S3 est alors apparue presque aussitôt
  • En cause : lors de la tentative de reprise, l’étape de téléchargement des données S3 avait été sautée, sans que la valeur maximum log entry sequence number soit réinitialisée ; elle était donc restée à 0
  • Après correction de ce problème, la reconstruction de l’état s’est poursuivie normalement
• La reconstruction de l’état a progressé plus lentement que nécessaire
  • S’il avait été compris plus tôt que le débit disque était le goulot d’étranglement, le débit du volume EBS concerné aurait pu être augmenté
  • Le manque de sommeil a empêché une surveillance fine du processus ; sans cela, le goulot d’étranglement aurait pu être identifié dans gstat(8) et Amazon CloudWatch, puis le volume EBS reconfiguré

Reprise du service et attribution de crédits

• Vers le 2023-07-03 15:10 UTC, le processus de reconstruction de l’état s’est achevé
  • L’heure exacte de fin n’a pas été consignée
  • Le serveur a été laissé en mode lecture seule et des tests rapides ont été effectués
  • En comparaison avec l’état de l’ancien serveur, il a été vérifié que tout correspondait, à l’exception des quelques dernières secondes de données perdues par le système de fichiers de l’ancien serveur au moment de l’incident
• Le premier trafic de production après l’incident a eu lieu le 2023-07-03 15:25:58 UTC
  • Cela correspond à environ 26 heures et 16 minutes après le début de l’incident
• Tarsnap n’a pas de SLA explicite, mais applique une politique d’octroi de crédits pour les incidents jugés équitablement compensables
  • Le 2023-07-13, un crédit de 50 % d’un mois de frais de stockage a été attribué à tous les comptes Tarsnap
  • Le traitement de ces crédits a eu lieu après la résolution de l’incident et un temps de repos

[GN⁺]

Avis sur Hacker News

• Je ne m’attendais vraiment pas à voir ce billet arriver tout en haut de HN. J’aimerais répondre aux questions, mais il est 22 h, et mon enfant s’est endormi à 17 h, donc avec un peu de chance je pourrai dormir environ 4 heures avant qu’il se réveille.
  Je repasserai demain matin pour répondre aux questions.

  • Je me demande quelle raison il y aurait d’utiliser ce service plutôt que restic. Merci à Colin, mais à lire ce billet, on a l’impression qu’il n’y a en fait qu’une seule personne responsable de l’infrastructure de ce service.
    C’est bien d’indiquer clairement qu’il n’y a pas de SLA, mais j’ai le sentiment qu’un gros risque s’interpose entre mes sauvegardes et moi.
  • Si vous devez écrire un autre post-mortem à l’avenir — ce que j’espère rare, voire jamais — ce serait bien d’indiquer clairement les enseignements tirés, de façon à voir quels points ne se reproduiront pas, et pourquoi.
  • C’est un post-mortem vraiment bien écrit et réfléchi, mais j’espère ne plus jamais avoir à lire ce genre de texte :)
  • Il est temps de confier le support 24 h/24 à votre enfant ;)
    Je lis https://www.amazon.com/No-Cry-Sleep-Solution-Toddlers-Presch... et ça fonctionne dans une certaine mesure. On peut le trouver dans n’importe quelle bibliothèque, c’est-à-dire une sorte de Blockbuster pour les livres.
  • Je me demande combien de temps les journaux de transactions sont conservés avant d’être réécrits.
    Ces dernières semaines, j’ai moi aussi eu quelques instances EC2 qui sont tombées avec des symptômes ressemblant à une déconnexion d’EBS ; dans mon cas, c’était en eu-west.

• Le passage indiquant que, conformément à la politique ambiguë « Tarsnap n’a pas de SLA, mais accorde des crédits en cas d’incident si cela semble juste », 50 % d’un mois de frais de stockage ont été crédités sur tous les comptes Tarsnap le 13/07/2023 en dit long sur la personne qu’est Percival.
  Ce crédit paraît assez généreux pour indemniser suffisamment les clients, et contrairement aux grands fournisseurs cloud, il n’a pas obligé chaque client à venir quémander séparément. En plus de cela, il y avait un post-mortem clair, technique et détaillé. À mon avis, tout le monde devrait faire ainsi.

  • L’expression « merci d’être un phare dans l’obscurité » convient parfaitement.
    Je suis assez heureux de vivre dans un monde où Tarsnap existe et où les prix sont exprimés en picodollars.

• Si les procédures de reprise après sinistre avaient été correctement mises en place et testées, le temps d’indisponibilité aurait pu être bien plus réduit.
  Il faut disposer d’un système de staging entièrement séparé, pouvoir le faire tomber puis le reconstruire, tester régulièrement différents modes de panne et documenter tous les détails de la procédure de restauration du système.
  À long terme, il peut aussi valoir la peine d’envisager d’augmenter le chiffre d’affaires afin de pouvoir embaucher des personnes à temps partiel, ce qui serait très utile si quelque chose de similaire se produisait.
  Nous sommes nous aussi un petit fournisseur de solutions cloud, centré sur des API de ML, et au fil des années il est devenu évident que lorsqu’on utilise du matériel cloud, qu’il soit dédié ou virtuel, des pannes surviennent périodiquement. La RAM, les HDD et d’autres composants matériels peuvent tomber en panne à tout moment ; à long terme, c’est donc un point à prendre en compte à 100 % quand on exploite un service en ligne à haute disponibilité.

• Respect pour ce post-mortem honnête et pour la bonne gestion d’une situation difficile. Cela dit, concernant le manque de sommeil, s’il n’y a qu’une seule personne capable de corriger le problème, il n’y a pas à avoir honte d’accepter un peu de temps d’incident supplémentaire pour garder les idées claires.
  Aller dormir un peu alors que les alertes retentissent peut sembler étrange, mais l’adrénaline combinée au manque de sommeil rend très facile d’aggraver le problème.

  • Pas d’inquiétude, j’ai fait quelques siestes entre-temps. Le fait de me dire « ça a l’air de bien tourner, mais il faudra encore quelques heures, donc je vais régler une alarme dans 2 heures et dormir un peu » est l’une des raisons pour lesquelles je n’ai pas remarqué que la deuxième étape était inutilement limitée par un goulot d’étranglement d’E/S.

• D’après la description, ce processus de restauration semble relativement facile à tester régulièrement, ce qui permettrait de trouver les bugs restants ou d’évaluer le temps de reprise.
  Comme on le dit souvent, seule une sauvegarde testée est une vraie sauvegarde.

  • Ayant découvert seulement après l’avoir testée que ma procédure de reprise après sinistre ne fonctionnait pas, je suis d’accord à 100 %. Le seul plan ayant une chance de fonctionner réellement est un plan reproductible et testé.
  • Exact. Je voulais le faire depuis un moment, mais il y avait toujours quelque chose de plus prioritaire. Je n’avais pas réalisé qu’avant cet incident, nous ne l’avions pas testée depuis près de 10 ans.
    À l’avenir, je veillerai à donner une priorité élevée à une répétition annuelle.

• C’est toujours agréable de voir un post-mortem aussi professionnel, courtois et honnête

• Je me base peut-être sur d’anciennes informations sur l’entreprise Tarsnap, mais le seul facteur qui m’a fait hésiter à utiliser Tarsnap sérieusement, c’était la panne imprévue Colin Percival, autrement dit le risque lié à une personne clé.
  Je ne pense pas être le seul.

  • C’est un peu comme un calcul de temps moyen entre pannes. La question est de savoir si l’on fait confiance à une solution bien conçue d’une entreprise unipersonnelle bien conçue, avec peu de pièces mobiles, ou à celle d’une entreprise bien plus grande, mais avec beaucoup plus de pièces mobiles et probablement moins bien conçue.
    Personnellement, je choisirais la solution la plus simple. D’après mon expérience, il faut énormément de complexité supplémentaire pour atteindre le niveau de fiabilité d’un système simple, et la plupart de cette complexité aggrave les choses.
    C’est évident avec le clustering de serveurs. Un serveur unique doté d’une alimentation et d’un réseau fiables est plus fiable que toute tentative de redonder ce service, tant qu’on n’a pas atteint environ 5 fois le coût et la complexité. Ce n’est qu’à ce niveau qu’on obtient un temps moyen entre pannes comparable à celui d’un serveur unique, et seulement ensuite qu’une véritable amélioration devient possible.
    Je crois fermement que le meilleur chemin vers une vraie fiabilité, c’est la simplicité autant que possible et de bonnes sauvegardes. Si une disponibilité 24 h/24 et 7 j/7 est nécessaire, les technologies parmi lesquelles choisir se réduisent assez fortement.
  • Je comprends que ce soit un risque, mais je ne suis pas sûr que ce soit forcément plus risqué qu’avec une plus grande entreprise.
    C’est le travail de Colin, le nom de Colin y est associé, et c’est très important pour Colin.
    Chez BigBackupCorp, il est difficile d’obtenir le même type de service. Les employés sont remplaçables, la direction est remplaçable et, franchement, moi aussi, en tant que client, je suis remplaçable si l’entreprise change de cap et décide de devenir BigFlowerArrangementShippingCorp.
    Ce qu’il y a de bien avec une petite activité, c’est qu’elle fonctionne entièrement selon son propre intérêt. Pas de manipulations boursières ni de combines à la VC. Si l’activité est rentable, quelqu’un peut venir la racheter, y apposer son nom et en faire son affaire. Je pense que l’Internet ouvert bénéficie énormément de ce genre de choses.
  • Si l’on dressait la liste des concurrents disparus avant Tarsnap, le calcul pourrait changer un peu. Le risque à évaluer ne devrait pas être « que se passe-t-il s’il arrive quelque chose à l’opérateur ? », mais « que se passe-t-il s’il lui arrive quelque chose, que le service tombe, et que je n’ai pas non plus de sauvegarde de la sauvegarde ? ».
    Avec une planification prudente, on peut réduire ce risque autant qu’on le souhaite.
  • Si vous lisez HN, vous apprendrez probablement dans les 24 heures qu’il est arrivé quelque chose à Colin. En pratique, il faudrait que le stockage principal, Tarsnap et Colin tombent tous en même temps dans une fenêtre d’environ 24 heures, avant la migration vers un nouveau fournisseur de sauvegarde, pour que cela devienne vraiment problématique.
  • Je n’ai pas l’intention de faire davantage confiance à un fournisseur de sauvegarde que cela. Dès qu’on en dépend, il échouera au pire moment.
    Mieux vaut traiter un service comme Tarsnap comme une couche parmi plusieurs, construire des sauvegardes multicouches et les vérifier régulièrement.

• Une erreur du genre « les entrées de journal rejouées écrivent des données pour une machine qui n’existe pas » pourrait probablement être détectée en écrivant un modèle TLA+.

• Avec une combinaison du type restic+backblaze, les coûts baissent de plusieurs ordres de grandeur ; je me demande donc quel est l’avantage d’utiliser Tarsnap. Je ne vois pas quel besoin concret pourrait motiver quelqu’un à payer 3000 dollars par To-an.

  • Certains d’entre nous ont pas mal d’argent en trop et aiment avoir un prétexte pour payer cperciva afin qu’il ne travaille pas dans un boulot médiocre et qu’il consacre ses compétences et son talent à des choses plus grandes et meilleures.
    À ceux qui parlent du faible bus factor : vous n’allez quand même pas mettre vos sauvegardes dans un seul service ou un seul emplacement, si ? Vous utiliseriez Tarsnap avec Restic+Backblaze, Rsync.net, S3, etc., non ? « La sauvegarde est l’impôt que l’on paie pour s’offrir le luxe de la restauration. »
  • La déduplication fonctionne extrêmement bien, si bien que le coût de l’ensemble de données cœur très important que je sauvegarde sur Tarsnap est négligeable. Si les données changeaient plus souvent, le calcul serait probablement différent.
    Par exemple, j’utilise d’autres services pour mes bibliothèques de vidéos et de photos, mais je sauvegarde mes bases de données comptables et mes documents importants sur Tarsnap.
    J’utilise Tarsnap depuis 10 ans, et je n’ai quasiment pas eu de problèmes de disponibilité, ni presque aucun problème d’aucune sorte dont je me souvienne.

• On dirait que la majeure partie des 26 heures d’indisponibilité a été consacrée à la restauration des sauvegardes. Par coïncidence, c’est exactement la raison pour laquelle je ne peux pas utiliser Tarsnap en environnement de production.
  Du point de vue utilisateur, la restauration des sauvegardes est douloureusement lente. Quand mon système est hors ligne, je n’ai pas la patience d’attendre des heures à cause du service de sauvegarde. Cela s’est peut-être amélioré aujourd’hui, mais la dernière fois que je l’ai utilisé, il y a quelques années, restaurer une sauvegarde de quelques Go prenait grosso modo de l’ordre d’une heure.