Análisis post mortem de la interrupción de los servicios de análisis y del plano de control de Cloudflare

El jueves 2 de noviembre de 2023, a partir a las 11:43 UTC, los servicios de análisis y del plano de control de Cloudflare sufrieron una interrupción. El plano de control de Cloudflare consta principalmente de la interfaz que usan los clientes para todos nuestros servicios, incluidos nuestro sitio web y nuestras API. Nuestro servicio de análisis incluye funciones de registro y de informe de análisis.

El incidente duró desde el 2 de noviembre a las 11:44 UTC hasta el 4 de noviembre a las 04:25 UTC. Pudimos restaurar la mayor parte de nuestro plano de control en nuestro centro de recuperación tras desastre el 2 de noviembre a las 17:57 UTC. Muchos clientes no habrían sufrido ningún problema con la mayoría de nuestros productos una vez que el centro de recuperación tras desastre estuvo en línea. Sin embargo, la restauración de otros servicios llevó más tiempo y los clientes que los utilizaban pueden haber observado algún problema hasta que resolvimos por completo el incidente, durante el cual nuestros servicios de registros sin procesar no estuvieron disponibles para la mayoría de los clientes.

Ahora los servicios se han restaurado para todos los clientes. Durante todo el incidente, los servicios de seguridad y de red de Cloudflare continuaron funcionando con normalidad. El tráfico a través de nuestra red no resultó afectado, aunque los clientes no pudieron realizar cambios en esos servicios en momentos determinados.

En esta publicación explicamos los sucesos que causaron este incidente, la arquitectura con la que contábamos para evitar problemas de este tipo y qué falló y por qué, así como los cambios que estamos realizando a raíz de lo que hemos aprendido durante las últimas 36 horas.

Para empezar, esta situación nunca debería haberse producido. Creíamos que disponíamos de sistemas de alta disponibilidad, que deberían haber evitado una interrupción de este tipo, incluso cuando uno de los proveedores de nuestros centros de datos principales ha sufrido un fallo catastrófico. Además, aunque muchos sistemas se mantuvieron en línea de la forma esperada, algunos sistemas críticos tenían dependencias menos evidentes que causaron que dejaran de estar disponibles. Lamento y me avergüenza este incidente y las dificultades que ha causado a nuestros clientes y a nuestro equipo.

El plano de control y los sistemas de análisis de Cloudflare se ejecutan principalmente en los servidores de tres centros de datos ubicados en Hillsboro, Oregón. Disociados unos de otros, cada uno de los tres centros de datos tiene varios canales de suministro eléctrico, así como varias conexiones de red redundantes e independientes.

Las ubicaciones de los centros se eligieron intencionadamente para que la distancia entre ellos minimizara la posibilidad de que una catástrofe natural afectara a los tres, al mismo tiempo que su proximidad permite que cada uno de ellos ejecute clústeres de datos redundantes activo-activo. Esto significa que sincronizan continuamente los datos entre ellos. Este diseño implica que, si cualquiera de los centros se desconecta, los demás pueden seguir funcionando.

Se trata de un diseño de sistema que empezamos a implementar hace cuatro años. Aunque la mayoría de nuestros sistemas de plano de control críticos se habían migrado al clúster de alta disponibilidad, algunos servicios (en concreto, los productos más nuevos) aún no se habían añadido a este clúster.

Además, nuestros sistemas de registro no formaban parte de este clúster, de forma intencionada. La lógica subyacente a esa decisión era que el registro ya era un problema distribuido donde los registros se ponían en cola en el perímetro de nuestra red y luego se reenviaban al centro de datos principal en Oregón (o a otro centro regional en el caso de aquellos clientes que utilizaran servicios regionales para el registro). Si nuestro centro de registro estuviera desconectado, los registros de análisis se podrían en cola en el perímetro de nuestra red hasta que volviera a estar en línea. Determinamos que el retardo de los análisis era aceptable.

Flexential opera el mayor de los tres centros de datos de Oregón, al que nos referimos como "PDX-DC04". Cloudflare alquila el espacio en el centro PDX-04 donde alojamos nuestro mayor clúster de análisis, así como más de una tercera parte de las máquinas de nuestro clúster de alta disponibilidad. Es también la ubicación por defecto de los servicios que aún no hemos incorporado a este clúster. Somos un cliente relativamente importante del centro, con un consumo aproximado del 10 % de su capacidad total.

