Post Mortem: Störung aus Wartungsarbeiten

Im Rahmen der Wartung war es erforderlich, die Virtuellen Maschinen jedes Clusters mit einem neuen Betriebssystem-Image neu zu erstellen. Im Rahmen dieser Wartung antizipierten wir dafür auf Grundlage vorheriger Tests und unserer Erfahrungen bei vergangenen ähnlichen Wartungsmaßnahmen eine Downtime von wenigen Minuten pro Projekt.

Konkret kam es im Zeitraum vom 11.04.2024, 0:00 Uhr und 11.04.2024, 06:10 Uhr in mehreren Clustern jedoch zu Downtimes im Bereich von 1 Stunde bis zu 5 Stunden. Diese Downtimes lassen sich auf zwei Ursachen zurückführen:

1. Innerhalb der Cluster setzen wir auf CoreDNS, um Namensauflösung der Services untereinander anzubieten. Für die Hosting-Produkte setzen wir dabei einige selbst entwickelte CoreDNS-Plugins ein, die beispielsweise die Namensauflösung von Datenbankservern anbieten.
   
   Im Rahmen des Softwareupdates fiel ein Kompatibilitätsproblem zwischen den CoreDNS-Plugins und der in den Produktiv-Clustern eingesetzten Version von CoreDNS auf, die von unserem Deployment-Tool nicht in der richtigen Reihenfolge aktualisiert wurden. Aus diesem Grund war die cluster-interne Namensauflösung für viele Projekte für einen Zeitraum von etwa 110 Minuten gestört.
2. Wir mussten Engpässe innerhalb unserer Cloud Infrastruktur feststellen, die bis zu diesem Zeitpunkt nicht negativ aufgefallen sind, insbesondere in der Bereitstellung von Container-Images.
   
   Im Zuge der Wartungsarbeiten wurde das Betriebssystem-Image der Nodes ausgetauscht. Hierzu wurden die Nodes neu angelegt und die Projekte auf diesen Nodes neu provisioniert. Dies ist üblicherweise ein sequentieller Prozess, der bei jedem Projekt lediglich zu einer sehr kurzen Downtime, maximal im Bereich einiger Minuten führt. Bei dieser Neuprovisionierung kam es aufgrund von Bottlenecks bei einer internen Container Registry bei der Bereitstellung der benötigten Systemimages zu deutlichen Verzögerungen.
   
   Die Kubernetes-Cluster werden über Gardener bereitgestellt; eine Open-Source-Lösung zum Deployment und Management von Kubernetes-Clustern in Cloud-Umgebungen. Gardener startete die betroffenen Nodes in diesem Fall deutlich schneller hintereinander als erwartet. Dies führte dazu, dass viele tausend Container in einem sehr kurzen Zeitraum neu erstellt wurden, und die unterliegende Registry die dafür benötigten Container-Images nicht schnell genug ausliefern konnte. In einem Cluster potenzierte sich dieses Phänomen durch eine gleichzeitig auftretende Störung der VPN-Verbindung zur Control Plane des Clusters (dazu mehr im nächsten Abschnitt).

Mit Ausnahme des von der Folgestörung betroffenen Clusters waren alle Projekte spätestens am 11.04.2024 um 6:10 Uhr wieder erreichbar. Damit haben die Wartungsarbeiten deutlich mehr Zeit in Anspruch genommen als geplant.

Die für die Wartung geplanten Arbeiten konnten wir am 11.04.2024 um 8:00 Uhr abschließen. Ein Cluster unserer Cloud-Infrastruktur war allerdings auch nach Abschluss der Wartungsarbeiten nicht erreichbar. Als Ursache hierfür konnten wir Verbindungsprobleme im Cluster-internen Netzwerk feststellen. Die Cloud-Plattform besteht aus einem zentralen Control Plane-Cluster und mehreren Workload-Clustern, auf denen die eigentlichen Hosting-Workloads betrieben werden. Die Workload-Cluster sind jeweils über VPN-Verbindungen mit dem Control Plane-Cluster verbunden. Dieses Problem ist in Folge der Wartung ausschließlich bei einem von mehreren, identisch gewarteten Workload-Clustern aufgetreten.

Bei der Diagnose dieser fehlerhaften VPN-Verbindung konnten wir extreme Latenzen von teilweise über 200 Sekunden (sic!) für einfache ICMP-Requests messen. Zudem konnten wir einen signifikanten Paketverlust feststellen. Aufgrund dieser Fehler war die externe Erreichbarkeit des Clusters nicht mehr gegeben.

Bei der Diagnose konnten wir den Fehler auf einige Netzwerkkarten innerhalb der Cloud-Plattform eingrenzen. Jedes Cluster enthält mehrere “Ingress-Nodes”, die dafür verantwortlich sind, die Netzwerkkonnektivität des Clusters nach außen sicherzustellen. In dem betroffenen Cluster waren alle Ingress-Nodes auf Hypervisoren gestartet, deren Netzwerkkarten im Zusammenspiel mit der verwendeten Kernel-Version einen Firmware Bug aufweisen, der für den Paketverlust verantwortlich war. Wir haben diese Ingress Nodes im Anschluss auf einen anderen Hypervisor migriert und konnten keinen Paketverlust mehr feststellen. Außerdem haben wir die Netzwerkinterfaces des betroffenen Systems ausgetauscht. Wir verwenden ausschließlich Netzwerkkomponenten namhafter Hersteller, setzen aber auf eine Durchmischung um das großflächige Auftreten von genau solchen Fehlern zu verhindern. Aufgrund dieses Vorgehens hat sich dieser Fehler auch nicht auf Hypervisoren anderer Cluster bemerkbar gemacht.

Im Zuge der Wartung wurde auch das Betriebssystem-Image der Nodes aktualisiert. Wir verwenden in unseren Clustern Garden-Linux, die empfohlene Linux-Distribution des Gardener-Projekts, das wir zur Orchestration unserer Kubernetes Cluster nutzen. In den neuesten Version von Garden-Linux ist aus Sicherheitsgründen der SSH-Zugriff standardmäßig deaktiviert. Die Diagnose der fehlerhaften VPN-Verbindung wurde durch diesen Umstand deutlich erschwert, da wir uns zum Debugging zunächst Zugriff zu den Systemen verschaffen mussten.

Im Zuge der Diagnose wurden Anpassungen an der Konfiguration der betroffenen VPN-Verbindungen vorgenommen, durch die das Problem behoben werden konnte. Ab 15 Uhr am 11.04.2024 konnten folglich wieder Systeme im betroffenen Cluster provisioniert werden, erste Projekte waren wieder erreichbar. An dieser Stelle kam der bereits im Kontext der Wartung erwähnte Bottleneck besonders deutlich zum tragen. Diesen konnten wir im Nachgang durch die Skalierung des betroffenen Services ebenfalls auflösen, sodass die Bereitstellung ab 16:31 Uhr deutlich schneller erfolgte. Um 17:42 Uhr waren mehr als 90 % der Projekte des betroffenen Clusters wiederhergestellt. Die verbliebenen Projekte konnten aufgrund weiterer Fehlerursachen, die im Zuge der Wartung aufgetreten sind, erst nach manuellem Eingriff gestartet werden.

Im Zuge der Wartung haben wir einige zusammenhängende bzw. sicherheitsrelevante Anpassungen am System ausgespielt. Neben Security Updates für das Betriebssystem und den verwendeten Apache Webserver bringen die Anpassungen Verbesserungen in der Performance unserer Kundenprojekte (Optimierungen am Speichermanagement und am Dateisystem) sowie die notwendigen technischen Grundlagen für weitere Features wie z. B. das Hosting von Containern auf der Cloud-Plattform für unsere Kunden. Wir haben die Wartungsarbeiten sorgfältig geplant und bereits am 04.04.2024 angekündigt.

