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) 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 de C2 para H3 para melhorar a largura de banda da 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.
  • Use recursos disponíveis apenas na nova instância de VM. Por exemplo, fazer upgrade de N4 para C4 para aproveitar opções adicionais de performance e manutenção.
  • Mude uma instância de máquina virtual (VM) para uma instância bare metal.
  • Adicione discos SSD locais à instância de VM C3 ou C3D.

Ao fazer upgrade para a série de máquinas de última geração, 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 a VM atual (de origem) atender às seguintes condições:

  • A versão do sistema operacional (SO) é compatível com a nova série de máquinas.
  • O tipo de disco do disco de inicialização anexado à VM de origem é compatível com a nova série de máquinas.
  • A VM não usa armazenamento SSD local.
  • Sua 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. After installing the Google Cloud CLI, initialize it by running the following command: 

        gcloud init

        If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

      2. Set a default region and zone.

        3. REST

        Para usar as amostras da API REST nesta página em um ambiente de desenvolvimento local, use as credenciais fornecidas para a CLI gcloud.

          After installing the Google Cloud CLI, initialize it by running the following command: 

          gcloud init

          If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

        Para mais informações, consulte Autenticar para usar REST na documentação de autenticação do Google Cloud .

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:

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 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 das 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 os tipos de máquina adequados à sua carga de trabalho. Considere se o aplicativo exige hardware específico (GPUs), alto desempenho ou custos mais baixos.
  • Revise 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, é compatível 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 possível série de máquinas. A nova série de máquinas pode não ser compatível com os mesmos recursos que você usa com a série atual, como tipos de máquinas personalizados, SSD local ou VM protegida.
  • Consulte as regiões e zonas para garantir que a nova série de máquinas esteja disponível em todas as regiões da sua VM atual. Talvez seja necessário ajustar os planos de implantação, alta disponibilidade e recuperação de desastres.
  • Revise seu 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 essa versão.
    • Se você estiver migrando para Arm e uma imagem 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 um driver de rede compatíveis.
  • 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, também é possível executar qualquer sistema operacional compatível com C3 metal, desde que o driver IDPF esteja ativado. As instâncias bare metal usam a interface de rede IDPF apresentada apenas como 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 e 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 em 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 são compatíveis apenas com os tipos de armazenamento Hyperdisk e SSD local.
    • As instâncias bare metal 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, crie 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, crie um novo disco de inicialização. Todos os dados no disco de inicialização de origem serão perdidos, a menos que você os copie para um disco temporário não inicializável. Em seguida, crie um novo disco de inicialização e copie os dados armazenados no disco temporário que 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á criar um snapshot do disco de inicialização atual e restaurá-lo para o novo tipo de disco compatível. Ao criar uma VM, é possível usar esse novo disco como disco de inicialização.
    • Se um disco que não é de inicialização usar um tipo 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, conforme descrito em Mudar o tipo de disco.
  • Não é possível mover discos SSD locais 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, copie os dados de volta para os discos SSD locais.
  • Se a instância de VM atual usa discos em um pool de armazenamento, mas você está movendo sua carga de trabalho para uma VM em uma região diferente, recrie 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. Verifique se os aplicativos e scripts usam nomes de dispositivos permanentes ou links simbólicos ao se referir aos discos anexados.

Requisitos de rede

Revise os seguintes requisitos de rede para sua 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) são compatíveis apenas com a interface de rede gVNIC.
    • As instâncias bare metal oferecem suporte apenas à interface de rede IDPF.

  • Verifique se o aplicativo e o sistema operacional são compatíveis com as interfaces disponíveis para a série de máquinas.

  • Revise a configuração de rede da VM para determinar se você precisa manter os endereços IP atribuídos. Se for o caso, você precisa promover os endereços IP para endereços IP estáticos.

  • Se você usa o desempenho de rede por VM 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 de Tier_1 com um tipo de máquina C2, mas não é necessário com uma VM H3.

