Postmortem zur Einstellung des Tarsnap-Dienstes

• Der zentrale Tarsnap-Server fiel in Amazon EC2 us-east-1 wegen eines failed system status check aus, wodurch der Dienst ab etwa 2023-07-02 13:07:58 UTC für rund 26 Stunden 16 Minuten unterbrochen war
• Die Störung wurde um 13:10 UTC erkannt, aber nach einem unerwarteten Neustart griff die Betriebsrichtlinie, den Servercode nicht automatisch zu starten, sondern ihn von einer Person manuell prüfen zu lassen
• Die Wiederherstellung erfolgte, indem die Metadaten-Header des log-strukturierten Dateisystems aus Amazon S3 gelesen und die Operationen lokal der Reihe nach wiedergegeben wurden; der erste Schritt endete am 2023-07-03 01:49:49 UTC
• Bei der Rekonstruktion des Zustands traten ein nicht getesteter Fall der 2014 implementierten Behandlung von machine re-owned sowie eine fehlende Initialisierung der Resume-Logik zutage; auch die Begrenzung des Datenträgerdurchsatzes verzögerte die Wiederherstellung
• Tarsnap hat zwar kein klares SLA, gewährte aber gemäß seiner Richtlinie bei als fair eingestuften Ausfällen am 2023-07-13 allen Konten eine 50-%-Gutschrift auf die Speicherkosten eines Monats

---

Ausfall und erste Reaktion

• Um etwa 2023-07-02 13:07:58 UTC ging der zentrale Server von Tarsnap in der Amazon-EC2-Region us-east-1 offline
  • Der EC2-Status war failed system status check
  • Bei einer virtuellen Maschine kann dieser Status auf verschiedene Ursachen hindeuten, etwa Stromausfall, Hardwarefehler des physischen Servers oder eine EC2-Netzwerkstörung
  • Zur selben Zeit waren keine breitflächigen Berichte über EC2-Störungen zu sehen, daher wurde ein isolierter Hardwarefehler als wahrscheinlichste Ursache angesehen
• Das Monitoring erkannte die Störung am 2023-07-02 um 13:10 UTC
  • Überwacht wurde, indem aus einer anderen EC2-Region alle 5 Minuten Archiv-Schreib-, Lese- und Löschvorgänge ausgeführt wurden
  • Die SMS-Benachrichtigung um 13:10 UTC weckte niemanden, aber die Telefonbenachrichtigung um 13:15 UTC leitete die Reaktion ein
  • Da die erste Untersuchung keinen klaren vorübergehenden Fehler zeigte, wurde von einem abgestürzten System ausgegangen und die Vorbereitung einer Ersatz-EC2-Instanz begonnen

Betriebsrichtlinie zur Vermeidung automatischer Neustarts

• Um etwa 2023-07-02 13:52 UTC startete Amazon den ausgefallenen Server auf einer neuen EC2-Instanz neu
  • Das war etwa 45 Minuten nach Beginn der Störung
  • Das Betriebssystem FreeBSD fuhr hoch, aber der Tarsnap-Servercode wurde nicht automatisch gestartet
• Der automatische Start war deaktiviert, damit nach einem unerwarteten Neustart der Zustand manuell geprüft werden kann, bevor wieder Traffic angenommen wird
  • Nach der Betriebsrichtlinie ist es wichtiger, „bei einem Defekt Datenverlust zu verhindern“, als „die Serviceverfügbarkeit zu maximieren“
• Nach dem Neustart zeigten die Serverlogs eine Beschädigung des Dateisystems
  • Es wurde angenommen, dass die Ursache entweder die Hardware außer Gefecht gesetzt oder die Verbindung zwischen dem Server und dem Elastic Block Store mit dem Dateisystem getrennt hatte
  • Statt den bestehenden Server wiederherzustellen, wurde beschlossen, die Einrichtung eines neuen Servers fortzusetzen

S3-Log-Struktur und Wiederherstellungsverfahren

• Der Tarsnap-Dienst speichert Daten als log-strukturiertes Dateisystem in Amazon S3
  • Jedes S3-Objekt enthält einen Header mit den Metadaten aller Log-Einträge und optional die Daten der Log-Einträge
  • Der Log-Eintrag start write transaction enthält nur einen Header zur Identifikation von Maschine und Transaktions-Nonce, aber keine Log-Daten
  • Der Log-Eintrag store data block enthält einen Header zur Identifikation von Maschine und Blocknamen sowie die Blockdaten selbst