El 2 de noviembre a las 08:50 UTC, Portland General Electric (PGE), la empresa de suministro eléctrico que presta servicio a PDX-04, realizó una operación de mantenimiento no planificada que afectó a uno de sus canales de suministro eléctrico independientes del edificio. Ese suceso cortó un canal de suministro a PDX-04. El suministro eléctrico de la instalación y por tanto del centro de datos se realiza mediante varios canales con cierto nivel de independencia. Sin embargo, Flexential activó sus generadores para complementar eficazmente el canal de suministro cortado.

En contra de las mejores prácticas, Flexential no informó a Cloudflare de que habían realizado la conmutación al suministro eléctrico del generador. Ninguna de nuestras herramientas de observabilidad pudo detectar que la fuente de suministro eléctrico había cambiado. Si el proveedor nos hubiera informado, hubiéramos podido pedir a un equipo que supervisara atentamente la instalación y que migrara los servicios del plano de control que dependían de ella mientras esta no funciona correctamente.

El hecho de que Flexential utilizara simultáneamente el canal de suministro eléctrico restante y los generadores es también inusual. No es raro que los proveedores de suministro eléctrico pidan a los centros de datos que se desconecten de la red eléctrica cuando hay una alta demanda de electricidad y que funcionen exclusivamente con generadores. Flexential opera 10 generadores, que incluyen unidades redundantes y pueden suministrar alimentación a la instalación a carga completa. Flexential hubiera podido suministrar alimentación a la instalación solo con el canal de suministro eléctrico restante. No hemos recibido ninguna respuesta clara acerca de la razón por la que decidieron suministrar alimentación a la instalación con la línea eléctrica y el generador.

A partir de esta decisión, Flexential aún no nos ha proporcionado información precisa acerca de la causa principal, de determinadas decisiones que tomaron o de los sucesos. Actualizaremos esta publicación cuando Flexential y PGE nos proporcionen más detalles acerca de lo sucedido. Una parte de las hipótesis que detallamos a continuación no son más que especulaciones sobre la serie de acontecimientos más probable, basadas en lo que algunos empleados de Flexential nos han comentado oficiosamente.

Una de las posibles razones por las que pueden haber dejado operativa la línea eléctrica es que Flexential forma parte de un programa con PGE denominado DSG. DSG permite que el proveedor eléctrico local opere los generadores de un centro de datos a fin de suministrar electricidad adicional a la red. A cambio, el proveedor eléctrico ayuda a la empresa con el mantenimiento de los generadores y el suministro de combustible. No hemos podido encontrar ningún registro de Flexential en el que se nos notificara acerca del programa DSG. Les hemos preguntado si el programa DSG estaba activo en el momento del incidente, pero no hemos recibido ninguna respuesta. Ignoramos si este programa contribuyó a las decisiones que tomó Flexential, pero podría explicar el mantenimiento de la línea eléctrica tras el inicio de los generadores.

Aproximadamente a las 11:40 UTC, se produjo un fallo de la conexión a tierra del transformador de PGE en PDX-04. Creemos, pero no hemos podido obtener la confirmación de Flexential ni de PGE, que se trató del transformador que redujo la potencia procedente de la red para el segundo canal, aún operativo cuando la corriente entraba en el centro de datos. Parece probable, aunque no hemos podido confirmarlo con Flexential o PGE, que el fallo de la conexión a tierra se debió al mantenimiento no planificado que PGE estaba realizando y que afectó al primer canal. O bien se trató de una coincidencia muy desafortunada.

Los fallos de conexión a tierra con líneas eléctricas de alto voltaje (12 470 voltios) pueden ser muy dañinos. En el caso de un fallo de este tipo, los sistemas eléctricos están diseñados para desactivarse rápidamente a fin de evitar daños. Lamentablemente, en ese caso la medida de protección también desactivó los generadores de PDX-04. Esto significó que las dos fuentes de generación de energía de la instalación (las líneas eléctricas redundantes y los 10 generadores) se desconectaron.

Por suerte, además de los generadores, PDX-04 también contiene un banco de baterías de SAI. Se supone que estas baterías son suficientes para suministrar alimentación a la instalación durante unos 10 minutos, el tiempo que se considera suficiente para cubrir el intervalo entre el corte de suministro y el inicio automático de los generadores. Por lo tanto, si Flexential lograra restaurar los generadores o el canal de suministro eléctrico en 10 minutos, no habría ninguna interrupción. En realidad, las baterías empezaron a fallar solo 4 minutos después, según las observaciones del fallo de nuestros propios equipos. Además, Flexential tardó mucho más de 10 minutos en restaurar los generadores.

