(cc) stars6 / Leonardo Rizzi
Amazon publicó hoy detalles del desastre ocurrido en su red la semana pasada, que causó la caída del servicio de una serie de empresas que dependen de estos servidores en la nube (incluyendo a Betazeta).
La compañía explicó que todo comenzó a mediodía (12:47, horario del Pacífico) del 21 de abril, en la Elastic Block Storage (EBS) de Amazon, que básicamente es el almacenamiento usado por el servicio EC2, que ofrece almacenamiento escalable en servidores en la nube. Amazon explicó que, por una falla humana, se realizó un cambio incorrecto en la configuración de la red, que hizo que el proceso de escalamiento fallara.
El cambio de configuración era para mejorar la capacidad de la red primaria. Durante el cambio, uno de los pasos estándar es mover el tráfico fuera de los routers redundantes en la red primaria EBS para permitir que la actualización ocurra. El cambio del tráfico fue ejecutado incorrectamente, y en lugar de enrutarlo hacia otro router en la red primaria, fue enviado a la red redundante de menor capacidad de EBS.
EBS funciona usando una tecnología peer-to-peer, que mantiene a los datos sincronizados en varios nodos, usando dos redes – una rápida para operaciones normales, y una lenta, que sirve de respaldo cuando la primaria falla. Cada nodo usa la red para crear múltiples copias de los datos usados a medida que se requiera. Cuando uno de los nodos deja de comunicarse con otro en medio de una operación, el primer nodo asume que el segundo falló, y busca otro que esté libre donde pueda replicarse. Esto normalmente pasa tan rápido que los humanos no están involucrados.
Cuando el enrutamiento del tráfico en la red primaria no funcionó correctamente, un grupo de nodos de EBS perdió contacto con sus réplicas. Cuando se restauró la conexión, tantos nodos se habían caído que cuando comenzaron a replicarse de nuevo, el espacio disponible se había acabado. Eso dejó a varios nodos en un círculo vicioso en donde buscaban una y otra vez espacio en otros nodos para crear espejos, cuando no había más espacio. Los requerimientos para crear nuevos nodos en EBS se apilaron, sobrecargando todo lo demás. A las 2:40, Amazon deshabilitó la capacidad de los clientes de crear nuevos volúmenes de datos. Una vez que los nuevos requerimientos dejaron de apilarse, parecía que la situación se había calmado, pero no fue así.
Espejos, más espejos
Los volúmenes de EBS siguieron buscando nodos donde replicarse, causando tensión constante en el sistema. Para las 11:30 am, los técnicos habían encontrado una forma de detener la locura sin afectar la comunicación entre los nodos. Una vez que se aplicó esa solución, un 13% de EBS todavía estaba atascada con requerimientos. Para mediodía, los ingenieros empezaron a buscar espacio para que los volúmenes atascados pudiesen replicarse, algo que no era fácil porque requería que se movieran físicamente servidores y se instalaran al cluster de EBS.
Eso tomó bastante tiempo. Para las 12:30 del 22 de abril, todavía había un 2,2% de EBS que estaba atascado. Con la nueva capacidad instalada, Amazon empezó a trabajar en hacer que los nodos se comunicara normalmente entre sí otra vez. Esto debía hacerse por etapas, y el trabajo se extendió hasta el día siguiente. Para las 18:15 del 23 de abril, las operaciones estaban casi de vuelta a la normalidad (excepto por el 2,2% que todavía estaba atascado). Resultó que esa parte tendría que ser recuperada manualmente. Los datos estaban respaldados en Amazon S3, y para el día siguiente, se había recuperado todo menos un 1,04% de los datos.
Se siguió trabajando, y al final un 0,07% de los datos involucrados no pudieron ser recuperados, dijo Amazon.
Lo que viene
La compañía informó que está auditando su proceso para realizar cambios en su red, que es donde comenzaron los problemas, y que aumentará la automatización del sistema para prevenir errores similares en el futuro. Además, todos los clientes recibirán un crédito de 10 días, independientemente de si sus servicios se vieron afectados o no. Amazon lanzó una larga lista de los cambios que realizará, que van desde aumentar la capacidad disponible para operaciones de recuperación, a hacer más fácil para los clientes acceder a más de una zona de disponibilidad y mejoras a su dashboard de estado.
Y por último, “queremos disculparnos. Sabemos cuán críticos son nuestros servicios para los negocios de nuestros clientes y haremos todo lo que esté en nuestras manos para aprender de este evento y usarlo para impulsar mejoras en nuestros servicios”.
Está claro que este evento tendrá repercusiones en la reputación de Amazon y en la forma de planear el uso de servidores de sus clientes. Al menos sirve para aprender un poco más sobre la nube y sus problemas…
Link: Summary of the Amazon EC2 and Amazon RDS service disruption (Amazon vía All Things D)
