Quer mover aplicações legadas que rodam em sistemas operacionais em fim de vida para o Google Cloud? Este post é para você. Vamos explorar as opções para importar máquinas virtuais com SO em EOL para o Google Compute Engine.
A realidade das aplicações legadas em fim de vida
Na DoiT International, atendemos clientes em diferentes estágios da jornada para a nuvem. Alguns já são nativos da nuvem e ainda não acumularam muita dívida técnica; outros mantêm aplicações legadas pelos mais variados motivos. Tem quem tente manter essas aplicações em dia e tem quem acabe no cenário deste artigo: hospedando aplicações legadas e esquecidas em sistemas operacionais em fim de vida (EOL). Se você tem aplicações nessa situação e quer movê-las para o Google Cloud, este artigo é para você. Vamos mostrar as opções disponíveis, para te ajudar a tomar as melhores decisões para os seus workloads.
Este artigo nasceu da observação de alguns clientes avaliando o Google Cloud VMware Engine (GCVE) para rodar aplicações legadas no Google Cloud. Como o GCVE é VMware por baixo dos panos, ele é uma ótima maneira de executar certas VMs, inclusive aquelas com sistemas operacionais em EOL. O problema é que o GCVE não escala bem para baixo em workloads menores e só compensa em custo se você aproveitar os recursos da menor configuração disponível.
O GCVE é, sim, uma opção para rodar aplicações legadas no Google Cloud, mas eu não o recomendaria como primeira escolha, a menos que seus workloads exijam esse tipo de escala. Falaremos mais sobre isso adiante.
Investiguei por que esses clientes estavam concluindo que precisavam do GCVE para rodar aplicações legadas em EOL e encontrei alguns obstáculos:
Primeiro, vi clientes tentando criar novas máquinas virtuais a partir de sistemas operacionais em EOL, como o Centos 6. Logo se descobre que a imagem não aparece mais entre as imagens públicas do Google. Tudo bem, e agora?
O passo seguinte foi tentar usar o recurso de importação do Google Compute Engine, que faz importações ad-hoc de imagens de VM. Era de se esperar que funcionasse com versões antigas de SO, mas, ao tentar importar um SO em EOL — Centos 6, neste exemplo —, recebi a má notícia:
$ gcloud compute instances import centos-6 --source-uri=gs://eol-migration1322/centos6 --zone=us-central1-a
WARNING: Importing OVF. This may take 40 minutes for smaller OVFs and up to a couple of hours for larger OVFs.
Created [https://cloudbuild.googleapis.com/v1/projects/johnd-test-01/locations/us-central1/builds/0e67bbb8-3389-4a34-adae-5f5566732085].
Logs are available at [https://console.cloud.google.com/cloud-build/builds;region=us-central1/0e67bbb8-3389-4a34-adae-5f5566732085?project=306419495665].
starting build "0e67bbb8-3389-4a34-adae-5f5566732085"
[import-ovf]: 2022-07-05T21:25:20Z Starting OVF import workflow.
[import-ovf]: 2022-07-05T21:25:21Z Found gs://eol-migration1322/centos6/centos6.ovf
[import-ovf]: 2022-07-05T21:25:21Z Found gs://eol-migration1322/centos6/centos6-disk1.vmdk
[import-ovf]: 2022-07-05T21:25:21Z Didn't find valid OS info in OVF descriptor. OS will be detected from boot disk.
[import-ovf]: 2022-07-05T21:25:21Z Will create instance of `g1-small` machine type.
[import-disk-1]: 2022-07-05T21:25:22Z Inspecting the image file...
[import-disk-1]: 2022-07-05T21:28:26Z Inspecting disk for OS and bootloader
[import-disk-1]: 2022-07-05T21:30:05Z Inspection result=os_release:{cli_formatted:"centos-6" distro:"centos" major_version:"6" minor_version:"10" architecture:X64 distro_id:CENTOS} elapsed_time_ms:98933 os_count:1
[import-ovf]: 2022-07-05T21:30:06Z Cleaning up.
[import-ovf]: 2022-07-05T21:30:06Z os `centos-6` is invalid. Allowed values: [centos-7 centos-8 debian-10 debian-11 debian-8 debian-9 opensuse-15 rhel-6 rhel-6-byol rhel-7 rhel-7-byol rhel-8 rhel-8-byol rocky-8 sles-12 sles-12-byol sles-15 sles-15-byol sles-sap-12 sles-sap-12-byol sles-sap-15 sles-sap-15-byol ubuntu-1404 ubuntu-1604 ubuntu-1804 ubuntu-2004 windows-10-x64-byol windows-10-x86-byol windows-2008r2 windows-2008r2-byol windows-2012 windows-2012-byol windows-2012r2 windows-2012r2-byol windows-2016 windows-2016-byol windows-2019 windows-2019-byol windows-2022 windows-2022-byol windows-7-x64-byol windows-7-x86-byol windows-8-x64-byol windows-8-x86-byol]
ERROR
ERROR: build step 0 "us-central1-docker.pkg.dev/compute-image-tools/wrappers/gce_ovf_import:release" failed: step exited with non-zero status: 1
ERROR: (gcloud.compute.instances.import) build 0e67bbb8-3389-4a34-adae-5f5566732085 completed with status "FAILURE"Ou seja, a importação de imagens só aceita determinados sistemas operacionais e versões — e o Centos-6 não está entre eles. Pelo console do Google Cloud ou pela linha de comando, o resultado é o mesmo. Adeus à opção do "botão fácil" de importar as imagens de disco direto para o Google Compute Engine (GCE).
A essa altura, alguém pode descobrir o GCVE e perceber que ele continua rodando tudo o que o VMware roda. Sobe um cluster, configura, importa as VMs — exatamente como on-prem. Pronto, problema resolvido! Será mesmo?
Estado atual do suporte do Google Cloud para imagens de SO em EOL
Boa parte da documentação de suporte do Google sobre sistemas operacionais em EOL recomenda, antes de tudo, atualizar o sistema operacional. É a prática recomendada, sem dúvida, mas nem todo mundo tem essa opção. Os desenvolvedores da aplicação podem não estar mais por perto, podem existir dependências de bibliotecas específicas ou simplesmente faltar recurso para atualizar a aplicação.
Opções para importar suas máquinas virtuais com SO em EOL para o GCE
Aqui estão as opções disponíveis, sem ordem específica. Cada uma tem seus prós e contras.
Opção 1: Reinstalar a aplicação legada usando uma imagem pública depreciada do GCE
Como mencionei, vi clientes tentarem usar imagens nativas do Google Cloud sem encontrar nenhuma de cara. Acontece que o Google manteve as imagens disponíveis, só que escondidas. Pesquisando na documentação de suporte para imagens em EOL, descobri que elas existem, mas estão marcadas como depreciadas. Veja um exemplo de documentação para o Centos 6.
No console do GCE, em Imagens, há um botão de alternância para mostrar imagens depreciadas. Ative essa opção e voilà: aparece a lista com todas as imagens antigas do GCE:
Filtre pelo que você procura — no meu caso, imagens do Centos 6 —, escolha a desejada e crie uma instância do GCE a partir dela.
Pela linha de comando, você chega ao mesmo resultado com:
gcloud compute images list --show-deprecated
A vantagem dessa opção é ter uma imagem original do Google, já com ferramentas como o os-agent e os ajustes de SO necessários para rodar no Compute Engine. Se sua aplicação é fácil de reinstalar e você tem poucas instâncias para mover, pode ser uma alternativa interessante.
Opção 2: Converter manualmente sua imagem de VM para um formato compatível com o GCE e importar à mão
O Google tem documentação de suporte para importar imagens manualmente e, em seguida, fazer os ajustes nas imagens importadas para que rodem bem no GCE. Esse processo pode ser útil se você tem appliances de VM customizados ou poucos servidores com volumes únicos para migrar para o GCE. Por ser manual, há mais espaço para erros.
Os passos básicos, dando continuidade ao exemplo do Centos 6, são:
Planeje seu caminho. Você vai precisar armazenar uma imagem exportada do ambiente de origem e ter uma forma de iniciá-la para fazer alterações e depois convertê-la para um formato compatível com o GCE. Garanta espaço em disco suficiente para acomodar a imagem, a versão comprimida e ainda alguma folga, para não esbarrar em erros de falta de espaço.
Faça uma cópia da imagem, inicialize-a no ambiente de origem e faça as alterações necessárias no SO antes de converter, como:
Edite o arquivo de configuração de boot do linux — /etc/grub.conf no nosso exemplo — e remova a linha que configura a splashimage de boot. Também remova os parâmetros de kernel rhgb e quiet. Adicione console=ttyS0,38400n8d aos parâmetros de kernel.
Garanta que você consegue fazer login pelo console com usuário e senha. Isso pode ser útil se a interface de rede não subir corretamente após o boot no GCE.
Garanta também que você tem uma chave ssh para acessar a imagem, por garantia.
Confirme que seus repositórios do Centos ainda funcionam. No meu caso, precisei apontá-los para vault.centos.org.
Atualize a configuração padrão da interface de rede. No centos-6, fica em /etc/sysconfig/network-scripts/ifcfg-eth0. Remova as linhas HW_ADDR e UUID e adicione ONBOOT=yes e MTU=1460 ao arquivo.
Remova as ferramentas do VMware ou de outros hipervisores.
Copie a imagem para um local onde você possa executar os próximos passos.
Converta a imagem para um formato aceito pelo GCE.
A maneira mais fácil que encontrei foi com o utilitário qemu-img. Instale o qemu.
Neste exemplo, pego um arquivo .vmdk do VMware e converto para o formato raw, que é o que o GCE exige:
qemu-img convert -f vmdk -O raw PATH/TO/VM.VMDK PATH/TO/disk.raw
Com o arquivo .VMDK convertido para .raw, é preciso compactá-lo com tar no formato oldgnu:
tar –format=oldgnu -Sczf compressed-image.tar.gz disk.raw- Faça upload do arquivo compressed-image.tar.gz para um bucket do Google Cloud Storage (GCS):
gsutil cp compressed-image.tar.gz gs://BUCKET\_NAMEPor fim, crie a imagem do GCE:
gcloud compute images create IMAGE_NAME --source-uri \ gs://BUCKET_NAME/compressed-image.tar.gz
Crie uma VM a partir da imagem resultante, instale o os-agent do Google e faça os ajustes necessários.
Crie uma VM a partir da imagem resultante do passo 3e.
gcloud compute instances create VM_NAME --zone ZONE --image IMAGE_NAME
Faça login na imagem usando a chave ssh sugerida no passo 2c.
Se não conseguir fazer login na sua instância, é provável que uma nova interface de rede tenha sido detectada no boot. Acesse a instância pelo console serial com usuário/senha e ajuste a interface de rede para a que foi detectada.
Uma vez logado, instale o os-agent do Google.
Se as instruções acima parecem demais, talvez a próxima opção seja para você. Recomendo ler a documentação de suporte do Google sobre importação manual de imagens e sobre ajustes nas imagens importadas. Anotei acima os passos básicos e alguns dos problemas que encontrei. Há vários requisitos e limitações, então leia com atenção.
Opção 3: Use o Migrate to Virtual Machines se você tem várias VMs para levar ao GCE
O Migrate to Virtual Machines (antigo Migrate for GCE) é uma ferramenta de migração feita para fazer lift and shift de servidores on-prem para o GCE. A versão mais recente é focada em migrações VMware. Se suas aplicações legadas já rodam em VMware, esta pode ser a melhor opção. Usar o Migrate to Virtual Machines exige um pouco de configuração inicial, mas, depois disso, dá para migrar muitas máquinas virtuais com facilidade, confiabilidade e o mínimo de downtime.
O Migrate to Virtual Machines funciona instalando um appliance de migração no seu ambiente VMware existente. Esse appliance faz a ponte entre o Google Cloud e o seu vSphere on-prem para que o Migrate to Virtual Machines consiga visualizar o ambiente vSphere, selecionar VMs para migrar, configurar a replicação de dados e gerenciar clones para testes ou cutovers, na hora de mover suas aplicações para o Google Cloud.
Acho que esta será a opção mais atraente para a maioria dos usuários. Diferente do processo manual de importação da opção 2, ela automatiza muitos passos e, pela minha experiência, migra imagens de forma confiável. Se você tem mais do que uns poucos servidores para mover, este é o caminho mais rápido. O Migrate to Virtual Machines também suporta vários sistemas operacionais atuais e legados.
O Migrate to Virtual Machines exige que o migrate connector consiga falar diretamente com as APIs do Google, seja pela internet, seja por alguma conectividade privada que você tenha entre seu ambiente VMware e o Google Cloud. Esta página de suporte resume as opções.
Os passos básicos para usar o Migrate to Virtual Machines são:
- Configurar os pré-requisitos, como ativar as APIs do Google Cloud associadas e definir quais projetos e permissões IAM usar.
- Instalar, configurar e registrar o migrate connector no seu ambiente VMware existente
- Começar a migrar VMs. O processo de migração pode ser dividido nos seguintes passos:
- Faça o onboarding das VMs no Migrate to Virtual Machines.
- Inicie a replicação para VMs selecionadas ou para todas. A replicação pode ser feita com as VMs de origem ainda em execução.
- Configure os detalhes da VM de destino, como tipos de instância, configuração de rede, etc.
- Opcionalmente, dá para testar uma migração pela função de clone. Recomendo fazer isso em um ambiente de destino isolado. Suas imagens de origem continuam rodando no VMware.
- Faça o cutover. Isso desliga a VM de origem, faz uma replicação final e provisiona as VMs de destino. Esse passo envolve downtime. Nas imagens que testei, observei cerca de 15 minutos de downtime entre o desligamento da imagem de origem e a nova instância subir no Google Cloud. A maior parte do tempo foi de processamento da imagem, então o tamanho da imagem influencia bastante.
- Faça a limpeza.
Opção 4: Use o Google Cloud VMware Engine para hospedar aplicações legadas grandes ou em volume
O Google Cloud VMware Engine é por onde vejo a maioria começar, justamente porque as outras opções são pouco divulgadas. O GCVE é um ótimo produto para os casos de uso certos, mas rodar poucas máquinas virtuais em um cluster GCVE pode sair caro.
A configuração mínima do GCVE é um cluster de 3 nós. Cada nó é uma instância ve1-standard-72, ou seja, 72 núcleos com hyperthreading (36 físicos), 768 GB de RAM e mais de 20 TB de SSD. No preço On-Demand, cada nó sai por US$ 9,29/hora, então o cluster mínimo de 3 nós fica em US$ 20.345,10 por mês. Descontos para commitments de 1 e 3 anos podem reduzir esse valor de forma significativa.
O Google oferece uma configuração de 1 nó, que reduz um pouco o preço e os recursos, mas a limita a um período de 60 dias, já que serve principalmente para POCs. Não rode workloads de produção nessa configuração.
O GCVE continua sendo uma opção viável para rodar aplicações legadas em fim de vida, desde que seus requisitos de recursos justifiquem, seus workloads tenham licenciamento pouco compatível com a nuvem (Windows Server, Oracle, etc.) ou se você já depende bastante do VMware on-prem e quer continuar usando-o para certos workloads, preservando os investimentos em ferramentas e operações.
Opção bônus 5: Use a ferramenta Migrate to Containers para conteinerizar certas aplicações legadas
A ferramenta Migrate to Containers do Google Cloud pode ser uma boa opção para certos workloads. Se você já se sente à vontade com containers e não quer subir mais máquinas virtuais no GCE, o Migrate to Containers pode ser uma alternativa interessante. O Migrate for Containers analisa seus workloads e, se forem adequados para conteinerização, gera um container do seu workload baseado em VM para uso em plataformas como Google Kubernetes Engine e Cloud Run.
Uma ressalva: nem todos os workloads são adequados para conversão. O Google traz exemplos de workloads que são bons candidatos e os que não são. Há também uma ferramenta de análise que ajuda nessa avaliação. Algumas modificações também podem ser necessárias. Vários sistemas operacionais atuais e legados são suportados.
Qual é a melhor opção para a sua aplicação legada esquecida?
Pelo que tenho visto com clientes, acredito que o Migrate to Virtual Machines é a melhor solução geral, equilibrando bem esforço, automação, confiabilidade e o menor downtime possível para workloads stateful.
Se você só tem 1 ou 2 imagens para resolver, reinstalar a aplicação em uma imagem depreciada do Google Cloud ou fazer uma conversão manual pode dar menos trabalho para colocar uma máquina virtual rodando no GCE. Por outro lado, essas opções não são ideais para migrar workloads stateful que não toleram muito downtime.
Se você já roda aplicações conteinerizadas, está disposto a fazer alguma modificação nos seus workloads quando necessário e não quer trazer máquinas virtuais para o seu mix, o Migrate to Containers pode ser uma alternativa interessante. A desvantagem é que nem todos os workloads são adequados para esse processo, e suas aplicações podem precisar de ajustes para que tudo funcione.
Por fim, se você tem necessidades em larga escala, especialmente com ambientes VMware existentes que podem ter complicações de licenciamento na nuvem, o GCVE permite preservar parte dos seus contratos de licenciamento atuais, que muitas vezes não permitem rodar certos workloads de forma econômica no GCE, além de aproveitar habilidades e ferramentas que sua equipe já domina. Dito isso, o GCVE em geral não é uma solução econômica para apenas algumas aplicações pequenas.