¿Cómo recrear un AMI que funciona a partir de la instantánea de recuperación después de la interrupción del 8 de agosto?

11

Después de la interrupción del servicio de Amazon el 8 de agosto , todas las AMI (basadas en EBS) dejaron de funcionar para muchos usuarios . Esto se debe a la corrupción de algunos sectores en las instantáneas en las que se basan las AMI.

Sin embargo, Amazon creó instantáneas de recuperación donde los problemas del disco deberían ser reparados. Esos se nombran a lo largo de las líneas de "Instantánea de recuperación para vol-xxxxxxxx".

Creé un nuevo AMI a partir de la instantánea de recuperación que funcionó bien, pero las instancias lanzadas desde este nuevo AMI no funcionan: su estado es "En ejecución", pero no puedo ingresar a la máquina ni acceder a ninguno de los servicios web que deberían estar ejecutándose allí. Se reduce a esto (desde System Log, accesible a través de la consola de administración de AWS):

EXT3-fs: sda1: couldn't mount because of unsupported optional features (240).

EXT2-fs: sda1: couldn't mount because of unsupported optional features (244).

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

He montado un volumen creado a partir de esa instantánea de recuperación en otro servidor en AWS, y todo parece bastante normal. Por ejemplo, fsck dice:

$ sudo fsck -a /dev/xvdg
fsck from util-linux-ng 2.17.2
uec-rootfs: clean, 53781/524288 files, 546065/2097152 blocks

En una de las discusiones del foro de AWS, encontré este consejo de alguien con problemas similares:

Una solución alternativa será hacer un volumen a partir de la instantánea y adjuntarlo a una instancia en ejecución, usar fsck --force para forzar la verificación del sistema de archivos y una vez borrado, puede hacer una instantánea y usarla para la AMI.

Pero no sé cómo forzar fsck en Ubuntu (11.04):

$ sudo fsck --force /dev/xvdg
fsck from util-linux-ng 2.17.2
fsck.ext3: invalid option -- 'o'

¿Alguien sabe cómo forzar la verificación del sistema de archivos en el volumen en Ubuntu? ¿Alguna otra idea sobre cómo iniciar instancias de trabajo basadas en la instantánea de recuperación?

En este momento parece que podría ser más rápido comenzar de nuevo desde un AMI de Ubuntu limpio y volver a configurar todos nuestros servicios. :-( Pero, por supuesto, preferiría no hacerlo si hay alguna forma de hacer que la instantánea de recuperación realmente funcione.

— Jonik
fuente

14

Me encontré con el mismo problema al intentar duplicar una máquina.

El problema resultó ser el núcleo. Tanto al crear la AMI como la instancia que seleccioné por defecto para la imagen del núcleo.

Para resolver el problema, recreé el AMI usando la misma imagen del núcleo que la instancia original.

— DCYorke
fuente

Para aclarar, la imagen predeterminada del kernel carece de soporte ext4, pero el kernel que se usó para construir el AMI siempre debe usarse de todos modos.

— DCYorke

Si solo queda la instantánea, será muy difícil recuperarla. ¿Puede sugerir un método para respaldar este tipo de metadatos (también, qué grupos de seguridad y datos de usuario se usan) con la instantánea o en otro lugar?

— Martijn Heemels

2

¿Podría probar el siguiente comando (note la opción -f en lugar de --force): sudo fsck -f /dev/xvdg

Espero que esto ayude. Fred

— Fred
fuente

fsck -fde hecho hace algo más (no sabe exactamente qué; man fsckno dice nada al respecto), entonces +1. Pero en cualquier caso, esto no resuelve todo el problema; Creé una instantánea y luego una AMI desde el volumen fscked, y lancé una instancia a partir de eso, y todavía recibo el mismo error "Kernel panic ... No se puede montar root" en el Registro del sistema.

— Jonik

0

No quería perder más tiempo luchando con problemas extraños específicos de AWS, así que creé una nueva instancia limpia de una de las AMI de Ubuntu oficiales (en mi caso, ami-359ea941que es una imagen de Ubuntu 11.04 respaldada por EBS de 32 bits en el eu-west-1 region), y recreé la configuración de mi servidor allí.

Sin embargo, el hecho de que pudiera montar un volumen creado a partir de la instantánea de recuperación en la nueva instancia hizo que la reconfiguración fuera mucho más rápida. Por ejemplo, hice algo como cp -a /mnt/recovery/usr/local /usrrestaurar muchas cosas debajo /usr/local.

Entonces, en mi caso, las copias de seguridad de recuperación estaban lejos de ser inútiles, ya que podía acceder a los datos que contenían. Pero, por supuesto, habría sido mejor crear un AMI a partir de la instantánea y continuar usando (instancias de) que, como todo el incidente, nunca sucedió. (¡Siéntase libre de agregar una respuesta si sabe cómo lograrlo!)

— Jonik
fuente