Como recriar uma AMI de trabalho a partir do instantâneo de recuperação após a interrupção em 8 de agosto?

11

Após a interrupção da Amazon em 8 de agosto , todas as AMIs (baseadas no EBS) deixaram de funcionar para muitos usuários . Isso ocorre devido à corrupção de alguns setores nos snapshots nos quais as AMIs se baseiam.

No entanto, a Amazon criou instantâneos de recuperação nos quais os problemas de disco deveriam ser corrigidos. Esses são nomeados de acordo com as linhas de "Instantâneo de recuperação para vol-xxxxxxxx".

Criei uma nova AMI a partir do instantâneo de recuperação que funcionou bem, mas as instâncias iniciadas a partir dessa nova AMI não funcionam: o estado delas é "Em execução", mas não posso fazer ssh na máquina nem acessar nenhum dos serviços da Web que deveriam estar em execução nela. Tudo se resume a isso (no System Log, acessível através do console de gerenciamento da 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)

Montei um volume criado a partir desse instantâneo de recuperação em outro servidor na AWS, e tudo parece bastante normal. Por exemplo, o fsck diz:

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

Em uma das discussões do fórum da AWS, encontrei este conselho de alguém com problemas semelhantes:

Uma solução alternativa será criar um volume a partir do snapshot e anexá-lo a uma instância em execução, use fsck --force para forçar a verificação do sistema de arquivos e, uma vez limpo, você poderá fazer um snapshot e usá-lo para a AMI.

Mas não sei como forçar o fsck no Ubuntu (11.04):

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

Alguém sabe como forçar a verificação do sistema de arquivos no volume no Ubuntu? Alguma outra idéia de como iniciar instâncias de trabalho baseadas no instantâneo de recuperação?

No momento, parece que pode ser mais rápido começar de novo a partir de uma AMI limpa do Ubuntu e redefinir todos os nossos serviços. :-( Mas é claro que eu preferiria não fazer isso se houver alguma maneira de fazer com que o instantâneo de recuperação funcione.

— Jonik
fonte

14

Encontrei o mesmo problema ao tentar duplicar uma máquina.

O problema acabou sendo o kernel. Tanto na criação da AMI quanto na instância, selecionei o padrão para a imagem do kernel.

Para resolver o problema, recriei a AMI usando a mesma imagem do kernel que a instância original.

— DCYorke
fonte

Para esclarecer, a imagem padrão do kernel carece de suporte ao ext4, mas o kernel usado para criar a AMI sempre deve ser usado de qualquer maneira.

— precisa saber é o seguinte

Se apenas o instantâneo permanecer, será muito difícil recuperar. Você pode sugerir um método para fazer backup desse tipo de metadados (também, quais grupos de segurança e dados do usuário são usados) com o instantâneo ou em outro lugar?

— Martijn Heemels

2

Você pode tentar o seguinte comando (note -f option em vez de --force): sudo fsck -f /dev/xvdg

Espero que isto ajude. Fred

— fred
fonte

fsck -fde fato faz algo mais (não sabe exatamente o que; man fscknão diz nada sobre isso), então +1. Mas, de qualquer forma, isso não resolve todo o problema; Criei uma captura instantânea e, em seguida, uma AMI do volume fscked e lancei uma instância a partir disso, e ainda recebo o mesmo erro "Kernel panic ... Unable to mount root" no Log do sistema.

— Jonik

0

Como não queria perder mais tempo lutando com problemas estranhos específicos da AWS, criei uma nova instância limpa de uma das AMIs oficiais do Ubuntu (no meu caso, ami-359ea941que é uma imagem do Ubuntu 11.04 suportada pelo EBS de 32 bits no eu-west-1 region) e recriou minha configuração de servidor lá.

O fato de eu poder montar um volume criado a partir do instantâneo de recuperação na nova instância tornou a redefinição muito mais rápida. Por exemplo, fiz algo como cp -a /mnt/recovery/usr/local /usrrestaurar muitas coisas abaixo /usr/local.

Portanto, no meu caso, os backups de recuperação estavam longe de serem inúteis, pois eu podia acessar os dados neles. Mas é claro que ainda seria melhor criar uma AMI a partir do instantâneo e continuar usando (instâncias de) que, como todo o incidente, nunca aconteceram. (Adicione uma resposta se souber como conseguir isso!)

— Jonik
fonte