• Im Normalzustand werden die Metadaten der Log-Einträge auf EC2 zwischengespeichert und nicht erneut aus Amazon S3 gelesen
  • Lesezugriffe auf Amazon S3 erfolgen nur, wenn als Antwort auf Anfragen von Tarsnap-Clients Blockdaten gelesen werden
• Die Wiederherstellung des Zustands der EC2-Instanz ist in zwei Schritte aufgeteilt
  • Zuerst werden alle Metadaten-Header aus S3 gelesen
  • Danach werden alle Operationen lokal replayed
  • In einem log-strukturierten Speicher werden Log-Einträge beim Löschen von Daten erneut geschrieben, um Speicherplatz freizugeben; deshalb können die beiden Schritte nicht gleichzeitig ausgeführt werden
  • Die Log-Einträge haben Sequenznummern, sodass sie in der richtigen Reihenfolge wiedergegeben werden können, müssen nach dem Abruf aber zunächst sortiert werden

Während der Wiederherstellung aufgedeckte Fehler und Engpässe

• Der erste Schritt verlief ohne Probleme und wurde am 2023-07-03 um 01:49:49 UTC abgeschlossen
  • Der Wiederherstellungsprozess war so konfiguriert, dass 250 gleichzeitige Anfragen an Amazon S3 gesendet wurden
  • Dieser Wert war auf das abgestimmt, was Amazon S3 vor 10 Jahren bewältigen konnte; heute hätte er vermutlich deutlich höher gesetzt werden können
• Der zweite Schritt scheiterte fast sofort
  • Es trat ein Fehler auf, wonach ein wiedergegebener Log-Eintrag Daten zu einer nicht existierenden Maschine schreiben würde
  • Ursache war Code zur Behandlung von Kontoverschiebungen von Maschinen, der 2014 geschrieben worden war
  • Wenn Tarsnap-Nutzer eine Maschine zwischen Konten verschieben mussten, wurde ein neuer Log-Eintrag machine registration gespeichert und der vorherige Eintrag gelöscht
  • Es gab Tests, aber der Fall, dass eine Maschine nach gespeicherten Daten re-owned wurde und anschließend der Serverzustand rekonstruiert werden musste, fehlte
  • Da die Sequenznummer des neuen Maschinenregistrierungs-Log-Eintrags höher war, sah es beim Replay so aus, als würden Daten für eine noch nicht existierende Maschine gespeichert
• Nachdem die Ursache identifiziert war, wurde dieser „seatbelt“ deaktiviert und die Zustandsrekonstruktion fortgesetzt
  • Kurz darauf trat jedoch ein Fehler auf, dass Daten in Amazon S3 nicht gefunden werden konnten
  • Grund war, dass beim Fortsetzungsversuch der Schritt zum Herunterladen der S3-Daten übersprungen wurde und dadurch der Wert maximum log entry sequence number nicht initialisiert wurde und bei 0 blieb
  • Nach Behebung dieses Problems lief die Zustandsrekonstruktion normal weiter
• Die Zustandsrekonstruktion verlief langsamer als nötig
  • Wäre bekannt gewesen, dass der Datenträgerdurchsatz der Engpass war, hätte der Durchsatz des betreffenden EBS-Volumes höher eingestellt werden können
  • Wegen Schlafmangels konnte der Prozess nicht genau überwacht werden; andernfalls hätte sich der Engpass mit gstat(8) und Amazon CloudWatch erkennen und das EBS-Volume neu konfigurieren lassen

Wiederaufnahme des Dienstes und Gutschrift

• Um etwa 2023-07-03 15:10 UTC war der Prozess zur Zustandsrekonstruktion abgeschlossen
  • Der genaue Abschlusszeitpunkt wurde nicht protokolliert
  • Der Server wurde im Read-only-Modus belassen und es wurden schnelle Tests durchgeführt
  • Durch Vergleich mit dem Zustand des bisherigen Servers wurde geprüft, ob Übereinstimmung bestand, abgesehen von den letzten wenigen Sekunden an Daten, die das Dateisystem des alten Servers zum Zeitpunkt des Ausfalls verloren hatte
• Der erste echte Produktions-Traffic nach dem Ausfall trat am 2023-07-03 um 15:25:58 UTC auf
  • Das war etwa 26 Stunden 16 Minuten nach Beginn der Störung
