¿Qué demonios le pasó a Cloudflare la semana pasada?
¿Qué diablos le sucedió a Cloudflare la semana pasada?
El 2 de noviembre de 2023, las interfaces de Cloudflare orientadas al cliente, incluidos su sitio web y sus APIs, junto con el registro y análisis, dejaron de funcionar correctamente. Eso fue malo.
Más de 7.5 millones de sitios web utilizan Cloudflare, y 3,280 de los 10,000 sitios más populares del mundo dependen de sus servicios de red de distribución de contenido (CDN). La buena noticia es que la CDN no se cayó. La mala noticia es que el Panel de control de Cloudflare y sus APIs relacionadas estuvieron inactivos durante casi dos días.
También: Los mejores servicios VPN (y cómo elegir el adecuado para ti)
Ese tipo de cosas simplemente no sucede, o al menos no debería suceder, a las grandes empresas de servicios de internet. Entonces, la pregunta de varios millones de dólares es: “¿Qué pasó?”. La respuesta, según el CEO de Cloudflare, Matthew Prince, fue un incidente relacionado con la electricidad en tres de los principales centros de datos de la empresa en Oregón, los cuales son gestionados por Flexential y causaron una serie de problemas uno tras otro. Treinta y seis horas después, Cloudflare finalmente volvió a la normalidad.
Prince no anduvo con rodeos al respecto:
- La fusión de Hulu y la aplicación de streaming de Disney Plus llega...
- La venta gigante de Black Friday de Anycubic está en vivo ahora con...
- Microsoft ofrece supercomputadoras gratuitas a las startups para el...
Para empezar, esto nunca debería haber pasado. Creíamos que teníamos sistemas de alta disponibilidad implementados que deberían haber evitado una interrupción como esta, incluso cuando uno de nuestros proveedores principales de centros de datos falló catastróficamente. Y aunque muchos sistemas permanecieron en línea como estaba previsto, algunos sistemas críticos tenían dependencias no evidentes que los hicieron inaccesibles. Lamento y me avergüenzo por este incidente y el dolor que causó a nuestros clientes y nuestro equipo.
Tiene razón, este incidente nunca debería haber ocurrido. El plano de control y los sistemas de análisis de Cloudflare se ejecutan en servidores ubicados en tres centros de datos alrededor de Hillsboro, Oregón. Sin embargo, cada uno de ellos es independiente; cada uno tiene múltiples fuentes de alimentación eléctrica y múltiples conexiones a internet redundantes e independientes.
Estos tres centros de datos no están tan cerca uno del otro como para que un desastre natural provoque el colapso de todos al mismo tiempo, pero, al mismo tiempo, están lo suficientemente cerca como para que puedan operar con conjuntos de datos redundantes activos. Por diseño, si alguna de las instalaciones se desconecta, las restantes deberían asumir la carga y continuar funcionando.
Suena genial, ¿verdad? Sin embargo, eso no fue lo que ocurrió.
Lo que sucedió primero fue que una falla de energía en las instalaciones de Flexential causó una interrupción del servicio inesperada. Portland General Electric (PGE) se vio obligada a apagar uno de sus suministros de energía independientes del edificio. El centro de datos tiene múltiples suministros con cierto nivel de independencia que pueden alimentar la instalación. Sin embargo, Flexential puso en funcionamiento sus generadores para complementar el suministro que estaba fuera de servicio.
Ese enfoque, por cierto, para aquellos de ustedes que no conocen las mejores prácticas de los centros de datos, es un no-no. No se debe usar energía externa y generadores al mismo tiempo. Para empeorar las cosas, Flexential no informó a Cloudflare que habían, de cierta manera, hecho la transición a la energía de los generadores.
También: 10 formas de acelerar tu conexión a internet hoy
Luego, hubo una falla a tierra en un transformador de PGE que iba hacia el centro de datos. Y cuando digo falla a tierra, no me refiero a un cortocircuito, como el que te hace bajar al sótano para arreglar un fusible. Me refiero a un chico malo de 12,470 voltios que dejó fuera de servicio la conexión y todos los generadores en menos tiempo del que te tomó leer esta oración.
En teoría, una batería de UPS debería haber mantenido los servidores en funcionamiento durante 10 minutos, lo que a su vez debería haber sido suficiente tiempo para encender los generadores nuevamente. En cambio, las baterías de UPS comenzaron a morir en unos cuatro minutos, y los generadores nunca volvieron a encenderse a tiempo de todos modos.
¡Ups!
Puede que no haya nadie que haya podido salvar la situación, pero cuando el personal presente durante la noche estaba compuesto por seguridad y un técnico sin acompañante que solo tenía una semana en el trabajo, la situación era desesperada.
También: Los mejores servicios de VPN para iPhone e iPad (sí, necesitas usar uno)
Mientras tanto, Cloudflare descubrió de la peor manera que algunos sistemas críticos y servicios más nuevos aún no se habían integrado en su configuración de alta disponibilidad. Además, la decisión de Cloudflare de mantener los sistemas de registro fuera del clúster de alta disponibilidad, porque los retrasos en la analítica serían aceptables, resultó ser incorrecta. Como el personal de Cloudflare no pudo examinar los registros para ver qué salía mal, el corte persistió.
Resultó que, si bien los tres centros de datos eran “principalmente” redundantes, no lo eran por completo. Los otros dos centros de datos en funcionamiento en el área asumieron la responsabilidad del clúster de alta disponibilidad y mantuvieron los servicios críticos en línea.
Hasta aquí todo bien. Sin embargo, un conjunto de servicios que se suponía que debían estar en el clúster de alta disponibilidad dependían de servicios que funcionaban exclusivamente en el centro de datos inoperativo.
Específicamente, dos servicios críticos que procesan registros y alimentan la analítica de Cloudflare – Kafka y ClickHouse – solo estaban disponibles en el centro de datos en línea. Entonces, cuando los servicios del clúster de alta disponibilidad solicitaron Kafka y Clickhouse, fallaron.
Cloudflare admite que fue “demasiado laxo al exigir que los nuevos productos y sus bases de datos asociadas se integren con el clúster de alta disponibilidad”. Además, demasiados de sus servicios dependen de la disponibilidad de sus instalaciones principales.
Muchas compañías hacen las cosas de esta manera, pero Prince admitió que esto “no aprovecha la fortaleza de Cloudflare. Somos buenos en sistemas distribuidos. A lo largo de este incidente, nuestra red global continuó funcionando como se esperaba, pero muchos servicios fallaron si la infraestructura central no estaba disponible. Necesitamos utilizar los sistemas distribuidos que ponemos a disposición de todos nuestros clientes para todos nuestros servicios, de modo que sigan funcionando en su mayoría normalmente incluso si nuestras instalaciones principales se ven interrumpidas.”
También: Ciberseguridad 101: Todo sobre cómo proteger tu privacidad y mantenerse seguro en línea
Horas más tarde, todo volvió a funcionar, y no fue fácil. Por ejemplo, casi todos los interruptores de corriente se quemaron, y Flexentail tuvo que comprar más para reemplazarlos todos.
Considerando que había habido múltiples sobretensiones, Cloudflare también decidió que el “único proceso seguro para recuperarse era seguir un reinicio completo de toda la instalación”. Eso significó reconstruir y reiniciar todos los servidores, lo que llevó horas.
Finalmente, el incidente que duró hasta el 4 de noviembre se resolvió. Mirando hacia adelante, Prince concluyó: “Tenemos los sistemas y los procedimientos adecuados para poder resistir incluso una cascada de fallas como la que vimos en nuestro proveedor de centro de datos, pero necesitamos ser más rigurosos al exigir que se sigan y se prueben las dependencias desconocidas. Esto será una prioridad para mí y para una gran parte de nuestro equipo durante el resto del año. Y el dolor de los últimos días nos hará mejores”.
