Processo correto para iniciar a nova Instância do EC2 a partir de uma captura instantânea do EBS

Question

Eu tenho uma instância do EC2 executando o Ubuntu 12.04 32bit AMI (disponível na primeira página do assistente Classic para iniciar uma nova instância). O dispositivo raiz é um volume do EBS. Depois, sigo estes passos:

• Pare o servidor
• Clique com o botão direito no volume na guia Volumes - > Criar instantâneo
• Clique com o botão direito no instantâneo na guia "Instantâneos" - > Criar imagem deste instantâneo
• Na guia AMI, clico com o botão direito do mouse na AMI recém-criada e selecione "Iniciar instância"

Durante a terceira etapa do assistente, percebo essa linha para "Configuração do dispositivo de armazenamento"

Root    /dev/sda1   snap-xxxxxx 8GiB    standard    true

Isto parece indicar para mim que está usando o instantâneo como o volume raiz para a nova instância (é, na verdade, o único volume).

Eu inicio a instância. No entanto, ele falha nas "verificações de status" durante a etapa de "inicialização". Se eu clicar com o botão direito na instância e "Get System Log", esta é a cauda do log:

Using IPI No-Shortcut mode
XENBUS: Timeout connecting to devices!
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.

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)

O que estou fazendo de errado aqui? Minha preocupação é dobrar:

• Se eu não conseguir inicializar a partir de um instantâneo, isso tornará o utilitário de instantâneo muito menos útil
• Se não for possível criar uma AMI a partir de um instantâneo para criar uma nova instância, isso não apenas reduz a utilidade dos instantâneos, mas nos faz pensar como posso "duplicar" instâncias facilmente.

Answer 1

Os erros que você obteve sugerem que seu sistema de arquivos é mais recente que o suportado pelo kernel (provavelmente um ext4 em um kernel que suporta apenas ext2 / 3). Algumas AMIs dependem de uma AKI não padrão (Amazon Kernel Image) para fornecer certos recursos.

Neste caso, o procedimento que você seguiu parece correto, portanto, quando combinado com o erro recebido, há uma boa chance de que as AKIs não coincidam. Verifique o AKI usado pela instância original e compare-o com o da nova instância. Se eles não corresponderem, especifique explicitamente o AKI no momento do lançamento. (Você também pode criar manualmente a AMI e, ao fazer isso, especificar a AKI naquele momento, para que seja necessário especificá-la na inicialização).

Como um aparte, um projeto de AMI melhor usará o PV-GRUB como um bootloader para carregar um kernel da própria AMI (ao invés de requerer uma AKI externa específica), o que simplifica o processo de manter o kernel atualizado. A documentação da AWS nos kernels fornecidos pelo usuário vale a pena ser lida se você quiser implementar isso em sua AMI.

    

Answer 2

Como você mencionou especificamente o Ubuntu, esta ferramenta pode ser útil para você:

• link

Eu tive a mesma coisa, e escolher a AKI correta para a versão do SO e arquitetura usando a ferramenta acima funcionou como um encanto.

    

Answer 3

Me deparei com um problema semelhante, e os padrões do AWS EC2 diferem para iniciar a instância vs. criar uma AMI: a virtualização de hardware (HVM) é a opção padrão no primeiro caso, mas paravirtual (PV) é o padrão para a imagem criação.

Eu tropecei nisso quando tentei mover a instância EC2 entre as zonas de disponibilidade, capturando instantaneamente o volume do EBS e criando uma nova AMI, e essa discrepância nas configurações (que eu não prestei atenção também) desperdiçou uma hora para mim.

Então, tl; dr: escolha HVM ao iniciar de uma AMI personalizada e sua instância deve inicializar bem.