Lecciones que se pueden extraer de la caída de Amazon

La informática tiene la peculiaridad de ser una ingeniería en la cual un técnico puede darle una justificación completamente convincente a otro explicando porqué ha sucedido algo que es en realidad totalmente falsa. Probablemente nunca sabremos con exactitud lo que provocó la caída de la zona este de Estados Unidos de Amazon durante casi 24 horas.

Justin Santa Barbara dice que fue debido a que Amazon no siguió sus propias especificaciones dando a entender claramente que la causa última de la caída fue que algún zote hizo negligentemente algo que no debía.

La explicación oficial es que falló una conexión de red, lo cual provocó que se activase un proceso de mirroring en los volúmenes de Elastic Block Store (EBS). Dicho proceso empezó a generar copias sin control de los volúmenes hasta que se agotó el espacio físico en disco y se fue todo a Alpedrete, incluído el propio panel de control de Amazon. Para solucionar el problema tuvieron que añadir más discos físicos de manera que algunos procesos pudieran completarse y se restaurase la operatividad del panel de control.

Para entender el suceso, es preciso conocer un poco acerca de la arquitectura redundante de alta disponibildiad de Amazon. El servicio EC2 está dividido en cinco regiones: EE.UU. Este, EE.UU. Oeste, Europa (Irlanda), Asia (Japón) y Asia (Singapur). Cada región es esencialmente un servicio diferente e independiente de las otras, se pueden comunicar entre ellas, pero la velocidad no es muy buena y además Amazon cobra por el ancho de banda consumido. Dentro de cada región existen diferentes zonas de disponibilidad. Las zonas de disponibilidad están comunicadas por líneas de alta velocidad y no comparten puntos únicos de fallo tales como el suministro eléctrico. Un arreglo típico de alta disponibilidad sobre Amazon suele ser colocar sistemas redundantes en zonas diferentes de la misma región. Por otra parte, las granjas de máquinas virtuales pueden compartir ficheros montando volúmenes EBS compartidos de los cuales Amazon hace mirroring automáticamente. Fue un fallo en este proceso de copia de los volúmenes EBS lo que causó el desastre.

De lo anterior, creo que se pueden extraer las siguientes lecciones:

1ª) Para garantizar la alta disponibilidad, no basta con que la infraestructura de hardware sea redundante. Debe de serlo asimismo el software. Si tienes 100 máquinas y el mismo sistema operativo en todas ellas y dicho sistema operativo falla, existe una alta probabilidad de que se caigan todas las máquinas simultáneamente.

2ª) Hay que verificar el buen funcionamiento de los mecanismos de recuperación de desastres. El peor día para enterarse que los backups no están funcionando correctamente es aquel en el que ha fallado un disco y se descubre que en lugar de copias de respaldo lo que se tiene es un armario lleno de cintas vacías.

3ª) Hay que seguir escrupulosamente los procedimientos operativos. Sin lugar a dudas, la primera causa de fallos de servicio en los que he estado involucrado ha sido porque de alguna manera en el equipo nos habíamos saltado algún paso del procedimiento estándar, bien durante el desarrollo, las pruebas o la operación del sistema.

4ª) Digan lo que digan mediante una terminología eufemística diseñada para atribuir los fallos a las máquinas, la culpa siempre es del informático.

Post relacionado: Diseñar y administrar un sistema requiere mucho de sentido común, aunque no lo creas (Ricardo Galli)

Compartir:
  • Twitter
  • Meneame
  • Facebook
  • Google Buzz
Esta entrada fue publicada en Casos Prácticos, Computación en la Nube. Guarda el enlace permanente.

Una respuesta a Lecciones que se pueden extraer de la caída de Amazon

  1. Pingback: Lecciones que se pueden extraer de la caída de Amazon « Conocimiento Libre (o lo que está detrás del Software Libre)

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *