Problemas ao migrar uma instância suportada pelo EBS em regiões da AWS

Question

Observação: também fiz essa pergunta nos fóruns do EC2, mas não recebi nenhum amor por lá. Espero que a comunidade ServerFault seja mais incrível.

A abertura da nova região da AWS em Sydney é algo que estamos esperando há muito tempo, mas estou tendo muitos problemas para migrar nossas instâncias da Califórnia.

Consegui migrar uma instância usando CloudyScripts para mover um instantâneo e, em seguida, disparar uma nova instância no Sydney região. Esta foi uma instância muito nova, então tanto a origem quanto o destino estavam rodando em um servidor Ubuntu 12.04 LTS e eu não tive problemas lá.

No entanto, o resto de nossas instâncias são todas do Ubuntu 10.04 LTS e, com elas, estou tendo muitos problemas.

Eu tentei seguir:

1- Após o whitepaper da AWS sobre as ocorrências de mudança que nos foi dado no recente Dia de Apreciação do Cliente em Sydney, onde a nova região foi lançada.

O problema com esta abordagem foi com o último passo (Passo 19) aqui você registra a imagem: ec2-register -s snap-0f62ec3f -n "Wombat" -d "migrou Wombat" - região ap-sudeste-2 -a x86_64 --kernel aki-937e2ed6 --block-device-mapping "/ dev / sdk = ephemeral0 "

Eu continuo recebendo este erro: Client.InvalidAMIID.NotFound: O ID da AMI 'ami-937e2ed6' não existe, o que eu acho que é devido ao kernel_id não existente na região de Sydney?

2- Usando CloudyScripts para mover um instantâneo e, em seguida, criando um novo volume e anexando a uma nova instância em Sydney

Isso resulta na suspensão apenas da inicialização e na falha das verificações de status. Eu não posso SSH ou olhar para o log do servidor

Suspeito que meu problema é encontrar o kernel_id correto para o volume na nova região. No entanto eu não consigo descobrir como ir sobre como encontrar este kernel_id, os que eu tentei (da instância original) não resultam no Client.InvalidAMIID.NotFound: O ID da AMI 'ami-937e2ed6' erro e qualquer outro kernel_id simplesmente não inicializará.

Eu tentei as versões 12.04 e 10.04 do Ubuntu. Nada parece funcionar, eu tenho batido minha cabeça contra a parede por um tempo agora, por favor, ajude!

Nova instância (quebrada) i-a1acda9b ami-9b8611a1 aki-31990e0b

Instância de origem i-08a6664e ami-b37e2ef6 aki-937e2ed6

p.s. Eu também tentei seguir este guia sobre a atualização da minha versão do Ubuntu LTS para 12.04 antes de fazer a migração, mas também não funcionou, ainda ficando preso na atualização do kernel_id link

    

Answer 1

Quando você especifica uma ID de kernel inexistente, o registrador ec2 informa incorretamente um erro de "Client.InvalidAMIID.NotFound". Este é um bug nas ferramentas da AWS.

Para identificar o ID do Kernel correto, ative uma nova instância de uma AMI na região de destino que corresponda à AMI de origem o mais próximo possível. No seu exemplo, inicie uma instância baseada em um Ubuntu 10.04 LTS AMI. Quando essa instância estiver em execução, você poderá ver qual ID do Kernel e ID do Ramdisk (se houver) foram usados para essa instância. Você pode usar esse mesmo ID do Kernel e ID do Randisk (se houver).

    

Answer 2

Sim, esse é um dos recursos irritantes da AWS: os AMI não são portáveis de região para região. Não são infraestruturas compatíveis, infelizmente.

No entanto, pelo menos uma empresa transformou a migração de instância do EC2 em um serviço. O Ylastic oferece "migração de clique único para AMIs do Linux EBS e instantâneos entre regiões." Usei esse serviço por um breve período no mês passado, quando ajudei um amigo a migrar uma instância de us-east-1 para us-west-2. Tornou-se tão complicado migrar manualmente que decidi experimentar o serviço e funcionou.

O Ylastic automaticamente otimiza as instâncias em seu nome para realizar o trabalho, o que pode demorar um pouco para ser concluído. Eles basicamente dd de seus dados para uma instância temporária na nova região e criam um novo instantâneo para você usar para iniciar instâncias nessa região. Em seguida, ele limpa depois de si, terminando os recursos usados para fazer a transferência.

No entanto, estrategicamente, é melhor automatizar o processo de criação de qualquer configuração de instância necessária em qualquer região. Fazemos isso com os livros de culinária do Chef, para que possamos ter o compatível AMI pronto para uso em qualquer região para nossos aplicativos. O único incômodo é manter o controle de quais AMIs e kernels usar em quais regiões. Mas quando você tiver um conjunto de receitas que funcione em todos os lugares, não precisará se preocupar com a migração de instâncias novamente.