Aunque no hemos recibido ninguna confirmación oficial, algunos empleados nos han comentado que tres hechos dificultaron la restauración de los generadores. En primer lugar, debido a cómo el fallo de conexión a tierra había hecho saltar los circuitos, era necesario acceder a ellos físicamente y reiniciarlos de forma manual. En segundo lugar, el sistema de control de acceso de Flexential no funcionaba con el respaldo de las baterías, por lo que estaba desconectado. Y, en tercer lugar, el personal nocturno de las instalaciones no incluía ningún experto en operaciones o en electricidad con experiencia (el turno de la noche se componía de personal de seguridad y de un técnico no acompañado que solo llevaba una semana en el puesto).

Entre las 11:44 y las 12:01 UTC, cuando los generadores aún no se habían reiniciado por completo, las baterías de SAI se agotaron y todos los clientes del centro de datos se quedaron sin energía. Durante todo este periodo, Flexential no comunicó en ningún momento a Cloudflare la existencia de un problema en la instalación. Recibimos la primera notificación acerca de problemas en el centro de datos cuando los dos enrutadores que conectan la instalación al resto del mundo se desconectaron a las 11:44 UTC. Cuando no pudimos conectar con los enrutadores directamente o mediante la gestión fuera de banda, intentamos contactar con Flexential y mandamos a nuestro equipo local que se desplazaran físicamente a la instalación. El primer mensaje que recibimos de Flexential acerca de que teníamos un problema fue a las 12:28 UTC.

Actualmente tenemos un problema con el suministro eléctrico en nuestro [PDX-04] que se inició aproximadamente a las 0500AM PT [12:00 UTC]. Los ingenieros están trabajando activamente para resolver el problema y restaurar el servicio. Informaremos acerca de la evolución cada 30 minutos o cuando dispongamos de más datos acerca de la hora estimada de la restauración del servicio. Les agradecemos su paciencia y comprensión.

Aunque el diseño de PDX-04 contaba con la certificación de nivel III antes de su construcción y se espera que proporcione alta disponibilidad de acuerdo con sus SLA, hemos previsto la posibilidad de que se desconecte. Incluso las instalaciones bien gestionadas pueden tener un mal día. Hemos planificado para esa eventual situación. Lo que esperábamos que sucediera en ese caso es que nuestro servicio de análisis se desconectara, los registros se pusieran en cola en el perímetro y sufrieran retardos, y determinados servicios menos prioritarios que no estuvieran integrados en nuestro clúster de alta disponibilidad se desconectaran temporalmente hasta que se pudieran restaurar en otra instalación.

Los otros dos centros de datos que operan en el área asumirían la responsabilidad del clúster de alta disponibilidad y mantendrían los servicios esenciales en línea. Eso solía funcionar de la forma prevista. Lamentablemente, descubrimos que un subconjunto de servicios que se suponía que estaban en el clúster de alta disponibilidad tenían dependencias de servicios que se ejecutaban exclusivamente en PDX-04.

En concreto, dos servicios esenciales que procesan registros y en los que se basan nuestros herramientas de análisis (Kafka y ClickHouse) solo estaban disponibles en PDX-04 pero tenían servicios que dependían de ellos y que se ejecutaban en el clúster de alta disponibilidad. Esas dependencias no deberían haber sido tan estrechas, su mecanismo de fallo debería haber sido mejor y las deberíamos haber detectado.

Habíamos realizado pruebas de nuestro clúster de alta disponibilidad desconectando por completo cada una de las otras dos instalaciones de centro de datos (y ambas), así como desconectando la parte de alta disponibilidad de PDX-04. Sin embargo, nunca habíamos probado desconectando por completo toda la instalación PDX-04. Como resultado, no habíamos detectado la importancia de algunas de estas dependencias de nuestro plano de datos.

Tampoco fuimos lo suficientemente estrictos acerca de la necesidad de integración de los nuevos productos y sus bases de datos asociadas con el clúster de alta disponibilidad. Cloudflare permite que varios equipos innoven rápidamente. Así, los productos a menudo toman distintas rutas hacia su versión Alpha inicial. A pesar de que nuestra filosofía es, con el tiempo, migrar el back-end de estos servicios a nuestras mejores prácticas, no es un requisito formal antes de la declaración de la disponibilidad general de los productos. Eso fue un error, porque suponía un funcionamiento incoherente de los mecanismos de protección redundantes que aplicábamos, que variaba según los productos.

Asimismo, un número excesivo de nuestros servicios dependen de la disponibilidad de nuestras instalaciones principales. Este es el método de creación de muchos servicios de software, pero no contribuye a la fortaleza de Cloudflare. Se nos dan bien los sistemas distribuidos. Durante todo este incidente, nuestra red global continuó funcionando de la forma prevista. Aunque algunos de nuestros productos y funciones pueden configurarse y recibir servicio a través del perímetro de nuestra red sin necesidad de las instalaciones principales, actualmente el número de ellos que falla si la instalación principal no está disponible es excesivo. Necesitamos utilizar los productos de sistemas distribuidos que ponemos a disposición de todos nuestros clientes para todos nuestros servicios, de manera que continúen funcionando en su mayor parte con normalidad incluso si se produce una interrupción de nuestras instalaciones principales.

A las 12:48 UTC, Flexential pudo reiniciar los generadores. El suministro eléctrico se restauró parcialmente en la instalación. A fin de no sobrecargar el sistema, el restablecimiento del suministro eléctrico a un centro de datos se suele realizar gradualmente, reactivando los circuitos uno a uno. Al igual que los interruptores de los circuitos en un domicilio, cada cliente cuenta con interruptores redundantes. Cuando Flexential intentó reactivar los circuitos de Cloudflare, se descubrió que los interruptores fallaban. No sabemos si no funcionaron debido al fallo de conexión a tierra o por alguna otra sobrecarga como resultado del incidente, o bien si estaban ya en mal estado y simplemente esto salió a la luz una vez que se habían desactivado.

Flexential inició el proceso de sustitución de los interruptores que fallaban. Para ello, tuvieron que proveerse de interruptores nuevos, ya que no disponían de un número suficiente para sustituir los defectuosos. Debido a que había más servicios desconectados de los esperados, y a que Flexential no nos podía indicar la hora del restablecimiento de nuestros servicios, a las 13:40 UTC tomamos la decisión de realizar la conmutación a los centros de recuperación tras desastre de Cloudflare ubicados en Europa. Por suerte, solo necesitábamos realizar la conmutación de un pequeño porcentaje del plano de control global de Cloudflare. La mayoría de nuestros servicios continuaron ejecutándose en nuestros sistemas de alta disponibilidad en los dos centros de datos principales activos.

Activamos los primeros servicios del centro de recuperación tras desastre a las 13:43 UTC. Los centros de recuperación tras desastre de Cloudflare proporcionan servicios esenciales del plano de control en caso de un desastre. No permiten nuestros servicios de proceso de registros, pero están diseñados para admitir los otros servicios de nuestro plano de control.

Cuando se activaron allí los servicios, sufrimos un problema de tipo "thundering herd", cuando las llamadas API que habían estado fallando sobrecargaron nuestros servicios. Implementamos límites de velocidad para mantener el volumen de solicitudes bajo control. Durante este periodo, los clientes de la mayoría de nuestros productos habrían observado errores intermitentes al realizar modificaciones mediante nuestro panel de control o nuestra API. A las 17:57 UTC, los servicios que se habían migrado correctamente al centro de recuperación tras desastre se habían estabilizado y la mayoría de los clientes ya no estaban directamente afectados. Sin embargo, algunos sistemas aún necesitaban configuración manual (p. ej., Magic WAN), y algunos otros servicios, en su mayor parte relacionados con el proceso de registros y algunas API personalizadas, no estuvieron disponibles hasta que restauramos PDX-04.

Un pequeño número de productos no se reactivaron adecuadamente en nuestros centros de recuperación tras desastre. Normalmente se trataba de productos más nuevos en los que no habíamos implementado y probado exhaustivamente un procedimiento de recuperación tras desastre, entre ellos, nuestro servicio Stream para la carga de nuevos vídeos y algunos otros servicios. Con el objetivo de restaurar estos servicios, nuestro equipo trabajó en dos vías simultáneas: 1) la nueva implementación de estos servicios en nuestros centros de recuperación tras desastre; y 2) su migración a nuestro clúster de alta disponibilidad.

Flexential sustituyó nuestros interruptores de circuito defectuosos, restauró ambos canales de suministro eléctrico y confirmó el total restablecimiento del suministro a las 22:48 UTC. Todo nuestro equipo se había puesto manos a la obra y había trabajado todo el día en la emergencia, así que decidí que la mayoría de nosotros nos tomáramos un descanso e iniciáramos la migración de vuelta a PDX-04 por la mañana. Esa decisión retardó nuestra completa recuperación, pero creo que redujo la posibilidad de que agraváramos esta situación con errores adicionales.

