Esta página foi traduzida pela API Cloud Translation.

Mover a carga de trabalho para uma nova instância de computação

Em determinadas situações, talvez seja necessário mover sua carga de trabalho de uma instância de máquina virtual (VM) existente para uma VM mais recente. Os motivos para migrar para uma nova VM incluem:

Aproveite os novos tipos de máquina para velocidades de armazenamento ou rede mais rápidas. Por exemplo, fazer upgrade do C2 para o H3 para melhorar a largura de banda de rede.
Aproveite um custo-benefício maior em relação à instância de VM de origem. Por exemplo, fazer upgrade de N1 para N4 para ter mais valor no processador Intel Xeon de 5ª geração.
Usar recursos disponíveis apenas na nova instância da VM. Por exemplo, fazer upgrade de N4 para C4 para aproveitar outras opções de desempenho e manutenção.
Mude uma instância de máquina virtual (VM) para uma instância bare metal.
Adicione discos SSD locais à instância da VM C3 ou C3D.

Ao fazer upgrade para a série de máquinas de geração mais recente, talvez seja possível usar o procedimento mais simples descrito em Editar o tipo de máquina de uma instância de computação se as seguintes condições forem atendidas pela VM atual (de origem):

A versão do sistema operacional (SO) é compatível com a nova série de máquinas.
O tipo de disco de inicialização anexado à VM de origem é aceito pela nova série de máquinas.
A VM não usa o armazenamento SSD local.
A VM com GPUs anexadas usa um tipo de máquina G2. Consulte Adicionar ou remover GPUs para mais detalhes .
A VM está usando apenas recursos compatíveis com a nova série de máquinas.
A VM não faz parte de um grupo gerenciado de instâncias (MIG).
A VM usa a interface de rede gVNIC.

Antes de começar

Configure a autenticação, caso ainda não tenha feito isso. A autenticação é o processo de verificação da sua identidade para acesso a serviços e APIs do Google Cloud. Para executar códigos ou amostras de um ambiente de desenvolvimento local, autentique-se no Compute Engine selecionando uma das seguintes opções:

Select the tab for how you plan to use the samples on this page:
Console

When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.
gcloud
1. Install the Google Cloud CLI, then initialize it by running the following command:
  gcloud init
  Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.
2. Set a default region and zone.

Funções exigidas

Para ter as permissões necessárias para editar ou mudar uma VM, peça ao administrador para conceder a você os seguintes papéis do IAM no projeto:

Administrador da instância da computação (v1) (roles/compute.admin.v1)
Para mudar o tipo de rede: Administrador de rede do Compute Engine (roles/compute.networkAdmin)

Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

Esses papéis predefinidos contêm as permissões necessárias para editar ou mudar uma VM. Para conferir as permissões exatas necessárias, expanda a seção Permissões necessárias:

Permissões necessárias

As permissões a seguir são necessárias para editar ou mudar uma VM:

Para mudar o tipo de máquina:
- compute.instances.stop no projeto
- compute.instances.create no projeto
- compute.instances.start no projeto
- compute.instances.setMachineType na instância
Para criar um snapshot do disco:
- compute.snapshots.create no projeto
- compute.disks.createSnapshot no disco
Para criar um disco:
- compute.disks.list no projeto
- compute.disks.create no projeto
- compute.disks.update no projeto
Para anexar um disco a uma VM:
- compute.instances.attachDisk na instância
- compute.disks.use no disco
Para excluir um disco: compute.disks.delete no projeto
Para fazer mudanças no tipo de rede:
- compute.networks.list no projeto
- compute.networks.update no projeto

Essas permissões também podem ser concedidas com funções personalizadas ou outros papéis predefinidos.

Avaliar as opções de migração de VM

A migração de um tipo de máquina para outro depende de vários fatores, incluindo a disponibilidade regional do novo tipo de máquina e a compatibilidade das opções de armazenamento e interfaces de rede em relação ao SO convidado da origem e à nova série de máquinas.

Requisitos de computação

Revise os seguintes requisitos para sua instância atual e o novo tipo de máquina:

