| Beginn der Störung | 27.07.2019, 05:07 Uhr |
| Ende der Störung | 27.07.2019, 17:01 Uhr |
Eine Vielzahl von virtuellen Server, die ihre Volumes von dem betroffenen Ceph-Cluster zur Verfügung gestellt bekamen, konnten keine IO-Operationen mehr auf ihren Volumes durchführen.
Alle Nodes des Ceph Clusters liefen, alle Festplatten/SSD der Nodes waren fehlerfrei ansprechbar, das Storage-Netzwerk sowie das Cluster-Netzwerk arbeiteten fehlerfrei. Dennoch konnten einigen virtuelle Servern keine IO-Operationen mehr durchführen. Ein exemplarisch durchgeführter Neustart eines virtuellen Servers scheiterte in der Startphase (kein IO). Der Fehler betraf virtuelle Server auf unterschiedlichen Host Servern, unabhängig davon, ob sie Volumes aus dem SSD oder dem SAS-Pool beziehen. Damit war ein Fehler auf den Host-Systemen auszuschließen.
Der Ceph-Cluster Status war trotz dieser Probleme im Status “health HEALTH_OK”, alle PGs waren active+clean. Im Verlauf der Fehleranalyse wurde gem. Emergency Runbook die Hardware geprüft; neben einer Sichtprüfung wurden auch alle Logfiles untersucht, ohne das Auffälligkeiten festzustellen waren. Weder waren Defekte an den Cluster-Nodes und den Netzwerk-Komponenten festzustellen, noch meldeten die Cluster-Daemons Fehler. Durch den externen Consultant wurden die Loglevels Schritt-für-Schritt im laufenden Cluster erhöht - in der entstandenen erheblichen Datenmenge konnte im höchsten Loglevel ein OSD-Kommunikationsproblem identifiziert werden.
Im Laufe der weiteren Analyse wurde dann auch eine Risikoabschätzung bezüglich Cluster-Verlust durchgeführt. Nach Risikoabwägung wurde der gesamten Datentransfer zum Ceph-Cluster unterbunden und dann alle OSD-Daemons des Clusters neu gestartet. Der Cluster war innerhalb von wenigen Minuten wieder verfügbar(HEALTH_OK). Das Scrubbing wurde abgewartet, bevor wir das erste Host-System wieder mit dem Cluster verbunden haben und einen IO-Test erfolgreich durchführen konnten.
Danach wurden alle betroffenen Host-Systeme mit ihren virtuellen Server wieder geregelt gestartet.
| 27.07.19 05:07 | Beginn der Fehler, nur im Nachhinein durch Rückschluss aus Logfile-Einträge ableitbar |
| 27.07.19 06:02 | “HighLoad”-Alerts diverser interne Systeme |
| 27.07.19 06:07 | Eskalation des Ausfalls durch OnCall, Zusammenstellung eines SRT Teams |
| 27.07.19 06:07 | Erstanalyse des Ausfallumfangs |
| 27.07.19 07:10 | Eintreffen des SRT vor Ort im RZ DUS1 |
| 27.07.19 07:20 | Sichtprüfung der Hardware (Switche und Cluster-Nodes) |
| 27.07.19 07:40 | In-Depth Fehleranalyse |
| 27.07.19 09:20 | Parallel: Anpassung der Homepage zwecks Kundeninformation, da auch Ticket- und E-Mail Systeme betroffen sind |
| 27.07.19 09:40 | Parallel: Start der Vorbereitungen Notfall-Plan: Wiederherstellung der vrituellen Server auf local SSD-Storage |
| 27.07.19 10:15 | Externer Support-Consultant wird hinzu gezogen |
| 27.07.19 16:13 | Zweifelsfreie Identifizierung des Root Cause: Keine Netzwerk-Kommunikation der OSD-Daemons |
| 27.07.19 16:33 | Erneuter InDepth Test der Netzwerk-Hardware |
| 27.07.19 16:51 | Rolling Restart der OSD Daemons nach Risikoabwägung |
| 27.07.19 16:59 | OSD-Daemons kommunizieren wieder, Cluster scrubbing startet |
| 27.07.19 17:23 | Service restored |
| 27.07.19 17:30 | Kontrolliertes Hochfahren der betroffenen Host-Server |