Para determinar o tipo de interface de rede da sua VM atual, use o comando gcloud compute instances describe para ver o 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. Você precisa 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:

  1. Solicite cota na região e nas zonas em que você planeja mover seus recursos. Se você tiver uma cota para um tipo de máquina, poderá solicitar a movimentação dela. O processo leva alguns dias para ser concluído.
  2. Crie uma reserva para as novas instâncias de VM e garanta que os recursos da máquina estejam disponíveis na nova região e nas novas zonas. Entenda como os recursos reservados são consumidos e teste se é possível consumir recursos reservados.
  3. Estenda seus planos de alta disponibilidade e recuperação de desastres para incluir a nova região.
  4. Se necessário, faça upgrade do SO na VM atual.
    1. Se compatível com o fornecedor do sistema operacional, 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 uma atualização no local do SO não for compatível, ao criar uma nova VM, você precisará criar um novo disco de inicialização. 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 sejam de inicialização anexados à VM atual:
  5. Se aplicável à sua distribuição Linux, verifique as regras 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 da nova instância. 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 estas etapas para se preparar para mover os dados dos discos anexados à sua instância atual para uma nova instância:

  1. 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 de disco.
  2. Se você estiver migrando de uma VM que executa o Microsoft Windows:
  3. Se a nova VM não for compatível com os mesmos tipos de disco da 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.
  4. Se a VM atual usa um tipo de disco para o disco de inicialização que não é compatível com a nova série de máquinas e você está 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.
  5. 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 compatível com a 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 esse disco temporário.

  6. Mude o tipo de disco de todos os discos conectados à VM atual que usam um tipo não compatível com a nova VM. Para mover os dados do disco para novos discos, crie snapshots deles. Também é possível transferir arquivos de uma VM para outra.

    1. É possível tirar os snapshots enquanto a VM está em execução, mas os dados gravados nos discos depois da captura não são incluídos. Como os snapshots são incrementais, é possível criar um segundo snapshot depois de parar 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 criar todos os snapshots de disco depois de interromper a VM. Recomendamos que você crie um snapshot de todos os discos anexados à 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 SSD locais 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 contidos nele. Por exemplo, se você fizer um snapshot de um disco de 1 TiB que está 85% cheio, ele pode levar 5 minutos para ser concluído. Mas, se você capturar um snapshot de um disco de 100 TiB que está 85% cheio, isso pode levar 11 minutos. Recomendamos que você faça snapshots de teste dos seus discos antes de iniciar o processo de migração para entender quanto tempo leva a criação de snapshots.

  7. Se você tiver um disco que possa ser colocado off-line, use a seguinte abordagem para mover os dados para um novo disco enquanto a VM de origem ainda está 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 instância atual para oferecer suporte à nova instância:

  1. Se a VM atual não usar gVNIC, crie uma instância com uma interface de rede que use gVNIC. Leia Visão geral do uso do gVNIC com as VMs do Compute Engine para entender as etapas necessárias ao criar uma instância.
  2. Se você estiver criando uma VM em uma nova região, crie uma rede VPC e sub-redes na nova região.
  3. Se você configurou contagens de fila NIC personalizadas, consulte Alocações de fila e alteração do tipo de máquina.
  4. Se você quiser manter os endereços IP usados pela VM de origem, promova-os para endereços IP estáticos.
  5. Cancele a atribuição do endereço IP estático antes de parar 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. Caso contrário, você vai se deparar com o problema conhecido que impede a inicialização correta da VM.

Antes de desligar o sistema, execute o seguinte comando 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 para a segunda geração de máquinas, leia as instruções na página Editar o tipo de máquina de uma VM. Se você quiser mudar o nome da VM, 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

Nesta seção, descrevemos 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 este procedimento, você cria uma nova instância de VM e move as cargas de trabalho para ela.

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

Criar a nova VM

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

  1. Se a VM de origem usar discos que não são de inicialização com um tipo compatível com a nova série de máquinas, remova os discos da VM.
  2. Interrompa a VM de origem.
  3. Crie snapshots de todos os discos ainda anexados à VM de origem.
  4. Crie uma instância de VM de computação usando uma imagem pública ou uma imagem personalizada configurada para usar gVNIC. Ao criar a nova VM, escolha as seguintes opções:
    • Selecione o tipo de máquina na série escolhida.
    • Selecione uma imagem de SO compatível ou use uma imagem personalizada que você criou anteriormente.
    • Selecione um tipo de disco compatível para o disco de inicialização.
    • Se você criou novos discos com base em 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 forem compatíveis com a nova instância, selecione gVNIC.
    • Especifique os endereços IP estáticos se você promoveu os endereços IP temporários da VM de origem.
  5. Inicie a nova VM.

Depois que a instância é iniciada

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

  1. Anexe os discos que você desconectou da VM de origem à nova VM.
  2. Para todos os discos anexados à VM de origem que usam um tipo não compatível com a nova VM, crie um disco com base em um snapshot e anexe-o à nova instância. Ao criar o novo disco, selecione um tipo compatível com a nova VM e especifique um tamanho pelo menos igual ao do disco original.
  3. Se a VM original usou uma política de recursos para qualquer disco recriado para a nova VM, adicione a política de recursos aos novos discos.
  4. 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 na nova instância necessários 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.
  5. 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 ativar os discos, é possível mover os dados do disco temporário para os discos SSD locais.
  6. Reatribua todos os endereços IP estáticos associados à VM de origem à nova VM.
  7. Conclua outras tarefas necessárias para tornar a nova VM altamente disponível, como configurar balanceadores de carga e atualizar as regras de encaminhamento.
  8. Opcional: atualize as entradas de DNS, se necessário, para a nova VM.
  9. Recomendado: programe backups de disco para os novos discos.
  10. Recomendado: se você mudou o SO para uma versão ou arquitetura diferente, recompile os aplicativos.

