Unidad 7.4: Migración y conmutación híbrida

Introducción

La migración es la unidad donde la honestidad de la plataforma importa más, porque la mayor fuente de riesgo en un proyecto es una capacidad que se asume pero que no está presente. IONOS CLOUD no tiene un asistente nativo de importación OVF/OVA: no se puede apuntar una consola a una exportación de vSphere y obtener una instancia de IONOS CLOUD en ejecución. Por lo tanto, la migración se diseña, no se importa, y el trabajo de diseño consiste en elegir la ruta diseñada adecuada para cada carga de trabajo y secuenciar esas rutas de modo que la empresa nunca esté fuera de línea más tiempo del que aceptó.

Esta unidad se centra en FinCorp, una empresa alemana de servicios financieros que gestiona un importante entorno de VMware bajo las obligaciones del RGPD y del BSI. Este entorno representa el uso más pesado de Private Cloud dedicada en todo el curso, por lo que el diseño de la migración se apoya directamente en él: cuando el destino es VMware dedicado, FinCorp puede mantener las VM intactas y utilizar herramientas nativas de VMware; cuando el destino es la superficie estándar de IONOS CLOUD Public Cloud, las mismas VM deben convertirse. Tomar bien esa bifurcación, carga de trabajo por carga de trabajo, es la arquitectura.

1. El marco de disposición, aplicado con honestidad

Antes de elegir cualquier herramienta, clasifique cada carga de trabajo según lo que usted pretende cambiar. El marco de disposición (el modelo "R") denomina las opciones realistas para un patrimonio de este tamaño. La versión honesta se reduce a tres, porque las demás (retener, retirar, recomprar) son decisiones de no migrar esa carga de trabajo en absoluto:

• Rehost ("lift and shift"): mover la carga de trabajo tal como está, con el mismo sistema operativo y la misma aplicación, hacia la infraestructura de destino. Es la vía más rápida, con el menor riesgo para la aplicación y sin beneficio de modernización.
• Replatform ("lift and reshape"): mantener la aplicación, pero sustituir un componente subyacente por un equivalente administrado, por ejemplo, mover una VM de PostgreSQL autogestionada hacia Managed PostgreSQL. El esfuerzo es moderado, elimina la carga operativa, pero introduce una etapa de migración de datos.
• Refactor: modificar la propia aplicación, por ejemplo, descomponer un monolito hacia Managed Kubernetes. El mayor esfuerzo y riesgo, se pospone a su propio programa en lugar de integrarse en una ola de conmutación.

La decisión de disposición es la que selecciona la ruta de infraestructura, y el punto de bifurcación más determinante es la plataforma de destino. Un rehost hacia un Private Cloud dedicado mantiene la VM íntegra y nativa de VMware, por lo que puede utilizar herramientas de replicación de VMware. Un rehost hacia la superficie estándar de IONOS CLOUD Public Cloud (Compute Engine) cruza un límite de hipervisor: Private Cloud ejecuta VMware ESXi, mientras que la familia de productos de Public Cloud ejecuta un sustrato diferente, basado en KVM, y las dos familias no son intercambiables. Ese límite, y no una preferencia, es la razón por la que algunos rehosts son una tarea de conversión de imagen y otros son una tarea de replicación.

Un replatform siempre conlleva una etapa de datos que la ruta de infraestructura no cubre. Convertir la imagen de disco de una VM de base de datos mueve la máquina; no hace que IONOS CLOUD Managed PostgreSQL adopte esos datos. Los datos se mueven por separado, mediante volcado y restauración (Sección 4). Trate cada replatform como dos migraciones coordinadas: la aplicación circundante y los datos que hay debajo de ella.

2. Las tres rutas de infraestructura

Cada disposición se resuelve en una de tres rutas diseñadas. Difieren en lo que se preserva, en qué herramientas transportan los bytes y en cuánto tiempo de inactividad cuesta el cambio.

2.1 Ruta 1: Conversión e subida de imagen

Esta es la ruta cuando el destino es la superficie estándar de IONOS CLOUD Public Cloud y la máquina virtual debe cruzar la frontera de VMware a KVM. No existe una importación nativa de OVF/OVA, por lo que la máquina virtual se convierte en una imagen arrancable y se sube, y luego se aprovisiona como una instancia de IONOS CLOUD.

