Migración de cargas de trabajo a Azure VMware Solution

En este artículo se proporcionan instrucciones para ayudar a los responsables de la toma de decisiones a definir su estrategia de migración para Azure VMware Solution, incluidas las fases de planeación, ejecución y retirada.

Diagrama que muestra el proceso de microsoft Cloud Adoption Framework para la adopción de Azure VMware Solution.

Azure VMware Solution proporciona una ruta estructurada para migrar cargas de trabajo basadas en VMware a Azure con un cambio mínimo en la aplicación. El éxito depende de más de mover máquinas virtuales. Las organizaciones necesitan directivas de migración claras, criterios de evaluación de cargas de trabajo, estándares de validación y controles de ejecución que reducen el riesgo, mantienen la continuidad operativa y admiten objetivos de plataforma a largo plazo.

Recomendación: Defina la estrategia de migración, el enfoque de evaluación de cargas de trabajo, la secuencia de migración y los requisitos de validación antes de migrar cargas de trabajo a Azure VMware Solution.

1. Planeación de la migración

Antes de diseñar nada, hágase una idea clara de qué va a migrar, en qué orden y por qué. Use la metodología de Cloud Adoption Framework Plan para evaluar su patrimonio. Azure VMware Solution encaja mejor con un enfoque de rehospedaje, en los casos en que se necesita una interrupción mínima y no se prevé una modernización a corto plazo. No es el entorno adecuado para todas las aplicaciones, y es en la fase de planificación donde se decide.

1.1 Detección e inventario

Azure Migrate examina el entorno de vSphere local y crea un inventario de máquinas virtuales, su uso de recursos y sus dependencias. Estos datos sirven para determinar tanto el dimensionamiento (cuántos hosts se necesitan y de qué tipo) como la planificación por oleadas (qué cargas de trabajo se trasladan juntas). Azure Migrate no realiza el traslado a Azure VMware Solution. Proporciona la evidencia para ajustar el tamaño y secuenciar el proyecto.

1.2 Estrategia de migración

Azure VMware Solution admite principalmente el enfoque de rehospedaje. Las aplicaciones que necesitan un tratamiento de refactorización o de reestructuración de la arquitectura podrían beneficiarse más de los servicios de proceso nativos de Azure. Registre estas decisiones para que el plan refleje las opciones deliberadas en lugar de las predeterminadas. Consulte Selección de una estrategia de migración a la nube.

1.3 Evaluación de cargas de trabajo

No todas las cargas de trabajo son un candidato igualmente adecuado para Azure VMware Solution. Antes de asignar cargas de trabajo a las oleadas de migración, evalúe sus requisitos técnicos, dependencias operativas y ajuste a la plataforma. Una evaluación estructurada le ayuda a identificar los riesgos tempranos, validar la idoneidad y asegurarse de que los planes de migración reflejen las prioridades empresariales en lugar de las suposiciones.

1.3.1 Requisitos

Antes de asignar una carga de trabajo a una oleada de migración, evalúe los requisitos técnicos, operativos y empresariales que influyen en su éxito en Azure VMware Solution. Esta evaluación le ayuda a determinar la idoneidad de la plataforma, identificar posibles desafíos de migración y proporcionar la información necesaria para las decisiones de ajuste de tamaño, secuenciación y preparación. Al evaluar cada carga de trabajo, céntrese en:

  • Requisitos de rendimiento: Comprenda las demandas de CPU, memoria, IOPS de almacenamiento y rendimiento de red. Asigne estos requisitos a las SKU de host de Azure VMware Solution y a las directivas de almacenamiento de vSAN, incluidas la configuración de RAID y los valores de tolerancia a errores (FTT).

  • Dependencias de la aplicación: Identifique los sistemas con los que se comunica cada carga de trabajo. Las dependencias determinan el planeamiento de oleadas de migración y si los sistemas dependientes deben moverse juntos.

  • Requisitos de compatibilidad: Confirme que los sistemas operativos invitados y el software de terceros son compatibles con Azure VMware Solution. La mayoría de las cargas de trabajo que se ejecutan en entornos locales con vSphere funcionan en Azure VMware Solution sin necesidad de modificaciones, pero valide en lugar de darlo por sentado y asegúrese de probar su estrategia de reversión para las migraciones que presenten problemas.

  • Requisitos de red: Documente los segmentos de red, las direcciones IP, las configuraciones dns y las reglas de firewall que requiere cada carga de trabajo. Identifique las cargas de trabajo sensibles a la latencia y asegúrese de que la arquitectura de red está optimizada para satisfacer sus demandas.

