Dropbox: Desconectamos un centro de datos para probar nuestra preparación ante desastres. Así es como fue

El servicio de almacenamiento de archivos en la nube, Dropbox, ha explicado cómo desconectó por completo su centro de datos clave para probar sus capacidades de preparación ante desastres.

Como explica Dropbox, después de migrar su infraestructura informática de Amazon Web Services en 2015 y luego lanzar su sistema de almacenamiento de contenido de archivos Magic Pocket, la empresa se volvió «altamente centralizada» en su centro de datos de San José (SJC), ubicado no muy lejos de San Andreas Falla.

Dada la criticidad del centro de datos de San José, Dropbox quería saber qué pasaría con la disponibilidad global si esa región o «metro» se cayera, por lo que la empresa trabajó con el objetivo, en noviembre del año pasado, de probar su resiliencia físicamente desconectando la red de fibra de sus centros de datos SJC.

MarketingyPublicidad.es recomienda

Los mejores servicios de almacenamiento en la nube

Los mejores servicios de almacenamiento en la nube

Los servicios de almacenamiento en la nube personales y para pequeñas empresas gratuitos y económicos están en todas partes. Pero, ¿cuál es mejor para ti? Veamos las principales opciones de almacenamiento en la nube.

«En un mundo donde los desastres naturales son cada vez más frecuentes, es importante que consideremos el impacto potencial de tales eventos en nuestros centros de datos», explicó el equipo que dirigió el proyecto en una publicación de blog detallada.

VER: ¿Qué es la computación en la nube? Todo lo que necesitas saber sobre la nube explicado

La empresa almacena contenido de archivos y metadatos sobre archivos y usuarios. Magic Pocket divide los archivos de contenido en bloques y los replica en su infraestructura en diferentes regiones. El sistema está diseñado para servir datos en bloque independientemente de diferentes centros de datos simultáneamente en caso de que un centro de datos se caiga, lo que lo convierte en un sistema denominado «activo-activo».

Dropbox buscaba la misma arquitectura activo-activo para su pila de metadatos. Pero en aquel entonces, su principal base de datos MySQL para metadatos estaba en el SJC y no había probado correctamente su capacidad de conmutación por error o activo-pasivo. Quería probar cómo su base de datos en SJC conmutaría por error a una base de datos MySQL replicada en su centro de datos pasivo en Idaho. Una prueba de conmutación por error en 2015 fue exitosa, pero sus ingenieros se dieron cuenta de que la arquitectura activa-activa para metadatos sería más difícil que para el almacenamiento en bloque.

Los ingenieros de la empresa se decidieron por el modo activo-pasivo para los metadatos y en 2019 comenzaron a ejecutar muchas pruebas de conmutación por error.

Pero luego, en mayo de 2020, una «falla crítica» en las herramientas de conmutación por error de Dropbox «causó una interrupción importante, lo que nos costó 47 minutos de tiempo de inactividad». La empresa inició una auditoría de emergencia de sus herramientas y procesos de conmutación por error, y creó un equipo dedicado de recuperación ante desastres de siete personas cuyo objetivo era reducir el objetivo de tiempo de recuperación (RTO) para fines de 2021.

«Nos dimos cuenta de que la mejor manera de asegurarnos de no depender del metro activo era realizar una prueba de recuperación ante desastres en la que desconectamos físicamente SJC del resto de la red de Dropbox», explica la empresa.

«Si desconectar SJC demostró tener un impacto mínimo en nuestras operaciones, esto demostraría que, en caso de un desastre que afecte a SJC, Dropbox podría estar funcionando normalmente en cuestión de horas. Llamamos a este proyecto el agujero negro de SJC».

Después de asegurarse de que los servicios críticos que se ejecutan en SJC fueran multi-homed (que se ejecutan desde otro área metropolitana que no sea SJC), el equipo decidió cómo simularían la pérdida total de SJC.

Inicialmente, Dropbox planeó aislar SJC de la red drenando los enrutadores de la red metropolitana, pero optó por la medida más drástica de desconectar la fibra de la red.

«Si bien esto habría hecho el trabajo, finalmente llegamos a un enfoque físico que sentimos que simulaba mejor un escenario de desastre real: ¡desconectar la fibra de la red!»

Realizó dos pruebas a través de dos centros de datos en su área metropolitana de Dallas Forth Worth (DFW) (DFW4 y DFW5), pero la primera prueba que desconectó DFW4 se consideró un fracaso porque afectó la disponibilidad global y la prueba finalizó antes de tiempo. Dropbox asumió incorrectamente que DFW4 y DFW5 eran más o menos equivalentes y no tuvo en cuenta las dependencias entre instalaciones.

VER: La computación en la nube es la clave del éxito empresarial. Pero desbloquear sus beneficios es un trabajo duro.

Unas semanas más tarde, los ingenieros realizaron una nueva prueba que bloquearía todo el metro de DFW. Los ingenieros de cada una de las dos instalaciones desconectaron la fibra a pedido.

Dropbox no observó ningún impacto en la disponibilidad y mantuvo el agujero negro durante los 30 minutos completos y se consideró un éxito.

A las 5 p. m. (hora del Pacífico) del jueves 18 de noviembre de 2021, Dropbox finalmente realizó la prueba principal en su SJC, donde los ingenieros desconectaron uno por uno cada uno de los tres centros de datos del metro. Dropbox superó el umbral del agujero negro de 30 minutos sin observar un impacto en la disponibilidad global, aunque algunos servicios internos se vieron afectados.

«Sí, lo sabemos, esto probablemente suene un poco anticlimático. ¡Pero ese es exactamente el punto! Nuestro enfoque orientado a los detalles para preparar este evento es la razón por la cual el gran día transcurrió sin problemas», explicó la compañía.

Todavía no es una arquitectura activa-activa, pero Dropbox dice que confía en que, sin SJC, Dropbox en su conjunto aún podría sobrevivir a una interrupción importante en ese metro, señalando que el enfoque demostró que «ahora tenía a las personas y los procesos en lugar para ofrecer un RTO significativamente reducido, y que Dropbox podría ejecutarse indefinidamente desde otra región sin problemas. Y lo más importante, nuestro ejercicio de agujero negro demostró que, sin SJC, Dropbox aún podría sobrevivir».

Deja un comentario