Blog de Amazon Web Services (AWS)

Cómo mover cargas de trabajo a AWS sin refactorizar con Nutanix NC2

Por Guillermo Ruiz, Sr. Specialist Efficient Compute en Amazon Web Services (AWS) y Andrés Rey, especialista en cloud híbrida en Nutanix.

En la primera entrega de esta serie exploramos cómo desplegar un entorno de Nutanix Cloud Clusters (NC2) en AWS, los componentes que incluye y la integración de Nutanix con los servicios de AWS.

En entornos híbridos, la portabilidad de cargas de trabajo es esencial para garantizar la continuidad operativa y la agilidad del negocio. Gracias a Nutanix Cloud Clusters (NC2) en AWS y Flow Virtual Networking, es posible migrar máquinas virtuales (VMs) entre el data center on-premises y la nube sin modificar direcciones IP, aprovechando la extensión de redes L2 sobre L3 mediante VxLAN.

En esta publicación mostraremos cómo mover servicios desde un entorno de cloud privada a un entorno de cloud pública sin refactorizar, utilizando la consola Nutanix Prism Central. Este mismo procedimiento puede utilizarse para mover servicios a cloud privada o distribuir un servicio en un entorno híbrido.

Arquitectura general

La siguiente figura muestra la arquitectura de red híbrida que utilizaremos en este ejemplo. Ambos entornos (on-premises y NC2 en AWS) comparten la misma subnet extendida mediante Flow Virtual Networking, lo que permite que las VMs mantengan sus direcciones IP durante la migración.

Figura 1 Arquitectura de red híbrida utilizando Nutanix Flow Networking y NC2 en AWS.

Figura 1 Arquitectura de red híbrida utilizando Nutanix Flow Networking y NC2 en AWS.

Paso a paso: configuración y migración de VMs

1. Prerrequisitos

Antes de comenzar, asegúrate de cumplir con los siguientes requisitos:

  • Prism Central con ambos clústeres registrados (on-premises y NC2 en AWS).
  • Flow Virtual Networking habilitado (si se va a hacer uso de VxLAN para extensión L2).
  • Conectividad IP entre ambos entornos (VPN o AWS Direct Connect).

Para este ejemplo utilizaremos:

Componente Detalle
Prism Central on-premises 10.42.64.7
Prism Central en NC2 (AWS) 10.210.15.135
Subnet compartida 192.168.40.0/24 – Gateway 192.168.40.1
VMs a migrar 7 (Frontend / Backend)

2. Conectar ambos entornos como zonas de disponibilidad

Este procedimiento puede realizarse desde cualquiera de los dos Prism Central. Una vez conectados, la visibilidad es completa desde ambos sitios.

1. Accede a Prism Central on-premises y verifica que las VMs de Backend y Frontend se ejecutan en el clúster local (PHX).

Figura 2 VMs Back End y Front End cluster origen

Figura 2 VMs Back End y Front End cluster origen

2. Navega a Administration → Availability Zones → Connect to Availability Zone.

3. Indica la dirección IP del segundo Prism Central y las credenciales correspondientes.

Figura 3 Conexión entre Zonas de Disponibilidad

Figura 3 Conexión entre Zonas de Disponibilidad

Una vez validadas las credenciales, el segundo sitio (NC2 en AWS) aparecerá como registrado y disponible.

3. Crear políticas de replicación entre sitios

Desde Prism Central es posible configurar distintas políticas de protección y replicación, cada una con un RPO (Recovery Point Objective) diferente. El RPO define la cantidad máxima de datos que se puede perder en caso de fallo, medida en tiempo: un RPO de 1 hora significa que, en el peor escenario, se perderían como máximo los datos generados en la última hora antes del incidente.

  • Síncrona – RPO = 0 (requiere Metro Availability)
  • Near-sync – RPO de 1 a 15 minutos
  • Asíncrona – RPO de 1 hora o más

Para este ejemplo definiremos un RPO de 1 hora, lo que garantiza que las VMs estén replicadas en ambos entornos. Esto permite no solo migrar las VMs, sino también realizar pruebas de migración y validar que todo funciona correctamente antes de ejecutar la migración definitiva.

Navega a Prism Central → Data Protection → Protection Policies.

Figura 4 Configuración de política de protección

Figura 4 Configuración de política de protección

Las políticas de protección en Nutanix permiten replicar de N a N sitios, y además permiten implementar diferentes RPO bajo una misma política.

El siguiente paso es definir qué se protegerá. Se permite incluir VMs individuales o volúmenes, pero lo más recomendable es basar la protección en categorías (etiquetas). Esto permite que al añadir nuevos servicios, simplemente asignando la categoría correspondiente, queden protegidos de forma automática.

Para este ejemplo utilizaremos la categoría: Environment:App

Figura 5 Creación de una política de protección por categoría

Figura 5 Creación de una política de protección por categoría

4. Configurar Recovery Plans

Si bien Nutanix permite migrar o recuperar VMs de forma manual, lo más adecuado es automatizar el proceso mediante Recovery Plans. Estos permiten:

  • Definir secuencias de arranque (staging) del servicio
  • Configurar el mapeo de redes entre origen y destino
  • Ejecutar pruebas en redes aisladas antes de la migración definitiva

Navega a Data Protection → Recovery Plans y crea un nuevo plan:

Figura 6 Creación de un Recovery Plan con origen en la zona local y destino en NC2 (AWS).

Figura 6 Creación de un Recovery Plan con origen en la zona local y destino en NC2 (AWS).

Configuración del plan:

  • Origen: Local AZ (on-premises)
  • Destino: Prism Central en NC2 (AWS)

Secuencia de recuperación: Selecciona la categoría Environment:App para incluir automáticamente todas las VMs asociadas. Es posible añadir múltiples secuencias de arranque con categorías o VMs individuales para controlar el orden de inicio.

Figura 7 Configuración de la secuencia de arranque basada en categorías.

Figura 7 Configuración de la secuencia de arranque basada en categorías.

Mapeo de redes: Configura las redes de origen y destino. Además, puedes definir redes de test aisladas para validar el arranque de las VMs antes de la migración real.

Figura 8 Mapeo de redes origen/destino y redes de test para validación previa.

Figura 8 Mapeo de redes origen/destino y redes de test para validación previa.

Figura 9 Configuración mapeo de redes origen/destino.

Figura 9 Configuración mapeo de redes origen/destino

5. Asignar categorías a las VMs

Este paso puede realizarse antes o después de configurar las políticas. Al basarse en categorías, todas las VMs a las que se asigne la etiqueta quedarán incluidas automáticamente en las configuraciones de protección y recuperación.

  1. Navega a VMs y selecciona todas las VMs que pertenecen al servicio.
  2. Selecciona Actions → Manage Categories.
  3. Asigna la categoría Environment:App.

Fig. 10 Asignación de la categoría Environment:App a las VMs del servicio
Figura 10 Asignación de la categoría Environment:App a las VMs del servicio

Al asignar la categoría, el sistema confirmará que tiene asociadas las políticas de protección y recuperación configuradas previamente.

Figura 11 Confirmación políticas protección asignadas a la categoría Environment:App

Figura 11 Confirmación políticas protección asignadas a la categoría Environment:App

6. Ejecutar la migración

Con el Recovery Plan configurado, la migración entre on-premises y NC2 en AWS se ejecuta en pocos pasos:

1. Navega a Recovery Plans y selecciona el plan creado (en nuestro caso, “ARMMigration”).

Figura 12 Selección Plan Recuperación

Figura 12 Selección Plan Recuperación

2. Selecciona Actions → Failover.

Figura 13 Activación Failover

Figura 13 Activación Failover

3. Confirma las 7 VMs incluidas en la política y pulsa Failover.

Figura 14 Ejecución del failoverFigura 14 Ejecución del failover

Durante el proceso se realizará una última sincronización de las VMs antes de completar la migración.

Figura 15 Validación VMs antes de migración

Figura 15 Validación VMs antes de migración

Figura 16 Migración VMs a NC2 en AWS

Figura 16 Migración VMs a NC2 en AWS

Una vez completada la migración, accede a Prism Central en AWS para verificar que las VMs se ejecutan correctamente en la red de destino.

Figura 17 VMs migradas y en ejecución en NC2 sobre AWS en la red correcta

Figura 17 VMs migradas y en ejecución en NC2 sobre AWS en la red correcta

Nota: Existen opciones adicionales de migración, como la migración individual desde la propia VM (Actions → Migrate → Across clusters) o la restauración desde VM Recovery Points.

Figura 18 Migración individual VMFigura 18 Migración individual VM

7. Verificación

Verifica que las VMs se hayan migrado correctamente y que los servicios estén en ejecución. Comprueba:

  • Conectividad de red (las IPs se mantienen)
  • Estado de los servicios en las VMs
  • Acceso desde y hacia servicios nativos de AWS (Amazon RDS, Amazon S3, Amazon EC2)

Casos de uso

Esta solución permite abordar los siguientes escenarios en entornos híbridos:

Migración y modernización

Migre aplicaciones y datos existentes a AWS sin necesidad de refactorizar. NC2 en AWS se despliega en una VPC del cliente y utiliza las capacidades de red nativas de AWS, lo que permite a las cargas de trabajo migradas integrarse con servicios nativos como Amazon RDS, Amazon S3, Elastic Load Balancing y Amazon Route 53.

Disaster Recovery

Utilice Amazon S3 como destino para copias de snapshots desde el clúster NC2 mediante Nutanix Multi Cloud Snapshot Technology (MST). Esta capacidad permite replicar snapshots desde entornos on-premises hacia almacenamiento en S3, proporcionando una opción de recuperación de bajo coste y bajo mantenimiento.

Extensión de datacenter

Amplíe la capacidad de forma inmediata desplegando nodos NC2 en AWS. Los clústeres se provisionan en horas sobre instancias bare-metal de Amazon EC2, eliminando los plazos de adquisición de hardware para escenarios de expansión geográfica, cargas estacionales o entornos de desarrollo y pruebas.

Integración con servicios nativos de AWS

Las VMs ejecutándose en NC2 pueden utilizar Flow Virtual Networking con redes overlay en modo No-NAT, que se añaden a la tabla de rutas de la VPC. Esto permite que los servicios nativos de AWS accedan a las VMs del overlay como si fueran un rango CIDR nativo de la VPC.

Beneficios

La combinación de Nutanix Flow Virtual Networking y NC2 en AWS ofrece las siguientes ventajas operativas:

  • Sin refactorización: las aplicaciones se migran sin cambios de código ni reestructuración de la arquitectura.
  • Redes nativas de AWS: NC2 utiliza directamente security groups, network ACLs, VPN y AWS Direct Connect. No requiere configuraciones de red complejas adicionales.
  • Gestión unificada: operación centralizada desde Prism Central para entornos on-premises y cloud.
  • Integración con almacenamiento AWS: soporte para Amazon EBS, Amazon FSx y Amazon EFS como opciones de almacenamiento para las VMs.
  • Escalabilidad on-demand: capacidad de ampliar o reducir nodos del clúster según la demanda.
  • Gestión de sistemas: las VMs en NC2 pueden gestionarse con AWS Systems Manager para patching y fleet management una vez instalado el SSM Agent.

Conclusión

En este artículo hemos recorrido la configuración paso a paso de Flow Virtual Networking en NC2 sobre AWS para habilitar la movilidad de cargas de trabajo en entornos híbridos. El resultado es una arquitectura en la que las VMs se mueven entre on-premises y AWS manteniendo la conectividad con ambos entornos y con acceso directo a los servicios nativos de la nube, todo gestionado desde un único plano de control.

Para más información, consulte los siguientes recursos:

FAQ

P: ¿Se mantienen las direcciones IP de las VMs durante la migración?

R: Sí. Gracias a la extensión de redes L2 sobre L3 que proporciona Flow Virtual Networking, las VMs conservan sus direcciones IP al migrar entre on-premises y NC2 en AWS. No es necesario realizar cambios de configuración de red en las aplicaciones. La preservación de direcciones MAC depende del método de migración utilizado: herramientas como Nutanix Move , preservan tanto IP como MAC, mientras que en escenarios de DR Failover se recomienda verificar el comportamiento con la versión específica de AOS utilizada.

P: ¿Cuánto tarda la migración de VMs entre on-premises y NC2 en AWS?

R: El tiempo depende del volumen de datos a sincronizar en la última replicación. Con una política de RPO de 1 hora, el delta de datos es reducido, por lo que el failover típico se completa en minutos. La sincronización previa es continua y transparente.

P: ¿Es posible realizar un rollback después de migrar?

R: Sí. El Recovery Plan es bidireccional. Una vez ejecutado el failover hacia AWS, puedes configurar un failback hacia on-premises siguiendo el mismo procedimiento, invirtiendo origen y destino.

P: ¿Se puede probar la migración sin afectar al servicio en producción?

R: Sí. Los Recovery Plans permiten ejecutar test failovers en redes aisladas, arrancando las VMs replicadas en una red de pruebas sin impactar las VMs originales que continúan en producción.

P: ¿Qué tipos de replicación soporta Nutanix entre sitios?

R: Nutanix soporta tres modos: replicación síncrona (RPO = 0, requiere Metro Availability), near-sync (RPO de 1 a 15 minutos) y asíncrona (RPO de 1 hora o más). La elección depende de los requisitos de RPO y la latencia entre sitios.

P: ¿Es necesario refactorizar las aplicaciones antes de migrarlas?

R: No. Con NC2, las aplicaciones se migran tal cual (as-is), sin necesidad de modificar su arquitectura, configuración de red ni dependencias. La plataforma es la misma en ambos entornos.

P: ¿Se pueden integrar las VMs migradas con servicios nativos de AWS?

R: Sí. Una vez ejecutándose en NC2 sobre AWS, las VMs tienen acceso directo a servicios como Amazon RDS, Amazon S3, Amazon EC2 y cualquier otro servicio accesible a través de la VPC, sin necesidad de configuraciones adicionales.

Autores

Guillermo Ruiz Guillermo Ruiz es Sr. Specialist Solutions Architect de Efficient Compute en Amazon Web Services (AWS). Ayuda a equipos de ingeniería a optimizar sus cargas de trabajo de AI y a desplegar soluciones de computación confidencial. Sus áreas de interés adicionales incluyen Edge Computing y Observabilidad.
Andrés Rey Andrés Rey es especialista en cloud híbrida en Nutanix, con más de 20 años de experiencia en TI, abarcando preventa, consultoría y arquitectura en sectores como banca, automoción, energía y administración pública. Experto en la gestión de proyectos diversos con requisitos complejos.