Brand beim Cloud-Provider OVH – Wenn die Cloud in Flammen steht

Der Grund: ein Rechenzentrum von OVH in Straßburg ist abgebrannt und hat dabei auch andere Rechenzentren an diesem Standort in Mitleidenschaft gezogen.

Warum schreibe ich zu diesem Thema im eigentlich auf IT-Sicherheit spezialisierten Standpunkt? Weil es die Tücken der Verfügbarkeit von Diensten in der Cloud sehr schön illustriert.

Was war geschehen?

In den frühen Morgenstunden des 10. März ist im Rechenzentrum SBG2 von OVH ein Feuer ausgebrochen, die Ursache ist noch nicht abschließend geklärt. Dabei wurde das Rechenzentrum vollständig zerstört. Auch die Rechenzentren SBG1, SBG3 und SBG4 wurden in Mitleidenschaft gezogen. Zwar waren die Schäden an SBG1 weniger schwerwiegend und SBG3 und SBG4 wurden nicht direkt beschädigt, aber die Auswirkungen für die Kunden waren dennoch spürbar. Die Rechenzentren wurden im Rahmen dieses Vorfalls abgeschaltet oder isoliert und galten als offline. Damit waren effektiv 4 von 31 Rechenzentren von OVH in Europa nicht mehr verfügbar.

Aber wieso waren so viele Webseiten bzw. Kunden betroffen? Wir reden doch hier über die Cloud. Ist da nicht immer alles redundant und verteilt?

Die Cloud und die Verfügbarkeit

Hier besteht ein häufiges Missverständnis bei der Cloud-Nutzung: Automatisch passiert für die Datensicherheit erst einmal wenig. Zwar ist es mittlerweile weit weniger häufig, dass Daten ungeschützt und ohne Authentisierung aus einem Cloudspeicher geladen werden können, aber damit sind wir im Bereich der Vertraulichkeit der Daten. Vor einem Datenverlust, also der Beeinträchtigung der Verfügbarkeit hilft nur eine sinnvolle, getestete Backup- und Wiederherstellungsstrategie sowie sinnvolle Redundanzen.

Wenn ich bei einem Cloud-Anbieter Dienste bestelle, wie zum Beispiel einen Webserver oder einen Cloudspeicher, so muss ich mich als Nutzer entscheiden, welche Zusatzleistungen und Absicherungen ich benötige. Denn in den günstigsten Angeboten der Cloud-Anbieter ist keine Redundanz enthalten. Zwar wird meine Maschine bei einem Ausfall eines einzelnen Hosts wahrscheinlich an anderer Stelle im gleichen Rechenzentrum wieder starten, und auch gegen einzelne Festplattenausfälle im Rechenzentrum des Anbieters bin ich geschützt. Ich bin aber auf ein einzelnes Rechenzentrum in einer einzelnen Region beschränkt. Bei größeren Ereignissen, wie einem Rechenzentrums-Brand, existieren dann keine ausreichenden Redundanzen. In diesem Fall sind meine Dienste und meine Daten nicht mehr verfügbar und ohne ein ausreichend aktuelles Backup verloren.

Wenn ich das Risiko eines Ausfalls minimieren will, habe ich mehrere Möglichkeiten:

Einkauf der entsprechenden Redundanzen

Viele Cloud-Anbieter ermöglichen es, gegen einen Aufpreis die Daten weiter zu verteilen und auch Dienste über einzelne Rechenzentren hinweg abzusichern. Sollte also ein Rechenzentrum in einer Region ausfallen, so kann ich mich darauf verlassen, dass meine Dienste und Daten noch in einem anderen Rechenzentrum in dieser Region vorhanden sind. Dabei bleibt aber ein Aspekt zu berücksichtigen:
Zwar werden die Daten zwischen den Rechenzentren repliziert, dies geschieht aber im Allgemeinen asynchron. Wenn also das aktive Rechenzentrum just ein paar Sekunden vor der nächsten Replikation vollständig ausfällt, muss ich mit einem Datenverlust rechnen. Ein solcher Verlust kann ärgerlich sein, beispielsweise, wenn ich gerade meine Webseite angepasst oder einen großen Upload erledigt habe. In diesem Fall muss ich die entsprechenden Schritte noch einmal ausführen. Je nachdem, wie kritisch die Verfügbarkeit der aktuellsten Daten ist, bleibt es aber nicht bei „ärgerlich“. Gerade bei Daten, die aus regulatorischen Gründen aufbewahrt und immer aktuell sein müssen, reicht eine asynchrone Replikation evtl. nicht.