A primera hora del 3 de noviembre, nuestro equipo inició la restauración del servicio en PDX-04. Empezamos arrancando físicamente nuestros equipos de red. A continuación, activamos los miles de servidores y restauramos sus servicios. Ignorábamos el estado de nuestros servicios en el centro de datos, ya que creíamos que era probable que durante el incidente se hubieran producido varios ciclos de apagado y encendido. El único proceso que garantizaba una recuperación segura era realizar un arranque completo de toda la instalación.

Esto implicaba un proceso manual de conexión de nuestros servidores de gestión de configuración para empezar la restauración de la instalación. Este restablecimiento llevó 3 horas. A partir de ahí, nuestro equipo pudo arrancar el restablecimiento de los demás servidores en los que se basan nuestros servicios. El restablecimiento de cada uno de ellos llevó entre 10 minutos y 2 horas. Aunque pudimos ejecutar este proceso en paralelo en varios servidores, para algunos de ellos algunas dependencias inherentes entre los servicios hacían necesaria la conexión secuencial.

Los servicios se restauraron por completo el 4 de noviembre a las 04:25 UTC. La mayoría de los clientes, puesto que también almacenamos datos de análisis en nuestros centros de datos principales en Europa, no deberían observar ninguna pérdida de datos en la mayoría de los análisis en nuestro panel de control y nuestras API. No obstante, algunos conjuntos de datos que no se replican en la UE tendrán lagunas permanentes. Para aquellos clientes que utilizan nuestra función de envío de registros, los registros no se habrán procesado durante la mayor parte del suceso, así que lo que no se haya recibido no se recuperará.

Tenemos una serie de preguntas a las que necesitamos que Flexential nos dé respuesta. Pero también debemos asumir la posibilidad de que los centros de datos fallen en su totalidad. Google tiene un proceso para cuando hay un suceso o crisis importante, denominado Código Amarillo o Código Rojo. En estos casos, la mayoría o todos los recursos de ingeniería pasan a abordar el problema en cuestión.

Nosotros no habíamos contado con un proceso similar en el pasado, pero hoy es evidente que necesitamos implementar nuestra propia versión de este proceso: el Código Naranja. Dedicaremos todas las funciones de ingeniería no esenciales a centrarse en garantizar la alta disponibilidad de nuestro plano de control. Como parte de este proceso, esperamos los cambios siguientes:

• Eliminar las dependencias de nuestros centros de datos principales para la configuración del plano de control de todos los servicios y migrarlos, siempre que sea posible, para que reciban suministro primero de nuestra red distribuida

• Garantizar que el plano de control que se ejecuta en la red continúa funcionando incluso si todos nuestros centros de control principales están desconectados

• Requerir que todos los productos y todas las funciones con disponibilidad general dependan del clúster de alta disponibilidad (si dependen de cualquiera de nuestros centros de datos principales), sin tener dependencias de software de instalaciones específicas

• Requerir que todos los productos y todas las funciones con disponibilidad general tengan un plan de recuperación tras desastre fiable probado

• Probar el radio de alcance de los fallos del sistema y minimizar el número de servicios afectados por un fallo

• Implementar pruebas de caos más rigurosas de todas las funciones de los centros de datos, incluida la completa eliminación de cada una de las instalaciones de nuestros centros de datos principales

• Una auditoría exhaustiva de todos los centros de datos principales y un plan para una nueva auditoría a fin de garantizar que cumplen con nuestros estándares

• Un plan de recuperación tras desastre de los servicios de registro y de análisis que garantice que no se pierde ningún registro, incluso en el caso de un fallo de todas nuestras instalaciones principales

Como he dicho anteriormente, lamento y me avergüenza este incidente y las dificultades que ha causado a nuestros clientes y a nuestro equipo. Disponemos de los sistemas y los procedimientos adecuados para poder hacer frente incluso a la sucesión de fallos que observamos en nuestro proveedor de centro de datos, pero debemos ser más rigurosos acerca de su aplicación a fin de garantizar su seguimiento y la comprobación de dependencias desconocidas. Este tema tendrá plenamente mi atención y la de una gran parte de nuestro equipo durante el balance final del año. Las dificultades de los dos últimos días nos harán mejores.

Extracto: El jueves 2 de noviembre de 2023, a partir de las 11:43 UTC, los servicios de análisis y del plano de control de Cloudflare sufrieron una interrupción. Estos son los detalles.