Migrar cargas de trabalho do 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 compatível. É possível migrar cargas de trabalho usando um de dois métodos: a opção 1 envolve adicionar novos clusters de hardware a uma nuvem privada atual para criar uma nuvem privada de nós mistos, enquanto a opção 2 envolve implantar uma nova nuvem privada usando hardware novo.

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

Quando o Google Cloud agenda a desativação do hardware, você recebe uma notificação de fim da vida útil (EoL, na sigla em inglês) com um cronograma detalhado, limites de recursos e instruções de migração. Essas notificações segmentadas vão começar a ser lançadas no 1º trimestre de 2026, e os primeiros lotes de hardware ve1 vão chegar ao fim da vida útil no 1º trimestre de 2027. À medida que seu grupo de posições se aproxima da data de desativação programada, você pode migrar suas cargas de trabalho para um hardware mais novo.

Este documento descreve os detalhes do aviso de fim da vida útil e as etapas para migrar suas 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 fim da vida útil.

Antes de começar

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

Os requisitos importantes 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 à sua migração por um máximo de 60 dias após a aprovação da solicitação de cota de capacidade de destino:
    • Você precisa concluir a migração da carga de trabalho e desativar o hardware descontinuado nesse período.
    • Se a migração da carga de trabalho durar mais de 60 dias após o provisionamento do cluster de destino, você precisará trazer sua própria licença da Broadcom (BYOL) para cobrir qualquer consumo que exceda os direitos padrão.

Estes são os fatores que podem bloquear sua migração:

  • Bloqueador de espaço de endereço IP (bloqueador da opção 1): a opção 1 (nuvem privada de nó misto) exige que sua nuvem privada atual tenha espaço livre suficiente de endereço IP de gerenciamento. Você precisa de 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 puder 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 Planejar a capacidade para o espaço de endereço IP e determine se você atende aos requisitos.
  • Suporte a 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 recriá-las diretamente no cluster de destino.
  • Conectividade do VMware HCX:os dispositivos do VMware HCX Fleet não são compatíveis com o vMotion em tempo real padrão. Planeje 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.

Planejar a capacidade do 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 requer um mínimo de três nós.

  1. Confira o intervalo de endereços IP de gerenciamento e a versão do plano de IP da sua 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 sua nuvem privada.
  3. Verifique o número máximo de nós compatíveis com o tamanho do CIDR. Consulte a tabela 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 puder oferecer suporte a pelo menos três nós adicionais, não será possível usar uma nuvem privada de nós mistos. 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 conta do Google Cloud para dimensionar e determinar os tipos de nós ve2 corretos (mega, large, standard ou small) e as contagens para suas cargas de trabalho. Consulte Tipos de nós de 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 sua carga de trabalho exceder 60 dias após o provisionamento do cluster de destino, você precisará 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 posições de gerenciamento: o Google provisiona a capacidade nos grupos de posições corretos. Para configurações de nós mistos, o Cloud Customer Care configura o novo cluster no grupo de posições de destino. Para novas nuvens privadas, envie o nome planejado para sua equipe de conta antes de criar a nuvem privada para garantir que o Google a configure no grupo de posições correto.

Compromissos e faturamento do plano

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

  • Limitações do CUD ve1:apenas CUDs de um ano ve1 com opções de preços de licença portátil estão disponíveis. Para aplicar um novo contrato de um ano, migre para um novo grupo de veiculações ve1 na mesma região.
  • Suporte a CUDs do 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 do tempo restante dos grupos de posicionamento de nós na sua região, trabalhe com sua equipe de conta do Google Cloud para verificar sua qualificação.

Entenda o aviso de fim da vida útil do ve1

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

Principais componentes do aviso de fim da vida útil