Se você encontrar problemas ao mover sua carga de trabalho, entre em contato com o gerente técnico de contas (TAM) ou a Professional Services Organization (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 executando 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 de uma VM N1 para uma VM N4:

Opção 1:se a VM N1 usar a interface de rede VirtIO, crie uma VM N4. O N4 oferece suporte apenas à interface de rede gvnic e aos discos Hyperdisk Balanced. Crie um snapshot dos discos de inicialização e de dados do Persistent Disk, crie discos balanceados de hiperdisco com base nesses snapshots, anexe os discos balanceados de hiperdisco e crie a nova VM N4 com os discos balanceados de hiperdisco.

Você também pode 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 balanceado do Hyperdisk com base no snapshot do disco de inicialização, mas anexar 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 permanente para discos balanceados do Hyperdisk. Primeiro, remova os discos de inicialização e de dados do Persistent Disk, crie snapshots deles, 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 desanexe-as.

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

gcloud

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

  1. Pare a VM usando gcloud compute instances stop:

    gcloud compute instances stop VM_NAME \
  --zone=ZONE

    Substitua:

    • VM_NAME O nome da sua VM n1-standard-8 atual.
    • ZONE: a zona em que a VM está localizada.

  2. Crie snapshots dos seus 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 conectados à 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.

  3. Crie um novo disco do Hyperdisk Balanced para o disco de dados repetindo a etapa anterior e especificando 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 com base no 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: a performance de IOPS do disco (por exemplo, 3600).
    • Opcional: PROVISIONED_THROUGHPUT: a capacidade de processamento para provisionar o disco (exemplo: 290).

  4. Repita a etapa anterior para cada disco com snapshot.

  5. 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 balanceado de hiperdisco criado 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 criado com base no disco de snapshot de origem anexado à VM n1-standard-8.

  6. 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 um upgrade no local da máquina:

Essa opção só está 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 SSDs locais ou GPUs anexados e não fizer parte de um grupo gerenciado de instâncias (MIG). Realizar esse procedimento com uma VM N1 com uma interface de rede VirtIO gera um erro de incompatibilidade de VM.

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

REST

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

  1. Pare 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 sua VM n1-standard-8 atual.

  2. Crie snapshots dos discos usando o método disks.createSnapshot para criar um snapshot do disco de inicialização e do disco de dados Persistent Disk conectados à 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 permanente 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 de que você planeja criar um snapshot.
    • SNAPSHOT_NAME: um nome para o snapshot, como hdb-boot-disk ou hdb-data-disk.

  3. Crie um disco Hyperdisk Balanced usando o método disks.insert. Faça isso duas vezes: uma para incluir o name do disco de inicialização balanceado do Hyperdisk 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"
}'

  4. 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.

  5. 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 um upgrade no local da máquina:

Essa opção só está 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). Realizar esse procedimento com uma VM N1 com uma interface de rede VirtIO gera um erro de incompatibilidade de VM.

  1. Pare a VM usando o método instances.stop.

  2. Remova os discos usando o método instances.detachDisk para remover o disco de inicialização do Persistent Disk original da VM N1. Também é necessário 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.
    • DISK_NAME: o disco que você quer remover.

  3. Crie snapshots 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.

  4. Crie discos de inicialização e de dados do Hyperdisk Balanced usando o método disks.insert inclua o name do disco do Hyperdisk Balanced, sourceSnapshot para o novo disco do Hyperdisk Balanced, o type do disco, o Hyperdisk Balanced e o sizeGB do disco no corpo da solicitação.

  5. Faça um upgrade do tipo de máquina no local usando o método instances.setMachineType 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",
}

  6. Use o método instances.attachDisk para anexar o novo disco de inicialização Hyperdisk Balanced e os discos de dados do 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.
    • 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
}

  7. 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 é possível se conectar à nova VM e se a carga de trabalho está sendo executada conforme o esperado na nova VM, remova os recursos que não são mais necessários:

  1. Os snapshots criados para os discos anexados à VM de origem.
  2. Quaisquer programações de snapshots para os discos anexados à VM de origem.
  3. O disco temporário criado para copiar os dados do SSD local para a nova VM.
  4. A VM de origem e todos os discos anexados.

A seguir