Caída de la API de Cloudflare
(news.ycombinator.com)- La interrupción del Dashboard y la API de Cloudflare quedó resuelta después de devolver la Control Plane API y los servicios de producto al centro de datos principal de Portland
- Pudo haber habido fallas en solicitudes y mensajes de error en funciones del Dashboard, Alerts, Zero Trust, WARP, Pages, Workers y otros servicios que dependían de la infraestructura de API
- Cloudflare evaluó una pérdida de energía en el centro de datos e hizo failover de servicios; después de una recuperación parcial de energía en un centro de datos clave de Norteamérica, movió servicios críticos a un centro de datos de respaldo para reducir el impacto
- El impacto se dividió entre plano de datos y plano de control, y Logpush, Analytics, Workers Analytics Engine, Radar, CASB, DEX, Stream y DNS Updates, entre otros, pasaron por estados de unavailable, degraded y restored según el momento
- Algunos logs de Logpush y datos de analítica se perdieron durante el incidente; los logs cercanos al momento del cierre podían recuperarse, pero el alcance total del impacto no estaba confirmado mientras seguía en curso
Alcance del impacto de la interrupción del Dashboard y la API
- Cloudflare investigó y recuperó problemas en el Cloudflare Dashboard y las APIs relacionadas, y los usuarios pudieron experimentar fallas en solicitudes del Dashboard/API o mensajes de error
- La interrupción se extendió a varios servicios que dependen de la infraestructura de API de Cloudflare
- Alerts
- Funcionalidad del Dashboard
- Zero Trust
- WARP
- Cloudflared
- Waiting Room
- Gateway
- Stream
- Magic WAN
- API Shield
- Pages
- Workers
- Cloudflare indicó que este problema no afectó la entrega de archivos en caché del CDN de Cloudflare ni otras funciones de seguridad en el Edge de Cloudflare
Failover tras la pérdida de energía y recuperación en Portland
- Cloudflare hizo failover de servicios mientras evaluaba una pérdida de energía que afectó al centro de datos
- Después de una recuperación parcial de energía en un centro de datos clave de Norteamérica, algunos servicios críticos hicieron failover a un centro de datos de respaldo, lo que mitigó el impacto
- Durante la recuperación, en varias actualizaciones se repitieron los estados “gradual improvement” y “restore full functionality”
- En la etapa final, se devolvió la Control Plane API y los servicios de producto al centro de datos principal de Portland
- Desde 2023-11-06 17:00 UTC comenzó la restauración de la Control Plane API y Product Services a los primary HA datacenters de Portland
- Se indicó que el trabajo de restauración tomaría unas 2 horas y que, durante ese periodo, la disponibilidad de la API y el Dashboard de Cloudflare podía verse degradada
- Desde 2023-11-06 18:30 UTC, Pages y Workers Control Plane API y Product Services también comenzaron a restaurarse al centro de datos principal de Portland
- Tras completar la restauración, Cloudflare siguió monitoreando la estabilidad y los edge cases
Funciones afectadas en el plano de datos
- El impacto en el plano de datos se definió como el alcance en que la funcionalidad total del producto quedó parcial o totalmente afectada
- Los servicios impactados al inicio incluyeron Logpush, WARP/Zero Trust device posture, Cloudflare dashboard, Cloudflare API, Stream API, Workers API y Alert Notification System
- Los principales servicios cuyo estado cambió durante la recuperación fueron los siguientes
- Logpush: muchos clientes no recibieron logs y algunos logs pudieron haberse perdido. Después se recuperaron más jobs y se indicó que la mayoría de los jobs se restaurarían para las 07:00 UTC
- Analytics / GraphQL API: los datos de analítica de muchos clientes estuvieron unavailable en el Dashboard y la API; después se recuperó parte o la mayoría de la analítica, aunque algunos datasets seguían pendientes
- Workers Analytics Engine: permaneció unavailable en varias actualizaciones
- Stream API: pasó de not available a degraded performance but available, y después a restored
- Healthchecks: pasó de not available a restored sin analítica, y luego también se restauró la analítica de Healthcheck
- Radar: siguió en estado degraded hasta que Cloudflare Radar volvió a operational status
- Support Services: mientras el portal de soporte estuvo unavailable, los clientes Enterprise podían abrir tickets mediante la dirección de correo de soporte Enterprise; después, Portal, Phone y Chat volvieron a operational
- CASB: estuvo en estado not available o degraded performance; los CASB Findings existentes podían verse, pero el scanning estaba offline. Después, la CASB API volvió a online, el scanning engine siguió en recuperación y se indicó que no se esperaba pérdida de datos
- DEX: pasó de not available a DEX API online, mientras fleet status, HTTP y Traceroute Test Result data seguían recuperándose, con recuperación esperada alrededor del sábado 4 de noviembre a las 15:00 UTC
- DNS Updates: pasó de degraded a restored
Cambios de configuración limitados en el plano de control
- El impacto en el plano de control se definió como el caso en que las funciones del producto seguían operando en el edge, pero se veían afectados los cambios a configuraciones existentes
- Los servicios impactados al inicio incluyeron 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 y Cloudflare Images
- Los principales servicios cuyo estado cambió durante la recuperación fueron los siguientes
- Cloudflare API: se actualizó a estados de degraded but accessible o restored
- Cloudflare Pages: pasó de degraded but online a restored, aunque por un tiempo la creación/eliminación de proyectos y los direct upload deployments siguieron degradados
- Magic Transit / Magic WAN: pasaron de no permitir cambios a un estado en que el configuration plane funcionaba internamente; se indicó contactar al account team para cambios urgentes
- Argo Smart Routing: la configuración funcionaba, pero smart updates y analytics estaban offline
- Billing API / Registrar API: durante cierto periodo solo permitieron operaciones de solo lectura
- Lists: las actualizaciones de elementos de listas se suspendieron temporalmente; en el Dashboard funcionaban, pero la API podía devolver errores 429. Después pasaron a restored, aunque durante un tiempo solo se podían modificar desde el Dashboard
- SSL / SSL for SaaS: hubo retrasos en el aprovisionamiento de SSL y en la validación de custom hostnames, y luego pasó a restored
- Access API, Images API, SOC Proactive Alerts, ZT Gateway, Area 1 Email Security y Direct Upload Deployments también pasaron por estados de degraded, unavailable y restored según la actualización
Logs perdidos y análisis posterior
- Cloudflare indicó que durante el incidente se perdieron algunos logs de Logpush y datos de analítica
- Los logs cercanos al cierre del incidente podían recuperarse, pero mientras seguía en curso todavía no se conocía el alcance total del impacto
- En una actualización se indicó que todos los pipelines de logs y analítica estarían en estado operational para el sábado 4 de noviembre de 2023 a las 7:00 AM UTC
- En actualizaciones posteriores se expresó que “la mayoría de los logs se perdieron durante el incidente” y que, una vez resuelto, se daría una evaluación completa
- Más detalles pueden verse en el post-mortem on Cloudflare control plane and analytics outage de Cloudflare
1 comentarios
Opiniones en Hacker News
Cuando trabajé ahí hace poco más de 3 años, la arquitectura era tal que, si PDX se caía, se caían los sistemas centrales.
Cosas como la defensa contra DDoS ya se manejaban dentro de cada PoP, así que las inundaciones L3/L7 o ataques nuevos estaban bien, pero casi todo lo demás se calculaba en PDX y luego se distribuía como datos de configuración a cada PoP.
El flujo era: el PoP genera/recopila datos → los envía a PDX → PDX calcula → distribuye actualizaciones/datos a los PoP; si PDX muere, muchas funciones que dependen de datos recientes empiezan a operar cada vez más con estado obsoleto.
No creo que todo haya cambiado desde entonces, así que más que un simple “API caída”, es muy probable que funciones como balanceo de carga, caché jerárquico, Argo Smart Routing y Warp/Zero Trust estén en un estado de degradación, funcionando con información de estado antigua y sin actualizaciones desde PDX.
Incluso si fuera “solo la API caída”, mucha automatización de clientes bloquea ataques mediante llamadas a la API, así que eso abre una ventana de oportunidad bastante grande para los atacantes.
Justo antes de irme estaban invirtiendo en levantar AMS, pero nunca vi una prueba grande de failover exitosa, y la mayoría de los servicios que necesitaban estado reciente no conocían ese mecanismo.
Además, gran parte de la observabilidad también estaba basada en PDX, así que mando ánimo a los equipos y SRE que ahora deben estar corriendo a ciegas.
Cloudflare dijo que estaba evaluando la pérdida de energía que afectó al centro de datos mientras realizaba failover de servicios.
Se cortó la energía de la red eléctrica, pasaron a generadores, pero los generadores también fallaron; parece que parte de la energía de la red volvió y se está recuperando una parte del sitio.
https://puck.nether.net/pipermail/outages/2023-November/0149...
Pero la intención y la realidad siempre se separan, y escuché varias razones por las que hacer failover automático, o manual de emergencia, a un centro de datos al otro lado del mundo no era una solución realista para muchas cargas de trabajo.
Cloudflare hace muchas pruebas de caos y también prueba con muchísima regularidad el aislamiento completo de la red de un centro de datos.
Me encantaría colarme en la reunión donde discutan por qué este incidente fue tan diferente.
Solo construí directamente una de las dos, pero marketing siempre las mencionaba juntas.
Si no eres un usuario enterprise que personaliza la topología del caché jerárquico mediante la API, creo que en general no pasa nada si la topología de caché queda desactualizada por días o semanas.
Pero, como dices, muchas otras cosas sí pueden tener problemas.
Por muy bien que hagas el mantenimiento y la planificación previa, al final no hay cero probabilidad de que aparezca una condición inesperada, o para la que no se pudo preparar por costos, y tire abajo infraestructura crítica.
Como la UI del dashboard parece usar la API para las actualizaciones, probablemente se debió a la degradación del acceso a la API.
Aunque en la UI parecía que las actualizaciones de DNS se aplicaban, en realidad no se propagaban; después de la interrupción, tuvimos que borrar por completo el dominio en el dashboard de Cloudflare y crearlo de nuevo para que SSL y la propagación de DNS volvieran a funcionar.
Ya pasaron 12 horas y el problema sigue.
Estoy tomando un curso online de producción musical, los videos están en Cloudflare Stream y no se reproduce ninguno.
https://www.cloudflare.com/products/cloudflare-stream/
El problema del punto único de falla para media Internet sigue asomando la cabeza.
https://www.cloudflarestatus.com/incidents/hm7491k53ppg
Pensé que solo afectaba al dashboard y a funciones dentro del dashboard, pero si el streaming de video de Cloudflare no funciona, supongo que no es así.
No sé bien, pero Cloudflare me da algo de mala espina.
No entiendo por qué tanta gente cree que está bien dejar que una gran parte de Internet dependa de una sola empresa.
Puede que mi percepción sea equivocada, pero Cloudflare me parece un retador confiable frente a esos gigantes oligopólicos, y me gustaría que hubiera más Cloudflares.
La verdad no conozco muchos servicios similares que ofrezcan un plan gratuito tan generoso como Cloudflare.
Si usas TLS correctamente, ofrece seguridad de extremo a extremo, pero si usas Cloudflare, Cloudflare puede acceder a todo el tráfico en texto plano.
Si un sitio pequeño puede ser objetivo de DoS, al final tiene que usar Cloudflare.
Es mi impresión personal, y podría estar equivocado.
Pensé que quizá habían vuelto a hacer commit de ese bug hace unos días
https://blog.cloudflare.com/cloudflare-incident-on-october-3...
No fue eso; parece más bien una falla eléctrica en un centro de datos central
Hay más detalles en otros comentarios
A estas alturas, ya terminé disfrutando las caídas como si fuera Pavlov
Es ya la segunda caída solo en la última semana
Para agregar a una respuesta de comentario muerto, esto no tiene nada que ver con la elección del lenguaje de programación
DreamHost también tiene problemas en PDX desde las 4:54 a. m., hora del Pacífico
https://www.dreamhoststatus.com
Se informó que Flexential PDX02 perdió energía más o menos al mismo tiempo en que empezó esto
Cloudflare acaba de anunciar que está evaluando una pérdida de energía que afectó al centro de datos y, al mismo tiempo, está realizando la conmutación por error del servicio
En nuestro Flexential tenemos 5 generadores, respaldo de baterías en el subsuelo y zonas aisladas
Lo más impresionante es que la página de estado sí funciona de verdad
Claro, lo más probable es que esté alojada en otro lugar, pero cada vez que hay una caída grande siempre pienso lo mismo y me da risa
No se ve nada bien
Espero que esto no haga que dejen de usar sus propios servicios
Los despliegues de Vercel y las funciones edge en general tampoco funcionan
La página de estado dice: “identificamos un problema con uno de nuestros proveedores upstream como la causa raíz y estamos colaborando para mitigarlo”
Me pregunto si las funciones edge usan Workers internamente
Enlace: https://www.vercel-status.com/
En otro enlace del mismo hilo dicen que Flexential PDX02 perdió energía en el mismo momento
Parece que se cortó la energía de la compañía eléctrica, cambiaron a generadores, los generadores también fallaron, y al volver parte de la energía de la compañía se está recuperando parte del sitio
Suena a que se cayó todo el centro de datos y que la conmutación por error de Cloudflare no lo manejó tan fluidamente como se esperaba
https://puck.nether.net/pipermail/outages/2023-November/0149...
No sé si deberíamos sentir orgullo o miedo de que tantos de estos productos no sean más que wrappers alrededor de productos de Cloudflare
En este caso no creo que sea un wrapper; App Platform de DO es bastante sofisticada como para estar montada solo sobre Workers
Supongo que varias cargas de trabajo clave están usando Workers
Mal timing
Hoy por la tarde es la presentación de resultados trimestrales