O aviso inclui os seguintes detalhes:

  • Região e zona em que o aviso de fim da vida útil se aplica.
  • Seu uso atual: lista todos os seus projetos ativos e nuvens ve1 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 terá mais suporte
  • Oferta de capacidade futura: o aviso de fim da vida útil oferece uma oferta de capacidade futura para cada cluster ve1 na região:
    • Se a opção de capacidade desejada for ve1: o mesmo número de nós do cluster ve1 atual, com uma configuração de vida útil suficientemente mais longa.
    • Se a oferta de capacidade de destino for ve2: tipo de nó ve2-mega-128, oferecendo recursos equivalentes ou maiores de computação, memória e capacidade de armazenamento.
    • SLA e falha de tolerância (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 padrão de FTT de 1.

Principais etapas de migração

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

  1. Revise a oferta de capacidade de destino para cada cluster sujeito ao fim da vida útil. Se você precisar de uma configuração diferente (tipos ou quantidade de nós), trabalhe com sua equipe de conta doGoogle Cloud para ajustar a oferta de capacidade.
  2. Gerencie os descontos por uso contínuo (CUDs): se você tiver compromissos ativos de CUD do ve1 que vão além das datas de fim da vida útil do hardware, trabalhe com sua equipe de conta para ajustar ou encerrar esses compromissos.
  3. Selecione seu caminho de migração: crie 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. Execute a migração: migre suas cargas de trabalho usando o caminho escolhido. Você tem um período máximo de suporte de 60 dias para concluir a migração depois que o Google aprovar sua solicitação de cota.
  5. Desative 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 sua rede corretamente. Isso também ajuda a evitar interrupções no 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 híbrida com nós mistos Opção 2: implantação de uma nova 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 Requer espaço livre suficiente de CIDR na nuvem privada atual para oferecer suporte ao cluster adicionado (mínimo de três nós). O 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. Requer a configuração de novas topologias de rede, DNS e coordenadas de acesso.
Fluxo de trabalho de migração vMotion padrão do VMware e vMotion de armazenamento. Migrações em grande escala usando o VMware HCX.
Método de criação Solicitado usando um tíquete do Cloud Customer Care (não é possível adicionar clusters a nuvens privadas híbridas por conta própria). Totalmente self-service (console, API REST, Google Cloud CLI ou Terraform).

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

Com esse método, é possível adicionar clusters de família de hardware de destino diretamente à nuvem privada atual e migrar cargas de trabalho cluster por cluster. Observe que o limite de migração de 60 dias se aplica a cada migração de cluster.

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

  1. No console do Google Cloud , envie um pedido 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, você poderá conferir a nova cota no console.

Crie o cluster de destino na sua 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 da 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 de VMware vMotion e 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 Mudar o recurso de computação e o armazenamento.
  3. Escolha o novo cluster e os repositórios de dados de destino.

Migrar VMs de gerenciamento de nuvem privada

Se o cluster que você está desativando for o principal (primeiro) da nuvem privada, migre 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 do cluster (como adicionar nós) durante a migração. O status da nuvem privada muda para "Atualizando" durante o processo.
  3. Desmonte todos os repositórios de dados NFS conectados aos clusters ve1 antigos.

Ajustar outras configurações e aplicativos

  • Malhas de serviço do VMware HCX: os dispositivos da frota não são compatíveis com o 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 do Aria: migre VMs de aplicativos do Aria de maneira semelhante às VMs de carga de trabalho padrão.
  • Plataformas de banco de dados: recrie as 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 das cargas de trabalho e das VMs de gerenciamento, exclua o cluster desativado usando o console Google Cloud , 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 para uma nova nuvem privada

Esse método permite implantar uma nuvem privada completamente 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 console do Google Cloud , 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 (criada antes de novembro de 2022), crie a nova nuvem privada no mesmo projeto para continuar usando os recursos de rede padrão. 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 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 de que 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 da Aria: se você usa pacotes da Aria licenciados pelo Google, peça 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 uso contínuo (CUDs) durante a migração.

Incentivos de faturamento por uso duplo

Para ajudar a compensar as cobranças de uso simultâneo (duplo) associadas à execução das pegadas desativadas e de destino durante a janela de migração, o Google oferece incentivos para reduzir as cobranças de uso duplo por um período fixo. Planeje seu período de migração com cuidado para aproveitar esses incentivos.

Ajustes de desconto por compromisso de uso (CUD)

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

  • Sobreposição de linha do tempo: se seus compromissos de CUD expirarem antes da data de EOL do grupo de posicionamento de nós atual, o faturamento não vai mudar.
  • Migração em nós ve1: se a oferta de capacidade de destino usar novo hardware ve1, seus compromissos de CUD vão continuar válidos durante o prazo.
  • Migração para nós ve2: como os tipos de CUD estão vinculados a categorias de hardware específicas, trabalhe com sua equipe de conta para encerrar ou converter contratos ve1 ativos:
    • CUDs não conversíveis: você precisa cancelar os CUDs padrão atuais e comprar novos CUDs padrão de ve2.
    • CUDs conversíveis: é possível converter CUDs padrão ve1 ativos em CUDs ve2 de licença portátil.
Uso atual Cronogramas Oferta futura Impacto do CUD
ve1 Todos os ve1 CUDs expiram antes do fim da vida útil ve1 ou ve2 As CUDs atuais não serão afetadas.
ve1 Alguns CUDs do ve1 expiram após o fim da vida útil ve1 A migração não vai afetar as CUDs atuais. O grupo de posições de ve1 de destino tem vida útil suficiente.
ve1 Alguns CUDs ve1 não conversíveis expiram após o fim da vida útil ve2 Você precisa encerrar os CUDs ve1 atuais e comprar novos CUDs ve2. Trabalhe com sua equipe de conta.
ve1 Alguns CUDs conversíveis ve1 expiram após o fim da vida útil ve2 Converter CUDs de ve1 para CUDs de licença portátil ve2 adequados. Trabalhe com sua equipe de conta.

A seguir