Consulte a documentação do recurso de família de máquinas para identificar quais tipos de máquina são adequados para sua carga de trabalho. Considere se o aplicativo requer hardware específico (GPUs), alto desempenho ou custos mais baixos.
Analise os recursos dos tipos de disco compatíveis com o novo tipo de máquina. A maioria dos recursos do Persistent Disk, mas não todos, são compatíveis com o Hyperdisk. No entanto, o Hyperdisk oferece recursos adicionais que não estão disponíveis com o Persistent Disk.
Analise os recursos da série de máquinas em potencial. A nova série de máquinas pode não ser compatível com os mesmos recursos que você usa com sua série atual, como tipos de máquinas personalizados, SSD local ou VM protegida.
Verifique as regiões e zonas para garantir que a nova série de máquinas esteja disponível em todas as regiões como sua VM atual. Talvez seja necessário ajustar os planos de implantação, alta disponibilidade e recuperação de desastres.
Revise o plano de migração do SO:
- Se a nova VM exigir uma versão mais recente do SO, verifique se os aplicativos são compatíveis com a versão mais recente do SO.
- Se você estiver migrando para o Arm e uma imagem do Arm não estiver disponível para sua versão atual do SO, escolha um novo SO ou uma versão do SO para executar os aplicativos e verifique se eles são compatíveis com o novo SO.
É possível migrar de uma instância de VM C3 para uma instância bare metal C3, desde que a instância de VM C3 de origem use um sistema operacional e driver de rede com suporte.
Se você estiver migrando de uma série de máquinas diferente da C3 para uma instância bare metal, crie uma nova instância. Talvez seja necessário executar seu próprio hipervisor. No entanto, você também pode executar qualquer sistema operacional com suporte para C3, desde que o driver IDPF esteja ativado. As instâncias bare metal usam a interface de rede IDPF apresentada como apenas uma função física, não virtual.

Requisitos de armazenamento

Revise os seguintes requisitos de armazenamento para sua instância atual e o novo tipo de instância:

Revise os tipos de armazenamento e as interfaces de armazenamento compatíveis com a nova série de máquinas.
- Por padrão, as séries de máquinas de primeira e segunda geração usam apenas o tipo de armazenamento Persistent Disk e as interfaces VirtIO-SCSI.
- As séries de máquinas de terceira geração e mais recentes (como M3, C3 e N4) oferecem suporte apenas à interface NVMe, e algumas oferecem suporte apenas aos tipos de armazenamento Hyperdisk e SSD local.
- As instâncias bare metal (como C3 e X4) oferecem suporte apenas ao Hyperdisk.
Compatibilidade do disco:
- Se o disco de inicialização usar um tipo que não é compatível com a nova série de máquinas, por exemplo, pd-standard, será necessário criar um novo disco de inicialização para a nova VM.
- Se você estiver fazendo upgrade do SO para uma nova versão e o sistema operacional não oferecer suporte a upgrades no local, será necessário criar um novo disco de inicialização. Todos os dados no disco de inicialização de origem são perdidos, a menos que você os copie para um disco não inicializável temporário. Em seguida, crie um novo disco de inicialização e copie os dados armazenados no disco temporário não de inicialização para o novo disco de inicialização.
- Se você não estiver fazendo upgrade da versão do SO, poderá fazer um snapshot do disco de inicialização atual e restaurá-lo para o novo tipo de disco compatível. Ao criar uma VM, você pode usar esse novo disco como o disco de inicialização.
- Se um disco que não é de inicialização usar um tipo de disco que não é compatível com a nova série de máquinas, use um snapshot para mudar o disco de origem para um novo tipo de disco, conforme descrito em Mudar o tipo de disco.
Os discos SSD locais não podem ser movidos para uma nova VM. É possível anexar um disco grande o suficiente para armazenar todos os dados do SSD local à VM atual e usar um snapshot para mudar o disco de origem para um novo tipo de disco, conforme descrito em Mudar o tipo de disco. Depois de criar uma VM com discos SSD locais anexados, você poderá copiar os dados de volta para os discos SSD locais.
Se a instância de VM atual usar discos em um pool de armazenamento, mas você estiver movendo a carga de trabalho para uma VM em uma região diferente, será necessário recriar os discos e o pool de armazenamento na nova região.
Se a nova série de máquinas usar uma interface de disco diferente (por exemplo, NVMe em vez de SCSI), os nomes dos dispositivos de disco no SO convidado serão diferentes. Confira se os aplicativos e scripts usam nomes de dispositivo permanentes ou links simbólicos ao se referir aos discos anexados.

Requisitos de rede

Confira os requisitos de rede a seguir para a instância atual e o novo tipo de instância:

Revise as interfaces de rede compatíveis com a nova VM.
- Por padrão, as séries de máquinas de primeira e segunda geração usam apenas a interface de rede VirtIO.
- As séries de máquinas de terceira geração e mais recentes (como M3, C3 e N4) oferecem suporte apenas à interface de rede gVNIC.
- As instâncias bare metal oferecem suporte apenas à interface de rede IDPF.
Verifique se o aplicativo e o sistema operacional oferecem suporte às interfaces disponíveis para a série de máquinas.
Revise a configuração de rede da VM para determinar se é necessário manter os endereços IP atribuídos. Se sim, promova os endereços IP para endereços IP estáticos.
Se você usa o desempenho de rede por VM de Tier_1 com a VM atual, verifique se ele está disponível ou é necessário com a nova série de máquinas. Por exemplo, é possível usar a rede Tier_1 com um tipo de máquina C2, mas ela não é necessária com uma VM H3.

