Post Mortem: Netzwerkstörung 14. September 2023

• 10:29 Uhr: Uns erreichen erste Alerts, die von den Totmannschaltern verschiedener Alerting-Systeme in der Cloud-Plattform ausgelöst werden. Diese lösen aus, wenn das Monitoring-System selbst keine Netzwerkkonnektivität hat.
• 10:37 Uhr: Das zuständige Team ist informiert und beginnt mit der Ermittlung der Fehlerursache.
• 10:45 Uhr: Die Ursache der Störung (in unseren Spine-Switchen installierte neue Transceiver) wurde rückgängig gemacht, indem die entsprechenden Transceiver wieder ausgebaut wurden. Dies führte jedoch nicht zur Wiederherstellung der Konnektivität.
• 12:05 Uhr: Ein Hardwaredefekt eines Switches wurde als weiterer Teil des Problems identifiziert.
• 12:08 Uhr: Die Verbindung zwischen Mailsystem und Cloud-Plattform wurde per Konfiguration getrennt, um für die Kunden, die nicht auf der Cloud-Plattform liegen, wieder den Empfang und Versand von E-Mails zu ermöglichen.
• 12:27 Uhr: Konnektivität zu einem Teil der Cluster in der Cloud-Plattform ist wiederhergestellt.
• 15:40 Uhr: Vollständige Wiederherstellung der Konnektivität.

Die Netzwerk-Architektur des mittwald Rechenzentrums besteht aus einer Leaf-Spine-Architektur, die kontinuierlich erweitert wird. Zur Vorbereitung einer Erweiterung dieser Netzwerkarchitektur wurden am Donnerstagmorgen neue Transceiver für in der Folgewoche noch zu legende Kabel in zwei Spine-Switchen installiert. Wir gingen in diesem Fall davon aus, dass die bloße Montage dieser Transceiver den Betrieb der Netzwerkhardware nicht beeinträchtigt.

Die eingesetzten Switches stellen (neben den üblichen Ports mit einer Bandbreite von 40 Gbit/s) auch einige Ports mit einer Bandbreite von 100 Gbit/s zur Verfügung, die als Uplinkports genutzt werden können. Die Verwendung dieser Uplinkports schränkt jedoch die Nutzung einiger übriger Ports ein, insbesondere hinsichtlich der sogenannten Channelization (also das Aufteilen eines einzelnen 40 Gbit/s-Ports auf vier unabhängige 10 Gbit/s-Verbindungen). Aus diesem Grund wurden diese Ports für Verbindungen ohne Channelization genutzt – beispielsweise für die Konnektivität unserer Cloud-Plattform.

In Vorbereitung eines Ausbaus dieser Netzwerkarchitektur wurden nun also zusätzliche Transceiver in den 100 Gbit/s-Ports dieser Switche installiert. Entgegen vorheriger Annahmen störte dies jedoch die Konnektivität einiger der übrigen Ports auf demselben Switch, und trennte somit die Verbindung unserer Cloud-Plattform zu unseren restlichen Netzbereichen. Während der Fehlersuche fiel zudem auf, dass in demselben Zeitfenster die Packet Forwarding Engine auf einem nachgelagerten Switch innerhalb der Cloud-Plattform aufgrund eines Hardwaredefekts ausgefallen war.
Neben der Verfügbarkeit der auf der Cloud-Plattform aufbauenden Hosting-Produkte hatte diese Störung auch Einfluss auf interne Systeme, die Ressourcen innerhalb der Cloud-Plattform nutzten – davon betroffen waren beispielsweise das Kundencenter, das mStudio (beide binden beispielsweise Storage-Ressourcen von dort ein, und werden teilweise auch direkt auf der Plattform betrieben) sowie das Mail-System (dessen Authentifizierungsdatenbank auf der Cloud-Plattform betrieben wird).

Nach dem Bekanntwerden der Störung wurde zunächst die zuvor getätigte Änderung zurückgerollt, indem die zuvor eingesteckten Transceiver wieder entfernt wurden. Dies behob das Problem jedoch nicht. Weiterhin war in den Logs und Monitoring-Schnittstellen der betroffenen Hardware keine Fehlerursache erkennbar. Während des Troubleshootings konnten unsere Netzwerktechniker letztlich das Fehlerbild darauf eingrenzen, dass sich die betroffenen Switches — insbesondere hinsichtlich der Nutzung der Uplink-Ports — anders verhalten, als in der Herstellerdokumentation angegeben. Letztendlich half ein Reboot der betroffenen Switches, um die Konnektivität der entsprechenden Ports wiederherzustellen. Ab diesem Zeitpunkt war ein Teil der Cloud-Plattform bereits wieder erreichbar.