Unser Wartungsworkflow beinhaltet mehrstufige Tests der geplanten Änderungen, um einen negativen Impact bestmöglich auszuschließen. Änderungen durchlaufen ein Code Review und verschiedene Test Pipelines, bevor sie zunächst in ein Dev-System ausgespielt und dort nochmals getestet werden. Werden auch hier keine Auffälligkeiten erkannt, übernehmen wir die Änderungen in ein Staging-System, bevor wir sie schlussendlich ins Produktivsystem übernehmen. Wartungen am Produktivsystem werden im “viele-Augen-Prinzip” gewissenhaft geplant und mit Hilfe von Wartungschecklisten vorbereitet und durchgeführt, um Unstimmigkeiten bereits im Vorfeld soweit möglich vorzubeugen. Trotz dieser bedachtsamen Vorbereitung kam es bei der vergangenen Wartung zu erheblichem Kundenimpact.

Wir konnten aus den Unstimmigkeiten bei der Wartung und der darauffolgenden Störung eines der gewarteten Cluster einige Erkenntnisse für unseren Wartungsworkflow und den Aufbau unserer Clusterarchitektur ableiten. Dazu gehört unter anderem:

• die vorherige Prüfung der Zugänglichkeit von Systemen über alternative Zugriffswege (hier die Erreichbarkeit per SSH)
• die Skalierung kritischer Clusterkomponenten, die bei einer Wartung ungewöhnlich hoher Last ausgesetzt sein können
• dass auch der Datendurchsatz cluster-interner Ingress-Controller ein Bottleneck beim Holen von Images darstellen kann

Mit der Entwicklung unserer Cloud Hosting Plattform haben wir im Jahr 2019 begonnen. Seit 2022 setzen wir das Produkt aktiv zum Hosting unserer Space Server und proSpace Produkte ein. Wir sind mit dem Ziel gestartet, eine Hosting-Plattform zu entwickeln, die uns und unseren Kunden die nötige technische Flexibilität bietet, um verschiedenste Anwendungen im Agenturkontext darauf zu betreiben und technischen Neuerungen jederzeit schnellstmöglich folgen zu können.

Die bisherigen Erfahrungen mit dem Betrieb des Systems haben uns gezeigt, an welchen Stellen wir Komplexität reduzieren können. Daher entwickeln wir bereits seit September 2023 eine parallele Cloud-Infrastruktur, in deren Architektur diese Learnings einfließen. Ziel ist es, alle Funktionalitäten und die Flexibilität zu erhalten und weiter zu stabilisieren, die wir für unsere aktuellen Hosting-Produkte und die für die Zukunft geplanten Features benötigen.

Das beinhaltet beispielsweise, zukünftig weniger auf komplexe Cloud-Architekturen wie OpenStack und vermehrt auf Bare-Metal-Architekturen zu setzen. Ebenso zählt dazu, die Bereitstellung von Kubernetes-Clustern auf dieser Infrastruktur deutlich zu vereinfachen und die Abhängigkeit zu komplexen Cluster-Bereitstellungstools wie Gardener zu reduzieren.

Durch diese Architekturänderungen minimieren wir die Fehleranfälligkeit des Systems deutlich, und sorgen für eine bessere Wartbarkeit. Außerdem sorgen die Anpassungen durch Reduzierung des Ressourcen-Overheads für eine noch bessere Performance unserer Produkte.

Wir planen, die neue Architektur im Herbst diesen Jahres in Betrieb zu nehmen und (über eine noch zu bestimmende Übergangszeit) alle aktuellen Cloud-Projekte auf diese neue Architektur zu migrieren. Bis es soweit ist, pflegen wir die bestehende Cloud-Architektur natürlich weiterhin und sorgen für einen sicheren, stabilen, zuverlässigen und performanten Betrieb. Genauere Informationen zu diesem Architektur-Redesign veröffentlichen wir in den kommenden Tagen in unserem Agentur-Hub.