• Tarsnap hat zwar kein klares SLA, wendet aber eine Richtlinie an, nach der bei als fair angesehenen Ausfällen Gutschriften gewährt werden
  • Am 2023-07-13 erhielten alle Tarsnap-Konten eine Gutschrift von 50 % der Speicherkosten eines Monats
  • Die Gutschrift wurde nach der Störungsbehebung und einer Ruhepause verarbeitet

[GN⁺]

Meinungen auf Hacker News

• Ich hätte wirklich nicht erwartet, dass dieser Beitrag ganz oben auf HN landet. Ich würde gern Fragen beantworten, aber es ist jetzt 22 Uhr, und mein Kind ist um 17 Uhr eingeschlafen. Wenn ich Glück habe, kann ich wohl etwa 4 Stunden schlafen, bevor es aufwacht.
  Ich schaue morgens wieder rein und beantworte Fragen.

  • Ich frage mich, warum man diesen Dienst statt restic verwenden sollte. Dank an Colin, aber nach diesem Beitrag wirkt es so, als gäbe es für diesen Dienst faktisch nur eine einzige Person, die für die Infrastruktur verantwortlich ist.
    Es ist gut, dass klar gesagt wird, dass es kein SLA gibt, aber es fühlt sich an, als läge ein großes Risiko zwischen mir und meinen Backups.
  • Falls ihr in Zukunft noch einmal eine Postmortem-Analyse schreibt – was ich natürlich hoffe, dass es selten oder gar nicht passiert –, wäre es gut, die Learnings klar zu benennen, sodass ersichtlich ist, welcher Punkt warum nicht noch einmal auftreten wird.
  • Eine wirklich gut geschriebene und durchdachte Postmortem-Analyse, aber ich hoffe, so etwas nie wieder lesen zu müssen :)
  • Jetzt ist es Zeit, dem Kind den 24/7-Support zu übertragen ;)
    Ich lese https://www.amazon.com/No-Cry-Sleep-Solution-Toddlers-Presch... und sehe damit gewisse Erfolge. Man bekommt es in jeder Bibliothek, also diesem Blockbuster für Bücher.
  • Ich frage mich, wie lange die Transaktionslogs aufbewahrt werden, bevor sie überschrieben werden.
    In den letzten Wochen sind auch bei mir ein paar EC2-Instanzen ausgefallen, mit Symptomen, als wären sie von EBS getrennt worden; in meinem Fall war es eu-west.

• Der Teil, dass Percival gemäß der etwas vagen Richtlinie „Tarsnap hat kein SLA, vergibt aber Gutschriften für Ausfälle, wenn es fair erscheint“ am 13.07.2023 allen Tarsnap-Konten 50 % der monatlichen Speicherkosten gutgeschrieben hat, zeigt sehr gut, was für ein Mensch er ist.
  Diese Gutschrift wirkt ziemlich großzügig darin, Kunden angemessen zu entschädigen, und anders als große Cloud-Anbieter hat er nicht jeden Kunden einzeln antanzen und betteln lassen. Dazu kam eine klare, technische und detaillierte Postmortem-Analyse. Meiner Meinung nach sollte es überall so laufen.

  • „Danke, dass du ein Leuchtturm in der Dunkelheit bist“ trifft es genau.
    Es ist ziemlich schön, in einer Welt zu leben, in der Tarsnap existiert und in Picodollars abgerechnet wird.

• Wenn die Disaster-Recovery-Prozeduren richtig eingerichtet und getestet worden wären, hätte sich die Downtime deutlich reduzieren lassen.
  Man braucht ein vollständig separates Staging-System, das man herunterfahren und neu aufbauen kann, sollte regelmäßig verschiedene Fehlermodi testen und alle Details der Systemwiederherstellung dokumentieren.
  Langfristig wäre es auch überlegenswert, den Umsatz zu steigern, um Teilzeitpersonal einstellen zu können, das bei ähnlichen Vorfällen sehr hilfreich wäre.
  Wir sind ebenfalls ein kleiner Anbieter von Cloud-Lösungen mit Fokus auf ML-APIs, und über die Jahre ist immer klarer geworden, dass bei Cloud-Hardware – ob dediziert oder virtuell – regelmäßig Ausfälle auftreten. RAM, HDDs oder andere Hardwarekomponenten können jederzeit kaputtgehen; beim langfristigen Betrieb hochverfügbarer Online-Dienste muss man das zu 100 % einplanen.

