El 8 de marzo, Datadog sufrió una interrupción grave que hizo que su servicio de observabilidad prestado en modo SaaS no estuviera disponible durante aproximadamente 24 horas. El incidente le costó a la editorial cinco millones de dólares, es decir, el volumen de negocios de aproximadamente un día para la empresa fundada en 2010 por dos residentes del centro, Olivier Pomel y Alexis Lê-Quôc. Queda por ver cómo pudo haber ocurrido lo que hoy sigue siendo la única interrupción global del servicio, mientras Datadog se basa en una arquitectura multinube masiva (el servicio se ejecuta en cinco regiones alojadas por los tres principales hiperescaladores, AWS, GCP y Azure). . ). Esto es lo que el boletín intenta descifrar El ingeniero pragmático en su última edición, seguida unas horas más tarde por un publicación de blog publicado en el sitio web de la editorial por su cofundador, Alexis Lê-Quôc.
La interrupción se originó en la aplicación de una actualización del sistema aplicada a Ubuntu, un sistema operativo instalado en decenas de miles de nodos de Kubernetes. Máquinas que desaparecen misteriosamente de la red una vez aplicado el parche. Media hora después del inicio de esta actualización, el 8 de marzo, la interrupción se hizo oficial en el sitio de soporte del editor. Los servicios se restablecerán al día siguiente, casi 27 horas después, aunque no estará operativo todo el servicio hasta el día siguiente, casi 48 horas después de que comenzara el incidente.
Una arquitectura con una dependencia circular
En detalle, el despliegue de la última versión de Ubuntu da lugar a una actualización de seguridad de systemd, el primer proceso que se inicia tras cargar el kernel de Linux. Pero, según el análisis de The Pragmatic Engineer, el fallo no tiene su origen en la naturaleza de los parches, sino en su aplicación automática, que implica un reinicio de Linux, el proceso systemd y todos sus subprocesos, incluido el de gestión de la red. . La aplicación automática de la actualización de seguridad de systemd "provocó una interacción negativa con la pila de red", reconoce Alexis Lê-Quôc en su blog, reiniciando el proceso systemd-networkd que provocó la eliminación de las rutas de red gestionadas por una CNI (Container Network Interface). Complemento de Cilium, utilizado por Datadog para gestionar las comunicaciones entre contenedores. Es este borrado el que provocó mecánicamente que los nodos se desconectaran. Un mecanismo que Datadog claramente tuvo dificultades para caracterizar. “El factor agravante es que ni un nodo nuevo ni uno reiniciado muestran este comportamiento porque, durante una secuencia de inicio normal, systemd-networkd siempre se inicia antes de que el complemento CNI instale las reglas de enrutamiento. En otras palabras, aparte del escenario de actualización de systemd-networkd en un nodo en funcionamiento, ninguna prueba reprodujo la secuencia exacta”, escribe el cofundador de la editorial para justificar la duración de la interrupción.
Este problema inicial provocó luego una reacción en cadena. "En una forma de dependencia circular, el reinicio también dejó fuera de línea el plano de control de enrutamiento de la red", escribe The Pragmatic Engineer. Simplemente porque entre los entornos virtuales desconectados por el error se encontraban los que gestionaban el Control Plane, basado en Cilium. "Por lo tanto, la mayoría de los clústeres de Kubernetes que utilizamos para ejecutar nuestra plataforma no pudieron generar nuevas cargas de trabajo, repararlas automáticamente y escalarlas automáticamente", reconoce Datadog en su análisis post mortem. Otro factor que explica la duración de la interrupción del servicio que sufrieron los clientes de la editorial. “Si el avión de control no se hubiera visto afectado, la interrupción probablemente habría sido breve. En este caso, Datadog podría simplemente volver a ensamblar los nodos faltantes utilizando el plano de control”, escribe The Pragmatic Engineer.
Las fallas del plan de resiliencia
Queda una pregunta clave: ¿por qué esta interrupción se extendió a toda la infraestructura cuando Datadog está tomando medidas relevantes en términos de resiliencia? En particular una política de aplicación progresiva de parches, “región por región, clúster por clúster y nodo por nodo”, y el uso de varios proveedores de nube (los tres principales en este caso). Para el boletín especializado, esta rápida propagación se debe a la elección del editor de utilizar sus proveedores de nube como capa IaaS y utilizar la misma imagen del sistema operativo en todos estos entornos. Una imagen que contiene "un canal de actualización de seguridad heredado, que provocaba la aplicación automática de parches", según el análisis post mortem del editor. Un detalle que acabó haciendo ineficaces las precauciones tomadas por Datadog, ya que la actualización que provocó el colapso de la arquitectura de Kubernetes se implementó en todas las máquinas virtuales en menos de una hora, a pesar de la ausencia de un enlace de red directo entre las regiones de la nube. Curiosamente, la elección de confiar en varios hiperescaladores complicó bastante el reinicio de Datadog, que tuvo que gestionar las diferentes lógicas de los proveedores (en particular en la gestión de los nodos afectados por el fallo).
En la publicación de su blog, el cofundador de la editorial detalla las medidas que se tomaron para evitar que un incidente similar vuelva a ocurrir. Empezando, obviamente, por desactivar el canal de actualización automática en la imagen de Ubuntu. Datadog también cambió la configuración de systemd-networkd para no restablecer la tabla de enrutamiento al reiniciar. “Construimos regiones de Datadog con el objetivo explícito de ser autosostenibles y resilientes a las fallas locales. [...] Sin embargo, no hemos logrado imaginar cómo estos servicios podrían permanecer indirectamente vinculados, y esta brecha influirá en la forma en que sigamos fortaleciendo nuestra infraestructura”, reconoce Alexis Lê-Quôc.
Otras noticias que te pueden interesar