Esta es una publicación que nunca pensé que tendría que escribir. Menos de cinco meses después del corte eléctrico de uno de nuestros principales centros de datos, ha vuelto a ocurrir en el mismo centro de datos. ¡Qué mala suerte! y, si estás pensando "¿por qué siguen usando esta instalación?", no te culpo. coincidimos. Sin embargo, la cuestión es que, aunque es posible que muchas cosas no hayan cambiado en el centro de datos, los cambios en Cloudflare sí han sido significativos durante esos cinco meses. Así que, si bien en aquel entonces la desconexión de un importante centro de datos fue un problema, esta vez no lo ha sido tanto.
Te explicamos cómo un centro de datos de alta disponibilidad se queda sin electricidad por segunda vez en cinco meses. Pero, más aún, te contamos cómo nuestro equipo trabajó para garantizar que, incluso si uno de nuestros centros de datos esenciales se quedaba sin energía, nuestros clientes no se vieran afectados.
El 2 de noviembre de 2023, una de nuestras instalaciones esenciales en la región de Portland (Oregón) se quedó sin electricidad durante un periodo prolongado. Ocurrió debido a una sucesión de fallos en cadena, al parecer a causa del mantenimiento del proveedor de la red eléctrica, que culminó con un fallo de fase a tierra en la instalación, y empeoró por una serie de incidentes desafortunados que impidieron que la instalación volviera a estar en línea de manera oportuna.
Si quieres leer todo lo ocurrido con detalle, haz clic aquí.
Cuando un centro de datos tiene una pérdida total de energía es un problema grave, pero es algo que se suponía que debíamos esperar. Por desgracia, a pesar de esa posibilidad, no habíamos aplicado una serie de requisitos en nuestros productos que garantizaran que siguieran funcionando ante un fallo importante.
Ese fue un error que nunca íbamos a permitir que volviera a ocurrir.
Código naranja
El incidente fue tan grave que declaramos lo que llamamos código naranja. Tomamos prestada la idea de Google, que, ante una amenaza existencial para su negocio, declara un código amarillo o un código rojo. Nuestro logotipo es naranja, así que hemos modificado un poco la fórmula.
Nuestra idea del código naranja era que la persona que liderara la respuesta al incidente, en este caso nuestro vicepresidente sénior de operaciones técnicas, Jeremy Hartman, estaría facultado para encargar a cualquier ingeniero de nuestro equipo que trabajara en lo que considerara el proyecto de mayor prioridad (a menos que declaráramos un código rojo, que en realidad acabamos haciendo debido a un hackeo, y que entonces tendría una prioridad aún mayor. Si te interesa, puedes leer más sobre ello aquí).
Después de superar el incidente inmediato, Jeremy evaluó rápidamente el trabajo más importante que había que hacer para garantizar una alta disponibilidad incluso en el caso de otro fallo catastrófico de una instalación importante del centro de datos. Y el equipo se puso a trabajar.
¿Cómo lo hicimos?
No esperábamos una prueba tan extensa en el mundo real tan rápido, pero el universo encierra misterios inescrutables. El martes 26 de marzo, apenas cinco meses después del incidente inicial, la misma instalación sufrió otro apagón importante. A continuación, analizaremos la causa de esta nueva interrupción, pero lo más importante es que nos permitió probar el trabajo que nuestro equipo había realizado con el código naranja. ¿Cuáles fueron los resultados?
En primer lugar, repasemos las funciones que ofrecen los centros de datos de Portland en Cloudflare. Como se describe en la publicación del 2 de noviembre, el plano de control de Cloudflare consiste principalmente en la interfaz orientada al usuario para todos nuestros servicios, incluidos nuestro sitio web y nuestra API. Además, los servicios subyacentes que proporcionan las canalizaciones de análisis y registros se sirven principalmente desde estas instalaciones.
Al igual que en noviembre, se nos avisó inmediatamente de que habíamos perdido la conectividad con nuestro centro de datos PDX01. A diferencia de ese entonces, supimos con certeza al instante que una vez más nos habíamos quedado sin electricidad, lo que nos situó exactamente en la misma situación que cinco meses antes. También sabíamos, gracias a una prueba de corte interna realizada con éxito en febrero, cómo debían reaccionar nuestros sistemas. Pasamos meses preparándonos, actualizando innumerables sistemas y activando grandes volúmenes de capacidad de red y servidores, que culminaron con una prueba para demostrar que el trabajo estaba teniendo el efecto deseado, que en este caso fue una conmutación por error automática a las instalaciones redundantes.
Nuestro plano de control consta de cientos de servicios internos, y se espera que cuando perdamos uno de los tres centros de datos críticos en Portland, estos servicios sigan funcionando con normalidad en las otras dos instalaciones, y que nosotros sigamos operando principalmente en Portland. Tenemos la capacidad de conmutar por error a nuestros centros de datos europeos en caso de que nuestros centros de Portland dejen de estar disponibles por completo. Sin embargo, esa es una opción secundaria, y no algo que persigamos de inmediato.
El 26 de marzo de 2024, a las 14:58 UTC, PDX01 se desconectó y nuestros sistemas empezaron a reaccionar. A las 15:05 UTC, nuestras API y paneles de control funcionaban con normalidad, todo ello sin intervención humana. Nuestro objetivo principal en los últimos meses ha sido asegurarnos de que nuestros clientes puedan seguir configurando y operando los servicios de Cloudflare en caso de una interrupción similar. Hubo algunos servicios específicos que requirieron intervención humana y, por lo tanto, tardaron un poco más en restablecerse, sin embargo, el mecanismo de la interfaz principal funcionaba como se esperaba.
Para ser más precisos, durante el incidente del 2 de noviembre de 2023, el plano de control de los siguientes servicios se interrumpió durante al menos seis horas, y algunos de ellos se vieron afectados en términos operativos durante días.
API y panel de control
Zero Trust
Magic Transit
SSL
SSL para SaaS
Workers
KV
Waiting Room
Load Balancing
Puerta de enlace Zero Trust
Access
Pages
Stream
Images
Durante el incidente del 26 de marzo de 2024, todos estos servicios estaban en funcionamiento a los pocos minutos de la avería eléctrica, y muchos de ellos no sufrieron ningún impacto durante la conmutación por error.
El plano de datos, que gestiona el tráfico que los clientes de Cloudflare dirigen a través de nuestros más de 300 centros de datos, no se vio afectado.
Nuestra plataforma de análisis, que proporciona una visión del tráfico de los clientes, se vio afectada y no se restauró por completo hasta más tarde ese mismo día. Era lo previsto, ya que la plataforma de análisis depende del centro de datos PDX01. Al igual que con el trabajo del panel de control, empezamos a desarrollar nueva capacidad en la plataforma de análisis inmediatamente después del incidente del 2 de noviembre de 2023. Sin embargo, se necesita un poco más de tiempo para completar el trabajo. Hemos estado trabajando lo más rápido posible para eliminar esta dependencia, y esperamos completar este trabajo en un futuro próximo.
Una vez que validamos la funcionalidad de nuestros servicios del plano de control, nos enfrentamos una vez más al arranque en frío de un centro de datos muy grande. Esta actividad llevó aproximadamente 72 horas en noviembre, pero esta vez pudimos completarla en aproximadamente 10 horas. Todavía queda trabajo por hacer para que sea aún más rápido en el futuro, y seguiremos perfeccionando nuestros procedimientos en caso de que tengamos un incidente similar más adelante.
¿Cómo hemos llegado hasta aquí?
Como hemos mencionado anteriormente, el apagón del pasado mes de noviembre nos llevó a implementar el código naranja, un proceso en el que dedicamos la mayoría o todos los recursos de ingeniería cuando hay un incidente o una crisis importante. En los últimos cinco meses, hemos cambiado todas las funciones de ingeniería no críticas para centrarnos en garantizar una alta fiabilidad de nuestro plano de control.
Los equipos de nuestros departamentos de ingeniería aunaron sus fuerzas para garantizar que nuestros sistemas fueran más resistentes ante un fallo similar en el futuro. Aunque el incidente del 26 de marzo fue inesperado, era algo para lo que nos habíamos estado preparando.
La diferencia más obvia es la velocidad a la que el plano de control y las API recuperaron el servicio. Sin intervención humana, la capacidad de iniciar sesión y realizar cambios en la configuración de Cloudflare fue posible siete minutos después de la avería de PDX01. Esto se debe a nuestros esfuerzos por migrar todas nuestras bases de datos de configuración a una topología de alta disponibilidad (HA), y aprovisionar previamente suficiente capacidad para poder absorber la pérdida de capacidad. Más de 100 bases de datos en más de 20 clústeres de bases de datos diferentes fallaron simultáneamente en la instalación afectada y el servicio se restauró automáticamente. Esta fue la culminación de más de un año de trabajo, y nos aseguramos de demostrar nuestra capacidad de conmutación por error con pruebas semanales.
Otra mejora significativa son las actualizaciones de nuestra infraestructura Logpush. En noviembre, el apagón del centro de datos PDX01 nos impidió enviar los registros a nuestros clientes. Durante el trabajo del código naranja, invertimos en garantizar la alta disponibilidad de la infraestructura de Logpush en Portland, y además creamos una opción de conmutación por error activa en Ámsterdam. Logpush aprovechó nuestra expansión masiva del clúster de Kubernetes, que abarca todas nuestras instalaciones de Portland, y proporciona a los propietarios de servicios una forma eficaz de implementar servicios compatibles de alta disponibilidad que incorporan resiliencia. De hecho, durante nuestro ejercicio en preparación del caos de febrero, encontramos un fallo en nuestra implementación de alta disponibilidad en Portland, pero los clientes no se vieron afectados porque la infraestructura Logpush de Ámsterdam se hizo cargo satisfactoriamente. Durante este incidente, vimos que las correcciones que habíamos realizado desde entonces funcionaban, y pudimos enviar los registros desde la región de Portland.
Otras mejoras en nuestros productos Stream y Zero Trust permitieron que siguieran funcionando sin apenas verse afectados, o solo mínimamente. Nuestros productos Stream, que utilizan muchos recursos informáticos para transcodificar vídeos, se pudieron transferir sin problemas a nuestras instalaciones de Ámsterdam para que continuaran funcionando. Los equipos recibieron objetivos de disponibilidad específicos para los servicios y se les proporcionaron varias opciones para alcanzarlos. Stream es un buen ejemplo de un servicio que eligió una arquitectura de resistencia diferente, pero pudo prestar su servicio sin problemas durante esta interrupción. Zero Trust, que también se vio afectado en noviembre, ha trasladado desde entonces la gran mayoría de sus funciones a nuestros cientos de centros de datos, que siguieron funcionando sin problemas durante este incidente. En última instancia, esta es la estrategia que queremos que adopten todos los productos de Cloudflare, ya que nuestros más de 300 centros de datos ofrecen el mayor nivel de disponibilidad posible.
¿Qué pasó con la energía en el centro de datos?
El 26 de marzo de 2024, a las 14:58 UTC, PDX01 se quedó sin suministro eléctrico, afectando en consecuencia a la infraestructura física de Cloudflare tras un fallo simultáneo de cuatro conmutadores propiedad de Flexential y operados por ellos que daban servicio a todos nuestros contenedores. Eso hizo que tanto las rutas de alimentación primarias como las redundantes se desactivaran en todo el entorno. Durante la investigación realizada por Flextential, los ingenieros se centraron en un conjunto de equipos conocidos como placas de conmutación de circuitos (CSB). Los CSB se asemejan a un cuadro eléctrico, que consta de un disyuntor de entrada principal y una serie de interruptores de salida más pequeños. Los ingenieros de Flexential informaron de que la infraestructura anterior a los CSB (alimentación eléctrica, generador, SAI y PDU/transformador) no se vio afectada y siguió funcionando con normalidad. Del mismo modo, la infraestructura descendente de los CSB, como los paneles de alimentación remotos y los conmutadores conectados, tampoco sufrió daños, lo que implica que la interrupción se limitó a los propios CSB.
La evaluación inicial de la causa de los fallos del CSB de Flexential apunta a que uno de los factores fue la configuración incorrecta de la coordinación de los interruptores en los cuatro CSB. Los ajustes de disparo demasiado restrictivos pueden dar lugar a una protección contra sobrecorriente demasiado sensible y a posibles disparos molestos de los dispositivos. En nuestro caso, la configuración de los interruptores de Flexential dentro de los cuatro CSB era demasiado baja en relación con las capacidades de alimentación suministradas a niveles inferiores. Cuando uno o más de estos interruptores se activaban, se producía un fallo en cadena del resto de placas CSB activas, lo que provocaba una pérdida total de energía que daba servicio al contenedor de Cloudflare y a otros en la infraestructura compartida. Durante la evaluación del incidente, nos comunicaron que el equipo de las instalaciones de Flexential observó la configuración incorrecta del disparo, restableció los CSB y los ajustó a los valores esperados, lo que permitió a nuestro equipo encender nuestros servidores de forma escalonada y controlada. No sabemos cuándo se establecieron estos ajustes. Normalmente, se haría como parte de un proceso de puesta en marcha del centro de datos y/o un estudio de coordinación de interruptores antes de instalar las cargas críticas del cliente.
¿Y después?
Nuestra principal prioridad es completar el programa de resiliencia para nuestra plataforma de análisis. Los análisis no son solo gráficos bonitos en un panel de control. Cuando quieres comprobar el estado de los ataques, las actividades que bloquea un firewall o incluso el estado de Cloudflare Tunnel, necesitas análisis. Tenemos pruebas de que el patrón de resiliencia que estamos adoptando funciona según lo previsto, por lo que este sigue siendo nuestro principal objetivo, y avanzaremos lo más rápido posible.
Hubo servicios que siguieron requiriendo intervención manual para restablecerse correctamente, y hemos recopilado datos y acciones para cada uno de ellos a fin de garantizar que no vuelvan a ser necesarias. Seguiremos utilizando pruebas de corte de producción para demostrar que todos estos cambios y mejoras proporcionan la resistencia que esperan nuestros clientes.
Seguiremos trabajando con Flextential en actividades de seguimiento para conocer mejor sus procedimientos operativos y de revisión en la mayor medida posible. Aunque este incidente se limitó a una sola instalación, convertiremos este ejercicio en un proceso que garantice un enfoque similar en todas nuestras instalaciones críticas de centros de datos.
Una vez más, lamentamos mucho el impacto en nuestros clientes, en particular en aquellos que dependen de Analytics Engine, que no pudieron acceder a esa función del producto durante el incidente. Nuestro trabajo durante los últimos cuatro meses ha dado los resultados que esperábamos, y seguiremos totalmente centrados en completar el trabajo restante.