• Respekt für die ehrliche Postmortem-Analyse und den guten Umgang mit einer schwierigen Situation. Was den Schlafmangel angeht: Wenn es nur eine Person gibt, die das Problem beheben kann, muss man sich nicht dafür schämen, etwas zusätzliche Ausfallzeit in Kauf zu nehmen, um wieder klar denken zu können.
  Es fühlt sich seltsam an, sich schlafen zu legen, während Alarme laufen, aber die Kombination aus Adrenalin und zu wenig Schlaf macht es sehr leicht, die Lage noch zu verschlimmern.

  • Keine Sorge, ich habe zwischendurch ein paar Nickerchen gemacht. „Das scheint gut zu laufen, braucht aber noch ein paar Stunden; ich stelle den Wecker auf in 2 Stunden und schlafe etwas“ war einer der Gründe, warum ich nicht bemerkt habe, dass der zweite Schritt unnötig in einen I/O-Flaschenhals geraten war.

• Nach der Beschreibung wirkt dieser Wiederherstellungsprozess relativ leicht regelmäßig testbar; dabei könnte man verbleibende Bugs finden oder die Wiederherstellungszeit abschätzen.
  Wie man so sagt: Nur ein getestetes Backup ist ein echtes Backup.

  • Aus der Perspektive von jemandem, der erst durch Tests herausgefunden hat, dass sein Disaster-Recovery-Prozess nicht funktioniert: 100 % Zustimmung. Der einzige Plan, der in der Praxis eine Chance hat zu funktionieren, ist ein wiederholbarer und getesteter Plan.
  • Genau. Ich wollte das schon eine Weile machen, aber es gab immer etwas mit höherer Priorität. Bis zu diesem Ausfall war mir nicht klar, dass ich es fast 10 Jahre lang nicht getestet hatte.
    Künftig werde ich sicherstellen, dass eine jährliche Probe eine hohe Priorität hat.

• Es ist immer gut, eine so professionelle, höfliche und ehrliche Postmortem-Analyse zu sehen.

• Ich beziehe mich vielleicht auf veraltete Informationen über die Firma Tarsnap, aber der einzige Faktor, der mich zögern ließ, Tarsnap ernsthaft zu nutzen, war ein unerwarteter Colin-Percival-Ausfall, also das Key-Person-Risiko
  Ich glaube nicht, dass ich damit allein bin

  • Das ist ähnlich wie eine Berechnung der mittleren Zeit zwischen Ausfällen. Es geht darum, ob man einer gut konzipierten Lösung eines gut aufgestellten Ein-Personen-Unternehmens mit wenigen beweglichen Teilen vertraut oder der Lösung eines viel größeren Unternehmens, die aber viel mehr bewegliche Teile hat und wahrscheinlich weniger gut konzipiert ist
    Ich persönlich würde die einfachere Lösung wählen. Meiner Erfahrung nach braucht es enorm viel zusätzliche Komplexität, um das Zuverlässigkeitsniveau einfacher Systeme zu erreichen, und der Großteil dieser Komplexität macht die Lage eher schlechter
    Beim Server-Clustering wird das deutlich. Ein einzelner Server mit stabiler Stromversorgung und stabilem Netzwerk ist zuverlässiger als jeder Versuch, diesen Dienst redundant auszulegen, bis Kosten und Komplexität ungefähr um den Faktor 5 gestiegen sind. Erst etwa dann erreicht man eine mittlere Zeit zwischen Ausfällen, die mit einem einzelnen Server vergleichbar ist, und erst danach sind tatsächliche Verbesserungen möglich
    Ich bin fest davon überzeugt, dass der beste Weg zu echter Zuverlässigkeit so viel Einfachheit wie möglich und gute Backups sind. Wenn 24/7-Verfügbarkeit das ganze Jahr über nötig ist, schränkt das die wählbaren Technologien ziemlich stark ein
  • Ich verstehe, dass das ein Risiko ist, bin aber nicht überzeugt, dass es zwangsläufig riskanter ist als bei größeren Unternehmen
    Das ist Colins Arbeit, Colins Name steht dafür, und es ist Colin sehr wichtig
    Bei BigBackupCorp ist es schwer, dieselbe Art von Service zu bekommen. Mitarbeiter sind austauschbar, das Management ist austauschbar, und ehrlich gesagt bin auch ich als Kunde austauschbar, wenn das Unternehmen beschließt, seine Richtung zu ändern und zu BigFlowerArrangementShippingCorp zu werden
    Das Gute an kleinen Unternehmen ist, dass sie vollständig aus eigenem Interesse handeln. Es gibt keine Spielchen mit dem Aktienkurs und keine VC-Tricks. Wenn es ein profitables Geschäft ist, kann jemand kommen, es übernehmen und es unter seinem eigenen Namen zu seiner eigenen Sache machen. Ich glaube, das offene Internet profitiert stark von so etwas
  • Wenn man eine Liste der Wettbewerber erstellt, die vor Tarsnap verschwunden sind, kann die Rechnung etwas anders aussehen. Das zu bewertende Risiko sollte nicht lauten: „Was passiert, wenn dem Betreiber etwas zustößt?“, sondern: „Was ist, wenn ihm etwas zustößt, der Dienst ebenfalls ausfällt und ich kein Backup des Backups gemacht habe?“
    Dieses Risiko lässt sich mit sorgfältiger Planung so klein machen, wie man möchte
  • Wenn man HN liest, würde man vermutlich innerhalb von 24 Stunden erfahren, dass Colin etwas zugestoßen ist. Realistisch betrachtet müssten der primäre Speicher, Tarsnap und Colin alle gleichzeitig innerhalb eines Fensters von etwa 24 Stunden ausfallen, bevor man zu einem neuen Backup-Anbieter gewechselt ist, damit es wirklich ein Problem gibt
  • Ich habe nicht vor, einem Backup-Anbieter mehr zu vertrauen als das. Denn sobald man sich darauf verlässt, wird er im schwierigsten Moment ausfallen
    Dienste wie Tarsnap sollte man besser als eine von mehreren Schichten betrachten, mehrschichtige Backups aufbauen und sie regelmäßig überprüfen

