Keine fünf Monate nach einem Stromausfall in einem unserer großen Rechenzentren ist genau das gleiche am selben Standort noch einmal passiert. Das ist ausgesprochen ärgerlich. Und wenn Sie sich fragen, warum wir diese Einheit trotzdem weiter nutzen, können wir Ihnen das nicht verübeln. Wir haben uns diese Frage auch gestellt. Doch die Sache ist die: Bei diesem Rechenzentrum selbst hat sich in den besagten fünf Monaten vielleicht nicht viel verändert, bei Cloudflare aber sehr wohl. Vor fünf Monaten war der Ausfall eines wichtigen Rechenzentrums für uns ausgesprochen unangenehm, doch dieses Mal waren die Konsequenzen deutlich weniger schwerwiegend.
Wir wollen nun näher darauf eingehen, wie es dazu kommen konnte, dass in einem hochverfügbaren Rechenzentrum zum zweiten Mal innerhalb von fünf Monaten der Strom ausgefallen ist. Es wird aber vor allem auch darum gehen, wie unser Team verhindert hat, das dieser Stromausfall in einem unserer kritischen Rechenzentren negative Auswirkungen auf unsere Kunden hatte.
Am 2. November 2023 ist bei einem unserer wichtigen Standorte in Portland (US-Bundesstaat Oregon) für längere Zeit der Strom ausgefallen. Ursache war eine Abfolge von Störungen, die offenbar durch Wartungsarbeiten des Stromnetzbetreibers verursacht wurden und ihren Höhepunkt in einem Erdschluss an der Anlage fanden. Erschwerend kam eine Reihe unglücklicher Zwischenfälle hinzu, die verhinderten, dass die Anlage schnell wieder ans Netz gehen konnte.
Alle Einzelheiten nachlesen können Sie hier.
Natürlich ist es äußerst misslich, wenn in einem Rechenzentrum der Strom ausfällt, aber wir hätten damit rechnen müssen. Leider hatten wir bestimmte Vorkehrungen nicht getroffen, mit denen sichergestellt worden wäre, dass unsere Produkte trotz eines größeren Stromausfalls in Betrieb bleiben.
Für uns war damals aber klar, dass wir nicht zulassen würden, dass sich das noch einmal wiederholt.
Code Orange
Der Zwischenfall war so ärgerlich, dass wir „Code Orange“ eingeführt haben. Die Idee stammt ursprünglich von Google, wo Berichten zufolge „Code Yellow“ oder „Code Red“ ausgerufen wird, wenn ein in hohem Maße geschäftsschädigendes Problem auftritt. Weil unser Logo in Orange gehalten ist, haben wir die Bezeichnung leicht abgeändert.
Wir hatten uns überlegt, dass in einem Fall von „Code Orange“ die Person, die während des Vorfalls die Verantwortung innehat – in diesem Fall unser SVP of Technical Operations, Jeremy Hartman –, befugt sein sollte, jeden unserer Entwickler mit der aus seiner Sicht dringlichsten Arbeit an dem Projekt zu beauftragen. (Eine noch höhere Priorität wäre nur im Fall eines „Code Red“ gegeben, den wir aufgrund eines Hacking-Zwischenfalls letztlich ausgerufen haben. Mehr dazu erfahren Sie hier.)
Nach dem eigentlichen Zwischenfall musste unsere Hochverfügbarkeit im Fall eines weiteren schwerwiegenden Ausfalls eines wichtigen Rechenzentrums sichergestellt werden. Jeremy ermittelte deshalb schnell die wichtigsten dafür erforderlichen Maßnahmen. Dann machte sich das Team an die Arbeit.
Wie haben wir uns geschlagen?
Wir hätten uns nicht träumen lassen, dass unsere Vorkehrungen so schnell auf die Probe gestellt werden. Doch genauso kam es. Am Dienstag, den 26. März – also nur knapp fünf Monate nach dem ersten Zwischenfall – wurde am selben Standort erneut ein größerer Stromausfall verzeichnet. Auf dessen Ursachen werden wir nun näher eingehen. Entscheidender ist aber, dass der jüngste Vorfall die perfekte Gelegenheit bot, die von unserem Team für „Code Orange“ geleistete Arbeit einem Praxistest zu unterziehen. Was dabei herausgekommen ist?
Schauen wir uns zunächst noch einmal an, welche Funktionen die Rechenzentren von Cloudflare in Portland bieten. Wie im Beitrag vom 2 .November 2023 beschrieben, besteht die Steuerungsebene von Cloudflare hauptsächlich aus der Kunden-Schnittstelle für alle unsere Dienste, einschließlich unserer Website und API. Auch die zugrundeliegenden Services, die Analyse- und Protokollierungspipelines bieten, werden hauptsächlich von diesen Einrichtungen aus bereitgestellt.
Genau wie im November wurden wir sofort darüber informiert, dass die Verbindung zu unserem PDX01-Rechenzentrum unterbrochen war. Wir hatten sehr schnell die Gewissheit, dass es sich erneut um einen vollständigen Stromausfall handelte und wir uns in genau der gleichen Situation befanden wie fünf Monate zuvor. Dank eines erfolgreichen internen Tests im Februar, im Zuge dessen wir die Verbindung gekappt hatten, wussten wir auch, wie unsere Systeme im Idealfall reagieren sollten. Wir haben Monate damit verbracht, unzählige Systeme vorzubereiten und zu aktualisieren und enorme Netzwerk- und Serverkapazitäten zu aktivieren. Am Ende stand ein Test, mit dem überprüft wurde, ob in diesem Fall wie gewünscht ein automatisches Failover erfolgt und die redundanten Standorte die Arbeit übernehmen.
Unsere Steuerungsebene besteht aus Hunderten interner Dienste und unsere Erwartung war, dass bei einem Ausfall von einem der drei kritischen Rechenzentren in Portland diese Dienste in den verbleibenden zwei Einrichtungen weiter normal funktionieren und Portland Hauptbetriebsort bleibt. Im Fall eines vollständigen Ausfalls aller unserer Rechenzentren in Portland haben wir die Möglichkeit, einen Failover zu unseren europäischen Rechenzentren durchzuführen. Allerdings handelt es sich hierbei nur um eine zweitrangige Option.
Am 26. März 2024 um 15:48 Uhr MEZ ist bei PDX01 der Strom ausgefallen, woraufhin unsere Systeme reagiert haben. Um 16:05 Uhr MEZ funktionierten unsere API und Dashboards normal, und zwar ohne menschliches Eingreifen. In den vorangegangenen Monaten haben wir uns vor allem darauf konzentriert, sicherzustellen, dass unsere Kunden ihre Cloudflare-Services bei einem ähnlichen Ausfall weiter konfigurieren und nutzen können. Bei ein paar Diensten war ein manuelles Eingreifen erforderlich, weshalb es etwas länger dauerte, bis sie wieder einsatzbereit waren. Der Hauptmechanismus der Schnittstelle hat aber wie erwartet funktioniert.
Um das Ganze etwas zu verdeutlichen: Während des Vorfalls vom 2. November 2023 waren die folgenden Dienste mindestens sechs Stunden lang nicht verfügbar, einige davon sogar mehrere Tage lang.
API und DashboardZero TrustMagic TransitSSLSSL für SaaSWorkersKVWaiting RoomLastverteilungZero Trust-GatewayAccessPagesStreamImages
Demgegenüber waren diese Services während des Zwischenfalls am 26. März 2024 wenige Minuten nach dem Stromausfall wieder verfügbar und viele wurden durch den Failover überhaupt nicht beeinträchtigt.
Nicht betroffen war die Datenebene, die den Traffic der Cloudflare-Kunden verarbeitetet, welcher über unsere mehr als 300 Rechenzentren geleitet wird.
Unsere Analytics-Plattform, die einen Überblick über den Datenverkehr unserer Kunden bietet, funktionierte nur eingeschränkt und dieses Problem wurde erst im weiteren Tagesverlauf vollständig behoben. Das war von uns auch erwartet worden, weil sich die Analytics-Plattform auf das PDX01-Rechenzentrum stützt. Genau wie bei der Steuerungsebene haben wir unmittelbar nach dem Vorfall vom 2. November begonnen, neue Analytics-Kapazitäten aufzubauen. Da dies aber einen größeren Arbeitsaufwand erfordert, brauchen wir noch etwas Zeit, um unser Ziel zu erreichen. Wir tun aber unser Möglichstes zur Beseitigung dieser Abhängigkeit und gehen davon aus, dass wir dieses Vorhaben in naher Zukunft abschließen können.
Nachdem wir uns vergewissert hatten, dass unsere Steuerungsebene wieder ordnungsgemäß funktioniert, sahen wir uns erneut dem Kaltstart eines sehr großen Rechenzentrums gegenüber. Im November hatte dies etwa 72 Stunden in Anspruch genommen. Diesmal gelang es uns innerhalb von rund zehn Stunden. Wir werden unsere Verfahren aber weiter optimieren, um in Zukunft bei ähnlichen Vorfällen noch schneller sein zu können.
Welcher Weg hat uns hierher geführt?
Wie bereits erwähnt, hat uns der Stromausfall vom letzten November zur Einführung von „Code Orange“ veranlasst. Dies sollte es uns ermöglichen, im Fall eines schwerwiegenden Problems oder einer Krise die meisten oder alle technischen Ressourcen auf die Behebung des jeweiligen Problems zu konzentrieren. In den letzten fünf Monaten haben wir alle nicht kritischen technischen Funktionen auf die Gewährleistung einer hohen Zuverlässigkeit unserer Steuerungsebene umgestellt.
Teams aus allen unseren technischen Abteilungen haben in gemeinsamer Arbeit sichergestellt, dass unsere Systeme ähnlichen zukünftigen Ausfällen besser standhalten. Der Vorfall vom 26. März kam zwar überraschend, doch wir hatten uns auf solche Szenarien vorbereitet.
Der offenkundigste Unterschied zwischen den beiden Zwischenfällen ist die Zeit, die bis zur Wiederherstellung der Funktionsfähigkeit der Kontrollebene und API verstrichen ist. Diesmal war es ohne menschliches Zutun sieben Minuten nach dem Ausfall von PDX01 möglich, sich anzumelden und Änderungen an der Cloudflare-Konfiguration vorzunehmen. Das ist auf unsere Bemühungen zurückzuführen, alle unsere Konfigurationsdatenbanken auf eine hochverfügbare Topologie umzustellen und im Voraus genügend Kapazitäten aufzubauen, um Ausfälle aufzufangen. Über 100 Datenbanken in mehr als 20 verschiedenen Clustern sind bei der betroffenen Einrichtung gleichzeitig ausgefallen, danach aber automatisch an anderer Stelle wieder in Betrieb gegangen. Dies war das Ergebnis von mehr als einem Jahr Arbeit. Dass ein Failover bei Bedarf ordnungsgemäß erfolgen kann, kontrollieren wir mit wöchentlichen Tests.
Eine weitere bedeutende Verbesserung sind Updates unserer Logpush-Infrastruktur. Im November konnten wir infolge des Ausfalls des PDX01-Rechenzentrums keine Protokolle an unsere Kunden übertragen. Im Rahmen der Arbeit an „Code Orange“ haben wir in den Aufbau hochverfügbarer Logpush-Infrastruktur in Portland investiert und zusätzlich eine aktive Failover-Option in Amsterdam geschaffen. Logpush nutzte die Vorteile unseres stark erweiterten Kubernetes-Clusters. Dieser erstreckt sich über alle unsere Standorte in Portland und ermöglicht Service-Betreibern die reibungslose Bereitstellung von Diensten mit integrierter Ausfallsicherheit, die den Anforderungen der Hochverfügbarkeit genügen. Tatsächlich haben wir während unserer Chaosübung im Februar eine Schwachstelle in unserer Hochverfügbarkeits-Implementierung in Portland festgestellt. Davon waren aber keine Kunden betroffen, weil die Logpush-Infrastruktur in Amsterdam erfolgreich die Arbeit übernommen hat. Während dieses Vorfalls beobachteten wir, dass die von uns in der Zwischenzeit vorgenommene Fehlerbeseitigung erfolgreich war und wir Protokolle aus der Region Portland übertragen konnten.
Eine Reihe anderer Verbesserungen an unseren Stream- und Zero Trust-Produkten hatten wenig bis gar keine Auswirkungen auf deren Betrieb. Unsere Stream-Produkte, die für die Transkodierung von Videos eine Menge Rechenressourcen benötigen, konnten zur Aufrechterhaltung des Betriebs nahtlos zu unserem Standort in Amsterdam verlagert werden. Die Teams erhielten spezifische Verfügbarkeitsziele für die Services und verschiedene Optionen, um diese Ziele zu erreichen. Stream ist ein gutes Beispiel eines Diensts, für den eine andere Ausfallsicherheitsarchitektur gewählt wurde, der während des Ausfalls aber reibungslos genutzt werden konnte. Ein Großteil der Funktionen der Zero Trust-Lösung, die im November ebenfalls betroffen war, wurden in der Zwischenzeit in unsere Hunderte von Rechenzentren verlagert, die während des gesamten Vorfalls ebenfalls problemlos funktionierten. Letztendlich streben wir dies diese Strategie bei allen Cloudflare-Produkten an, weil unsere mehr als 300 Rechenzentren das größtmögliche Maß an Verfügbarkeit bieten.
Was war der Grund für den Stromausfall im Rechenzentrum?
Am 26. März 2024 um 15:58 Uhr MEZ wurde die Stromversorgung der physischen Infrastruktur von Cloudflare am Standort PDX01 vollständig unterbrochen, nachdem Berichten zufolge gleichzeitig vier Verteilerschränke von Flexential ausgefallen waren, die alle Cloudflare-Cages versorgen. Damit standen waren sowohl die primären als auch die redundanten Stromversorgungswege in der gesamten Umgebung nicht mehr verfügbar. Die Techniker von Flextential konzentrierten sich bei ihren Nachforschungen auf die sogenannten Circuit Switch Boards (CSB). Ein CSB ist mit einer Schalttafel vergleichbar, die aus einem Haupteingangs-Leitungsschutzschalter und einer Reihe kleinerer Ausgangs-Leitungsschutzschalter besteht. Die Techniker von Flexential berichteten, dass die den CSB vorgeschaltete Infrastruktur (Stromzuleitung, Generator, USV und PDU/Transformator) nicht beeinträchtigt wurde und weiterhin normal funktionierte. Auch die den CSB nachgeschaltete Infrastruktur, etwa Remote Power Panels und angeschlossene Schaltanlagen, war nicht betroffen. Das deutete darauf hin, dass das Problem bei den CSB selbst lag.
Eine erste Bewertung der Ursache für die CSB-Ausfälle von Flexential legt nahe, dass falsche Einstellungen für die Koordination der Leistungsschutzschalter innerhalb der vier CSB dazu beigetragen haben. Allzu restriktive Auslöseeinstellungen können zu einem übermäßig sensiblen Überstromschutz und Fehlauslösungen führen. In unserem Fall war die Schwelle für die Leistungsschutzschalter von Flexential innerhalb der vier CSB im Verhältnis zu den nachgelagerten Stromkapazitäten zu niedrig eingestellt. Wenn einer oder mehrere dieser Leistungsschutzschalter auslösten, kam es zu einem Folgeausfall der verbleibenden aktiven CSB-Platinen und damit zu einem Totalausfall der Stromversorgung von Käfigen – unter anderem dem von Cloudflare – in der gemeinsamen Infrastruktur. Im Zuge der Ersteinschätzung des Vorfalls wurde uns mitgeteilt, dass das Facility-Team von Flexential die falschen Auslöse-Einstellungen bemerkt, die CSB zurückgesetzt und die Einstellungen gemäß den erwarteten Werten angepasst hat. Das erlaubte es unserem Team, unsere Server schrittweise und kontrolliert wieder hochzufahren. Wann diese Einstellungen ursprünglich festgelegt wurden, wissen wir nicht. In der Regel erfolgt ihre Festlegung/Anpassung während der Inbetriebnahme eines Rechenzentrums und/oder einer Koordinationsprüfung von Leistungsschutzschaltern, bevor kritische Verbraucherlasten installiert werden.
Was steht als Nächstes an?
Unser Programm zur Gewährleistung der Ausfallsicherheit unserer Analytics-Plattform abzuschließen, hat für uns oberste Priorität. Analytics beschränkt sich nicht auf hübsche, über ein Dashboard abrufbare Diagramme. Die Plattform wird auch benötigt, um den Status von Angriffen, die von einer Firewall blockierten Aktivitäten oder sogar den Status von Cloudflare-Tunneln zu überprüfen. Wir haben Belege dafür, dass das von uns angewandte Ausfallsicherheitsmuster wie erwartet funktioniert. Deshalb richten wir darauf auch weiter unser Hauptaugenmerk, um in diesem Bereich so schnell wie möglich weitere Verbesserungen zu erzielen.
Bei einigen Diensten waren trotzdem noch manuelle Eingriffe zur ordnungsgemäßen Wiederherstellung erforderlich. Um dafür zu sorgen, dass keine weiteren manuellen Schritte erforderlich sind, haben wir für jeden dieser Services Daten und Maßnahmen erfasst. Wir werden auch weiterhin Produktivtests durchführen, um zu kontrollieren, dass durch diese Änderungen und Verbesserungen die von unseren Kunden erwartete Ausfallsicherheit gewährleistet werden kann.
Darüber hinaus werden wir weiterhin mit Flextential bei Folgeaktivitäten zusammenarbeiten, um eine klarere Vorstellung von den Betriebs- und Überprüfungsverfahren der Firma zu erhalten. Dieser Zwischenfall war zwar auf einen einzigen Standort beschränkt, wir werden aber aus dieser Erfahrung heraus einen Prozess entwickeln, mit dem wir einen vergleichbaren Überblick über alle unsere kritischen Rechenzentren sicherstellen können.
Wir möchten uns ausdrücklich bei unseren Kunden für die Beeinträchtigungen entschuldigen – insbesondere bei denjenigen, die während des Vorfalls die Analytics-Engine nicht nutzen konnten. Unsere Arbeit in den letzten vier Monaten hat zu den von uns erwarteten Ergebnissen geführt und wir werden unseren Fokus auch weiterhin voll und ganz darauf legen, dieses Projekt zum Abschluss zu bringen.