¡Hola, DreamHosters!
Recientemente, DreamObjects sufrió una interrupción prolongada. El servicio estuvo en gran medida inaccesible durante un período de aproximadamente seis horas el viernes 13 de junio y nuevamente durante un segundo período de aproximadamente cuatro horas el sábado 14 de junio. Queríamos ofrecerte una visión sobre el qué y el porqué de la interrupción.
Primero, para contextualizar, vamos a discutir cómo funciona DreamObjects. DreamObjects existe como un clúster de servidores, donde cada servidor tiene varios discos duros. La mayoría de los servidores en el clúster ejecutan un software llamado Ceph, que es un sistema de almacenamiento distribuido y tolerante a fallos.
Un sistema de almacenamiento distribuido es aquel que almacena datos en múltiples unidades, y frecuentemente esas unidades están distribuidas en múltiples servidores. Un sistema de almacenamiento tolerante a fallos es aquel que puede manejar la pérdida de una o más unidades, o incluso servidores enteros o bastidores de servidores, sin perder datos. Ceph (y por lo tanto DreamObjects) es tanto distribuido como tolerante a fallos. En resumen, cualquier cosa que nos envíes se escribe en tres unidades para proteger la integridad y durabilidad de tus datos.
Eso no quiere decir que cada máquina en el clúster tenga la tarea de almacenar tus datos. Algunas – las puertas de enlace – son las máquinas con las que realmente te comunicas a través de las APIs HTTP de S3 o Swift. Estas puertas de enlace luego emiten solicitudes en tu nombre a las máquinas que realmente almacenan los datos.
Y eso nos lleva a la causa raíz del corte: en resumen, las puertas de enlace no podían comunicarse con los servidores de almacenamiento backend, y por lo tanto el servicio parecía estar “inactivo” a pesar de que el sistema de almacenamiento subyacente estaba activamente trabajando; ocupado asegurando que tus datos estuvieran seguros.
El viernes, se realizó un cambio en el “CRUSH map”, que indica a Ceph cómo se debe dividir los datos entre los servidores y discos que componen DreamObjects. Estos cambios eran necesarios, pero no deberían haberse realizado todos a la vez. Esto resultó en tanto movimiento de datos dentro del backend del clúster que las solicitudes desde las puertas de enlace no pudieron ser atendidas de manera oportuna. Para la seguridad de los datos, que es la primera tarea de cualquier sistema de almacenamiento, Ceph da prioridad al movimiento interno de datos sobre las solicitudes de las puertas de enlace. Nuestros ingenieros efectivamente, y bastante inadvertidamente, crearon un ataque de denegación de servicio interno contra DreamObjects. El cambio en el mapa se realizó como resultado de un problema urgente con el propio clúster de Ceph. Este cambio, sin embargo, se realizó con prisa y debería haberse implementado más lentamente durante una ventana de mantenimiento preprogramada (y anunciada).
El apagón del viernes empeoró debido a un error en la versión de Ceph que estábamos utilizando en ese momento. Este error hacía que los discos individuales se volvieran inaccesibles de manera repetida y eso aumentó drásticamente el tiempo de recuperación desde el cambio de mapa. Aproximadamente a mitad del apagón decidimos actualizar Ceph. Eso es lo que finalmente permitió que el clúster volviera a la normalidad mucho más rápido de lo que normalmente podría haber sido.
El sábado, otro error fue descubierto por el estrés de la continua recuperación del clúster y eso también nos causó perder acceso a unidades individuales repetidamente. Nuestros amigos en Inktank amablemente desarrollaron una compilación personalizada de Ceph para nosotros para solucionar el problema.
En resumen, la interrupción de DreamObjects fue el resultado de un cambio excesivamente agresivo en nuestra configuración de Ceph y luego se agravó por errores latentes dentro de Ceph. Al final, pudimos resolver rápidamente todos los problemas con la ayuda de Inktank y el propio Ceph se fortaleció gracias a nuestros hallazgos. También es importante señalar que el sistema de almacenamiento subyacente funcionó como estaba diseñado, asegurando que los datos de los clientes estuvieran seguros y nunca en riesgo.
Estamos absolutamente comprometidos a asegurar la alta calidad y disponibilidad de todos nuestros servicios. El equipo de DreamObjects ha identificado una serie de cambios en nuestro código, procesos y procedimientos para asegurar que este tipo de interrupción no vuelva a suceder. Específicamente, los ingenieros de operaciones auditarán los cambios en el “CRUSH map” a través de un proceso de revisión más riguroso, incluyendo una revisión externa por Inktank, los creadores de Ceph. Además, cambios de esta escala serán anunciados con suficiente antelación y realizados en horarios fuera de pico para limitar el riesgo.
Una última cosa.
Todos los clientes de DreamObjects recibirán un 10% de descuento en su factura del mes de junio de 2014.
Muchos agradecimientos se deben a nuestros colegas de DreamHost en Operaciones del Centro de Datos, Soporte Técnico y Operaciones en la Nube; y a las grandes personas de Inktank, por trabajar incansablemente para restaurar la disponibilidad y proteger los datos de los clientes.
