Cloudflare-API ausgefallen
(news.ycombinator.com)- Die Störung von Cloudflare Dashboard und API wurde als resolved markiert, nachdem die Control Plane API und Produktservices zurück in das zentrale Rechenzentrum in Portland verlagert worden waren
- Bei Dashboard-Funktionen, Alerts, Zero Trust, WARP, Pages, Workers und weiteren Diensten, die von der API-Infrastruktur abhängen, konnten fehlgeschlagene Requests und Fehleranzeigen auftreten
- Cloudflare bewertete einen Stromausfall im Rechenzentrum, führte ein Failover der Dienste durch und reduzierte die Auswirkungen, nachdem die Stromversorgung eines zentralen nordamerikanischen Rechenzentrums teilweise wiederhergestellt und zentrale Dienste in ein Backup-Rechenzentrum verlagert worden waren
- Die Auswirkungen wurden in Data Plane und Control Plane unterteilt; Logpush, Analytics, Workers Analytics Engine, Radar, CASB, DEX, Stream, DNS Updates und weitere Dienste wechselten je nach Zeitpunkt zwischen unavailable, degraded und restored
- Einige Logpush-Logs und Analysedaten gingen während des Incidents verloren; Logs nahe dem Ende des Incidents konnten möglicherweise wiederhergestellt werden, der gesamte Umfang der Auswirkungen war während des Vorfalls jedoch noch nicht abschließend geklärt
Umfang der Störung von Dashboard und API
- Cloudflare untersuchte und behob Probleme mit dem Cloudflare Dashboard und den zugehörigen APIs; Nutzer konnten fehlgeschlagene Dashboard-/API-Requests oder Fehleranzeigen erleben
- Die Störung weitete sich auf mehrere Dienste aus, die von der Cloudflare-API-Infrastruktur abhängen
- Alerts
- Dashboard functionality
- Zero Trust
- WARP
- Cloudflared
- Waiting Room
- Gateway
- Stream
- Magic WAN
- API Shield
- Pages
- Workers
- Cloudflare erklärte, dass dieses Problem weder die Auslieferung zwischengespeicherter Dateien über das Cloudflare CDN noch andere Sicherheitsfunktionen am Cloudflare Edge beeinträchtigte
Failover nach Stromausfall und Wiederherstellung in Portland
- Cloudflare bewertete den Stromausfall, der ein Rechenzentrum betraf, und führte gleichzeitig ein Failover der Dienste durch
- Nachdem die Stromversorgung eines zentralen nordamerikanischen Rechenzentrums teilweise wiederhergestellt war, wurden einige zentrale Dienste in ein Backup-Rechenzentrum verlagert, wodurch die Auswirkungen abgemildert wurden
- Während der Wiederherstellung tauchten in mehreren Updates wiederholt Zustände wie „gradual improvement“ und „restore full functionality“ auf
- In der letzten Phase wurden die Control Plane API und Produktservices zurück in das zentrale Rechenzentrum in Portland verlagert
- Ab 2023-11-06 17:00 UTC begann die Wiederherstellung der Control Plane API und der Product Services in den primary HA datacenters in Portland
- Die Wiederherstellungsarbeiten wurden mit etwa 2 Stunden angegeben; in diesem Zeitraum konnte die Verfügbarkeit von Cloudflare API und Dashboard eingeschränkt sein
- Ab 2023-11-06 18:30 UTC begann auch die Wiederherstellung der Pages- und Workers-Control-Plane-API sowie der Product Services in den zentralen Rechenzentren in Portland
- Auch nach Abschluss der Wiederherstellung überwachte Cloudflare Stabilität und Edge Cases
Beschädigte Funktionen in der Data Plane
- Die Auswirkungen auf die Data Plane wurden als Bereich definiert, in dem die Gesamtfunktionalität eines Produkts teilweise oder vollständig betroffen war
- Zu den anfangs betroffenen Diensten gehörten Logpush, WARP/Zero Trust device posture, Cloudflare dashboard, Cloudflare API, Stream API, Workers API und Alert Notification System
- Wichtige Dienste, deren Status sich während der Wiederherstellung änderte, waren:
- Logpush: Viele Kunden erhielten keine Logs, und einige Logs könnten verloren gegangen sein. Später wurden weitere Jobs wiederhergestellt; für die Mehrheit der Jobs wurde eine Wiederherstellung bis 07:00 UTC angekündigt
- Analytics / GraphQL API: Bei vielen Kunden waren analytics data in Dashboard und API unavailable; später wurden einige oder die meisten analytics wiederhergestellt, einige Datasets blieben jedoch betroffen
- Workers Analytics Engine: Blieb in mehreren Updates im Status unavailable
- Stream API: Wechselte von not available zu degraded performance but available und später zu restored
- Healthchecks: Wechselte von not available zu restored ohne analytics; später wurden auch Healthcheck analytics auf restored gesetzt
- Radar: Blieb zunächst degraded, bis Cloudflare Radar wieder in den operational status zurückkehrte
- Support Services: Während das Support Portal unavailable war, konnten Enterprise-Kunden Tickets über die Enterprise support email address einreichen; später waren Portal, Phone und Chat wieder operational
- CASB: War im Zustand not available oder degraded performance; bestehende CASB Findings konnten angezeigt werden, scanning war jedoch offline. Später war die CASB API online, die scanning engine befand sich in Wiederherstellung, und es wurde kein Datenverlust erwartet
- DEX: Wechselte von not available zu DEX API online; fleet status sowie HTTP- und Traceroute Test Result data befanden sich in Wiederherstellung, mit erwarteter Wiederherstellung um Saturday Nov 4 15:00 UTC
- DNS Updates: Wechselte von degraded zu restored
Eingeschränkte Konfigurationsänderungen in der Control Plane
- Die Auswirkungen auf die Control Plane wurden als Bereich definiert, in dem die Produktfunktionalität am Edge weiterlief, Änderungen an bestehenden Konfigurationen jedoch betroffen waren
- Zu den anfangs betroffenen Diensten gehörten Magic Transit, Argo Smart Routing, Workers KV, WAF, Rate Limiting, Rules, WARP/Zero Trust Registration, Waiting Room, Load Balancing and Healthchecks, Cloudflare Pages, Zero Trust Gateway, DNS Authoritative and Secondary, Cloudflare Tunnel, Workers KV namespace operations, Magic WAN und Cloudflare Images
- Wichtige Dienste, deren Status sich während der Wiederherstellung änderte, waren:
- Cloudflare API: Wurde auf degraded but accessible oder restored aktualisiert
- Cloudflare Pages: Wechselte von degraded but online zu restored; für einige Zeit waren das Erstellen/Löschen von Projects und direct upload deployments degraded
- Magic Transit / Magic WAN: Wechselte von einem Zustand, in dem Änderungen nicht möglich waren, zu einem Zustand, in dem die configuration plane intern funktionierte; für dringende Änderungen wurde empfohlen, das account team zu kontaktieren
- Argo Smart Routing: Die configuration funktionierte, aber smart updates und analytics waren offline
- Billing API / Registrar API: Für einen bestimmten Zeitraum waren nur read-only operations möglich
- Lists: list item updates wurden vorübergehend ausgesetzt; im Dashboard funktionierten sie, über die API konnten sie jedoch 429-Fehler zurückgeben. Später wechselte der Dienst in den restored status, Änderungen waren für eine Weile aber nur über das Dashboard möglich
- SSL / SSL for SaaS: Es gab Verzögerungen bei SSL provisioning und custom hostname validation; später wechselte der Dienst zu restored
- Access API, Images API, SOC Proactive Alerts, ZT Gateway, Area 1 Email Security, Direct Upload Deployments wechselten je nach Update ebenfalls zwischen degraded, unavailable und restored
Verlorene Logs und Nachanalyse
- Cloudflare erklärte, dass während des Incidents einige Logpush-Logs und analytics data verloren gingen
- Logs nahe dem Ende des Incidents konnten möglicherweise wiederhergestellt werden; während des Vorfalls war der gesamte Umfang der Auswirkungen jedoch noch nicht bekannt
- In einem Update hieß es, dass alle Logs und die analytics pipeline bis Saturday 4th November 2023 7AM UTC operational sein würden
- In späteren Updates hieß es, „die meisten Logs seien während des Incidents verloren gegangen“, und Cloudflare kündigte an, nach Behebung des Incidents eine vollständige Bewertung bereitzustellen
- Weitere Details finden sich in Cloudflares post-mortem on Cloudflare control plane and analytics outage
1 Kommentare
Meinungen auf Hacker News
Als ich vor etwas mehr als drei Jahren dort gearbeitet habe, war die Architektur so, dass bei einem Ausfall von PDX die zentralen Systeme ausfielen.
Dinge wie DDoS-Abwehr wurden bereits in jedem PoP verarbeitet, sodass L3/L7-Floods oder neue Angriffe kein Problem waren, aber fast alles andere wurde in PDX berechnet und dann als Konfigurationsdaten an die einzelnen PoPs verteilt.
Der Ablauf war: PoP erzeugt/sammelt Daten → sendet sie an PDX → Berechnung in PDX → Updates/Daten werden an die PoPs verteilt. Wenn PDX ausfiel, liefen viele Funktionen, die auf aktuelle Daten angewiesen waren, zunehmend mit veraltetem Zustand weiter.
Ich glaube nicht, dass sich seitdem alles geändert hat; daher handelt es sich vermutlich weniger um einen simplen „API-Ausfall“, sondern eher um einen Zustand mit Leistungsverschlechterungen, bei dem Funktionen wie Load Balancing, Tiered Cache, Argo Smart Routing und Warp/Zero Trust ohne PDX-Updates mit veralteten Zustandsinformationen laufen.
Selbst wenn es „nur ein API-Ausfall“ wäre, blockieren viele Kundenautomatisierungen Angriffe per API-Aufruf – für Angreifer öffnet sich damit also ein ziemlich großes Zeitfenster.
Kurz vor meinem Weggang wurde in den Aufbau von AMS investiert, aber ein großer Failover-Test war nie erfolgreich gewesen, und die meisten Dienste, die aktuellen Zustand benötigen, kannten diese Methode nicht.
Außerdem basierte auch der Großteil der Observability auf PDX; mein Mitgefühl gilt den Teams und SREs, die jetzt wohl im Blindflug unterwegs sind.
Cloudflare erklärte, man bewerte einen Stromausfall, der das Rechenzentrum beeinträchtigt habe, und führe gleichzeitig ein Service-Failover durch.
Der Netzstrom fiel aus, man schaltete auf Generatoren um, doch auch die Generatoren versagten; offenbar ist ein Teil des Netzstroms zurück, und Teile des Standorts werden wiederhergestellt.
https://puck.nether.net/pipermail/outages/2023-November/0149...
Allerdings klaffen Absicht und Realität immer auseinander, und es wurden mehrere Gründe genannt, warum ein automatisches oder im Notfall manuelles Failover in ein Rechenzentrum auf der anderen Seite der Erde für viele Workloads keine realistische Lösung war.
Cloudflare macht viel Chaos Testing und testet auch sehr regelmäßig die vollständige Netzwerkisolierung von Rechenzentren.
Ich würde mich gern heimlich in die Besprechung schleichen, in der diskutiert wird, warum dieser Vorfall so anders war.
Ich habe nur eines von beiden direkt gebaut, aber im Marketing wurden sie immer zusammen genannt.
Wenn man kein Enterprise-Nutzer ist, der die Tiered-Cache-Topologie per API anpasst, dürfte es meist in Ordnung sein, wenn die Cache-Topologie ein paar Tage oder Wochen veraltet ist.
Wie gesagt können aber viele andere Dinge Probleme bekommen.
Egal wie gut Wartung und Vorausplanung sind: Die Wahrscheinlichkeit ist nicht null, dass irgendwann Bedingungen eintreten, die man nicht erwartet hat oder aus Kostengründen nicht abgesichert hat, und dann kritische Infrastruktur ausfällt.
Da die Dashboard-UI für Updates offenbar die API nutzt, lag es vermutlich an einer verschlechterten API-Erreichbarkeit.
In der UI sah es so aus, als würden DNS-Updates übernommen, tatsächlich wurden sie aber nicht propagiert; nach dem Ausfall musste ich in Cloudflares Dashboard die Domain komplett löschen und neu anlegen, damit SSL und DNS-Propagation wieder funktionierten.
Nach 12 Stunden besteht das Problem immer noch.
Ich belege einen Online-Kurs für Musikproduktion, dessen Videos auf Cloudflare Stream liegen, und keines davon lässt sich abspielen.
https://www.cloudflare.com/products/cloudflare-stream/
Das Problem eines Single Point of Failure für das halbe Internet zeigt sich immer wieder.
https://www.cloudflarestatus.com/incidents/hm7491k53ppg
Ich dachte, nur das Dashboard und Funktionen innerhalb des Dashboards seien betroffen, aber wenn Cloudflares Videostreaming nicht funktioniert, scheint das wohl doch nicht der Fall zu sein.
Ich weiß nicht genau, aber bei Cloudflare habe ich ein etwas ungutes Gefühl.
Ich verstehe nicht, warum so viele Menschen es für in Ordnung halten, dass große Teile des Internets von einem Unternehmen abhängen.
Vielleicht liege ich mit meiner Wahrnehmung falsch, aber Cloudflare wirkt auf mich wie ein glaubwürdiger Herausforderer der oligopolartigen Großkonzerne, und ich wünschte, es gäbe mehr Cloudflares.
Mir fällt tatsächlich kein vergleichbarer Dienst ein, der eine ähnlich großzügige kostenlose Stufe anbietet.
Richtig eingesetztes TLS bietet Ende-zu-Ende-Sicherheit, aber wenn man Cloudflare nutzt, kann Cloudflare auf den gesamten Klartext-Traffic zugreifen.
Wenn eine kleine Website Ziel eines DoS werden kann, muss sie letztlich Cloudflare nutzen.
Das ist mein persönlicher Eindruck, und ich könnte falschliegen.
Ich dachte kurz, ob sie den Bug von vor ein paar Tagen wieder committet hätten
https://blog.cloudflare.com/cloudflare-incident-on-october-3...
War es aber nicht; es sieht nach einem Stromausfall in einem zentralen Rechenzentrum aus
Mehr Details stehen in anderen Kommentaren
Inzwischen bin ich schon fast pawlowsch darauf konditioniert, Ausfälle zu genießen
Allein letzte Woche war das schon der zweite Ausfall
Ergänzend zur Antwort auf den toten Kommentar: Das hat überhaupt nichts mit der Wahl der Programmiersprache zu tun
Auch DreamHost hat seit 4:54 Uhr Pacific Time Probleme in PDX
https://www.dreamhoststatus.com
Es wurde gemeldet, dass Flexential PDX02 ungefähr zu dem Zeitpunkt, als das hier begann, die Stromversorgung verloren hat
Cloudflare hat gerade bekanntgegeben, dass sie einen Stromausfall mit Auswirkungen auf ein Rechenzentrum untersuchen und gleichzeitig ein Service-Failover durchführen
Unser Flexential-Standort hat fünf Generatoren, Batterie-Backup im Untergeschoss und isolierte Bereiche
Am beeindruckendsten ist, dass die Statusseite tatsächlich funktioniert
Natürlich sind sie wahrscheinlich anderswo gehostet, aber bei jedem großen Ausfall muss ich daran denken und lachen
Sieht nicht besonders gut aus
Ich hoffe, dass sie deswegen nicht aufhören, ihre eigenen Dienste zu nutzen
Vercel-Deployments und Edge Functions funktionieren ebenfalls nicht
Auf der Statusseite heißt es: „Wir haben ein Problem bei einem unserer Upstream-Anbieter als Root Cause identifiziert und arbeiten gemeinsam an einer Abmilderung“
Ich frage mich, ob Edge Functions intern Workers verwenden
Link: https://www.vercel-status.com/
Ein anderer Link im selben Thread sagt, dass Flexential PDX02 zur gleichen Zeit die Stromversorgung verloren hat
Offenbar fiel der Netzstrom aus, man schaltete auf Generatoren um, die dann ebenfalls ausfielen; inzwischen scheint ein Teil des Netzstroms zurück zu sein und Teile der Site werden wiederhergestellt
Klingt so, als sei das gesamte Rechenzentrum ausgefallen und Cloudflares Failover habe das nicht so reibungslos abgefangen wie erhofft
https://puck.nether.net/pipermail/outages/2023-November/0149...
Ich weiß nicht, ob man stolz oder verängstigt sein sollte, dass so viele dieser Produkte im Grunde nur Wrapper um Cloudflare-Produkte sind
In diesem Fall scheint es aber kein Wrapper zu sein; DOs App Platform ist ziemlich ausgefeilt, um nur auf Workers aufzusetzen
Ich vermute, dass mehrere zentrale Workloads Workers nutzen
Schlechtes Timing
Heute Nachmittag ist die Quartalszahlen-Präsentation