Am 15. Februar 2022 um 21:00 Uhr (UTC) fiel unser Validator aus und setzte die Validierung effektiv für 11 Stunden bis 8:00 Uhr des folgenden Tages aus.
Wir wurden sofort über den Ausfall des Validator benachrichtigt.
Kurz darauf haben wir den Validator deregistriert, damit keine weiteren Proposals verpasst wurden, die den aktuellen Prozentsatz der Uptime (die derzeit bei 99,3 % liegt) weiter verringert hätten, bis das Problem behoben werden konnte. Der Validator wurde am nächsten Morgen mit einer geringeren Gebühr von 0,1 % (statt 1,99 %) erneut registriert. Die Gebühr wird sich in etwa 2 Wochen wieder normalisieren.
Post-Mortem
Hier gehen wir detailliert darauf ein, was schief gelaufen ist und wie wir versuchen, diese Art von Situation in Zukunft zu verhindern.
Alle Zeiten sind in UTC (Londoner Zeit) angegeben.
15.02.2022, 21 Uhr
Der derzeit aktive Validator Nodes wurde von unserem Hosting-Provider heruntergefahren und in den Wartungsmodus versetzt. Die Wartungsarbeiten begannen um 21:00 Uhr und dauerten bis 7:00 Uhr am nächsten Morgen.
Die Wartung von 3 unserer Server (an 3 verschiedenen Tagen) wurde tatsächlich im Voraus angekündigt, sodass all dies vollständig vermeidbar war. Das war ein menschlicher (mein) Fehler. Ich habe die Servernamen verwechselt und dachte, das würde erst am nächsten Tag passieren. Das ist mein Fehler und ich entschuldige mich bei unseren Stakern für die unnötige Ausfallzeit.
Selbst mit diesem menschlichen Fehler hätte dies keine große Sache sein sollen.
Die Ausfallzeit für den Wechsel zum Failover sollte nur ein paar Minuten lang sein.
Schließlich war ich alarmiert und konnte sofort reagieren.
Aufgrund unerwarteter Komplikationen mit der Failover-Node war dieser jedoch nicht sofort einsatzbereit.
Obwohl es einen Snapshot des Ledgers und der zugehörigen DB-Dateien gab, schienen sie beschädigt zu sein, und so begann die Failover-Node erneut von Anfang an mit der Synchronisierung.
Eine vollständige Synchronisierung von Null dauert mindestens 12 Stunden. Das ist ein großes Problem.
So wie man es eben tut, ging ich im #node-runners-Kanal auf dem RadixDLT-Discord-Server, um darüber zu jammern.
Da die Radix-Community ist so großartig ist, haben die Leute haben mich sofort gehört.
Faraz von radstakes.com bot sofort seine Hilfe an. Rigel (Marco) von StakingCoins hat hat auch gleich geantwortet und mir einen Link zu einem Backup der Datenbank von seinem Validator angeboten, um die Re-Synchronisation zu beschleunigen. Das Backup war schon etwas älter, würde aber trotzdem viel Zeit sparen.
Faraz fuhr dann fort, darauf hinzuweisen, dass Stuart von RadixPool immer noch ein relativ aktuelles Backup mit der Community auf der RadixPool-Website teilte. Wie Faraz im Discord sagte, schulden wir Stuart definitiv mehr als ein paar Bier für seinen fortwährenden Dienst an der Radix-Community.
Mit Stuarts Backup konnte ich die Failover-Node gegen 23 Uhr neu synchronisieren.
Danke an Faraz und Rigel, dass sie so nett und hilfsbereit sind! Und danke an Stuart für die Bereitstellung dieser Snapshots.
15.02.2022, 23 Uhr
Zu diesem Zeitpunkt hatte ich den Validator wieder aktiviert, aber noch nicht registriert. Das Problem war wieder ein unerwartetes für mich 1 . Der ursprüngliche Validator-Server konnte eigentlich in keiner Weise von mir kontrolliert werden. Der Hosting-Provider erlaubt es nicht, den Server zu deaktivieren oder zu entfernen, seinen Internetzugang zu entfernen, Ports zu schließen oder ähnliches. Nachdem die Wartung also abgeschlossen war, würde der Server dann automatisch neu starten und versuchen die Validierung fortzusetzen.
Dies ist ein Problem, da niemals 2 Nodes mit demselben Schlüssel aktiv sein dürfen, die beide zu validieren versuchen. Dies führt zu verpassten Proposals, da sie unter den Validatoren um den Platz kämpfen.
Nach meiner Erfahrung mit anderen Hosting-Anbietern wäre dies normalerweise kein Problem gewesen. Ich würde einfach den inaktiven Server deaktivieren, damit er nicht automatisch neu startet.
Leider, und damit habe ich nicht gerechnet, hatte ich bei unserem jetzigen Provider keine solche Kontrolle über den Server.
Ich hätte das natürlich erkennen müssen, bevor diese Situation eintrat. Mein Fehler.
Das bedeutet, dass ich nicht verhindern konnte, dass es irgendwann automatisch wieder online geht und die Dinge ruiniert.
Aus diesem Grund habe ich mich schweren Herzens entschieden, den Validator bis zum Ende des Wartungsfensters am nächsten Morgen abgemeldet zu lassen.
16.0.2022, 7 Uhr
Als das Wartungsfenster endlich vorbei war, kam der ursprüngliche Validator wie erwartet wieder online.
Jetzt war es natürlich wieder nicht synchron, da es seit etwa 11 Stunden nicht mehr online war.
Wenn ich sicher gewusst hätte, dass der alte Validator erst zu einem bestimmten Zeitpunkt wieder online kommt, hätte ich den Validator nicht abmelden müssen. Ich hätte alle Zeit der Welt gehabt, den alten Server abzuschalten, während er aufholte, sobald er wieder online war.
Leider hätte es jederzeit innerhalb eines 8-Stunden-Zeitfensters mitten in der Nacht wieder online gehen können. Wir haben dies bei der Wartung eines anderen Servers beobachtet.
Jetzt hatte ich wieder die Kontrolle über den Server und habe die Radix-Node darauf deaktiviert.
Dann habe ich das noch synchronisierte Failover zum Validator hochgestuft und den Validator neu registriert, damit er wieder am Netzwerk teilnimmt.
Wie oben erwähnt, habe ich bei der Neuregistrierung des Validators dies mit einer viel niedrigeren Gebühr von 0,1% im Gegensatz zu unserer normalen Gebühr von 1,99% getan. Ich hatte ursprünglich beabsichtigt, die Gebühr zu senken, um die verpassten Belohnungen auszugleichen. Ich habe dann nach einigen Diskussionen in unserem Discord meine Meinung geändert.
Um ehrlich zu sein: Es ist nur so niedrig wie jetzt, weil ich bei der Ummeldung nicht berücksichtigt habe, dass der Gebührenparameter in der Transaktion eigentlich nicht in Prozent (1,99), sondern in Promille (199) erwartet wurde. Aber immerhin haben unsere Staker jetzt mehr Rewards, als ich ursprünglich für eine Weile beabsichtigt hatte.
Diese Änderung wird jedoch in etwa 2 Wochen auf 1,99 % zurückgesetzt.
Zusammenfassung
Zusammenfassend: Das Problem wurde durch menschliches Versagen (1) verursacht, also zunächst von mir. Das Failover war dann nur verzögert verfügbar (2). Und selbst als der Failover bereit war, konnten wir den Validator aufgrund von Bedenken hinsichtlich der doppelten Validierung (3) nicht erneut registrieren.
Ich kann nur versprechen, dass meine Fehler nicht noch einmal passieren. Ich habe von ihnen gelernt und werde von nun an besonders vorsichtig sein.
Was technische Probleme betrifft, so sollen diese in Zukunft gemildert werden.
1Was natürlich nicht die Schuld des Anbieters ist. Das Problem war nur, dass ich mich zu sehr an Cloud-Hosting-Anbieter wie AWS oder Hetzner gewöhnt hatte, wo man so etwas einfach machen kann. Aber für unsere Node haben wir uns für Root-Server entschieden, die näher am Metall liegen, die natürlich nicht annähernd so flexibel sind.
Die Zukunft
Das kritischste Problem war hier das Problem der doppelten Validierung (3). Ohne dies wäre der Validator trotz Problem Nummer 2 (die beschädigte Datenbank auf dem Failover-Server) innerhalb von 2 Stunden nach dem Ausfall wieder betriebsbereit gewesen. Immer noch nicht ideal, aber viel besser als 11 Stunden.
Vermeidung von Doppelvalidierung
Um dies in Zukunft zu verhindern, werden wir unser Docker-Setup anpassen.
Aktuell wird vor dem Start der Docker-Dienste auf einem Server einmalig die Konfiguration auf dem Server angepasst (Validator vs Full Node Configuration). Ab dann startet der Server immer in dieser konfigurierten Rolle, also entweder als Validator oder nur als Full Node.
Wenn ein Server komplett ausfällt, so dass nicht einmal mehr in der Konfiguration auf seiner Platte angepasst werden kann (wie es in diesem Fall passiert ist), können wir den anderen nicht sicher auf die Validator-Rolle umstellen.
Dieser Schritt hätte kurz vor dem Wartungsfenster erfolgen sollen. Es ist ein Problem, dass dies einen manuellen Schritt erfordert, bevor der Server ausfällt, da wir bei diesem Anbieter nicht sicherstellen können, dass er runtergefahren bleibt.
Um dies verbessern, machen wir die Konfigurationsquelle für den Wechsel zwischen Validator und Full Node extern. Das heißt, es wird eine Konfigurationsdatei geben, beispielsweise in einem öffentlichen S3-Bucket, die einfach die IP des Servers enthält, der einer Rolle zugeordnet ist.
Wir werden den Docker-Container so anpassen, dass er diese externe Quelle prüft, um zu entscheiden, ob er als Validator oder Full Node startet. Dies bedeutet, dass selbst wenn der ursprüngliche Validator-Server wieder online geht, diese Datei überprüft wird und sobald er feststellt, dass er nicht mehr die Validator-Rolle hat, er einfach nur als Full Node gestartet wird, wodurch das Problem der doppelten Validierung verhindert wird.
Sollte die externe Konfigurationsquelle aus irgendeinem Grund nicht verfügbar sein, könnten wir immer noch auf die manuelle Konfiguration auf dem Server zurückgreifen. Aber standardmäßig würde der Node-Container überhaupt nicht starten.
Snapshots externer Datenbanken
Problem Nummer 2 war die beschädigte Datenbank auf der Failover-Node. Dies sollte natürlich zunächst nicht passieren und wir werden auch dieses Problem beheben. Wir glauben, dass dies auf einen Neustart des Servers während des lokalen Snapshot-Prozesses zurückzuführen ist. Das Überschreiben des letzten Snapshots hat ihn dann beschädigt. Wir werden dies so anpassen, dass wir mehrere Snapshots behalten, damit wir in diesem Fall auf einen vorherigen zurückgreifen können.
Darüber hinaus werden wir uns eine Scheibe von Stuart abschneiden und zusätzliche externe Snapshots der Datenbank speichern, die wir dann als letzten Ausweg herunterladen können.
Abschließende Gedanken
Diese lange Ausfallzeit von 11 Stunden wurde durch mehrere separate Probleme verursacht, die alle zusammenkamen, aber am Ende durch meine Fehler ausgelöst wurden. Wir sind uns bewusst, dass unser Setup nicht ideal war und wir ein Problem in diesem Ausmaß selbst angesichts menschlicher Fehler auf meiner Seite hätten verhindern können.
Wir haben daraus gelernt und werden unsere Infrastruktur entsprechend verbessern, um in Zukunft einen zuverlässigeren Service anbieten zu können.
Ein großes Dankeschön an alle unsere Staker , die trotz dieser vorübergehenden Probleme bei uns bleiben, und insbesondere an diejenigen, die ihre Unterstützung in unserem Telegram-Kanal zum Ausdruck gebracht haben.