1.3.2 Tratamiento de carga de trabajo

La evaluación de la carga de trabajo identifica lo que necesita una carga de trabajo. El tratamiento de la carga de trabajo determina qué acción realizar. Los responsables de la toma de decisiones deben evaluar si cada aplicación pertenece a Azure VMware Solution, si debe permanecer en el entorno local o si las partes de la aplicación son mejor atendidas por servicios nativos de Azure. Para cada carga de trabajo, determine:

  • Si la carga de trabajo debe estar ahí. Las cargas de trabajo que ya se ejecutan bien en vSphere son candidatas naturales, especialmente aquellas que no tienen un plan de modernización a corto plazo. Para una carga de trabajo destinada a retirarse o a ser sustituida por una solución SaaS, evalúa si migrarla aporta valor o si debe permanecer donde está hasta el final de su vida útil.

  • Si cada nivel debe estar ahí. Una carga de trabajo suele tener más de un nivel, como un front-end web y una base de datos. Puede ejecutar las máquinas virtuales de la aplicación en Azure VMware Solution y conectarlas a servicios de datos nativos de Azure, como Azure SQL Database. Esa configuración proporciona ventajas de base de datos administradas junto con las cargas de trabajo de VMware y reduce los costos de host y licencia de VMware.

1.4 Preparación para la migración

Defina los requisitos operativos, de rendimiento, seguridad y gobernanza mínimos que cada carga de trabajo debe cumplir antes de aprobarlo para su uso en producción.

Aplique un marco de validación coherente en todas las oleadas de migración. El marco debe definir las verificaciones requeridas, los criterios de aprobación y las evidencias que los equipos deben aportar antes de la aprobación de la transición. Como mínimo, valide:

  • Estado de replicación de HCX

  • Enrutabilidad del segmento NSX

  • Estado del host ESXi

  • Alcance de los servicios de identidad y autenticación desde el segmento de destino

  • Estado de los servicios auxiliares, como la copia de seguridad y la supervisión

Decida si los equipos deben capturar las métricas de rendimiento de línea base del entorno de origen antes de la migración. Estas medidas proporcionan un punto de referencia para validar el rendimiento posterior a la migración e identificar las regresiones.

Antes de la migración, requiera que los equipos determinen si los registros DNS externos, las configuraciones del equilibrador de carga, los puntos de conexión de aplicación u otras dependencias de conectividad requieren actualizaciones. Incluya todos los cambios requeridos en el plan de cambio de producción por oleadas para reducir el riesgo de interrupción del servicio.

1.5 Secuencia de la migración de Azure VMware Solution

La secuenciación de migración determina qué cargas de trabajo se mueven a Azure VMware Solution primero, segundo, etc. La buena planificación de oleadas reduce el riesgo y evita interrupciones innecesarias.

  • Agrupar por dependencia: Use los datos de dependencia de la detección para buscar conjuntos de máquinas virtuales que funcionan estrechamente juntos, como un servidor de aplicaciones y su base de datos. Muévalos en la misma ola, por lo que el tráfico no cruza la red para cada solicitud cuando una parte todavía espera en el entorno local.

  • Identifique las reglas existentes: Documente cualquier regla de afinidad o antiafinidad de su entorno local y planifique cómo reproducirlas. Las directivas de ubicación de Azure VMware Solution imponen la afinidad entre máquinas virtuales y hosts, lo cual es importante para restricciones de licencia como las de SQL Server y para requisitos estrictos de rendimiento.

  • Secuencia por riesgo: Comience con cargas de trabajo de menor riesgo, como sistemas que no son de producción o aplicaciones con pocas dependencias. Su equipo adquiere confianza en el proceso antes de encargarse de aplicaciones críticas para el negocio. Pase a cargas de trabajo de mayor complejidad a medida que crece la experiencia.

  • Alinee la secuencia con los planes de ampliación de la red: Basa la secuencia en la topología de la red local. Cuando varias aplicaciones comparten un segmento de red, migrelas en la misma ola o en oleadas consecutivas. Después, puede migrar el segmento sin demora a una red nativa de Azure VMware Solution y eliminar la extensión temporal.

1.6 Herramientas de migración

Use VMware HCX para mover cargas de trabajo a Azure VMware Solution con una interrupción mínima. HCX Enterprise se incluye sin costo adicional e instala de forma predeterminada, lo que desbloquea opciones como Replication Assisted vMotion y Mobility Optimized Networking. No es necesario usar HCX y también puede incorporar cargas de trabajo físicas mediante una solución de migración de asociados.