Der beschädigte Switch wurde zudem durch ein Trennen vom Stromnetz ebenfalls zunächst kurzfristig wieder in einen funktionsfähigen Zustand überführt, und dann im Nachhinein ausgetauscht. Im Anschluss fiel auf, dass die Spine-Switche nun veraltete Informationen in ihren Routing-Tabellen aufgebaut hatten, die manuell zurückgesetzt werden mussten.
Nach diesen Maßnahmen war die Netzwerkkonnektivität aller Cluster in der Cloud-Plattform grundsätzlich wieder gegeben. In den jeweiligen Workloads waren durch die Unterbrechung der Konnektivität Folgeschäden entstanden (so haben die Server in der Cloud-Plattform beispielsweise die Verbindung zu ihrem Storage verloren, und virtuelle Loadbalancer verloren die Verbindung zu ihren Upstream-Servern). Diese Fehlerzustände korrigierten sich durch die Self-Healing-Funktionen der jeweiligen Cloud-Plattformen weitgehend automatisch. Insbesondere in unseren eigenen Anwendungen mussten jedoch einige Dienste von Hand neu gestartet werden, um ihre Netzwerkkonnektivität wieder herzustellen.

Im Nachgang an die Störung wurden wir am Freitagmorgen durch Meldungen von mStudio Kunden weiterhin auf sporadische Schwierigkeiten bei der Anmeldung am Mailsystem aufmerksam gemacht. Dabei fiel uns auf, dass einer der (mehreren) Authentifizierungsserver des Mailsystems seine Verbindung zur Authentifizierungsdatenbank nach der Störung nicht wieder richtig aufgebaut hatte. Da die Störung lediglich einen von vielen Authentifizierungsservern betraf und der Fehler nicht von „normalen“ Login-Fehlversuchen unterschieden werden konnte, war die (leicht) erhöhte Fehlerrate bei den Logins im Monitoring nicht sofort ersichtlich, und das (eigentlich dafür vorgesehene) Alerting-System schlug nicht an.
 

„Habt ihr denn keine Redundanzen, die solche Ausfälle verhindern würden?“, könnte man nun fragen. Und tatsächlich ist genau diese Redundanz ja eine der Stärken der Leaf-Spine-Architektur (in welcher die einzelnen Switche miteinander vollvermascht sind) gegenüber klassischen Netzwerkarchitekturen. Dennoch ist es uns ein wichtiges Ziel, unsere Netzwerkarchitektur kontinuierlich weiter auszubauen und auf zukünftige Skalierungsanforderungen reagieren zu können. Auf genau solch eine Ausbaumaßnahme sollte die Installation der neuen Transceiver vorbereiten, die leider — entgegen unserer ursprünglichen Erwartungen — die an sich redundanten Ports dieser Switches deaktiviert hat. Der gleichzeitig aufgetretene Hardware-Schaden an einem nachgelagerten Switch hat zudem insgesamt zu einem sehr uneinheitlichen Fehlerbild geführt, was die Fehlersuche weiter erschwert hat. 

Um weitere Hardware-Ausfälle in der Netzwerkarchitektur zu vermeiden, werden wir alle (potentiell) betroffenen Switche in Zusammenarbeit mit dem Hersteller austauschen. Wir haben zudem alle Logs der betroffenen Geräte gesichert und werden diese im Nachhinein weiter analysieren.
In unserer Softwareentwicklung wenden wir die etablierten Resiliency Design Patterns an, und werden im Nachgang hinterfragen, wie wir die Resilienz unserer eigenen Anwendungen in der Zukunft noch weiter erhöhen können, um die Recovery nach derartigen Incidents zukünftig verkürzen zu können.

Wir werden außerdem in unserem Mailsystem Maßnahmen ergreifen, um leichte Veränderungen in den Login-Fehlerraten (die ansonsten vielleicht im Grundrauschen untergehen würden) präziser erkennen und schneller darauf reagieren zu können.