El motivo de la caída de las aplicaciones de Facebook se debió por el sistema que administra la capacidad de su red troncal global, que es la columna vertebral que Facebook ha construido para conectar todas sus instalaciones informáticas, que consta de decenas de miles de millas de cables de fibra óptica que cruzan el mundo y conectan todos sus centros de datos, informó Santosh Janardhan, vicepresidente de Infraestructura de Facebook, a través del blog de ingeniería de la compañía.
Janardhan también destacó que dicha interrupción no fue causada por una actividad maliciosa, sino por un error de su propia creación.
Durante uno de los trabajos de mantenimiento de rutina, se emitió un comando con la intención de evaluar la disponibilidad de la capacidad de la red troncal global, que accidentalmente cortó todas las conexiones en su red troncal, desconectando los centros de datos de Facebook a nivel mundial.
Este cambio provocó una desconexión completa de las conexiones de servidor entre sus centros de datos e Internet, lo que ocasionó que sus servidores de DNS se volvieran inalcanzables a pesar de que todavía estaban operativos, lo que hizo imposible que el resto de Internet encontrara sus servidores.
Para solucionar la falla, los ingenieros tuvieron que ir a los centros de datos para que depurarán el problema y reiniciarán el sistema. Aunque no fue fácil, indicó el ejecutivo, ya que sus instalaciones están diseñadas con altos niveles de seguridad física y del sistema en mente, para que sea difícil de modificar incluso cuando se tiene acceso físico a ellos.
Todo esto ocasionó que tomara más tiempo activar sus protocolos de acceso seguro necesario para que sea seguro trabajar en los servidores.
Cuando se restauró la conectividad de nuestra red troncal en las regiones de nuestro centro de datos, todo volvió a funcionar. No obstante, no se podía activar sus servicios de forma directa ya que al revertir repentinamente tal caída en el consumo de energía podría poner en riesgo todo, desde sistemas eléctricos hasta cachés.
Por Santosh Janardhan explicó que gracias a su experiencia por simulacros de «storm» que realizan durante mucho tiempo pudieron volver las cosas en línea y administrar de forma cuidados las cargas crecientes.
Finalmente pudieron recuperar relativamente todo de forma muy rápia sin más fallas en todo el sistema.
«De ahora en adelante, nuestro trabajo es fortalecer nuestras pruebas, simulacros y resistencia general para asegurarnos de que eventos como este sucedan lo menos posible«, concluyó en su comunicado.
Te dejamos el comunicado completo de Facebook
Más detalles sobre la interrupción del 4 de octubre
Por
Santosh Janardhan
Ahora que nuestras plataformas están funcionando como de costumbre después de la interrupción de ayer, pensé que valdría la pena compartir un poco más de detalles sobre lo que sucedió y por qué, y lo más importante, cómo estamos aprendiendo de ello.
Esta interrupción fue provocada por el sistema que administra la capacidad de nuestra red troncal global. La columna vertebral es la red que Facebook ha construido para conectar todas nuestras instalaciones informáticas, que consta de decenas de miles de millas de cables de fibra óptica que cruzan el mundo y conectan todos nuestros centros de datos.
Esos centros de datos vienen en diferentes formas. Algunos son edificios masivos que albergan millones de máquinas que almacenan datos y ejecutan las cargas computacionales pesadas que mantienen nuestras plataformas en funcionamiento, y otros son instalaciones más pequeñas que conectan nuestra red troncal a Internet en general y a las personas que usan nuestras plataformas.
Cuando abre una de nuestras aplicaciones y carga su feed o mensajes, la solicitud de datos de la aplicación viaja desde su dispositivo a la instalación más cercana, que luego se comunica directamente a través de nuestra red troncal a un centro de datos más grande. Ahí es donde se recupera y procesa la información que necesita su aplicación, y se envía de vuelta a través de la red a su teléfono.
El tráfico de datos entre todas estas instalaciones informáticas se gestiona mediante enrutadores, que determinan dónde enviar todos los datos entrantes y salientes.
Y en el extenso trabajo diario de mantener esta infraestructura, nuestros ingenieros a menudo necesitan tomar parte de la red troncal fuera de línea para el mantenimiento, tal vez reparando una línea de fibra, agregando más capacidad o actualizando el software en el enrutador. Esta fue la fuente del apagón de ayer.
Durante uno de estos trabajos de mantenimiento de rutina, se emitió un comando con la intención de evaluar la disponibilidad de la capacidad de la red troncal global, que accidentalmente cortó todas las conexiones en nuestra red troncal, desconectando efectivamente los centros de datos de Facebook a nivel mundial. Nuestros sistemas están diseñados para auditar comandos como estos para evitar errores como este, pero un error en esa herramienta de auditoría no detuvo correctamente el comando.
Este cambio provocó una desconexión completa de nuestras conexiones de servidor entre nuestros centros de datos e Internet. Y esa pérdida total de conexión provocó un segundo problema que empeoró las cosas. Uno de los trabajos que realizan nuestras instalaciones más pequeñas es responder a las consultas de DNS.
DNS es la libreta de direcciones de Internet, lo que permite que los nombres web simples que escribimos en los navegadores se traduzcan a direcciones IP de servidor específicas.
Esas consultas de traducción son respondidas por nuestros servidores de nombres autorizados que ocupan direcciones IP bien conocidas, que a su vez se anuncian al resto de Internet a través de otro protocolo llamado protocolo de puerta de enlace fronteriza (BGP). Para garantizar un funcionamiento confiable, nuestros servidores DNS desactivan esos anuncios de BGP si ellos mismos no pueden hablar con nuestros centros de datos, ya que esto es una indicación de una conexión de red no saludable.
En la interrupción reciente, toda la red troncal se retiró de la operación, lo que hizo que estas ubicaciones se declararan insalubres y retiraran esos anuncios de BGP.
El resultado final fue que nuestros servidores DNS se volvieron inalcanzables a pesar de que todavía estaban operativos. Esto hizo imposible que el resto de Internet encontrara nuestros servidores. Todo esto sucedió muy rápido.
Y mientras nuestros ingenieros trabajaban para averiguar qué estaba sucediendo y por qué, se enfrentaron a dos grandes obstáculos: primero, no era posible acceder a nuestros centros de datos a través de nuestros medios normales porque sus redes estaban caídas, y segundo, la pérdida total de DNS se rompió. muchas de las herramientas internas que normalmente usamos para investigar y resolver interrupciones como esta.
Nuestro acceso a la red principal y fuera de banda no funcionaba, por lo que enviamos ingenieros al sitio a los centros de datos para que depuraran el problema y reiniciaran los sistemas. Pero esto llevó tiempo, porque estas instalaciones están diseñadas con altos niveles de seguridad física y del sistema en mente.
Es difícil acceder a ellos y, una vez que estás dentro, el hardware y los enrutadores están diseñados para ser difíciles de modificar incluso cuando tienes acceso físico a ellos. Por lo tanto, tomó más tiempo activar los protocolos de acceso seguro necesarios para que las personas estén en el sitio y puedan trabajar en los servidores. Solo entonces podríamos confirmar el problema y volver a poner nuestra columna vertebral en línea. Una vez que se restauró la conectividad de nuestra red troncal en las regiones de nuestro centro de datos, todo volvió a funcionar.
Pero el problema no había terminado: sabíamos que volver a activar nuestros servicios de una vez podría causar una nueva ronda de accidentes debido a un aumento en el tráfico. Los centros de datos individuales informaron caídas en el uso de energía en el rango de decenas de megavatios, y revertir repentinamente tal caída en el consumo de energía podría poner en riesgo todo, desde sistemas eléctricos hasta cachés.
Afortunadamente, este es un evento para el que estamos bien preparados gracias a los simulacros de «tormenta» que hemos estado realizando durante mucho tiempo.
En un ejercicio de tormenta, simulamos una falla importante del sistema desconectando un servicio, un centro de datos o una región completa, y probamos toda la infraestructura y el software involucrados.
La experiencia de estos simulacros nos dio la confianza y la experiencia para volver a poner las cosas en línea y administrar cuidadosamente las cargas crecientes. Al final, nuestros servicios se recuperaron relativamente rápido sin más fallas en todo el sistema.
Y aunque nunca antes habíamos corrido una tormenta que simulara que nuestra columna vertebral global se desconectaba, ciertamente buscaremos formas de simular eventos como este en el futuro. Cada fracaso como este es una oportunidad para aprender y mejorar, y hay mucho que aprender de este. Después de cada problema, pequeño o grande, realizamos un extenso proceso de revisión para comprender cómo podemos hacer que nuestros sistemas sean más resistentes. Ese proceso ya está en marcha.
Hemos trabajado mucho para fortalecer nuestros sistemas para evitar el acceso no autorizado, y fue interesante ver cómo ese endurecimiento nos ralentizó mientras intentábamos recuperarnos de una interrupción causada no por una actividad maliciosa, sino por un error de nuestra propia creación.
Creo que una compensación como esta vale la pena: mayor seguridad diaria frente a una recuperación más lenta de un evento tan raro como este. De ahora en adelante, nuestro trabajo es fortalecer nuestras pruebas, simulacros y resistencia general para asegurarnos de que eventos como este sucedan lo menos posible.
