Migrar cargas de trabalho de hardware ve1 desativado

Este documento explica como migrar suas cargas de trabalho do Google Cloud VMware Engine do hardware ve1 desativado para o hardware ve1 ou ve2 com suporte. É possível migrar cargas de trabalho usando um dos dois métodos: a opção 1 envolve a adição de novos clusters de hardware a uma nuvem privada atual para criar uma nuvem privada de nó misto, enquanto a opção 2 envolve a implantação de uma nova nuvem privada usando um novo hardware.

Google Cloud está desativando o hardware ve1 de primeira geração de forma contínua à medida que a infraestrutura física atinge o fim da vida útil. As desativações ocorrem em lotes com base em grupos de posicionamento em diferentes regiões de serviço.

Quando Google Cloud agenda seu hardware para desativação, você recebe uma notificação de fim da vida útil (EoL, na sigla em inglês) direcionada que contém um cronograma detalhado, limites de recursos e instruções de migração. Essas notificações direcionadas começam a ser lançadas no primeiro trimestre de 2026, e os primeiros lotes de hardware ve1 chegam ao fim da vida útil até o primeiro trimestre de 2027. À medida que o grupo de posições atinge a data de desativação programada, é possível migrar as cargas de trabalho para um hardware mais recente.

Este documento descreve os detalhes do aviso de EoL e as etapas para migrar as cargas de trabalho. Para manter a continuidade do serviço e garantir a cobertura do contrato de nível de serviço (SLA), conclua a migração antes que os clusters atinjam as datas de EoL.

Antes de começar

Antes de configurar novos recursos, consulte os requisitos, as limitações e os fatores que podem bloquear a migração nesta seção. Essas informações ajudam a planejar uma migração bem-sucedida e evitar interrupções de serviço.

Os requisitos críticos a serem considerados antes de iniciar uma migração são os seguintes:

  • Janela de migração estrita de 60 dias:o Google oferece suporte à migração por no máximo 60 dias após a aprovação da solicitação de cota de capacidade de destino:
    • É necessário concluir a migração da carga de trabalho e desativar o hardware desativado dentro desse período.
    • Se a duração da migração da carga de trabalho exceder 60 dias após o provisionamento do cluster de destino, será necessário trazer sua própria licença da Broadcom (BYOL, na sigla em inglês) para cobrir qualquer consumo que exceda os direitos padrão.

Os fatores que podem bloquear a migração são os seguintes:

  • Bloqueador de espaço de endereço IP (bloqueador da opção 1) : a opção 1 (nuvem privada de nó misto) exige que a nuvem privada atual tenha espaço de endereço IP de gerenciamento livre suficiente. É necessário espaço suficiente para oferecer suporte ao cluster de destino adicionado, que exige um mínimo de três nós. Se o bloco CIDR atual não oferecer suporte a pelo menos três nós adicionais, não será possível usar a opção 1. Nesse caso, implante uma nova nuvem privada (opção 2). Consulte a capacidade do plano para o espaço de endereço IP para determinar sua qualificação.
  • Suporte ao banco de dados de migração em tempo real:algumas plataformas de banco de dados não toleram migrações vMotion em tempo real. Identifique essas instâncias de banco de dados de VM e planeje a recriação delas diretamente no cluster de destino.
  • Conectividade do VMware HCX:os dispositivos do VMware HCX Fleet não oferecem suporte ao vMotion em tempo real padrão. É necessário planejar a reimplantação das malhas de serviço do HCX no cluster de destino. Para mais informações, consulte o artigo da Broadcom Migrar dispositivos HCX para um SSO, PSC ou vCenter diferente (em inglês).

Capacidade do plano para o espaço de endereço IP

Se você migrar usando uma nuvem privada de nó misto (opção 1), verifique se a nuvem privada atual tem espaço disponível suficiente no intervalo de endereços IP de gerenciamento. O cluster de destino adicionado exige um mínimo de três nós.

  1. Consulte o intervalo de endereços IP de gerenciamento e a versão do plano de IP da nuvem privada. Para referência, consulte Versões de divisão do intervalo CIDR de sub-redes.
  2. Conte o número atual de nós na nuvem privada.
  3. Verifique o número máximo de nós com suporte do tamanho do CIDR. Consulte a tabela de tamanho do intervalo CIDR das sub-redes vSphere e vSAN.
  4. Calcular: Existing node count + 3 ≤ maximum nodes supported by CIDR size