Para determinar o tipo de interface de rede da VM atual, use o comando gcloud compute instances describe para conferir a nic-type da VM:

  gcloud compute instances describe VM_NAME --zone=ZONE

Se a VM tiver um nic-type definido como VIRTIO, não será possível mudar o tipo de interface de rede. É necessário criar uma nova VM e definir o tipo de interface de rede como gVNIC.

Preparar a migração das VMs atuais

Depois de concluir a seção de avaliação, a próxima etapa é se preparar para mover as instâncias de VM solicitando recursos para a nova instância de VM e preparando backups da instância de VM de origem.

Preparar recursos de computação

Conclua as etapas a seguir para se preparar para mover sua instância atual para uma nova:

Solicite a cota na região e nas zonas para onde você planeja mover seus recursos. Se você tiver cota para um tipo de máquina, poderá solicitar a transferência dela. O processo leva alguns dias para ser concluído.
Crie uma reserva para as novas instâncias de VM para garantir que os recursos da máquina estejam disponíveis na nova região e nas zonas. Entenda como os recursos reservados são consumidos e teste se você pode consumir recursos reservados.
Estenda seus planos de alta disponibilidade e recuperação de desastres para incluir a nova região.
Se necessário, faça upgrade do SO na VM atual.
1. Se o fornecedor do sistema operacional oferecer suporte, faça um upgrade no local do SO para uma versão compatível com a nova série de máquinas e verifique se a carga de trabalho está funcionando como esperado na nova versão do SO.
2. Se não houver suporte para upgrade in-place do SO, crie um novo disco de inicialização ao criar uma nova VM. Determine quais informações você precisa copiar do disco de inicialização atual e copie-as para um local temporário em um disco que não é de inicialização para que possam ser transferidas para a nova VM. Se você não tiver discos que não são de inicialização conectados à VM atual:
  - Para tipos de máquina de primeira e segunda geração, consulte Adicionar armazenamento em disco permanente à VM.
  - Para tipos de máquina de terceira geração e mais recentes, consulte Adicionar armazenamento do Hyperdisk à VM.
Se aplicável à sua distribuição do Linux, verifique as regras do udev em /etc/udev/rules.d/. Esse arquivo pode conter entradas relevantes para a configuração de hardware da instância atual, mas não para a nova. Por exemplo, a entrada a seguir garante que eth0 seja fornecido pelo driver virtio-pci (VirtIO Net), o que impede que o driver gve (gVNIC) forneça essa interface. Isso pode levar a scripts de inicialização de rede e problemas de conectividade na nova instância:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="virtio-pci", ATTR{dev_id}=="0x0", KERNELS=="0000:00:04.0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Preparar recursos de armazenamento

Siga as etapas abaixo para se preparar para mover os dados dos discos anexados à sua instância atual para uma nova instância:

Em sistemas Linux, teste os aplicativos e scripts atualizados para garantir que eles funcionem com nomes de dispositivos persistentes ou links simbólicos em vez dos nomes de dispositivos.
Se você estiver migrando de uma VM que executa o Microsoft Windows:
- Atualize o driver NVMe nas VMs criadas antes de maio de 2022. Isso se aplica ao disco de inicialização da VM atual e a todos os snapshots ou imagens personalizadas criados anteriormente usados para criar uma VM.
- O Windows precisa ser reconfigurado para começar a usar o driver NVMe do Microsoft (StorNVMe). Siga as instruções para atualizar o dispositivo de inicialização.
Se a nova VM não oferecer suporte aos mesmos tipos de disco que a VM atual, talvez seja necessário atualizar os scripts de implantação ou modelos de instância para oferecer suporte à nova série de máquinas.
Se a VM atual usar um tipo de disco de inicialização que não é compatível com a nova série de máquinas e você estiver migrando várias VMs com a mesma configuração, crie uma imagem personalizada para usar ao criar as novas VMs:
1. Crie um snapshot do disco de inicialização pd-standard da VM atual.
2. Crie uma imagem personalizada usando o snapshot do disco como origem.
Se você precisar mover informações do SSD local, crie um disco em branco grande o suficiente para fazer backup dos discos SSD locais.
1. Se possível, use um tipo de disco compatível com a nova VM.
2. Se não houver tipos de disco compatíveis com a VM atual e a nova, crie um disco temporário usando um tipo de disco com suporte à VM atual.
3. Anexe o novo disco à VM atual e formate e monte o disco.
4. Copie os dados dos discos SSD locais anexados à VM atual para este disco temporário.
Mude o tipo de disco de todos os discos anexados à VM atual que usam um tipo de disco que não tem suporte da nova VM. Para mover os dados para novos discos, crie snapshots deles. Também é possível transferir arquivos de uma VM para outra.
1. É possível fazer os snapshots enquanto a VM está em execução, mas os dados gravados nos discos após a criação do snapshot não são capturados. Como os snapshots são incrementais, é possível fazer um segundo snapshot depois de interromper a VM para capturar todas as mudanças mais recentes. Essa abordagem minimiza o tempo em que a VM fica indisponível enquanto você muda para uma nova VM.
2. Como alternativa, você pode fazer todos os snapshots do disco depois de interromper a VM. Recomendamos que você crie um snapshot de todos os discos conectados à VM, mesmo que o tipo de disco seja compatível com a nova série de máquinas. Inclua todos os discos temporários que contêm os dados do SSD local copiados.
3. O tempo necessário para criar um snapshot de um disco depende de vários fatores, como o tamanho do disco e a quantidade de dados nele. Por exemplo, se você fizer um snapshot de um disco de 1 TiB com 85% de ocupação, talvez leve 5 minutos para concluir. No entanto, se você fizer um snapshot de um disco de 100 TiB com 85% de capacidade, poderá levar 11 minutos para concluir. Recomendamos que você faça snapshots de teste dos discos antes de iniciar o processo de migração para entender quanto tempo a criação de snapshots leva.
Se você tiver um disco que pode ser desconectado, use a abordagem a seguir para mover os dados para um novo disco enquanto a VM de origem ainda estiver disponível:
1. Desconecte o disco da VM.
2. Crie um snapshot do disco.
3. Use o snapshot para criar um novo disco usando um tipo de disco compatível com a nova série de máquinas. O novo disco precisa ter o mesmo tamanho ou ser maior que o disco de origem.

Preparar recursos de rede

Siga estas etapas para atualizar a configuração de rede usada pela sua instância atual e oferecer suporte à nova instância:

Se a VM atual não usar o gVNIC, crie uma nova instância com uma interface de rede que use o gVNIC. Consulte Visão geral do uso do gVNIC com as VMs do Compute Engine para entender as etapas necessárias ao criar uma nova instância.
Se você estiver criando uma VM em uma nova região, crie uma rede VPC e sub-redes na nova região.
Se você configurou contagens de fila NIC personalizadas, consulte Alocações de fila e alteração do tipo de máquina.
Se você quiser manter os endereços IP usados pela VM de origem, promova os endereços IP para endereços IP estáticos.
Desfaça a atribuição do endereço IP estático antes de interromper a VM de origem.

Preparar o sistema operacional SUSE Enterprise Linux Server

Para evitar dependências específicas de hardware, recrie o initramfs (sistema de arquivos RAM inicial). Isso inclui uma variedade maior de drivers e módulos, tornando o sistema operacional compatível com outros tipos de instância. Se isso não for feito, ocorrerá o problema conhecido que impede a inicialização adequada da VM.

Antes de desligar o sistema, execute o comando a seguir como root para recriar o initramfs com todos os drivers:

  sudo dracut --force --no-hostonly

Mover a carga de trabalho para a nova VM

Depois de preparar as VMs para a migração, a próxima etapa é mover a carga de trabalho para a nova VM.

Se você estiver movendo suas VMs da primeira geração para a série de máquinas da segunda geração, leia as instruções na página Editar o tipo de máquina de uma VM. Se você quiser mudar o nome da VM atual, consulte as informações em Renomear uma VM.

Permissões exigidas para a tarefa

Para executar esta tarefa, é preciso ter a permissão a seguir:

compute.instances.setMachineType na VM

Esta seção descreve como mover sua carga de trabalho de uma VM de primeira ou segunda geração para uma VM de terceira geração (ou mais recente). Durante esse procedimento, você cria uma nova instância de VM e move as cargas de trabalho para ela.

Ao criar a nova VM, escolha um dos tipos de disco compatíveis com o disco de inicialização, por exemplo, hiperdisco equilibrado.

Criar a nova VM

Ao mover as cargas de trabalho de VMs de primeira ou segunda geração (N1 ou N2, por exemplo) para a terceira geração ou mais recente, primeiro crie uma VM e mova as cargas de trabalho.

