OVHcloud-Brand: Datenlokalität ist nicht Katastrophentrennung

Zusammenfassung

Feueralarme wurden am 10. März 2021 um 00:35 Uhr am OVHcloud-Standort Straßburg ausgelöst. Der Brand begann in Energie-Räumen im Erdgeschoss von SBG2, zerstörte dieses Gebäude, beschädigte vier der zwölf Räume von SBG1 und erzwang eine Stromabschaltung auf dem gesamten Campus. SBG3 und SBG4 wurden nicht vom ursprünglichen Brand erfasst, aber die Dienste dort waren aufgrund der erforderlichen elektrischen Trennung, Sicherheitsinspektion, Reinigung und gestaffelten Wiederinbetriebnahme nicht verfügbar. Niemand wurde getötet oder verletzt.
Die französische Untersuchung zur industriellen Sicherheit konnte die genaue Ursache der nahezu gleichzeitigen elektrischen Störungen, die an einer USV und den zugehörigen Bleibatterien beobachtet wurden, nicht ermitteln. Sie stellte jedoch Ausbreitungs- und Reaktionsfaktoren fest: keine automatische Löschvorrichtung in den fünf Straßburger Gebäuden, schnelle Rauchausbreitung durch das offene kühlungsorientierte Design von SBG2, begrenzte Löschwasserkapazität und eine schwierige standortweite Stromabschaltung. Funktionierende Detektion, Nachtpersonal, feuerbeständige Trennung zum Schutz von SBG3 und das Eintreffen eines leistungsstarken deutsch-französischen Löschboots begrenzten schlimmere Folgen.
Verfügbarkeitsverlust und dauerhafter Datenverlust waren unterschiedliche Ergebnisse. OVHcloud berichtete von etwa 65.000 betroffenen Kunden und 120.000 gestörten Diensten, während Netcraft feststellte, dass etwa 3,6 Millionen Websites auf 464.000 Domänen offline gingen. OVHcloud sagte, viele Kunden, die Daten verloren, hätten kein optionales Backup gewählt. Das schließt die Frage der Verantwortlichkeit nicht ab: OVHclouds eigenes Registrierungsdokument besagte, dass angebotene Backups im selben oder einem anderen Rechenzentrum gespeichert werden konnten, und ein späteres Berufungsurteil betraf einen Kunden, dessen bezahltes automatisches Backup im selben Gebäude wie die Produktion zerstört wurde.
Der Vorfall offenbarte einen Kategoriefehler bei der Cloud-Beschaffung. Datensouveränität, rechtliche Zuständigkeit, Latenz, Verfügbarkeit, Backup und Notfallwiederherstellung sind verwandt, aber nicht austauschbar. Daten in Frankreich oder der Europäischen Union zu halten, kann eine Lokalitätspolitik erfüllen, während gleichzeitig Produktions- und Wiederherstellungskopien eine gemeinsame physische Gefahr teilen. Umgekehrt kann eine geografisch entfernte Kopie innerhalb desselben Rechtsgebiets und unter denselben europäischen Kontrollen verbleiben.
OVHcloud kündigte erhebliche Änderungen nach dem Brand an, darunter breitere automatische Löschung, stärkere Unterteilung, separate Energieräume, ferngesteuerte Stromabschaltungen, Standortaudits, Zusammenarbeit mit der Feuerwehr und neue Multi-Zonen- und Fern-Backup-Optionen. Ein rechenschaftspflichtiger Abschluss erfordert jedoch dienst- und standortspezifische Nachweise: abgeschlossene Kontrollabdeckung, unabhängige Inspektion, realistische Brand- und Stromtrennungsübungen, deklarierte Backup-Standorte, erfolgreiche Wiederherstellungstests und der Nachweis, dass die Kundenwiederherstellung nicht von der beschädigten Region oder derselben Steuerungsebene abhängt.

Ein physischer Brand wurde zu einem Cloud-Rechenschaftsereignis

Der Begriff „Daten in der Cloud“ fördert eine Abstraktion. Sie ist nützlich, wenn Ingenieure eine Standardschnittstelle für Rechenkapazitäten wünschen, aber gefährlich, wenn Entscheidungsträger beginnen, Standort, Strom und Feuer als Details von jemand anderem zu betrachten. Jeder virtuelle Server steht in einem Raum. Jede Speicherreplikat belegt Geräte, die an elektrische und Kühlsysteme angeschlossen sind. Jeder Wiederherstellungsworkflow hängt von Menschen, Netzwerken, Anmeldeinformationen, Katalogen und einem Ort ab, von dem Ersatzkapazität bezogen werden kann.

Straßburg machte diese physische Kette sichtbar. In den frühen Morgenstunden des 10. März 2021 zerstörte ein Brand SBG2, eines der Gebäude auf dem OVHcloud-Campus am Port du Rhin. SBG1 wurde teilweise zerstört. Die beiden anderen Rechenzentren auf dem Gelände wurden heruntergefahren, obwohl das erste Unternehmensupdate sie als unbeschädigt beschrieb.

Der Verlust erfolgte daher über mindestens drei verschiedene Mechanismen: Geräte wurden physisch zerstört; Geräte in benachbarten Gebäuden waren Hitze, Rauch, Wasser oder Unsicherheit ausgesetzt; und gesunde Geräte wurden unverfügbar, als das Gelände elektrisch isoliert und gesichert werden musste.

Diese Mechanismen sind wichtig, weil sie unterschiedlichen Kontrollen entsprechen. Automatische Löschung und Unterteilung können einen Brand eindämmen. Unabhängige Stromzonen können den Bereich verkleinern, den die Feuerwehr trennen muss. Eine Multi-Site-Anwendung kann weiterlaufen, während eine Site nicht verfügbar ist. Ein entferntes, verifiziertes Backup kann den Wiederaufbau unterstützen, nachdem Daten zerstört wurden. Eine Statusseite kann Kunden durch diese Optionen führen. All dies als „Redundanz“ zu bezeichnen, verbirgt, wer jede Ebene kontrolliert und welches Ereignis sie überleben kann.