• Fehler wie ein wiedergegebener Log-Eintrag, der Daten zu einer Maschine aufzeichnet, die gar nicht existiert, könnte man vermutlich mit einem TLA+-Modell finden

• Mit einer Kombination wie restic+backblaze liegen die Kosten um mehrere Größenordnungen niedriger; ich frage mich daher, welchen Vorteil Tarsnap bietet. Ich weiß nicht, welche konkreten Anforderungen einen dazu motivieren würden, 3000 Dollar pro TB-Jahr zu zahlen

  • Einige von uns haben ziemlich viel Geld übrig und mögen einen Vorwand, cperciva Geld zu geben, damit er nicht in einem miserablen Job arbeitet, sondern seine Fähigkeiten und Talente für größere und bessere Dinge einsetzt
    An die Leute, die nach dem niedrigen Bus-Faktor fragen: Ihr legt eure Backups doch nicht nur bei einem Dienst oder an einem einzigen Ort ab, oder? Ihr nutzt doch Tarsnap zusammen mit Restic+Backblaze, Rsync.net, S3 usw.? „Backups sind die Steuer, die man zahlt, um sich den Luxus der Wiederherstellung leisten zu können“
  • Die Deduplizierung funktioniert sehr gut, daher sind die Kosten für das sehr wichtige Kerndatenpaket, das ich bei Tarsnap sichere, vernachlässigbar. Wenn sich die Daten häufiger ändern würden, sähe die Rechnung wohl anders aus
    Für meine Video- und Fotobibliothek nutze ich zum Beispiel andere Dienste, aber Buchhaltungsdatenbanken und wichtige Dokumente sichere ich bei Tarsnap
    Ich nutze Tarsnap seit 10 Jahren, hatte kaum Verfügbarkeitsprobleme und, soweit ich mich erinnere, praktisch keine Probleme irgendeiner Art

• Es klingt so, als sei der Großteil der 26 Stunden Downtime für die Wiederherstellung aus Backups draufgegangen. Zufälligerweise ist genau das der Grund, warum ich Tarsnap nicht in der Produktionsumgebung einsetzen kann
  Aus Nutzersicht ist die Wiederherstellung aus Backups schmerzhaft langsam. Wenn mein System offline ist, habe ich nicht die Geduld, wegen eines Backup-Dienstes stundenlang zu warten. Vielleicht ist es inzwischen besser, aber als ich es vor ein paar Jahren zuletzt genutzt habe, dauerte die Wiederherstellung eines Backups von ein paar GB ungefähr in der Größenordnung einer Stunde