Aber selbst diese „einfache“ Redundanz hätte in diesem Fall nicht viel gebracht. Da bei diesem Ereignis eine ganze Region des Cloud-Anbieters ausgefallen ist, blieb auch auf dieser Ebene keine Redundanz. Zwar wären die Daten evtl. noch in einem aktuellen Stand in einem Rechenzentrum vorhanden, aber ein Zugriff ist nicht mehr möglich. Besser als ein Totalverlust, aber je nach Reparaturzeit nicht viel besser. Hier kann eine zusätzliche Redundanz über Regionen hinweg sinnvoll sein, aber diese ist natürlich mit weiteren Kosten verbunden.

Aufbau eigener Redundanzen

Als Alternative ist es möglich, diese Redundanzmechanismen auch manuell umzusetzen. Dazu kaufe ich mir die entsprechenden Ressourcen (virtuelle Maschinen, Cloudspeicher und ggf. Datenvolumen) und richte die Mechanismen selber ein. In diesem Bereich gibt es viele kommerzielle und freie Werkzeuge, die eine Spiegelung von Daten und Diensten über Rechenzentrumsgrenzen hinweg ermöglicht. Das hat direkt mehrere Vorteile:

Erstens kann ich selbst entscheiden, ob ich statt einer asynchronen Replikation lieber eine synchrone Spiegelung nutze. Damit habe ich immer an allen beteiligten Standorten den aktuellen Datenbestand. Bevor eine Schreiboperation auf den Speicher als abgeschlossen gilt, müssen alle diese Operation bestätigen.
Zweitens: Ich bin bei den Redundanzen auch nicht auf eine Region beschränkt. Ich kann solche Mechanismen auch Regionen-übergreifend umsetzen. Dabei werden die Distanzen aber deutlich größer, und eine synchrone Spiegelung ist in diesem Fall nicht immer technisch möglich. Hier können aber hybride Ansätze helfen: Ich nutze innerhalb einer Region die synchrone Spiegelung und repliziere Regionen-übergreifend asynchron. Damit bin ich im Falle eines Großereignisses, wie dem oben beschriebenen Brand, deutlich besser geschützt.

Diese Variante hat aber auch einen entscheidenden Nachteil, der schon aus der Beschreibung teilweise ersichtlich wird: Eine solche Lösung ist mit einem enormen Aufwand verbunden. Man muss sich mit der Technologie beschäftigen, muss die Systeme in Eigenregie installieren, konfigurieren und betreiben. Dazu gehören auch Aspekte wie Patch Management. Das sind alles Dinge, die ich mir in der Cloud eigentlich sparen will. Zusätzlich ergeben sich nicht unerhebliche Kosten, wenn ich die Systeme mindestens viermal brauche: Pro Region mind. zwei Standorte und pro Standort mind. ein System. Damit bin ich um den Faktor vier teurer als die günstigste Variante ohne Standort- oder Regionen-übergreifende Redundanz.

Fazit

Auch Cloud-Provider sind nicht vor Naturgewalten oder den Gesetzen der Physik sicher. Zwar ist die Verfügbarkeit von Systemen in der Cloud häufig vergleichbar oder sogar besser als an eigenen Standorten, gerade bei kleinen Unternehmen. Aber wenn es eine große Störung gibt, sind die Auswirkungen umso umfassender. Während bei einigen Ausfällen in der Vergangenheit meistens Konfigurationsfehler ursächlich, aber die Daten nicht verloren waren, zeigt der Brand bei OVH, dass es auch mehr sein kann.

Dieser Vorfall hat eindrucksvoll demonstriert, dass auch „die Cloud“ nicht immer verfügbar ist und dass Redundanzen sehr stark vom Kundenverhalten abhängen. Ich kann Dienste hochverfügbar realisieren, muss dafür aber einen Aufpreis zahlen. Entweder indem ich die Zusatzdienstleistungen des Providers bezahle oder in der Cloud meine Hochverfügbarkeit in Eigenregie aufbaue und betreibe. Dann muss ich aber auch den notwendigen Know-how-Aufbau betreiben und bezahlen. Welche Lösung letztendlich die beste ist, muss von Fall zu Fall entschieden werden.

Verweise

[1] Netcraft, „3.6 million websites taken offline after fire at OVH datacenters“, https://news.netcraft.com/archives/2021/03/10/ovh-fire.html