Se o bloco CIDR não oferecer suporte a pelo menos três nós adicionais, não será possível usar uma nuvem privada de nó misto. Nesse caso, implante uma nova nuvem privada (opção 2).

Planejar a capacidade do nó

Se a oferta de capacidade futura especificar nós ve2, trabalhe com sua equipe de contas para dimensionar e determinar os tipos de nó ve2 corretos (mega, large, standard, ou small) e as contagens para suas cargas de trabalho. Google Cloud Consulte os tipos de nós HCI do VMware Engine para especificações técnicas.

Requisitos de licença e software

Considere os seguintes requisitos de licença e software para sua migração:

  • Licenças da Broadcom: se a duração da migração da carga de trabalho exceder 60 dias após o provisionamento do cluster de destino, será necessário trazer sua própria licença da Broadcom para cobrir qualquer consumo que exceda seus direitos padrão.
  • Malhas de serviço do VMware HCX: os dispositivos do VMware HCX Fleet não oferecem suporte ao vMotion. É necessário reimplantar as malhas de serviço do HCX no cluster de destino. Para mais informações, consulte o artigo da Broadcom Migrar dispositivos HCX para um SSO, PSC ou vCenter diferente.
  • Grupos de posicionamento de gerenciamento: o Google provisiona capacidade nos grupos de posicionamento corretos. Para configurações de nó misto, o Cloud Customer Care configura o novo cluster no grupo de posicionamento de destino. Para novas nuvens privadas, envie o nome da nuvem privada planejada para sua equipe de conta antes de criar a nuvem privada para garantir que o Google a configure no grupo de posições correto.

Planejar compromissos e faturamento

Antes de selecionar um caminho de migração, consulte as seguintes restrições para descontos por compromisso de uso (CUDs):

  • Limitações de CUD ve1:apenas CUDs ve1 de um ano com opções de preços de licença portátil estão disponíveis. Para aplicar um novo compromisso de um ano, é necessário migrar para um novo grupo de posições ve1 na mesma região.
  • Suporte a CUD ve2:os compromissos de CUD de três anos só são aceitos nas famílias de nós ve2.
  • Verificação de qualificação:como os novos compromissos dependem da vida útil restante dos grupos de posicionamento de nós na sua região, é necessário trabalhar com sua Google Cloud equipe de contas para verificar sua qualificação.

Entender o aviso de fim da vida útil do ve1

O aviso de fim da vida útil (EoL) ve1 é um e-mail oficial que informa que os nós bare metal ve1 estão chegando ao fim da vida útil.

Principais componentes do aviso de EoL

O aviso inclui os seguintes detalhes:

  • Região e zona em que o aviso de EoL se aplica.
  • Uso atual: lista todos os projetos ativos e ve1 nuvens privadas na região, detalhando:
    • Nome da nuvem privada
    • Número do projeto
    • Nome do cluster
    • Tipo de nó ve1 (HCI ou SON)
    • Número de nós ve1 de cada tipo
    • Data de fim da vida útil após a qual o cluster não tem mais suporte
  • Oferta de capacidade futura: o aviso de EoL oferece uma oferta de capacidade futura para cada ve1 cluster na região:
    • Se a oferta de capacidade de destino for ve1: o mesmo número de nós que no cluster ve1 atual, com uma configuração de vida útil suficientemente maior.
    • Se a oferta de capacidade de destino for ve2: tipo de nó ve2-mega-128, que oferece recursos de capacidade de computação, memória e armazenamento equivalentes ou maiores.
    • SLA e tolerância a falhas (FTT): para qualquer cluster com três ou mais nós, a oferta futura consiste em um mínimo de três nós. Isso garante um valor de FTT padrão de 1.

Principais etapas de migração

A migração consiste na seguinte sequência de etapas:

  1. Analise a oferta de capacidade de destino para cada cluster sujeito ao EoL. Se você precisar de uma configuração diferente (tipos ou quantidade de nós), trabalhe com sua Google Cloud equipe de contas para ajustar a oferta de capacidade.
  2. Gerenciar descontos por compromisso de uso (CUDs): se você tiver compromissos de CUD ve1 ativos que sobrevivem às datas de EoL do hardware, trabalhe com sua equipe de contas para ajustá-los ou encerrá-los.
  3. Selecione o caminho de migração: escolha entre criar uma nuvem privada de família de nós mistos ou uma nova implantação de nuvem privada. Para ajudar você a decidir, compare os métodos de migração na seção a seguir.
  4. Executar a migração: migre as cargas de trabalho usando o caminho escolhido. Você tem uma janela de suporte máxima de 60 dias para concluir a migração depois que o Google aprovar sua solicitação de cota.
  5. Desativar o hardware antigo: exclua os clusters ve1 desativados e as cotas associadas para concluir a migração.