1.6.1 Enfoque de migración

vMotion migra una carga de trabajo en ejecución sin tiempo de inactividad y, en Generation 2, suele ser más rápido que los métodos de transferencia masiva. La migración masiva y asistida por replicación puede ejecutarse más lentamente en la actualidad en la generación 2, por lo que debe planear ventanas más largas y programar oleadas en consecuencia. Consulte Consideraciones de diseño para la nube privada de generación 2 de Azure VMware Solution.

1.6.2 Gobernanza de extensiones de red

Algunos equipos tratan la extensión de red como un diseño permanente. Pero no lo es. Mantenga las extensiones abiertas solo para la ventana de migración. La extensión de red de HCX amplía una red local en Azure VMware Solution en el nivel 2, lo que permite a las cargas de trabajo mantener sus direcciones existentes durante el traslado. Este diseño evita volver a configurar las aplicaciones por adelantado y conlleva inconvenientes que un responsable de la toma de decisiones debe gobernar.

  • Dependencia local. Normalmente, una red extendida mantiene su puerta de enlace local, por lo que la carga de trabajo sigue dependiendo del sitio de origen después de moverla.

  • Enrutamiento ineficaz. El tráfico puede volver al entorno local y regresar, un patrón denominado tromboning que añade latencia y puntos de fallo.

Establezca una directiva firme. Extienda una red solo cuando una carga de trabajo no pueda cambiar su dirección y quite cada extensión una vez que se muevan sus cargas de trabajo. Evalúe primero la red local para saber qué segmentos necesitan extensión y durante cuánto tiempo. Esa evaluación sirve de base tanto para tu plan por fases como para el calendario de la extensión. Mobility Optimized Networking puede reducir el efecto trombón en casos concretos, así que confirma las configuraciones compatibles antes de activarlo. Consulte Configuración de la extensión de red de HCX.

2. Preparación de la migración

La siguiente secuencia de implementación refleja las dependencias entre fases. Cada paso supone que el paso anterior está completo y validado.

  1. Zona de aterrizaje de la plataforma: Asegúrese de que todos los servicios de red, identidad, seguridad y supervisión centralizados necesarios están listos para integrarse con las cargas de trabajo de VMware de Azure. Aplique las líneas de base de seguridad y gobernanza a través de Azure Policy a la jerarquía del grupo de administración que le ayude a lograr los requisitos de cumplimiento. La generación 2 se implementa dentro de tu red virtual, por lo que una directiva de base que impone reglas estrictas sobre los grupos de seguridad de red o las tablas de rutas puede bloquear la implementación. Quite esas directivas específicas de la red virtual de la nube privada antes de implementarlas y vuelva a aplicarlas después. Incorpore esta excepción en su planificación de referencia para que la gobernanza no frene el despliegue.

  2. Zonas de aterrizaje de carga de trabajo: Coloque las zonas de aterrizaje de carga de trabajo (suscripciones) en el grupo de administración correcto, en línea o interno ("Corp").

  3. Intervalos de direcciones IP: Reserve un bloque de direcciones /22 mínimo para la nube privada. Para la generación 2, reserva también dos bloques /24 adicionales para la administración y el enlace ascendente de HCX. Confirme que ninguno de estos rangos se solape con el espacio de direcciones de sus instalaciones locales, de Azure o de cualquier otra nube. No se puede corregir fácilmente esta condición después de la implementación. Consulte Consideraciones de diseño de generación 2.

  4. Solicitud de cuota: Solicitar cuota anticipada, ya que la asignación puede tardar hasta cinco días laborables. Solicite capacidad suficiente para el crecimiento y la recuperación ante desastres, como la redundancia N+1, que consiste en un host adicional al necesario para la carga de trabajo. Confirme la licencia Portable de VMware Cloud Foundation que requieren las nuevas implementaciones. Consulte Solicitud de cuota de host.

  5. Implementación de nube privada de Azure VMware Solution: Implemente la nube privada de Generación 2 en la red virtual de Azure. Consulte Creación de una nube privada de generación 2.

  6. Configuración de redes e identidades: Empareja la red de nube privada con el centro y establece la conectividad local. Conecte vCenter Server al origen de identidad externo para que los administradores inicien sesión con cuentas administradas en lugar de credenciales integradas compartidas.

  7. Supervisión y administración: Reenvíe los registros a la solución de administración de registros y configure las alertas de Service Health. Incorpore máquinas virtuales invitadas a través de Azure Arc para que pueda controlarlas con las mismas herramientas de Azure que use en otro lugar.

  8. Instalación de HCX: Instale HCX y pruebe la conectividad de sitio a sitio antes de iniciar la primera oleada.