El requisito técnico innegociable es el conjunto de controladores de invitado. Las instancias de IONOS CLOUD Public Cloud se inician en KVM y requieren controladores KVM VirtIO; una imagen que solo lleva los controladores paravirtualizados de VMware no se iniciará correctamente o se ejecutará sin rendimiento de disco y red. Para invitados de Windows, IONOS CLOUD proporciona una imagen ISO que contiene los controladores VirtIO relevantes, que usted monta como una unidad CD-ROM e instala antes o durante el cambio. La secuencia práctica es instalar los controladores VirtIO en la máquina virtual de origen mientras aún se ejecuta en VMware (de modo que la imagen convertida ya los contenga), convertir el disco virtual a un formato de carga admitido, subirlo y aprovisionar una instancia a partir de la imagen subida. El modo de firmware importa: un invitado instalado bajo UEFI debe aprovisionarse para iniciar UEFI en el destino, y un invitado instalado bajo BIOS heredado debe iniciar BIOS; una incompatibilidad produce una imagen no arrancable y es el fallo evitable más común en esta ruta.

La Ruta 1 es inherentemente un cambio sin conexión para la carga de trabajo convertida: el origen se apaga para obtener un estado de disco coherente, se convierte, se sube y se inicia en el destino. El tiempo de inactividad abarca la conversión y la subida, lo cual escala con el tamaño del disco y el ancho de banda del enlace, por lo que es la ruta con la ventana de cambio más grande y menos predecible. Es la ruta correcta para cargas de trabajo que se están modernizando en la superficie de Public Cloud, y la ruta incorrecta para un parque de recursos grande que simplemente desea mantener íntegro.

2.2 Ruta 2: Réplica nativa de VMware hacia Private Cloud dedicado

Cuando el destino es Private Cloud dedicado, la máquina virtual nunca sale de VMware, por lo que la migración se mantiene dentro de las herramientas nativas de VMware y la ventana de cambio se reduce. La herramienta que IONOS CLOUD proporciona para esto es VMware Cloud Director Availability (VCDA).

VCDA es una oferta de Disaster-Recovery-as-a-Service que protege vApps y máquinas virtuales con réplica asíncrona, las migra, realiza el conmutado por error y revierte el conmutado por error, desplegada entre el vCenter en las instalaciones del cliente y el IONOS CLOUD Private Cloud. En un IONOS CLOUD Private Cloud, el dispositivo del lado de la nube se aprovisiona automáticamente, y el cliente despliega un dispositivo de réplica en las instalaciones que coincida en el vCenter local; luego se emparejan. La versión desplegada es VCDA 4.7.x. El dispositivo en las instalaciones alcanza el dispositivo de la nube a través de la IP pública del Private Cloud en el puerto TCP 55443. Comercialmente, esta es la propiedad decisiva: solo se facturan las máquinas virtuales protegidas, a 50 EUR por máquina virtual por mes para VCDA Protection, y la función de migración en sí es gratuita. Por lo tanto, un parque de recursos grande puede migrarse con VCDA sin cargo de migración por máquina virtual, pagando solo por las máquinas virtuales que mantenga bajo protección DR continua después.

El modelo de réplica es lo que hace que el cambio sea corto. VCDA replica de forma asíncrona mientras el origen sigue ejecutándose, por lo que los datos se preparan en el destino antes de cualquier interrupción. El cambio es un conmutado por error: el origen se quiesce, se replica la delta final y la máquina virtual se enciende en el sitio de IONOS CLOUD Private Cloud. Dado que VCDA también realiza el conmutado por error inverso, el cambio tiene un punto de reversión definido: si la validación falla, se conmuta la máquina virtual de vuelta al sitio en las instalaciones que sigue intacto. Esta es la razón más importante por la que un gran parque de VMware apunta a Private Cloud en lugar de la ruta de conversión: las máquinas virtuales se mantienen íntegras, la ventana de cambio por máquina virtual es de minutos en lugar de horas, y la reversión está integrada en la misma herramienta.

Dos puntos de red gobiernan lo limpio que es el aterrizaje del cambio:

• Extensión de capa 2. Para permitir que las máquinas virtuales migradas mantengan sus direcciones IP existentes durante un cambio por fases, NSX-T proporciona un VPN de capa 2, que extiende un segmento de capa 2 entre la red en las instalaciones y un segmento NSX en el Private Cloud. Los segmentos NSX son dominios virtuales de capa 2, por lo que un segmento extendido permite que una máquina virtual migrada se sitúe en el mismo dominio de difusión que tenía en las instalaciones mientras sus pares aún están siendo movidos. Esto es lo que evita re direccionar cada máquina virtual el primer día y permite que un clúster de dependencias se mueva por etapas.
• Solo movilidad intraclúster. Una vez que las máquinas virtuales están ejecutándose en el Private Cloud, vMotion puede moverlas en vivo entre hosts dentro del clúster (por ejemplo, para equilibrar la carga o para drenar un host). vMotion es solo intraclúster. No es un mecanismo de migración entre sitios y no mueve una máquina virtual en ejecución desde las instalaciones a IONOS CLOUD; ese movimiento entre sitios es la función de VCDA, y es una operación de réplica y conmutado por error, no un movimiento en vivo entre sitios. No diseñe un cambio alrededor de mover máquinas virtuales en ejecución entre sitios sin interrupción; esa capacidad no está presente.

2.3 Ruta 3: Copia de seguridad y restauración

La tercera ruta trata la migración como una recuperación: haga una copia de seguridad de la carga de trabajo desde el origen y restáurela en el destino. Es la más lenta para el cambio porque es secuencial (una copia de seguridad completa, luego una restauración completa) y está sin conexión durante todo el tiempo, pero es la más universalmente aplicable y no requiere un enlace en vivo entre sitios. Úsela para cargas de trabajo donde ni una ruta de réplica limpia de VMware ni una conversión de imagen están justificadas: servidores con baja tasa de cambios, sistemas de archivo o cualquier cosa donde una ventana de mantenimiento larga sea aceptable y la simplicidad operativa supere a la velocidad del cambio. También es la alternativa natural cuando una conversión de la Ruta 1 resulta no arrancable y el calendario no permite un segundo intento.

2.4 Elección entre las rutas

Lo siguiente compara las tres rutas en las dimensiones que realmente impulsan la decisión.

La regla que sigue: una máquina virtual destinada a VMware dedicado toma la Ruta 2 por defecto, porque es la única ruta que mantiene la máquina virtual íntegra y da un cambio corto y reversible. Una máquina virtual que se está modernizando en la superficie de Public Cloud toma la Ruta 1 y acepta el trabajo de conversión y la ventana más larga. La Ruta 3 es la alternativa para la cola larga donde ninguna ruta de propósito especial justifica su complejidad.

3. Planificación de oleadas y conmutación híbrida

Una infraestructura de gran escala nunca se conmuta de una sola vez. Se descompone en oleadas, y la unidad de una oleada es un clúster de dependencias: un conjunto de VM que se comunican entre sí y deben moverse juntos o mantenerse alcanzables a través del límite mientras están divididos. Dividir una aplicación con mucha comunicación a través del límite entre las instalaciones locales y la nube en medio de una oleada convierte cada llamada interna en un viaje de ida y vuelta a través del enlace híbrido, por lo que el clúster de dependencias, y no la VM individual, es el átomo de planificación.

Ordene las oleadas para eliminar el riesgo de forma temprana y las dependencias de manera limpia:

1. Oleada piloto: un clúster de dependencias pequeño, autónomo y de baja criticidad. Su propósito es validar la ruta elegida de extremo a extremo (conversión o emparejamiento VCDA, el enlace híbrido, las puertas de validación) antes de que se mueva algo importante.
2. Oleadas de hoja de dependencia: los sistemas de los que otros dependen, pero que a su vez dependen de poco, se mueven antes que sus consumidores, de modo que los consumidores nunca apunten a través del límite hacia algo que no ha llegado.
3. La oleada de base de datos: secuenciada deliberadamente en relación con sus aplicaciones (Sección 4), porque se trata de volcado/restauración y, por lo tanto, es una conmutación dura, no gradual.
4. Las oleadas de aplicación y borde: los consumidores, que se mueven una vez que sus datos y dependencias ya están en su lugar.

Durante toda la migración, la infraestructura es híbrida, por lo que el enlace entre el sitio local e IONOS CLOUD es estructural, no accidental. Dos estructuras del Módulo 3 lo soportan: un VPN Gateway (IKEv2/WireGuard, HA activo-pasivo sobre una IP pública compartida) para conectividad cifrada entre sitios, y Cross-Connect para un interconexión privada de mayor ancho de banda cuando el volumen de la migración o el tráfico residual a través del límite lo justifica. Para las VM que aterrizan en Private Cloud dedicado, la VPN L2 NSX-T de la Sección 2.2 es la extensión a nivel de segmento que permite que un clúster de dependencias abarque ambos sitios sin reasignación de direcciones. Dimensione estos enlaces para el movimiento de datos de la migración, no solo para el tráfico en estado estable; un enlace de tamaño insuficiente es la causa más común de que una oleada exceda su ventana.

Cada oleada termina en una puerta de validación antes de desviar el tráfico: confirme que la carga de trabajo se inicia, que la aplicación responde en sus puntos finales, que los datos están intactos y actualizados, y que los sistemas dependientes aún pueden alcanzarla a través de cualquier límite que quede. Solo después de que la puerta se supere se conmuta el tráfico, típicamente reorientando el DNS (Unidad 3.7), lo que dirige las nuevas conexiones al punto final migrado mientras el antiguo se drena.

Si una puerta falla, la posición de reversión difiere según la ruta y debe diseñarse de antemano:

• Ruta 2 (VCDA): la reversión de conmutación por error devuelve la VM al sitio local intacto. Esta es la reversión más limpia y otra razón por la que las cargas de trabajo con destino a VMware son de menor riesgo.
• Ruta 1 y Ruta 3: la VM de origen se apagó pero no se destruyó, por lo que la reversión consiste en volver a encender el origen (y reorientar el DNS). Mantenga el origen intacto e intocado hasta que la puerta se supere; no descomisione un origen en la misma oleada que lo migra.
• Las Snapshot son una reversión dentro del destino, no entre sitios. Una Snapshot a nivel de VM en el destino (ya sea una Snapshot de vSphere en Private Cloud o una Snapshot de Block Storage en IONOS CLOUD) le permite revertir una VM recién migrada a su estado recién llegado si un cambio posterior a la conmutación sale mal. Es local a la región y a nivel de VM, y, crucialmente, no es consistente a nivel de base de datos: una Snapshot de una VM de base de datos en ejecución puede capturar un estado de transacción en curso que no se restaura de forma limpia. Las Snapshot protegen el paso de conmutación; no reemplazan el volcado/restauración de la oleada de base de datos.

4. La ola de bases de datos: volcado y restauración

Las bases de datos son la ola que con mayor frecuencia rompe un plan que de otro modo sería sólido, porque el instinto es migrarlas como cualquier otra VM. Para las cargas de trabajo que se están replataformando hacia bases de datos administradas de IONOS CLOUD, ese instinto es incorrecto: no existe un cambio nativo basado en replicación desde una base de datos de origen hacia IONOS CLOUD Managed PostgreSQL, MariaDB o MongoDB. La ruta de migración admitida es volcado y restauración. Se exporta un volcado lógico desde el origen y luego se carga en el clúster administrado de destino.

Esto da forma a la ola de tres maneras. En primer lugar, se trata de un cambio definitivo con tiempo de inactividad real: para obtener un volcado coherente, se detienen las escrituras en el origen, se realiza el volcado, se restaura y se valida antes de reanudar las escrituras contra el destino. La ventana de tiempo escala con el volumen de datos, por lo que la ola de bases de datos recibe la ventana de mantenimiento más generosa en el plan. En segundo lugar, el punto de reversión es el propio origen: se mantiene la base de datos de origen en línea y como autoridad hasta que el destino restaurado supere su puerta de validación, y luego se cambia la cadena de conexión de la aplicación. En tercer lugar, una instantánea en el lado del destino no es la red de seguridad aquí. Dado que las instantáneas no son coherentes a nivel de base de datos, el volcado es el artefacto de migración autoritativo y el origen es el punto de reversión autoritativo. Se debe secuenciar la ola de bases de datos de modo que su ventana de volcado/restauración se alinee con, e idealmente preceda, el cambio de las aplicaciones que dependen de ella, para que esas aplicaciones lleguen a una base de datos que ya esté poblada y validada.

Resumen de la decisión

Utilice la disposición para seleccionar la ruta de infraestructura, la plataforma de destino para confirmarla y la tabla siguiente como criterio de referencia general.

Restricciones duras que deben aplicarse en cada oleada: no existe una importación nativa de OVF/OVA (la conversión se realiza mediante ingeniería); vMotion es solo intraclúster y no es un traslado entre sitios; la migración de bases de datos es solo mediante volcado/restauración; y las instantáneas son a nivel de VM, locales a la región y no consistentes a nivel de base de datos. Para FinCorp, el amplio parque de VMware se resuelve de manera limpia: la mayor parte del parque se reubica en un Private Cloud dedicado mediante VCDA (VMs íntegras, migración gratuita, reversión mediante conmutación inversa, VPN L2 NSX-T que mantiene las direcciones estables entre oleadas escalonadas), las bases de datos designadas para servicios gestionados se replataforman mediante volcado/restauración en su propia oleada con ventana horaria, y solo las cargas de trabajo explícitamente modernizadas toman la ruta de conversión de imagen hacia la superficie de Public Cloud.

Resumen

La migración a IONOS CLOUD se diseña, no se importa: al no existir una importación nativa de OVF/OVA, la arquitectura elige una de tres rutas honestas por carga de trabajo (conversión de imagen y carga a la superficie de Public Cloud KVM, replicación VCDA a VMware dedicado, o copia de seguridad/restauración), las secuencia por clúster de dependencias en oleadas sobre un enlace híbrido dimensionado, y controla cada oleada con validación y un rollback específico de la ruta. La oleada de bases de datos es un cambio duro independiente mediante volcado y restauración, y las instantáneas son una red de seguridad a nivel de VM para el paso de cambio, no un sustituto de este.

Puntos clave:

• No existe una importación nativa de OVF/OVA; la migración se diseña por carga de trabajo, y la plataforma de destino (VMware frente a KVM) selecciona la ruta.
• VCDA 4.7.x es la ruta nativa de VMware hacia Private Cloud dedicado: replicación asíncrona, migración gratuita, conmutación por error y conmutación inversa por error, con solo las VMs protegidas facturadas a 50 EUR por VM al mes; el dispositivo de la nube se alcanza en TCP 55443.
• NSX-T L2 VPN extiende un segmento de capa 2 entre sitios para que las oleadas por fases conserven sus direcciones IP; vMotion es solo intraclúster y nunca es un movimiento en vivo entre sitios.
• La ruta de conversión de imagen requiere controladores KVM VirtIO y firmware UEFI/BIOS coincidente, y es un cambio fuera de línea escalado por el tamaño del disco y el ancho de banda del enlace.
• Las bases de datos se migran mediante volcado y restauración con una ventana de cambio duro; la fuente permanece como autoridad hasta que el destino valida, y las instantáneas no son consistentes a nivel de base de datos.

Terminología importante:

• VCDA (VMware Cloud Director Availability): la herramienta nativa de VMware para DRaaS que IONOS CLOUD proporciona para replicar, migrar, conmutar por error y revertir la conmutación por error de VMs entre vCenter en las instalaciones y IONOS CLOUD Private Cloud; versión 4.7.x, migración gratuita, Protección por VM facturada por separado.
• NSX-T L2 VPN: una extensión de capa 2 que extiende un segmento NSX entre sitios para que las VMs migradas conserven sus direcciones durante un cambio por fases.
• Disposición: la decisión por carga de trabajo (realojar, replatformar, refactorizar) que selecciona la ruta de migración de infraestructura.
• Oleada: un clúster de dependencias de cargas de trabajo migradas juntas, con una puerta de validación y un rollback definido al final.

Lectura adicional

• Unidad 4.4: Private Cloud (Dedicated VMware): la plataforma de destino para la ruta de migración nativa de VMware
• Unidad 5.3: Bases de datos relacionales: modos de replicación y la ruta de migración mediante volcado y restauración para la ola de bases de datos
• Unidad 3.6: Conectividad híbrida: VPN Gateway y Cross-Connect, los enlaces que soportan el cambio a la arquitectura híbrida
• Unidad 7.1: Resiliencia y continuidad del negocio: conmutación por error de DNS orquestada por el cliente y las estrategias de recuperación en las que se basa