Comparar opções de migração

Escolher o caminho de migração correto ajuda a configurar a rede corretamente. Ele também ajuda a evitar interrupções de serviço durante a migração. A tabela a seguir compara os critérios técnicos, de rede e operacionais de cada opção.

Recurso Opção 1: nuvem privada de nó misto (híbrida) Opção 2: nova implantação de nuvem privada
Descrição Adicione clusters de família de hardware de destino diretamente à nuvem privada atual. Implante uma nuvem privada totalmente nova no hardware de destino.
Requisito para intervalo de IP de gerenciamento Exige espaço CIDR livre suficiente na nuvem privada atual para oferecer suporte ao cluster adicionado (mínimo de três nós). Espaço insuficiente é um fator de bloqueio para a opção 1. Flexível. Usa um novo intervalo de endereços IP de gerenciamento.
Impacto na rede e no DNS Mínima. Preserva as redes, sub-redes e interfaces de gerenciamento atuais. Alto. Exige a configuração de novas topologias de rede, DNS e coordenadas de acesso.
Fluxo de trabalho de migração VMware vMotion e Storage vMotion padrão em tempo real. Migrações em grande escala usando o VMware HCX.
Método de criação Solicitado usando o tíquete do Cloud Customer Care (não é possível adicionar clusters a nuvens privadas híbridas). Totalmente self-service (console, API REST, Google Cloud CLI ou Terraform).

Opção 1: migração de nuvem privada de nó misto

Esse método permite adicionar clusters de família de hardware de destino diretamente à nuvem privada atual e migrar cargas de trabalho cluster por cluster. O limite de migração de 60 dias se aplica a cada migração de cluster.

Enviar uma solicitação de cota para hardware de destino

  1. No Google Cloud console, envie uma solicitação de cota para a nova família de hardware de destino (ve1 ou ve2) e contagens de nós.
  2. Na descrição da solicitação de cota, escreva explicitamente as seguintes propriedades:
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"
  3. Depois que o Google aprovar a solicitação, será possível conferir a nova cota no console.

Criar o cluster de destino na nuvem privada

  1. Não é possível criar clusters em nuvens privadas de nó misto. Envie um tíquete de suporte para solicitar a configuração do cluster.
  2. Forneça os seguintes detalhes no tíquete de suporte:
    • Número do projeto
    • Nome da nuvem privada
    • Novo nome do cluster de destino
    • Nova família de máquinas (ve1 ou ve2) e tipo de nó
    • Contagem de nós HCI
    • Contagem de nós somente de armazenamento (se aplicável)
  3. O Cloud Customer Care notifica você quando o cluster de destino está on-line.

Migrar cargas de trabalho

Depois que o cluster de destino estiver pronto, use a combinação do VMware vMotion e do Storage vMotion para migrar VMs de carga de trabalho e discos de VM:

  1. No vSphere Client, clique com o botão direito do mouse na VM e selecione Migrar.
  2. Selecione Alterar o recurso de computação e o armazenamento.
  3. Escolha o novo cluster e os datastores de destino.

Migrar VMs de gerenciamento de nuvem privada

Se o cluster que você está desativando for o cluster principal (primeiro) da nuvem privada, será necessário migrar as VMs de gerenciamento:

  1. Use o console do Google Cloud VMware Engine ou a API REST para migrar VMs de gerenciamento para o novo cluster. Para instruções detalhadas, consulte Gerenciar recursos de nuvem privada.
  2. Não realize outras atividades de cluster (como adicionar nós) durante a migração. O status da nuvem privada muda para "atualizando" durante o processo.
  3. Desmonte todos os datastores NFS conectados aos clusters ve1 antigos.

Ajustar outras configurações e aplicativos

  • Malhas de serviço do VMware HCX: os dispositivos do Fleet não oferecem suporte ao vMotion. Reimplante os componentes da malha de serviço do HCX no cluster de destino. Para mais informações, consulte o artigo da Broadcom Migrar dispositivos HCX para um SSO, PSC ou vCenter diferente. Envie um tíquete de suporte se precisar de ajuda.
  • Aplicativos Aria: migre VMs de aplicativos Aria de maneira semelhante às VMs de carga de trabalho padrão.
  • Plataformas de banco de dados: recrie instâncias de banco de dados no cluster de destino se elas não tolerarem o vMotion.