Se a VM de origem usar discos que não são de inicialização com um tipo de disco compatível com a nova série de máquinas, remova os discos da VM.
Pare a VM de origem.
Crie snapshots de todos os discos que ainda estão anexados à VM de origem.
Crie uma nova instância de VM de computação usando uma imagem pública ou uma imagem personalizada configurada para usar a gVNIC. Ao criar a nova VM, escolha as seguintes opções:
- Selecione o tipo de máquina da série escolhida.
- Selecione uma imagem do SO com suporte ou use uma imagem personalizada que você criou anteriormente.
- Selecione um tipo de disco de inicialização compatível.
- Se você criou novos discos a partir de snapshots dos discos originais, inclua esses novos discos.
- Especifique a nova rede VPC se você estiver criando a instância em uma região diferente.
- Se o VirtIO e a gVNIC tiverem suporte para a nova instância, selecione gVNIC.
- Especifique os endereços IP estáticos se você tiver promovido os endereços IP temporários da VM de origem.
Inicie a nova VM.

Depois que a instância é iniciada

Agora que a nova instância foi criada e iniciada, siga as etapas a seguir para concluir a configuração da nova instância e copiar todos os dados da instância de origem.

Anexe os discos que você desconectou da VM de origem à nova VM.
Para discos anexados à VM de origem que usam um tipo de disco sem suporte à nova VM, crie um disco com base em um snapshot e anexe-o à nova instância. Ao criar o novo disco, selecione um tipo de disco compatível com a nova VM e especifique um tamanho pelo menos igual ao do disco original.
Se a VM original usou uma política de recursos para os discos recriados para a nova VM, adicione a política de recursos aos novos discos.
Se você criou a nova VM usando uma imagem do SO pública, e não uma imagem personalizada, faça o seguinte:
1. Configure os usuários, os drivers, os pacotes e os diretórios de arquivos necessários na nova instância para oferecer suporte à carga de trabalho.
2. Instale os aplicativos e programas modificados na nova VM. Recompile os programas no novo SO ou arquitetura, se necessário.
Opcional: se você moveu o conteúdo dos discos SSD locais para um disco temporário e a nova VM tem armazenamento SSD local anexado, depois de formatar e montar os discos, você pode mover os dados do disco temporário para os discos SSD locais.
Reatribua todos os endereços IP estáticos associados à VM de origem à nova VM.
Conclua todas as tarefas necessárias para tornar a nova VM altamente disponível, como configurar balanceadores de carga e atualizar as regras de encaminhamento.
Opcional: atualize as entradas de DNS, se necessário, para a nova VM.
Recomendado: programe backups de disco para os novos discos.
Recomendado: se você mudou o SO para uma versão ou arquitetura diferente, recompile seus aplicativos.

Se você encontrar problemas ao mover a carga de trabalho, entre em contato com o gerente técnico de contas (TAM) ou a organização de serviços profissionais (PSO) do Google para receber ajuda.

Exemplo de migração de n1-standard-8 para n4-standard-8

O exemplo a seguir é uma migração de uma VM n1-standard-8 para uma VM n4-standard-8. A VM n1-standard-8 tem um disco de inicialização PD-SSD em execução com uma imagem Ubuntu1804 e um disco de dados PD-SSD. Use a CLI ou a API REST para esse procedimento.

Há duas opções disponíveis para fazer upgrade da VM N1 para uma VM N4:

Opção 1:se a VM N1 usa a interface de rede VirtIO, crie uma nova VM N4. O N4 oferece suporte apenas à interface de rede gvnic e discos Hyperdisk Balanced. Você cria um snapshot dos discos de inicialização e de dados do Persistent Disk, cria discos do Hyperdisk Balanced com base nesses snapshots, anexa os discos do Hyperdisk Balanced e cria a nova VM N4 com os discos do Hyperdisk Balanced.

Também é possível criar um novo disco de inicialização do Hyperdisk Balanced usando uma versão mais recente do SO Ubuntu. Nesse cenário, é possível criar um novo disco Hyperdisk Balanced a partir do snapshot do disco de inicialização, mas anexe esse disco como um disco que não é de inicialização à VM N4. Em seguida, copie os dados que não são do sistema do snapshot restaurado para o novo disco de inicialização.

