Mover VM de zona no Google Cloud: o passo a passo com disco, IP e firewall

A VM web01 roda em southamerica-east1-a há dois anos, e agora o banco gerenciado foi para southamerica-east1-b. Cada consulta atravessa zonas, a latência subiu e o tráfego entre zonas aparece na fatura. A resposta curta: não existe "arrastar" uma VM. Você para a aplicação, tira um snapshot do disco, cria um disco e uma VM nova na zona de destino a partir dele, reaproveita o IP estático se ficar na mesma região, testa e só então apaga a antiga.

O trabalho pesado não é o comando. É lembrar de tudo o que a VM antiga tinha e ninguém documentou: tags de firewall, conta de serviço, metadados, IP interno fixo em algum arquivo de configuração. Este guia é o roteiro com gcloud. Para o lado do que mais aponta para a máquina, leia também mudar uma VM de zona muda endereço, disco e o que você esqueceu de apontar.

Por que a VM não muda de zona sozinha

No Compute Engine, a VM e o disco persistente zonal pertencem a uma zona. O disco é um recurso daquela zona, então não pode ser anexado a uma máquina em outra. Mudar de zona significa recriar os dois do outro lado a partir de uma cópia.

Os endereços seguem regras próprias. Um IP externo estático é regional, então pode passar de uma VM em -a para outra em -b dentro da mesma região. Um IP externo efêmero vai embora quando a VM é apagada. Se a mudança for para outra região, nem o estático acompanha, e aí o nome DNS é o que salva você.

Já as regras de firewall pertencem à rede VPC, não à zona. Elas se aplicam à VM nova desde que ela tenha as mesmas tags de rede ou a mesma conta de serviço que as regras usam como alvo. É aqui que muita migração sobe uma máquina que ninguém consegue acessar.

Levantar o inventário antes da janela

Rode o comando abaixo e guarde a saída num arquivo. Ela é a sua lista do que precisa existir do outro lado.

gcloud compute instances describe web01 \
  --zone=southamerica-east1-a \
  --format=yaml > web01-antes.yaml

Dessa saída, anote: tipo de máquina, discos anexados (boot e dados), tags, conta de serviço e escopos, metadados (incluindo chaves SSH e script de inicialização), IP interno e configuração de acesso externo. Se a VM tem IP externo efêmero, promova para estático antes de qualquer outra coisa, informando o endereço atual:

gcloud compute addresses create web01-ip \
  --addresses=203.0.113.10 \
  --region=southamerica-east1

Com isso o endereço passa a pertencer ao projeto e sobrevive à exclusão da VM antiga. Faça o mesmo raciocínio para o IP interno se algum serviço aponta para ele: reserve como estático e reaproveite na VM nova com --private-network-ip.

Baixar o TTL do DNS um dia antes

Mesmo que o IP externo seja reaproveitado, tenha o plano B. Baixe o TTL do registro DNS para poucos minutos um dia antes, como descrito em DNS com TTL baixo na troca. Se algo der errado e você precisar de um IP novo, a troca propaga rápido.

O passo a passo da migração

1. Avise e pare o que grava. Pare a aplicação ou desligue a VM. Snapshot de disco em uso é consistente como uma queda de energia, e banco de dados no meio de uma escrita é exatamente o que você não quer copiar.
2. Tire o snapshot de cada disco. Snapshots são globais, então servem para qualquer zona.
3. Crie os discos na zona de destino a partir dos snapshots.
4. Libere o IP externo da VM antiga apagando a VM antiga ou removendo a configuração de acesso dela. O endereço só pode estar em uma máquina por vez.
5. Crie a VM nova com o disco de boot, as mesmas tags, a mesma conta de serviço e o IP reservado.
6. Teste uma leitura e uma escrita antes de declarar a migração concluída.
7. Guarde o snapshot por alguns dias antes de apagar.

# 1 e 2: parar e fotografar o disco de boot
gcloud compute instances stop web01 --zone=southamerica-east1-a

gcloud compute snapshots create web01-snap-20261017 \
  --source-disk=web01 \
  --source-disk-zone=southamerica-east1-a

# 3: disco novo na zona de destino
gcloud compute disks create web01-b \
  --source-snapshot=web01-snap-20261017 \
  --zone=southamerica-east1-b

# 4: liberar o IP apagando a VM antiga, mantendo o disco original
gcloud compute instances delete web01 \
  --zone=southamerica-east1-a \
  --keep-disks=all

# 5: VM nova com o que estava no inventário
gcloud compute instances create web01-b \
  --zone=southamerica-east1-b \
  --machine-type=e2-medium \
  --disk=name=web01-b,boot=yes,auto-delete=yes \
  --tags=http-server,https-server \
  --service-account=web01@meu-projeto.iam.gserviceaccount.com \
  --scopes=cloud-platform \
  --address=web01-ip

O --keep-disks=all é a sua rede de proteção: a VM antiga some, mas o disco original continua em -a. Se a VM nova não subir, você recria a antiga com o mesmo disco e o mesmo IP e volta ao ponto de partida. Se a VM tinha discos de dados, repita snapshot e criação para cada um e anexe com outro --disk sem boot=yes.

Metadados de instância, como chaves SSH específicas da VM e script de inicialização, não vêm no snapshot. Copie do arquivo de inventário com --metadata ou --metadata-from-file. Se o projeto usa OS Login ou chaves no nível do projeto, isso já vale para a VM nova.

O teste antes de apontar o tráfego

Entre por SSH na VM nova e confira o básico: o serviço subiu, o disco montou no mesmo caminho, a aplicação alcança o banco. Depois faça uma operação de leitura e uma de escrita pela interface real, não só um curl na página inicial. No caso da web01, a escrita falhou na primeira tentativa: o arquivo /etc/hosts tinha o IP interno antigo do servidor de cache, fixo há dois anos. Foi o inventário que achou isso em cinco minutos, e não o cliente na segunda de manhã.

Anote a hora exata em que o tráfego passou para a VM nova. Se o suporte receber reclamação, essa hora separa problema de migração de problema que já existia.

Erros comuns

• Apagar a VM antiga com IP efêmero: o endereço volta para o pool do Google e não há como recuperá-lo. Todo cliente que apontava para ele fica no endereço morto.
• Esquecer as tags de rede: a VM sobe, mas as regras de firewall não se aplicam a ela, e nem SSH nem HTTP entram.
• Snapshot com a aplicação gravando: o disco novo pode subir com arquivo ou banco corrompido, e o problema aparece dias depois.
• Manter as duas VMs ativas recebendo escrita: parte dos dados vai para cada lado e juntar depois é trabalho manual.
• Apagar snapshot e disco antigo no mesmo dia: você perde o caminho de volta justamente quando ele ainda é útil.
• IP interno fixo em arquivo de configuração: outros serviços continuam falando com o endereço velho e o erro parece intermitente.

Checklist

• A saída de describe da VM antiga está salva.
• O IP externo é estático antes de qualquer exclusão.
• O TTL do DNS foi reduzido com um dia de antecedência.
• A aplicação estava parada no momento do snapshot.
• A VM nova tem as mesmas tags, conta de serviço e metadados.
• Uma leitura e uma escrita reais funcionaram na VM nova.
• A hora da troca de tráfego está anotada.
• Snapshot e disco antigo têm data marcada para exclusão, não foram apagados no mesmo dia.

Rode gcloud compute instances describe na sua VM mais importante agora. O IP externo dela é estático ou efêmero, e em quantos arquivos de configuração o IP interno está escrito?