Desativar o cluster desativado

  1. Depois de concluir e verificar a migração de cargas de trabalho e VMs de gerenciamento, exclua o cluster desativado usando o Google Cloud console, a API REST ou a linha de comando da Google Cloud CLI.
  2. Envie uma solicitação de cota para reduzir a cota do hardware do cluster de origem. Na descrição da solicitação, especifique:
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"

Opção 2: migração de nova nuvem privada

Esse método permite implantar uma nuvem privada totalmente nova no hardware de destino e migrar cargas de trabalho da nuvem privada desativada usando o VMware HCX.

Solicitação de cotas

  1. Envie uma solicitação de cota para o hardware de destino.
  2. Na descrição da solicitação, escreva explicitamente:
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"
    • "New PC Name: [YOUR_NEW_PC_NAME]"

Criar a nova nuvem privada

  1. Use o Google Cloud console, a API REST, a CLI do Google Cloud ou o Terraform para implantar sua nova nuvem privada no hardware de destino.
  2. Se a implantação atual usar uma rede legada do VMware Engine (uma rede do VMware Engine criada antes de novembro de 2022), crie a nova nuvem privada no mesmo projeto para continuar usando uma rede legada do VMware Engine. Para mais informações, consulte Redes padrão e legadas do Google Cloud VMware Engine.

Migrar cargas de trabalho usando o HCX

  1. Configure o VMware HCX na nova nuvem privada.
  2. Vincule as configurações do HCX e configure as malhas de migração para mover cargas de trabalho e dados dos clusters de nuvem privada desativados. Se a nuvem privada desativada tiver vários clusters, verifique se os perfis de computação e as malhas de serviço do HCX estão configurados para incluir todos os clusters dos quais você precisa migrar cargas de trabalho.
  3. Planeje lotes de migração durante as janelas de manutenção adequadas.

Ajustar serviços e aplicativos

  • VMware HCX: implante malhas de serviço do HCX na nova nuvem privada.
  • Produtos Aria: se você usa pacotes Aria licenciados pelo Google, solicite suporte para instalar o Aria Suite Lifecycle Manager (LCM) na nova nuvem privada.

Desativar a nuvem privada antiga

  1. Depois de verificar se todas as cargas de trabalho funcionam na nova nuvem privada, exclua os clusters antigos e a própria nuvem privada.
  2. Envie uma solicitação de cota para liberar a cota desativada. Na descrição da solicitação, especifique:
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"

Gerenciar compromissos e faturamento

Trabalhe com sua equipe de contas para organizar as estruturas de faturamento e alinhar os descontos por compromisso de uso (CUDs) durante a migração.

Ajustes de desconto por compromisso de uso (CUD)

O impacto das migrações de hardware ve1 nos seus descontos por compromisso de uso (CUDs) ve1 ativos depende do cronograma e das ofertas de capacidade:

  • Sobreposição de cronograma: se os compromissos CUD expirarem antes da data de EoL do grupo de posicionamento de nós atual, o faturamento não será alterado.
  • Migração em nós ve1: se a oferta de capacidade de destino usar um novo ve1 hardware, os compromissos de CUD permanecerão válidos durante o período.
  • Migração para nós ve2: como os tipos de CUDs são vinculados a categorias de hardware específicas, é necessário trabalhar com sua equipe de contas para encerrar ou converter contratos ve1 ativos:
    • CUDs não conversíveis: é necessário cancelar os CUDs padrão atuais e comprar novos CUDs ve2 padrão.
    • CUDs conversíveis: é possível converter CUDs ve1 padrão ativos em CUDs de licença portátil ve2.
Uso atual Cronogramas Oferta futura Impacto do CUD
ve1 Todos os CUDs ve1 expiram antes do EoL ve1 ou ve2 Os CUDs atuais não serão afetados.
ve1 Alguns CUDs ve1 expiram após o EoL ve1 A migração não vai afetar os CUDs atuais. O grupo de posições ve1 de destino tem vida útil suficiente.
ve1 Alguns CUDs ve1 não conversíveis expiram após o EoL ve2 É necessário encerrar os CUDs ve1 atuais e comprar novos CUDs ve2. Trabalhe com sua equipe de contas.
ve1 Alguns CUDs ve1 conversíveis expiram após o EoL ve2 Converta CUDs ve1 em CUDs ve2 de licença portátil apropriados. Trabalhe com sua equipe de contas.

A seguir