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: 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 ve1 de primera generación 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 ubicación en diferentes regiones de servicio.

Cuandoprogramatu hardware para el retiro, recibirás una notificación de fin de ciclo de vida (EoL) segmentada que contiene un cronograma detallado, límites de recursos y las instrucciones de migración. Google Cloud Estas notificaciones segmentadas comenzarán a implementarse en el primer trimestre de 2026, y los primeros lotes de hardware ve1 llegarán al final de su ciclo de vida en el primer trimestre de 2027. A medida que tu grupo de ubicación alcance la fecha de retiro programada, podrás 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 EoL.

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 ayudará a planificar una migración exitosa y evitar interrupciones del servicio.

Los requisitos fundamentales que debes tener en cuenta antes de iniciar 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 de destino:
    • Debes completar la migración de la carga de trabajo y retirar el hardware retirado dentro de este período.
    • Si la duración de la migración de la carga de trabajo supera los 60 días después de aprovisionar el clúster de destino, debes traer tu propia licencia de Broadcom (BYOL) para cubrir cualquier consumo que exceda los derechos estándar.

Los factores que podrían bloquear tu migración son los siguientes:

  • 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 puede admitir al menos tres nodos adicionales, no puedes usar la Opción 1. En este caso, debes implementar una nube privada nueva (Opción 2). Revisa la capacidad del plan para el espacio de direcciones IP para determinar tu elegibilidad.
  • Compatibilidad con la base de datos de migración en vivo: Algunas plataformas de bases de datos no pueden tolerar las migraciones de vMotion en vivo. Identifica estas instancias de base de datos de VM y planifica volver a crearlas directamente en el clúster de destino.
  • Conectividad de VMware HCX: Los dispositivos de VMware HCX Fleet no admiten vMotion en vivo estándar. Debes planificar 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 Migra dispositivos HCX a un SSO, PSC o vCenter diferente.

Planifica la capacidad para el espacio de direcciones IP

Si realizas la migración 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 información de referencia, consulta las versiones de división del rango CIDR de las subredes.
  2. Cuenta la cantidad actual de nodos en tu nube privada.
  3. Verifica los nodos máximos admitidos por el tamaño de tu CIDR. Consulta la tabla de tamaño del rango CIDR de las subredes de vSphere y vSAN.
  4. Calcula: Existing node count + 3 ≤ maximum nodes supported by CIDR size

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

Planifica la capacidad de los nodos

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

Requisitos de licencias y software

Ten en cuenta los siguientes requisitos de licencias y software 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 aprovisionar el clúster de destino, debes traer tu propia licencia de Broadcom para cubrir cualquier consumo que exceda tus derechos estándar.
  • Mallas de servicios 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 Migra dispositivos HCX a un SSO, PSC o vCenter diferente.
  • Grupos de ubicación de administración: Google aprovisiona capacidad en los grupos de ubicación correctos. Para 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. Para las nubes privadas nuevas, envía el nombre de la nube privada planificada a tu equipo de cuentas antes de crear la nube privada para asegurarte de que Google la configure en el grupo de ubicación correcto.

Planifica los compromisos y la facturación

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

  • Limitaciones de CUD ve1: Solo están disponibles los CUD 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.
  • Compatibilidad con CUD ve2: Los compromisos de CUD de tres años solo se admiten en las familias de nodos ve2.
  • Verificación de elegibilidad: Debido a 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.

Comprende tu 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 hardware físico 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 EoL.
  • Tu uso actual: Se enumeran todos tus proyectos activos y ve1 nubes privadas 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 fin de ciclo de vida después de la cual el clúster no es compatible
  • Oferta de capacidad futura: El aviso de EoL proporciona una oferta de capacidad futura para cada ve1 clúster en la región:
    • Si la oferta de capacidad de destino 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 de destino 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 de FTT predeterminado de 1.

Pasos clave de la migración

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

  1. Revisa la oferta de capacidad de destino para cada clúster sujeto a EoL. Si necesitas una configuración diferente (tipos o cantidad de nodos), trabaja con tu Google 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 sobreviven a las fechas de EoL 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 de familia de nodos mixtos o una implementación de nube privada nueva. 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 período de asistencia máximo 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 correcta. 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 para cada opción.

Función Opción 1: Nube privada de nodos mixtos (híbrida) Opción 2: Implementación de nube privada nueva
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 CIDR libre 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 la red y el DNS Es mínimo. Conserva las redes, las subredes y las interfaces de administración actuales. Alto. Requiere configurar nuevas topologías de red, DNS y coordenadas de acceso.
Flujo de trabajo de migración VMware vMotion y Storage vMotion en vivo estándar. Migraciones a gran escala con VMware HCX.
Método de creación Se solicita con un ticket de Atención al cliente de Cloud (no puedes agregar clústeres a nubes privadas híbridas por tu cuenta). Servicio 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 Google Cloud consola, 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 cuota nueva 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 notifica 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 carga 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 Change both compute resource and storage.
  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 retiras es el clúster 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. El estado de la nube privada cambia a actualización durante el proceso.
  3. Desmonta los almacenes de datos NFS conectados a los clústeres ve1 anteriores.

Ajusta otras configuraciones y aplicaciones

  • Mallas de servicios de VMware HCX: Los dispositivos de Fleet 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 Migra dispositivos HCX a un SSO, PSC o vCenter diferente. 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 carga de trabajo estándar.
  • Plataformas de bases de datos: Vuelve a crear instancias de bases de datos en el clúster de destino si no pueden tolerar 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 retirado con la Google Cloud consola, 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 de 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 Google Cloud consola, la API de REST, la 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 red estándar. Para obtener más información, consulta Redes estándar y heredadas 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á. Si tu nube privada que se retirará tiene varios clústeres, asegúrate de que tus perfiles de procesamiento de HCX y mallas de servicios 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 servicios 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 compromiso de uso (CUD) durante la migración.

Ajustes del descuento por compromiso de uso (CUD)

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

  • Superposición de cronograma: Si tus compromisos de CUD vencen antes de la fecha de EoL del grupo de ubicación de nodos actual, tu facturación no cambia.
  • Migración en nodos ve1: Si tu oferta de capacidad de destino 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 contratos ve1 activos:
    • CUD no convertibles: Debes cancelar los CUD estándar existentes y comprar CUD ve2 estándar nuevos.
    • CUD convertibles: Puedes convertir los CUD ve1 estándar activos en CUD ve2 de licencia portátil.
Uso actual Líneas de tiempo Oferta futura Impacto del CUD
ve1 Todos los CUD ve1 vencen antes del EoL ve1 o ve2 Los CUD existentes no se verán afectados.
ve1 Algunos CUD ve1 vencen después del EoL ve1 La migración no afectará los CUD existentes. El grupo de ubicación ve1 de destino tiene suficiente vida útil.
ve1 Algunos CUD ve1 no convertibles vencen después del EoL ve2 Debes rescindir los CUD ve1 existentes y comprar CUD ve2 nuevos. Trabaja con tu equipo de cuentas.
ve1 Algunos CUD ve1 convertibles vencen después del EoL ve2 Convierte los CUD ve1 en CUD ve2 de licencia portátil adecuados. Trabaja con tu equipo de cuentas.

¿Qué sigue?