3. Ejecución de la migración

Defina lo que significa "hecho" antes de cada onda. Una oleada se considera completada cuando se valida la carga de trabajo, se elimina la extensión de red y la aplicación funciona correctamente en su estado permanente.

Defina los criterios de reversión antes de cada oleada y pruebe la ruta de reversión antes de migrar los sistemas de producción. HCX admite la migración inversa y el enfoque exacto depende del tipo de migración que usó. Los criterios de éxito de Wave incluyen:

  1. Cada máquina virtual de la oleada se ejecuta sobre Azure VMware Solution y ya no depende de la extensión de red para el tráfico de producción.

  2. Cada aplicación es accesible por sus usuarios y sus sistemas dependientes.

  3. Cada máquina virtual aparece en las herramientas de supervisión sin advertencias ni errores.

  4. La reversión ya no es necesaria y se puede dar por cerrada formalmente.

  5. El rendimiento de la aplicación coincide o supera la línea base.

  6. Las cargas de trabajo cumplen los requisitos de seguridad y cumplimiento.

  7. La carga de trabajo se ha incorporado correctamente a las soluciones de copia de seguridad y recuperación ante desastres.

4. Evaluación de la migración y desmantelamiento

La migración no finaliza cuando las cargas de trabajo se encienden en Azure VMware Solution. Compruebe que las cargas de trabajo funcionan correctamente en su nuevo entorno, confirme que se quitan los alojamientos de migración temporales y retire formalmente la infraestructura de origen. Dejar la infraestructura local en su lugar puede dar lugar a dependencias no detectadas y no documentadas. Un proceso de evaluación y retirada disciplinados garantiza que la organización obtenga las ventajas esperadas de la migración sin llevar a cabo costos operativos o riesgos innecesarios.

4.1 Preparación de producción posterior al cambio

Exija criterios posteriores a la transición que confirmen que la carga de trabajo se comporta según lo previsto. Compruebe la conectividad de red y la resolución de nombres. Compruebe la función de la aplicación y la comunicación con los sistemas dependientes. Una vez que se mueva cada máquina virtual, confirme que se inicia, que sus recursos coinciden con el plan y que se aplica la directiva de almacenamiento correcta. Compare el rendimiento con la línea base de migración previa.

Elija su política de paridad. La decisión clave es si una carga de trabajo migrada debe alcanzar la paridad completa con el estado local antes de llamarla lista para producción o si se permiten desviaciones temporales. Muchas organizaciones exigen paridad de rendimiento inmediata para los sistemas orientados al cliente, pero conceden a las aplicaciones internas un breve período de estabilización con una fecha límite de corrección fija.

4.2 Validación de conectividad

Valide la conectividad de un extremo a otro en Azure VMware Solution, Azure, locales, Internet y resolución de nombres. Ejecute pruebas de humo de la aplicación para confirmar que la carga de trabajo cumple su propósito. Confirme si los registros de nombres externos o la configuración del equilibrador de carga deben actualizarse como parte del cambio.

Si ha creado una instancia secundaria de Azure VMware Solution para la recuperación ante desastres, asegúrese de que es accesible desde la instancia principal y desde cualquier cliente o servicios auxiliares que necesiten conectarse a él si está activado.

4.3 Disolución de la extensión de red

Cuando se hayan movido todas las cargas de trabajo de un segmento extendido, quite la extensión de capa 2 de HCX y confirme que la puerta de enlace nativa de Azure VMware Solution enruta correctamente. No deje una extensión instalada más tiempo del necesario para la migración.

4.4 Retirar el entorno de origen

La retirada de servicio supone la liberación formal de la capacidad de origen, las licencias y la cobertura operativa. Considérelo como una transferencia controlada en lugar de una tarea de limpieza. Si se omite el desmantelamiento, se paga por infraestructura inactiva y se mantiene una exposición de seguridad. Use Retirar las cargas de trabajo de origen después de la migración a la nube para establecer el orden de las operaciones, el período de retención de las copias de seguridad de origen, las aprobaciones necesarias para apagar los sistemas de origen y los criterios para recuperar licencias y hardware.

Pasos siguientes

Diseño de cargas de trabajo:

  • Last updated on