Opção 2:se a VM N1 usar a interface de rede gvnic, o sistema operacional tiver um driver de dispositivo de armazenamento NVMe, não tiver discos SSD locais ou GPUs anexados e não fizer parte de um grupo gerenciado de instâncias (MIG), será possível mudar o tipo de máquina de N1 para N4, mas ainda será necessário mudar os tipos de disco persistente para discos Hyperdisk Balanced. Primeiro, remova os discos de inicialização e de dados do Persistent Disk, crie snapshots dos discos, crie discos do Hyperdisk Balanced usando os snapshots como origem e anexe os novos discos do Hyperdisk Balanced à VM N4 depois de mudar o tipo de máquina. Se a VM tiver GPUs anexadas, primeiro desconecte-as.

O tempo para fazer um snapshot de um disco depende de vários fatores, como o número total de TBs em um disco. Por exemplo, se você criar um snapshot de um disco de 1 TB com 85% de uso, ele poderá levar 5 minutos para ser concluído. No entanto, se você fizer um snapshot de um disco de 100 TB com 85% de capacidade, o processo poderá levar 11 minutos. O Google recomenda que você faça snapshots de teste dos discos antes de iniciar o processo de migração para entender quanto tempo leva para fazer o snapshot.

gcloud

Opção 1: criar uma nova VM N4 com discos com snapshots

Interrompa a VM usando o comando gcloud compute instances stop:
```
gcloud compute instances stop VM_NAME \
  --zone=ZONE
```
Substitua:
- VM_NAME O nome da VM n1-standard-8 atual.
- ZONE: a zona em que a VM está localizada.
Faça um snapshot dos discos. Use o comando gcloud compute snapshots create para criar um snapshot do disco de inicialização do Persistent Disk e do disco de dados anexados à VM.
```
gcloud compute snapshots create SNAPSHOT_NAME \
    --source-disk=SOURCE_DISK_NAME \
    --source-disk-zone=SOURCE_DISK_ZONE
```
Substitua:
- SNAPSHOT_NAME: o nome do snapshot que você quer criar.
- SOURCE_DISK_NAME: o nome do disco de origem.
- SOURCE_DISK_ZONE: a zona do disco de origem.
Crie um novo disco do Hyperdisk Balanced para o disco de dados repetindo a etapa anterior e especifique as informações do disco de dados em vez do disco de inicialização. gcloud compute disks create:
```
gcloud compute disks create DISK_NAME \
    --project=PROJECT_NAME \
    --type=DISK_TYPE \
    --size=DISK_SIZE \
    --zone=ZONE \
    --source-snapshot=SNAPSHOT_NAME \
    --provisioned-iops=PROVISIONED_IOPS \
    --provisioned-throughput=PROVISIONED_THROUGHPUT
```
Substitua:
- DISK_NAME: o nome do novo disco que você está criando a partir do disco com snapshot.
- PROJECT_NAME: o nome do projeto.
- DISK_TYPE: o novo tipo de disco. Neste exemplo, é um disco Hyperdisk Balanced.
- DISK_SIZE: o tamanho do disco (exemplo: 100GB).
- ZONE: a zona em que o novo disco está localizado.
- SNAPSHOT_NAME: o nome do disco de origem do snapshot.
- Opcional: PROVISIONED_IOPS: o desempenho de IOPS do disco (exemplo: 3600).
- Opcional: PROVISIONED_THROUGHPUT: o desempenho de throughput para provisionar o disco (exemplo: 290).
Repita a etapa anterior para cada disco com snapshot.
Crie a VM n4-standard-8 e anexe os discos Hyperdisk Balanced usando o comando gcloud compute instances create:
```
gcloud compute instances create VM_NAME \
    --project=PROJECT_NAME \
    --zone=ZONE \
    --machine-type=NEW_MACHINE_TYPE \
    --boot-disk-device-name=BOOT_DISK_NAME \
    --disk=name=NON_BOOT_DISK_NAME, boot=no \
    --network-interface=nic-type=GVNIC
```
Substitua:
- VM_NAME: o nome da nova instância de VM.
- PROJECT_NAME: o nome do projeto.
- ZONE: a zona em que a nova VM está localizada.
- NEW_MACHINE_TYPE: o tipo de máquina, neste exemplo, n4-standard-8.
- BOOT_DISK_NAME O nome do disco de inicialização equilibrado do Hyperdisk que você criou com base no snapshot do disco de origem anexado à VM n1-standard-8.
- NON_BOOT_DISK_NAME O nome do disco de dados do Hyperdisk Balanced que você criou a partir do disco de snapshot de origem anexado à VM n1-standard-8.
Inicie a VM n4-standard-8 usando o gcloud compute instances start:
```
gcloud compute instances start VM_NAME
```
Substitua VM_NAME pelo nome da nova VM.

Opção 2: fazer upgrade de máquina no local:

Essa opção só estará disponível se a VM N1 usar a interface de rede gvnic, o sistema operacional tiver um driver de dispositivo de armazenamento NVMe, não tiver discos SSD locais ou GPUs conectados e não fizer parte de um grupo gerenciado de instâncias (MIG). A realização desse procedimento com uma VM N1 com uma interface de rede VirtIO gera um erro de incompatibilidade da VM.

Pare a VM.
Desconectar os discos da VM.
Crie um snapshot dos discos de inicialização e de dados.
Crie discos de inicialização e de dados do Hyperdisk Balanced usando um snapshot do disco como origem para cada disco.
Defina o tipo de máquina como uma VM N4.
Anexe o disco de inicialização e o disco de dados do Hyperdisk Balanced.
Inicie a VM N4.

REST

Opção 1: criar uma nova VM N4 com discos com snapshots

Interrompa a VM usando o método instances.stop:
```
 POST https://compute.googleapis.com/compute/v1/projects/PROJECT_NAME/zones/ZONE/instances/VM_NAME/stop
```
Substitua:
- PROJECT_NAME: o ID do projeto.
- ZONE: a zona que contém a VM.
- VM_NAME: o nome da VM n1-standard-8 atual.
Crie um snapshot dos discos usando o método disks.createSnapshot para criar um snapshot do disco de inicialização e do disco de dados do Persistent Disk anexado à instância.
```
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_NAME/zones/ZONE/disks/DISK_NAME/createSnapshot
```
No corpo da solicitação, inclua o nome do novo disco do Persistent Disk com snapshot.

Exemplo:
```
{
    "name": "SNAPSHOT_NAME"
}
```
Substitua:
- PROJECT_NAME: o nome do projeto.
- ZONE: a zona em que o disco está localizado.
- DISK_NAME: o disco que você planeja criar um snapshot.
- SNAPSHOT_NAME: um nome para o snapshot, como hdb-boot-disk ou hdb-data-disk.
Crie um disco Hyperdisk Balanced usando o método disks.insert. Você realiza essa etapa duas vezes: uma para incluir o name do disco de inicialização do Hyperdisk Balanced e outra para incluir o name dos discos de dados. Use o sourceSnapshot para os novos discos de inicialização e de dados do Hyperdisk Balanced, o type do disco, o Hyperdisk Balanced e o sizeGB do disco no corpo da solicitação.
```
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_NAME/zones/ZONEdisks
```
Substitua:
- PROJECT_NAME: o nome do projeto.
- ZONE: a zona em que o disco está localizado.
No corpo da solicitação, inclua o seguinte:

Exemplo:
```
{
    "name": "my-hdb-boot-disk" or "my-hdb-data-disk",
    "sourceSnapshot": "projects/your-project/global/snapshots/SNAPSHOT_NAME",
    "type": "projects/your-project/zones/us-central1-a/diskTypes/hyperdisk-balanced",
    "sizeGb": "100"
}'
```

Use o método instances.insert para criar a nova VM N4.


POST https://compute.googleapis.com/compute/v1/projects/PROJECT_NAME/zones/ZONE/instances

Substitua:

PROJECT_NAME: o nome do projeto.
ZONE: a zona em que o disco está localizado.

No corpo da solicitação, inclua o seguinte:


  {
    "machineType":"projects/your-project/zones/us-central1-a/machineTypes/n4-standard-8" "name":"VM_NAME",
    "disks": [
      {
        "boot": true,
        "deviceName": "my-hdb-boot-disk",
        "source": "projects/your-project/zones/us-central1-a/disks/my-hdb-boot-disk",
        "type": "PERSISTENT"
      },

      {
        "boot": false,
        "deviceName": "my-hdb-data-disk",
        "source": "projects/your-project/zones/us-central1-a/disks/my-hdb-data-disk",
        "type": "PERSISTENT"
      }
      ],
        "networkInterfaces":[
          {
            "network":"global/networks/NETWORK_NAME",
            "subnetwork":"regions/REGION/subnetworks/SUBNET_NAME",
            "nicType": "GVNIC"
          }
       ]
     }

Substitua:

VM_NAME: o nome da VM.
NETWORK_NAME: o nome da rede.
REGION: o nome da região.
SUBNET_NAME: o nome da sub-rede.

Inicie a VM usando o método instances.start:
```
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_NAME/zones/ZONE/instances/VM_NAME/start
```
Substitua:
- PROJECT_NAME: o nome do projeto.
- ZONE: a zona em que a VM está localizada.
- VM_NAME: o nome da VM.

Opção 2: fazer upgrade de máquina no local:

Essa opção só estará disponível se a VM N1 usar a interface de rede gvnic, não tiver discos SSD locais ou GPUs anexados e não fizer parte de um grupo gerenciado de instâncias (MIG). A realização desse procedimento com uma VM N1 com uma interface de rede VirtIO gera um erro de incompatibilidade da VM.

Interrompa a VM usando o método instances.stop.
Remova os discos usando o método instances.detachDisk para remover o disco de inicialização do Persistent Disk original da VM N1. Você também precisa desconectar todos os discos de dados da VM.
```
https://compute.googleapis.com/compute/v1/projects/PROJECT_NAME/zones/ZONE/instances/VM_NAME/detachDisk?deviceName=DISK_NAME
```
Substitua:
- PROJECT_NAME: o nome do projeto.
- ZONE: a zona em que o disco está localizado.
- VM_NAME: o nome da VM de origem com o disco pd-ssd anexado a ela.
- DISK_NAME: o disco que você quer remover.
Faça um snapshot dos discos. Use o método disks.createSnapshot para criar um snapshot do disco de inicialização do Persistent Disk e dos discos de dados conectados à instância.
Crie discos de inicialização e de dados do Hyperdisk Balanced usando o método disks.insert e inclua o name do disco Hyperdisk Balanced, sourceSnapshot do novo Hyperdisk Balanced, o type do disco, Hyperdisk Balanced, e sizeGB do disco no corpo da solicitação.
Faça um upgrade do tipo de máquina no local usando o método instances.setMachineType e inclua o machineType no corpo da solicitação:
```
POST  https://compute.googleapis.com/compute/v1/projects/PROJECT_NAME/zones/ZONEinstances/VM_NAME/setMachineTypeMACHINE_TYPE
```
Substitua:
- PROJECT_NAME: o nome do projeto.
- ZONE: a zona em que o disco está localizado.
- VM_NAME: o nome da VM que vai receber o upgrade.
- MACHINE_TYPE: o novo tipo de máquina.
No corpo da solicitação, inclua o seguinte:
```
{
 "machineType": "projects/PROJECT_NAME/zones/ZONE/machineTypes/MACHINE_TYPE",
}
```
Use o método instances.attachDisk para anexar o novo disco de inicialização Hyperdisk Balanced e os discos de dados Hyperdisk Balanced à VM N4.
```
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_NAME/zones/ZONE/instancesVM_NAMEattachDiskDISK_NAME
```
Substitua:
- PROJECT_NAME: o nome do projeto.
- ZONE: a zona em que o disco está localizado.
- VM_NAME: o nome da instância de VM de origem com o disco pd-ssd anexado a ela.
- DISK_NAME O disco que você quer anexar.
No corpo da solicitação, inclua o seguinte:
```
{
"source": "projects/your-project/zones/us-central1-a/disks/my-hdb-boot-disk",
"deviceName":"my-hdb-boot-disk","boot":true
}
```
```
{
"source": "projects/your-project/zones/us-central1-a/disks/my-hdb-data-disk",
"deviceName":"my-hdb-data-disk","boot":false
}
```
Inicie a VM N4 usando o método instances.start.
```
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_NAME/zones/ZONEinstances/VM_NAME/start
```
Substitua:
- PROJECT_NAME: o nome do projeto.
- ZONE: a zona em que o disco está localizado.
- VM_NAME: o nome da VM.

Limpar

Depois de verificar se você pode se conectar à nova VM e se a carga de trabalho está sendo executada conforme o esperado, remova os recursos que não são mais necessários:

Os snapshots criados para os discos anexados à VM de origem.
Qualquer programação de snapshots para os discos anexados à VM de origem.
O disco temporário criado para copiar os dados do SSD local para a nova VM.
A VM de origem e todos os discos anexados.

A seguir

Leia sobre os problemas conhecidos do Linux e do Windows Server.
Leia as dicas de solução de problemas.
Saiba mais sobre o ciclo de vida da migração.

Mover a carga de trabalho para uma nova instância de computação

Antes de começar

Console

gcloud

REST

Funções exigidas

Permissões necessárias

Avaliar as opções de migração de VM

Requisitos de computação

Requisitos de armazenamento

Requisitos de rede

Preparar a migração das VMs atuais

Preparar recursos de computação

Preparar recursos de armazenamento

Preparar recursos de rede

Preparar o sistema operacional SUSE Enterprise Linux Server

Mover a carga de trabalho para a nova VM

Permissões exigidas para a tarefa

Criar a nova VM

Depois que a instância é iniciada

Exemplo de migração de n1-standard-8 para n4-standard-8

gcloud

REST

Limpar

A seguir