Ausfall der Infrastruktur (aktualisiert)

Liebe FLOWWER-Kunden,

am Montag, den 19.04.2021 hat unser Monitoring gegen 10:45 Uhr erste Probleme mit dem Empfang von MailToFlowwer-Daten gemeldet. Kurz darauf sind weitere Maschinen mit Kommunikationsproblemen aufgefallen.

Sowohl Webserver als auch E-Mailverkehr sind ebenfalls vom Ausfall betroffen gewesen – damit wurde das FLOWWER-Ticketsystem nicht mit Kundenanfragen versorgt.

Wir haben das Thema sofort an unseren Infrastrukturanbieter gemeldet und eskaliert. Es wurde uns bestätigt, dass massive Probleme im Netzwerkbereich vorliegen und bereits mit Hochdruck an einer Lösung gearbeitet wird.

Nach Abwägung zwischen Verfügbarkeit und möglichem Datenverlust haben wir uns dazu entschlossen, alle FLOWWER-Dienste sicherheitshalber herunterzufahren.

Wir bitten, die Unannehmlichkeiten zu entschuldigen und versprechen Ihnen, dass wir alle Hebel in Bewegung setzen um FLOWWER schnellstmöglich wieder online zu bringen.

Vielen Dank für Ihr Verständnis
Sascha Schwegelbauer (CEO DotNetFabrik GmbH)

PS: Zahlreiche Kunden haben uns Hilfe angeboten – herzlichen Dank nochmals an dieser Stelle!

Update 2021-04-20 09:30 Uhr
Die Systeme laufen seit 02:00 Uhr morgens wieder stabil.
Weitere Infos folgen, sobald die Stellungnahme unseres Infrastrukturdienstleisters vorliegt.

Incident Statement 2021-04-27 19:30 Uhr
Wir haben inzwischen Rückmeldung der gridscale GmbH, unserem Infrastrukturdienstleister erhalten.
Dort wurde der Vorfall vom 19.04.2021 genau untersucht, nachfolgend das unveränderte Statement der gridscale GmbH:

„Wir möchten noch einmal den Tag vom 19.04.2021 aufgreifen und zu den dortigen Vorfällen Stellung nehmen sowie die gewohnte Transparenz herstellen.
Im Laufe des 19. April kam es am Standort FRA2 (Anm. DotNetFabrik: dort ist FLOWWER ‚zuhause‘) zu mehreren, voneinander unabhängigen, Störungen. Durch eine Denial-of-Service Attacke um 11:13 kam es zu einem erhöhten Aufkommen von Netzwerk-Verkehr. Die Denial-of-Service Attacke wurde von unseren Detektoren erkannt und umgehend mitigiert. Fast zeitgleich kam es zu einer Störung bei dem externen DNS Anbieter DNSimple, den wir als gridscale verwenden um verschiedene DNS Zonen hochverfügbar und unabhängig der Rechenzentren von gridscale zu verwalten.
Während die DoS-Attacke selber zu verlangsamten API-Aufrufen geführt hat, führte der Ausfall der DNS-Resolver zu einer nichtverfügbarkeit von DNS-Namen (bspw. Api.gridscale.io oder my.gridscale.io) was zu einer Reihe von Anzeigefehlern geführt hat. Workloads waren zu diesem Zeitpunkt nicht beeinträchtigt.
Kurze Zeit später kam es zu einem dritten, hiervon wiederum unabhängigen Incident. Ab 13:18 konnten wir beobachten das es am Standort FRA2 zu Problemen in der Provisionierung von Workloads gekommen ist. Dies hat sich zum einen darin geäußert, dass Workloads nicht sauber gestartet werden konnten zum anderen konnten wir beobachten dass laufenden Workloads Probleme im Zugriff auf die von ihnen verwendeten Festplatten hatten. Hierbei waren ausschließlich Festplatten betroffen die von unserem verteilten Storage bereitgestellt werden. Aufgrund eines diffusen Fehlerbildes war das initiale Einkreisen der Ursache erschwert.
Die Auswirkung dieses Fehlers auf Workloads hat sich über zwei Phänomene bemerkbar gemacht. Zum einen war es nicht möglich virtuelle Server auf betroffenen Compute Knoten zu starten. Dies ist durch entsprechende Fehlermeldungen in den grafischen Oberflächen bzw. durch einen entsprechenden Eintrag in der Historie des jeweiligen Objektes (bspw. Virtueller Server) festgehalten worden. Durch wiederholte Startvorgänge wurden die meisten Virtuellen Server auch während des Incidents letztlich gestartet, da die Wahl der Compute Node auf einem Zufallsprinzip beruht und nicht alle Compute Knoten vom selben Fehler betroffen waren.
Zum anderen sind die Datenträger einiger virtueller Servern im laufenden Betrieb in einen R/O-Zugriff versetzt worden. Diese Eigenschaft wurde auf Ebene des Virtualisierungs-Layers entschieden, da der vollständige Zugriff auf das initial verwendete Block-Device zeitweise verloren ging. Nur durch eine komplette Re-Initialisierung des Virtualisierungs-Layers (also PowerOff / PowerOn) war dieser Fehler zu beseitigen.
Die Ursache des Fehlers konnte im Laufe des Nachmittages durch eine Anpassung der Konfiguration in der Anbindung des verteilten Speichersysteme auf unseren Compute Knoten behoben werden. Über die folgenden Stunden haben sodann alle uns bekannten Virtuellen Server einer manuellen Prüfung überzogen und in Abstimmung mit betroffenen Partnern ggf. nötige individuelle Maßnahmen ergriffen, um einen Neustart durchzuführen.
Als eine der Folgemaßnahmen wurden verschiedene Log-Muster in unser zentrales Log Management aufgenommen, die Rückschlüsse auf diese Art von Problemen erlauben.“

(Quelle: gridscale GmbH)