Migra cargas de trabajo del hardware ve1 que se retirará

En este documento, se explica cómo migrar tus cargas de trabajo de Google Cloud VMware Engine del hardware ve1 que se retirará al hardware ve1 o ve2 compatible. Puedes migrar cargas de trabajo con uno de los dos métodos siguientes: La opción 1 implica agregar clústeres de hardware nuevos a una nube privada existente para crear una nube privada de nodos mixtos, mientras que la opción 2 implica implementar una nube privada nueva con hardware nuevo.

Google Cloud retirará el hardware de primera generación de ve1 de forma continua a medida que la infraestructura física llegue al final de su vida útil. Los retiros se producen en lotes según los grupos de colocación en diferentes regiones de servicio.

Cuando Google Cloud programa la baja de tu hardware, recibes una notificación específica sobre el final de la vida útil (EoL) que contiene un cronograma detallado, límites de recursos e instrucciones de migración. Estas notificaciones segmentadas comenzarán a lanzarse en el 1ᵉʳ trimestre de 2026, y los primeros lotes de hardware de ve1 llegarán al final de su ciclo de vida en el 1ᵉʳ trimestre de 2027. A medida que tu grupo de ubicación se acerca a la fecha de retiro programada, puedes migrar tus cargas de trabajo a hardware más nuevo.

En este documento, se describen los detalles del aviso de EoL y los pasos para migrar tus cargas de trabajo. Para mantener la continuidad del servicio y garantizar la cobertura del Acuerdo de Nivel de Servicio (ANS), completa la migración antes de que tus clústeres alcancen sus fechas de FdV.

Antes de comenzar

Antes de configurar recursos nuevos, revisa los requisitos, las limitaciones y los factores que podrían bloquear tu migración en esta sección. Esta información te ayuda a planificar una migración exitosa y evitar interrupciones del servicio.

Los requisitos críticos que debes tener en cuenta antes de comenzar una migración son los siguientes:

  • Período de migración estricto de 60 días: Google admite tu migración durante un máximo de 60 días después de aprobar tu solicitud de cuota de capacidad objetivo:
    • Debes completar la migración de la carga de trabajo y retirar el hardware obsoleto dentro de este período.
    • Si la duración de la migración de tu carga de trabajo supera los 60 días después de que aprovisiones el clúster de destino, debes usar tu propia licencia de Broadcom (BYOL) para cubrir cualquier consumo que supere los derechos estándar.

A continuación, se indican los factores que podrían bloquear tu migración:

  • Bloqueador de espacio de direcciones IP (bloqueador de la opción 1): La opción 1 (nube privada de nodos mixtos) requiere que tu nube privada existente tenga suficiente espacio de direcciones IP de administración libre. Necesitas suficiente espacio para admitir el clúster de destino agregado, que requiere un mínimo de tres nodos. Si tu bloque CIDR existente no admite al menos tres nodos adicionales, no puedes usar la opción 1. En este caso, debes implementar una nueva nube privada (opción 2). Revisa Planifica la capacidad para el espacio de direcciones IP para determinar tu elegibilidad.
  • Compatibilidad con bases de datos de migración en vivo: Algunas plataformas de bases de datos no admiten migraciones de vMotion en vivo. Identifica estas instancias de bases de datos de VM y planifica su recompilación directamente en el clúster de destino.
  • Conectividad de VMware HCX: Los dispositivos de VMware HCX Fleet no admiten la migración en vivo estándar de vMotion. Debes planificar la reimplementación de tus mallas de servicios de HCX en el clúster de destino. Para obtener más información, consulta el artículo de Broadcom Migrating HCX appliances to a different SSO, PSC, or vCenter.

Planifica la capacidad del espacio de direcciones IP

Si migras con una nube privada de nodos mixtos (opción 1), verifica que tu nube privada existente tenga suficiente espacio disponible en el rango de direcciones IP de administración. El clúster de destino agregado requiere un mínimo de tres nodos.

  1. Consulta el rango de direcciones IP de administración y la versión del plan de IP de tu nube privada. Para obtener más información, consulta Versiones de división del rango CIDR de subredes.
  2. Cuenta la cantidad actual de nodos en tu nube privada.
  3. Comprueba la cantidad máxima de nodos que admite tu tamaño de CIDR. Consulta la tabla Tamaño del rango CIDR de las subredes de vSphere y vSAN.
  4. Calcular: Existing node count + 3 ≤ maximum nodes supported by CIDR size

Si tu bloque CIDR no admite al menos tres nodos adicionales, no puedes usar una nube privada de nodos mixtos. En este caso, debes implementar una nueva nube privada (opción 2).

Planifica la capacidad de los nodos

