Retrospektive: Unser Plattformbetrieb 2023 – viele Updates und ein Downgrade

Grundsätzlich verfolgen wir beim Flying Circus den Ansatz, Patches, die Fehler beheben sollen, so schnell wie möglich einzuspielen und die Basisdistribution kontinuierlich alle zwei Wochen zu aktualisieren. Große funktionale Upgrades stellen wir in einem halbjährlichen Releasezyklus zur Verfügung, indem wir unsere Plattform auf die jeweils aktuell verfügbaren NixOS-Releases upgraden. 

Bei akuten Problemen z. B. in Form von besonders riskanten Sicherheitslücken, sind wir natürlich auch in der Lage, schneller zu reagieren und im Notfall einen verfügbaren Patch innerhalb weniger Stunden durch unsere Qualitätssicherung bis in die Produktivumgebungen zu bringen. In all diesen Situationen gilt die Annahme, dass neuere Versionen einer Software tendenziell weniger Fehler aufweisen sollten als ältere Versionen. Die allermeisten Entwickler z. B. bei NixOS geben sich hier entsprechend viel Mühe, Feature- und Bugfix-Releases klar zu trennen und mit automatisierten Tests die Qualität trotz schneller Release-Zyklen sehr hoch zu halten.

Neben den vielen kontinuierlichen Updates in unserem Releaseprozess gab es in diesem Jahr jedoch eine Besonderheit, die nur selten vorkommt: Im Falle unseres Plattformreleases vom 13. November (2023_029) haben wir uns dazu entschieden, einen bereits stabil im Einsatz befindlichen Kernel (Linux 6.1) wieder durch einen älteren Kernel (Linux 5.15) zu ersetzen. Statt der sonst üblichen kontinuierlichen Updates haben wir also ein Downgrade durchgeführt.

Wie kam es dazu?

Seit etwa 8 Monaten untersuchen wir in unserem Plattformteam ein Phänomen, bei dem sporadisch Abstürze einzelner virtueller Maschinen beobachtet wurden. 

Sporadisch heißt hier: 3 VMs verzeichneten über einen Zeitraum von 6 Monaten jeweils einen einzigen Crash, der uns aber aufgrund der Art und Weise, wie er auftrat, dazu veranlasste, die Situation genauer zu beobachten und zu untersuchen. Erste Ergebnisse deuteten darauf hin, dass die Abstürze auf einen möglichen Kernel-Bug zurückzuführen waren. Im Austausch mit den Linux-Entwicklern konnten wir schnell klären, dass es sich um einen bisher unbekannten Fehler im aktuellen Kernel 6.1 handelte. Die Seltenheit, mit der dieser Fehler zum Absturz einer virtuellen Maschine geführt hat, lässt erahnen, wie gering die Wahrscheinlichkeit ist, dass dieser Fehler zu einem tatsächlichen Absturz führt. 

Gleichzeitig ist dieser Fehler für die Kernel-Entwickler trotz unserer Unterstützung und detaillierter Fehlerberichte (und mittlerweile auch mit Cloudflare, einer weiteren betroffenen Firma) nicht reproduzierbar.

Mit dem Wissen um ein mögliches Problem im aktuell verwendeten Kernel auf unserer Plattform haben wir die Situation in den letzten Monaten aktiv und genau beobachtet. Im Austausch mit den Entwicklern haben wir immer wieder neue Theorien aufgestellt und kontinuierlich versucht, einen reproduzierbaren Zustand herzustellen, der den Fehler auslöst.

Durch das intensive Monitoring konnte unser Plattformteam eine Veränderung der Ausgangssituation beobachten. Vor einigen Wochen verzeichneten wir einen plötzlichen Anstieg der betroffenen Systeme - statt einzelner VMs über mehrere Monate gab es eine starke Häufung von gecrashten VMs innerhalb einer Woche. Diese Häufung hat unser Plattformteam in einen anderen Arbeitsmodus versetzt, um über alternative Strategien nachzudenken und die Situation zu bereinigen.

Durch unseren bereits intensiven und längeren Austausch mit den Entwicklern konnte inzwischen ein Subsystem im Speichermanagement als mögliche Ursache identifiziert werden. Dort wurden in den letzten Releases seit Kernel 5.17 umfangreiche neue Features implementiert, die die Speicherperformance vieler Systeme verbessern und grundsätzlich auch die Stabilität erhöhen sollen.

Mit diesen Informationen hatten wir nun einen starken Verdacht, in welcher Kernel-Version bzw. zu welchem Zeitpunkt sich das Problem eingeschlichen haben könnte. Ein Downgrade auf den Linux-Kernel 5.15 war daher die logische Entscheidung, um dem aktuellen Problem zu begegnen.

Was bedeutet das für die Plattform des Flying Circus?

Beim Linux-Kernel steht die Stabilität für die Entwickler an oberster Stelle. In einigen, wirklich seltenen Fällen reichen jedoch automatisierte Tests und ein Testbetrieb in Staging-Umgebungen nicht aus, um solche seltenen Fehler zu finden, da diese oft von sehr konkreten Lastverhalten, Konfigurationen, konkreten Daten auf den Festplatten abhängig sind und teilweise erst nach langer Uptime des Servers auftreten.

Um grundsätzlich eine hohe Stabilität, insbesondere einer Basiskomponente wie dem Linux-Kernel, gewährleisten zu können, wählen wir als Versionszweig sogenannte "Longterm"-Versionen (LTS), die über mehrere Jahre nur mit Bugfixes versorgt werden.

Mit dem Release unserer Plattform auf Basis von NixOS 23.05 haben wir den Kernel gewechselt. Seitdem verwenden wir die LTS-Version 6.1, die bereits am 11.12.2022 veröffentlicht wurde und auch bei NixOS als Standardversion im Einsatz ist. Beim Wechsel des Linux-Kernels achten wir darauf, dass der Entwicklungszweig zu diesem Zeitpunkt bereits eine gewisse Anzahl an Bugfix-Releases erhalten hat. Die Kernel-Version 6.1 hatte zu diesem Zeitpunkt bereits 30 Bugfix-Releases erhalten. Gleichzeitig war er im Releaseprozess von NixOS bereits ausgiebig getestet worden und hatte auch bei uns im Staging keine Probleme verursacht.