Post Mortem: Störung im Cloud Hosting Storage

31. Oktober: ca. 6:00 Uhr – 23:15 Uhr 

4. November: 8:18 Uhr – 11:24 Uhr 

Am 31. Oktober meldeten unsere Monitoring-Systeme gegen 6:00 eine eingeschränkte Verfügbarkeit der Cloud-Plattform, sowie der mStudio- und Kundencenter-Oberflächen und des Mailsystems. Als Ursache der Störung wurde schnell das zentrale Speichersystem der Cloud-Plattform erkannt. Obgleich sich die grundlegende Verfügbarkeit des Storages schnell erholte, schwankte die Verfügbarkeit der betroffenen Workloads über die nächste Stunde stark. 

Wir stellten fest, dass die gleichzeitige Anzahl an neu aufgebauten Verbindungen zum Storage-System die Verfügbarkeit desselben weiterhin beeinträchtigte. Gegen 8:00 entschlossen wir uns deshalb, die Menge der gleichzeitig neu aufgebauten Verbindungen zu drosseln, um die betroffenen Workloads nach und nach recovern zu können. Bis 9:00 war die Verfügbarkeit des mStudios, des Mailsystems und der Webmailers wiederhergestellt, und auch erste Kunden-Workloads auf der Cloud-Plattform waren wieder verfügbar. 

Die Recovery aller Workloads dauerte den gesamten Nachmittag über an. Da im Rahmen der Wiederherstellung auch eine große Menge virtueller Maschinen neu provisioniert werden musste, störten Performance-Engpässe in den internen Control Planes unserer Cloud-Plattform die Wiederherstellungszeit zusätzlich. Zahlreiche Virtuelle Maschinen benötigten manuelle Eingriffe, um ihre Volumes korrekt mounten zu können. 

Am Morgen des 4. November kam es zu einem ähnlichen Fehlerbild, ausgelöst durch den Ausfall eines einzelnen Ceph-Servers. Die darauffolgende Umverteilung von Daten führte erneut zu einer Beeinträchtigung der Gesamtperformance, in deren Folge einige Workloads die Verbindung zum Storagesystem verloren und neu provisioniert werden mussten. 

Zu einem Datenverlust kam es dabei zu keinem Zeitpunkt. 

Die Architektur des verwendeten Storage-Systems ist grundsätzlich darauf ausgelegt, Single-Points-Of-Failure zu vermeiden, damit eine jederzeitige Verfügbarkeit gewährleistet ist. Diese Maßnahmen erwiesen sich in diesem Fall als nicht ausreichend. 

Bei den vorliegenden Störungen kamen mehrere Faktoren zusammen: 

1. Im Falle des Ausfalls eines Servers beginnt Ceph, Daten im Cluster umzuverteilen (in Ceph-Fachsprache wird dieser Vorgang “Rebalancing” genannt), um die benötigte Datenredundanz wieder herzustellen. Je nach Umfang dieses Rebalancings ist die Performance (aber an sich nicht die Verfügbarkeit) des Clusters beeinträchtigt. 
2. Wenn gleichzeitig eine größere Menge von Clients (also beispielsweise Kunden-Workloads in der Cloud-Plattform oder interne Workloads) ihre Verbindung zum Storage Cluster verliert und neu aufbaut, kann diese Anzahl an Verbindungen ihrerseits die Performance und Verfügbarkeit sowohl des Storage-Systems, als auch der Control Plane der Cloud-Plattform (in diesem Fall also OpenStack und Gardener) selbst beeinträchtigen. 

In Kombination können diese beiden Faktoren trotz unseres 160 GBit Ceph-Backend-Netzwerkes zu einem kaskadierenden Fehlerbild führen (ähnlich der bekannten Cache Stampede), das nur durch die zeitliche Streckung der Wiederherstellung zu beheben ist. 

Unmittelbar nach der Störung haben wir unser Monitoring noch einmal intensiviert, um durch gezielte Alerts dieses spezielle Fehlerbild zukünftig deutlicher erkennen zu können. Gleichzeitig konnten wir aus dem Entstörungsprozess Erkenntnisse ziehen, anhand derer wir unsere Time to Recovery in Zukunft deutlich verkürzen.  

Losgelöst von diesem konkreten Incident haben wir die Abhängigkeit der Cloud-Plattform von einem zentralen Storagesystem bereits von einiger Zeit als Schwachstelle erkannt und auch deshalb seit März an einem Re-Engineering gearbeitet. Die Optimierungen wurden ab dem 13. November ausgerollt. Dabei haben wir uns auch von komplexen Infrastrukturplattformen wie OpenStack und Gardener getrennt. Wir setzen ab sofort auf einfachere und robustere Bereitstellungsmechanismen. Weitere Informationen dazu findest du in diesem Blogartikel über das Re-Engineering unserer Cloud-Plattform.