Si tu oferta de capacidad futura especifica nodos ve2, trabaja con tu equipo de cuentas de Google Cloud para determinar el tamaño y los tipos de nodos ve2 correctos (mega, large, standard o small) y los recuentos para tus cargas de trabajo. Consulta Tipos de nodos de HCI de VMware Engine para conocer las especificaciones técnicas.

Requisitos de licencias y software

Ten en cuenta los siguientes requisitos de software y licencias para tu migración:

  • Licencias de Broadcom: Si la duración de la migración de la carga de trabajo supera los 60 días después de que aprovisiones el clúster de destino, debes proporcionar tu propia licencia de Broadcom para cubrir cualquier consumo que supere tus derechos estándar.
  • Mallas de servicio de VMware HCX: Los dispositivos de VMware HCX Fleet no admiten vMotion. Debes volver a implementar tus mallas de servicios de HCX en el clúster de destino. Para obtener más información, consulta el artículo de Broadcom Migrating HCX appliances to a different SSO, PSC, or vCenter.
  • Grupos de posiciones de administración: Google aprovisiona capacidad en los grupos de posiciones correctos. En el caso de las configuraciones de nodos mixtos, el equipo de Atención al cliente de Cloud configura el clúster nuevo en el grupo de ubicación de destino. En el caso de las nubes privadas nuevas, envía el nombre planificado de la nube privada a tu equipo de cuentas antes de crearla para asegurarte de que Google la configure en el grupo de ubicación correcto.

Compromisos del plan y facturación

Antes de seleccionar una ruta de migración, revisa las siguientes restricciones para los descuentos por compromiso de uso (CUD):

  • ve1 Limitaciones del CUD: Solo están disponibles los CUD de ve1 de un año con opciones de precios de licencias portátiles. Para aplicar cualquier compromiso nuevo de un año, debes migrar a un nuevo grupo de ubicación ve1 en la misma región.
  • ve2 Compatibilidad con CUD: Los compromisos de CUD de tres años solo se admiten en las familias de nodos ve2.
  • Verificación de elegibilidad: Dado que los compromisos nuevos dependen de la vida útil restante de los grupos de ubicación de nodos en tu región, debes trabajar con tu Google Cloud equipo de cuentas para verificar tu elegibilidad.

Información sobre el aviso de fin de ciclo de vida de ve1

El aviso de fin de ciclo de vida (EoL) de ve1 es un correo electrónico oficial que te informa que tus nodos de metal desnudo de ve1 están llegando al final de su vida útil.

Componentes clave del aviso de EoL

El aviso incluye los siguientes detalles:

  • Región y zona en las que se aplica el aviso de FdV.
  • Tu uso actual: Se enumeran todos tus proyectos activos y las nubes privadas de ve1 en la región, con los siguientes detalles:
    • Nombre de la nube privada
    • Número del proyecto
    • Nombre del clúster
    • Tipo de nodo ve1 (HCI o SON)
    • Cantidad de nodos ve1 de cada tipo
    • Fecha de finalización del ciclo de vida después de la cual el clúster ya no es compatible
  • Oferta de capacidad futura: El aviso de EoL proporciona una oferta de capacidad futura para cada clúster de ve1 en la región:
    • Si la oferta de capacidad objetivo es ve1: La misma cantidad de nodos que en el clúster ve1 actual, con una configuración de vida útil suficientemente más larga.
    • Si la oferta de capacidad objetivo es ve2: Tipo de nodo ve2-mega-128, que ofrece recursos de capacidad de procesamiento, memoria y almacenamiento equivalentes o superiores.
    • ANS y tolerancia a fallas (FTT): Para cualquier clúster con tres o más nodos, la oferta futura consta de un mínimo de tres nodos. Esto garantiza un valor predeterminado de FTT de 1.

Pasos clave de la migración

La migración consta de la siguiente secuencia de pasos:

  1. Revisa la oferta de capacidad objetivo para cada clúster sujeto al FdV. Si necesitas una configuración diferente (tipos o cantidad de nodos), trabaja con tuGoogle Cloud equipo de cuentas para ajustar la oferta de capacidad.
  2. Administra los descuentos por compromiso de uso (CUD): Si tienes compromisos de CUD ve1 activos que superan las fechas de fin de vida útil del hardware, trabaja con tu equipo de cuentas para ajustarlos o rescindirlos.
  3. Selecciona tu ruta de migración: Elige entre crear una nube privada con una familia de nodos mixtos o una nueva implementación de nube privada. Para ayudarte a decidir, compara los métodos de migración en la siguiente sección.
  4. Ejecuta la migración: Migra tus cargas de trabajo con la ruta elegida. Tienes un plazo máximo de asistencia de 60 días para completar la migración después de que Google apruebe tu solicitud de cuota.
  5. Retira el hardware anterior: Borra los clústeres ve1 que se retirarán y las cuotas asociadas para completar la migración.

Compara las opciones de migración

Elegir la ruta de migración correcta te ayuda a configurar tu red de forma adecuada. También te ayuda a evitar interrupciones del servicio durante la migración. En la siguiente tabla, se comparan los criterios técnicos, de red y operativos de cada opción.

Función Opción 1: Nube privada híbrida (con nodos mixtos) Opción 2: Nueva implementación de nube privada
Descripción Agrega clústeres de familias de hardware de destino directamente a la nube privada existente. Implementa una nube privada completamente nueva en el hardware de destino.
Requisito para el rango de IP de administración Requiere suficiente espacio libre de CIDR en la nube privada existente para admitir el clúster agregado (mínimo de tres nodos). El espacio insuficiente es un factor de bloqueo para la opción 1. Flexible. Usa un rango de direcciones IP de administración completamente nuevo.
Impacto en las redes y el DNS Es mínimo. Conserva las redes, las subredes y las interfaces de administración actuales. Alta. Requiere configurar nuevas topologías de red, DNS y coordenadas de acceso.
Flujo de trabajo de migración vMotion estándar en vivo de VMware y Storage vMotion Migraciones a gran escala con VMware HCX
Método de creación Se solicitó a través de un ticket de Atención al cliente de Cloud (no puedes agregar clústeres a nubes privadas híbridas por tu cuenta). Es completamente de autoservicio (consola, API de REST, Google Cloud CLI o Terraform).

Opción 1: Migración de nube privada de nodos mixtos

Este método te permite agregar clústeres de familias de hardware de destino directamente a tu nube privada existente y migrar cargas de trabajo clúster por clúster. Ten en cuenta que el límite de migración de 60 días se aplica a cada migración de clúster.

Envía una solicitud de cuota para el hardware de destino

  1. En la consola de Google Cloud , envía una solicitud de cuota para la nueva familia de hardware de destino (ve1 o ve2) y los recuentos de nodos.
  2. En la descripción de la solicitud de cuota, escribe explícitamente las siguientes propiedades:
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"
  3. Después de que Google apruebe la solicitud, podrás ver la nueva cuota en la consola.

Crea el clúster de destino en tu nube privada

  1. No puedes crear clústeres en nubes privadas de nodos mixtos por tu cuenta. Envía un ticket de asistencia para solicitar la configuración del clúster.
  2. Proporciona los siguientes detalles en el ticket de asistencia:
    • Número del proyecto
    • Nombre de la nube privada
    • Nombre del nuevo clúster de destino
    • Nueva familia de máquinas (ve1 o ve2) y tipo de nodo
    • Recuento de nodos de HCI
    • Recuento de nodos solo de almacenamiento (si corresponde)
  3. El equipo de Atención al cliente de Cloud te notificará cuando el clúster de destino esté en línea.

Migra cargas de trabajo

Una vez que el clúster de destino esté listo, usa la combinación de VMware vMotion y Storage vMotion para migrar las VMs de cargas de trabajo y los discos de VM:

  1. En vSphere Client, haz clic con el botón derecho en la VM y selecciona Migrate.
  2. Selecciona Cambiar el recurso de procesamiento y el almacenamiento.
  3. Elige el clúster nuevo y los almacenes de datos de destino.

Migra las VMs de administración de la nube privada

Si el clúster que das de baja es el principal (primero) de la nube privada, debes migrar las VMs de administración:

  1. Usa la consola de Google Cloud VMware Engine o la API de REST para migrar las VMs de administración al clúster nuevo. Para obtener instrucciones detalladas, consulta Administra recursos de la nube privada.
  2. No realices otras actividades del clúster (como agregar nodos) durante la migración. Durante el proceso, el estado de la nube privada cambia a En actualización.
  3. Desmonta los almacenes de datos de NFS conectados a los clústeres ve1 anteriores.

Ajusta otras configuraciones y aplicaciones

  • Mallas de servicio de VMware HCX: Los dispositivos de flota no admiten vMotion. Vuelve a implementar los componentes de la malla de servicios de HCX en el clúster de destino. Para obtener más información, consulta el artículo de Broadcom Migrating HCX appliances to a different SSO, PSC, or vCenter. Envía un ticket de asistencia si necesitas ayuda.
  • Aplicaciones de Aria: Migra las VMs de aplicaciones de Aria de forma similar a las VMs de cargas de trabajo estándar.
  • Plataformas de bases de datos: Vuelve a compilar las instancias de bases de datos en el clúster de destino si no admiten vMotion.

Retira el clúster retirado

  1. Después de completar y verificar la migración de las cargas de trabajo y las VMs de administración, borra el clúster que se retirará con la consola de Google Cloud , la API de REST o la línea de comandos de Google Cloud CLI.
  2. Envía una solicitud de cuota para reducir la cuota del hardware del clúster de origen. En la descripción de la solicitud, especifica lo siguiente:
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"

Opción 2: Migración a una nube privada nueva

Este método te permite implementar una nube privada completamente nueva en el hardware de destino y migrar cargas de trabajo de la nube privada que se retirará con VMware HCX.

Cuota de solicitudes

  1. Envía una solicitud de cuota para el hardware de destino.
  2. En la descripción de la solicitud, escribe explícitamente lo siguiente:
    • "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]"

Crea la nueva nube privada

  1. Usa la consola de Google Cloud , la API de REST, la CLI de Google Cloud CLI o Terraform para implementar tu nueva nube privada en el hardware de destino.
  2. Si tu implementación actual usa una red heredada de VMware Engine (una red de VMware Engine creada antes de noviembre de 2022), crea la nueva nube privada en el mismo proyecto para seguir usando las funciones de redes estándar. Para obtener más información, consulta Redes heredadas y estándar de Google Cloud VMware Engine.

Migra cargas de trabajo con HCX

  1. Configura VMware HCX en la nueva nube privada.
  2. Vincula las configuraciones de HCX y configura las mallas de migración para mover cargas de trabajo y datos de los clústeres de la nube privada que se retirarán. Si tu nube privada que se retirará tiene varios clústeres, asegúrate de que tus perfiles de procesamiento y mallas de servicio de HCX estén configurados para incluir todos los clústeres desde los que necesitas migrar cargas de trabajo.
  3. Planifica lotes de migración durante los períodos de mantenimiento adecuados.

Ajusta los servicios y las aplicaciones

  • VMware HCX: Implementa mallas de servicio de HCX en la nueva nube privada.
  • Productos de Aria: Si usas paquetes de Aria con licencia de Google, solicita asistencia para instalar Aria Suite Lifecycle Manager (LCM) en la nueva nube privada.

Retira la nube privada anterior

  1. Después de verificar que todas las cargas de trabajo funcionen en la nueva nube privada, borra los clústeres anteriores y la nube privada.
  2. Envía una solicitud de cuota para liberar la cuota retirada. En la descripción de la solicitud, especifica lo siguiente:
    • "ve1 hardware end of life"
    • "Retiring PC Name(s): [YOUR_PC_NAME(S)]"
    • "Retiring Cluster Name(s): [YOUR_CLUSTER_NAME(S)]"

Administra los compromisos y la facturación

Trabaja con tu equipo de cuentas para organizar las estructuras de facturación y alinear los descuentos por uso comprometido (CUD) durante la migración.

Incentivos de facturación por doble uso

Para ayudar a compensar los cargos por uso simultáneo (doble) asociados con la ejecución de tu cobertura retirada y la de destino durante el período de migración, Google ofrece incentivos para mitigar los cargos por uso doble durante un período fijo. Planifica cuidadosamente el período de migración para aprovechar estos incentivos.

Ajustes del descuento por compromiso de uso (CUD)

El impacto de tus migraciones de hardware de ve1 en tus descuentos por uso comprometido (CUD) activos de ve1 depende de los plazos y las ofertas de capacidad:

  • Superposición de la línea de tiempo: Si tus compromisos de CUD vencen antes de la fecha de fin de vida útil del grupo de colocación de nodos actual, tu facturación no cambiará.
  • Migración en nodos ve1: Si tu oferta de capacidad objetivo usa hardware ve1 nuevo, tus compromisos de CUD seguirán siendo válidos durante su plazo.
  • Migración a nodos ve2: Debido a que los tipos de CUD se vinculan a categorías de hardware específicas, debes trabajar con tu equipo de cuentas para rescindir o convertir los contratos de ve1 activos:
    • CUDs no convertibles: Debes cancelar los CUDs estándares existentes y comprar nuevos CUDs estándares de ve2.
    • CUDs convertibles: Puedes convertir los CUDs estándar ve1 activos en CUDs ve2 con licencia portátil.
Uso actual Líneas de tiempo Oferta futura Impacto del CUD
ve1 Todos los CUD de ve1 vencen antes del final del ciclo de vida ve1 o ve2 No se verán afectados los CUD existentes.
ve1 Algunos CUD de ve1 vencen después del final del ciclo de vida ve1 La migración no afectará los CUD existentes. El grupo de posiciones ve1 objetivo tiene suficiente vida útil.
ve1 Algunos CUDs ve1 no convertibles vencen después del FdV ve2 Debes cancelar los CUD existentes de ve1 y comprar CUD nuevos de ve2. Trabaja con tu equipo de cuentas.
ve1 Algunos CUDs convertibles ve1 vencen después del FdV ve2 Convertir los CUDs de ve1 a los CUDs de licencia portátil de ve2 correspondientes Trabaja con tu equipo de cuentas.

¿Qué sigue?