Unidad 7.4: Migración y corte híbrido

Introducción

La migración es la unidad donde la honestidad de la plataforma es más importante, porque la mayor fuente de riesgo del proyecto es una capacidad asumida pero no presente. IONOS Cloud no tiene un asistente de importación de OVF/OVA nativo: no puede apuntar a una consola en una exportación de vSphere y tener una instancia de IONOS en ejecución que aparezca. La migración, por lo tanto, está diseñada, no importada, y el trabajo de diseño consiste en elegir el camino diseñado correcto por Workload y secuenciar esos caminos para que el negocio nunca esté fuera de línea más tiempo del que acordó ser.

Esta unidad se centra en FinCorp, la empresa de servicios financieros alemana que lleva un gran patrimonio de VMware bajo las obligaciones de GDPR y BSI. El patrimonio es el uso individual más pesado de Private Cloud dedicado en todo el curso, por lo que el diseño de migración se basa directamente en él: donde el objetivo es VMware dedicado, FinCorp puede mantener las máquinas virtuales (VM) completas y utilizar herramientas nativas de VMware; donde el objetivo es la superficie estándar de IONOS Public Cloud, las mismas VM deben ser convertidas. Obtener esa bifurcación correcta, Workload por Workload, es la arquitectura.

1. El Marco de Disposición, Aplicado Honestamente

Antes de elegir cualquier herramienta, clasifique cada Workload según lo que usted pretende cambiar. El marco de disposición (el modelo "R") nombra 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 ese Workload en absoluto:

• Rehost ("levantar y trasladar"): mover el Workload tal como está, mismo sistema operativo y aplicación, a la infraestructura objetivo. Camino más rápido, menor riesgo de aplicación, sin beneficio de modernización.
• Replatform ("levantar y reformar"): mantener la aplicación, pero cambiar un componente subyacente por un equivalente gestionado, por ejemplo, mover una base de datos auto-Managed PostgreSQL VM a Managed PostgreSQL. Esfuerzo modesto, elimina el trabajo operativo, pero introduce un paso de migración de datos.
• Refactor: cambiar la aplicación en sí, por ejemplo, descomponer un monolito en Managed Kubernetes. Mayor esfuerzo y riesgo, diferido a su propio programa en lugar de incorporado en una ola de corte.

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

Un replatform siempre conlleva un paso de datos que el camino de infraestructura no cubre. Convertir la imagen de disco de una base de datos VM mueve la máquina; no hace que IONOS 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 que rodea y los datos que se encuentran debajo de ella.

2. Las tres rutas de infraestructura

Cada disposición se resuelve en una de las tres rutas diseñadas. Difieren en lo que se conserva, qué herramienta transporta los bytes y cuánto tiempo de inactividad cuesta el corte.

2.1 Ruta 1: Conversión de imagen y carga

Esta es la ruta cuando el objetivo es la superficie estándar de IONOS Public Cloud y el VM debe cruzar la frontera VMware-to-KVM. No hay importación nativa de OVF/OVA, por lo que el VM se convierte en una imagen inicializable y se carga, luego se provisiona como una instancia de IONOS.

El requisito técnico no negociable es el conjunto de controladores del invitado. Las instancias de IONOS Public Cloud arrancan en KVM y requieren controladores VirtIO de KVM; una imagen que solo lleva controladores paravirtuales de VMware no arrancará correctamente o ejecutará sin rendimiento de disco y red. Para invitados de Windows, IONOS proporciona una imagen ISO que contiene los controladores VirtIO relevantes, que se montan como una unidad de CD-ROM y se instalan antes o durante el corte. La secuencia práctica es instalar controladores VirtIO en el VM de origen mientras aún se ejecuta en VMware (para que la imagen convertida ya los contenga), convertir el disco virtual a un formato de carga compatible, cargarlo y provisionar una instancia a partir de la imagen cargada. El modo de firmware es importante: un invitado instalado bajo UEFI debe arrancar UEFI en el objetivo, y un invitado instalado bajo BIOS legado debe arrancar BIOS; una discrepancia produce una imagen no inicializable y es el fallo evitable más común en esta ruta.

La Ruta 1 es inherentemente un corte fuera de línea para el Workload convertido: el origen se apaga para tomar un estado de disco coherente, se convierte, se carga y se arranca en el objetivo. El tiempo de inactividad abarca la conversión y la carga, que se escala con el tamaño del disco y la anchura de banda de la conexión, por lo que es la ruta con la ventana de corte más grande y menos predecible. Es la ruta correcta para las cargas de trabajo que se modernizan en la superficie de Public Cloud, y la ruta incorrecta para un gran patrimonio que simplemente se desea mantener intacto.

2.2 Ruta 2: Replicación nativa de VMware en Private Cloud dedicado

Cuando el objetivo es un Private Cloud dedicado, el VM nunca abandona VMware, por lo que la migración se mantiene dentro de la herramienta nativa de VMware y la ventana de corte se colapsa. La herramienta que IONOS 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 replicación asíncrona, las migra, realiza un failover y revierte el failover, desplegado entre el vCenter del cliente en las instalaciones y el Private Cloud de IONOS. En un Private Cloud de IONOS, el appliance del lado de la nube se auto-provisiona, y el cliente despliega un appliance de replicación coincidente en las instalaciones en el vCenter local; los dos se emparejan luego. La versión desplegada es VCDA 4.7.x. El appliance en las instalaciones alcanza el appliance 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 VM por mes para la protección de VCDA, y la función de migración en sí es gratuita. Un gran patrimonio puede migrarse así con VCDA sin cargo de migración por VM, pagando solo por las máquinas virtuales que se mantienen bajo protección de recuperación ante desastres después.

El modelo de replicación es lo que hace que la ventana de corte sea corta. VCDA replica de forma asíncrona mientras el origen sigue ejecutándose, por lo que los datos se preparan en el objetivo antes de cualquier tiempo de inactividad. El corte es un failover: el origen se silencia, se replica el delta final y el VM se enciende en el sitio de Private Cloud de IONOS. Dado que VCDA también realiza un failover inverso, el corte tiene una reversión definida: si la validación falla, se puede revertir el VM al sitio en las instalaciones que sigue intacto. Esta es la razón más importante por la que un gran patrimonio de VMware tiene como objetivo Private Cloud en lugar de la ruta de conversión: las máquinas virtuales permanecen intactas, la ventana de corte por VM es de minutos en lugar de horas, y la reversión está integrada en la misma herramienta.

Dos puntos de red gobiernan cómo aterriza limpiamente el corte:

• Extensión de capa 2. Para permitir que las máquinas virtuales migradas mantengan sus direcciones IP existentes durante un corte por fases, NSX-T proporciona un VPN de capa 2, que estira un segmento de capa 2 entre la red en las instalaciones y un segmento de NSX en el Private Cloud. Los segmentos de NSX son dominios de capa 2 virtuales, por lo que un segmento extendido permite que una máquina virtual migrada se encuentre en el mismo dominio de difusión que tenía en las instalaciones mientras sus pares aún se están moviendo. Esto es lo que evita volver a direccionar cada VM en el día uno y permite que una dependencia Cluster se mueva por etapas.
• Movilidad solo dentro de Cluster. Una vez que las máquinas virtuales se ejecutan en el Private Cloud, vMotion puede moverlas en vivo entre hosts dentro del Cluster (por ejemplo, para equilibrar la carga o drenar un host). vMotion es solo dentro del Cluster. No es un mecanismo de migración entre sitios y no mueve una máquina virtual en ejecución desde las instalaciones hasta IONOS; ese movimiento entre sitios es el trabajo de VCDA, y es una operación de replicar-luego-failover, no un movimiento en vivo entre sitios. No diseñe un corte alrededor del movimiento de máquinas virtuales en ejecución entre sitios sin un tiempo de inactividad; 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: respalda el Workload desde el origen y lo restaura en el objetivo. Es la más lenta para realizar el corte porque es secuencial (una copia de seguridad completa, luego una restauración completa) y está fuera de línea durante la duración, pero es la más universalmente aplicable y no requiere un enlace en vivo entre los sitios. Úsela para cargas de trabajo donde ni una ruta de replicación de VMware limpia ni una conversión de imagen es justificada: servidores con una tasa de cambio baja, sistemas de archivo o cualquier cosa donde una ventana de mantenimiento larga es aceptable y la simplicidad operativa supera la velocidad de corte. También es la reversión natural cuando una conversión de Ruta 1 resulta no inicializable y el calendario no permite un segundo intento.

2.4 Elección entre las rutas

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

La regla que sigue: una máquina virtual con destino VMware dedicado toma la Ruta 2 por defecto, porque es la única ruta que mantiene la máquina virtual completa y da un corte corto y reversible. Una máquina virtual que se moderniza 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 reversión para la cola larga donde ninguna ruta especializada gana su complejidad.

3. Planificación de olas y corte híbrido

Un gran estado nunca se corta de una vez. Se descompone en olas, y la unidad de una ola es una dependencia Cluster: un conjunto de máquinas virtuales que se comunican entre sí y deben moverse juntas o permanecer accesibles a través de la frontera mientras están divididas. Dividir una aplicación habladora a través de la frontera entre el entorno local y la nube en medio de una ola convierte cada llamada interna en un viaje de ida y vuelta sobre el enlace híbrido, por lo que la dependencia Cluster, no la máquina virtual individual VM, es el átomo de planificación.

Ordenar las olas para retirar el riesgo temprano y las dependencias de manera limpia:

1. Ola de prueba: una pequeña dependencia Cluster autocontenida y de baja criticidad. Su propósito es validar el camino elegido de extremo a extremo (conversión o emparejamiento de VCDA, el enlace híbrido, las puertas de validación) antes de que algo importante se mueva.
2. Olas de hoja de dependencia: los sistemas que otros dependen pero que dependen de poco en sí mismos se mueven antes que sus consumidores, para que los consumidores nunca apunten a través de la frontera a algo que no ha llegado.
3. La ola de base de datos: secuenciada deliberadamente en relación con sus aplicaciones (Sección 4), porque es un volcado/restauración y, por lo tanto, un corte duro, no un goteo.
4. Las olas de aplicación y borde: los consumidores, movidos una vez que sus datos y dependencias ya están en su lugar.

Durante la migración, el estado es híbrido, por lo que el enlace entre el sitio local y IONOS es de carga, no incidental. Dos constructos del Módulo 3 lo llevan: un VPN Gateway (IKEv2/WireGuard, alta disponibilidad activa-pasiva en un IP público compartido) para la conectividad del sitio al sitio cifrada, y Cross-Connect para un interconectado privado de mayor ancho de banda donde la migración Volume o el tráfico residual entre fronteras justifica. Para las máquinas virtuales que aterrizan en Private Cloud dedicados, el segmento de nivel NSX-T L2 VPN de la Sección 2.2 es la extensión de nivel de segmento que permite que una dependencia Cluster abarque ambos sitios sin volver a direccionar. Dimensionar estos enlaces para el movimiento de datos de la migración, no solo para el tráfico en estado estable; un enlace subdimensionado es la causa más común de que una ola supere su ventana.

Cada ola termina en una puerta de validación antes de que se desplace el tráfico: confirme que el Workload se inicia, la aplicación responde en sus puntos de conexión, los datos están intactos y actualizados, y los sistemas dependientes aún pueden llegar a ellos a través de cualquier frontera que quede. Solo después de que la puerta pase, se corta el tráfico, típicamente repuntando DNS (Unidad 3.7), lo que dirige las nuevas conexiones al punto de llegada migrado mientras el antiguo se drena.

Si una puerta falla, la posición de reversión difiere por camino y debe diseñarse con anticipación:

• Camino 2 (VCDA): el reversión de failover devuelve la máquina virtual VM al sitio local intacto. Esta es la reversión más limpia y otra razón por la cual las cargas de trabajo con destino VMware son de menor riesgo.
• Camino 1 y Camino 3: la máquina virtual VM de origen se apagó pero no se destruyó, por lo que la reversión es encender la fuente de nuevo (y re-desviar DNS). Mantenga la fuente intacta y sin tocar hasta que la puerta pase; no desmantelar una fuente en la misma ola que migra.
• Las instantáneas son una reversión dentro del destino, no entre sitios. Una instantánea de nivel de máquina virtual VM en el destino (ya sea una instantánea de vSphere Snapshot de Private Cloud o una instantánea de IONOS Block Storage Snapshot) le permite revertir una máquina virtual recién migrada VM a su estado recién llegado si un cambio posterior a la conmutación por error va mal. Es local de la región y de nivel de máquina virtual VM, y críticamente no es coherente con la base de datos: una instantánea de una base de datos de máquina virtual VM en ejecución puede capturar un estado de transacción en vuelo que no se restaura de manera limpia. Las instantáneas protegen el paso de conmutación; no reemplazan el volcado/restablecimiento de la ola de base de datos.

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

Las bases de datos son la ola que con más frecuencia rompe un plan de otro modo sólido, porque el instinto es migrarlas como cualquier otro VM. Para las cargas de trabajo que se están replataformizando en bases de datos gestionadas por IONOS, ese instinto es incorrecto: no hay un corte de conmutación nativo basado en replicación desde una base de datos de origen a IONOS Managed PostgreSQL, MariaDB, o MongoDB. La ruta de migración admitida es el volcado y la restauración. Usted exporta un volcado lógico desde la fuente, luego lo carga en la base de datos gestionada de destino Cluster.

Esto da forma a la ola de tres maneras. Primero, es un corte de conmutación duro con tiempo de inactividad real: para tomar un volcado coherente, se detienen las escrituras en la fuente, se volca, se restaura y se valida antes de reanudar las escrituras en la base de datos de destino. La ventana se escala con el tamaño de los datos Volume, por lo que la ola de bases de datos obtiene la ventana de mantenimiento más generosa en el plan. Segundo, la reversión es la fuente en sí: mantenga la base de datos de origen en línea y autoritativa hasta que la base de datos de destino restaurada supere su puerta de validación, luego cambie la cadena de conexión de la aplicación. Tercero, una instancia de Snapshot en el lado de destino no es la red de seguridad aquí. Debido a que las instantáneas no son coherentes con la base de datos, el volcado es el artefacto de migración autoritativo y la fuente es la reversión autoritativa. Secuencie la ola de bases de datos para que su ventana de volcado/restauración se alinee con, e idealmente preceda, el corte 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 objetivo para confirmarla y la tabla a continuación como rubrica de vista general.

Restricciones difíciles que se deben llevar a cada ola: no hay importación nativa de OVF/OVA (la conversión está diseñada); vMotion es solo intra-Cluster y no es un movimiento entre sitios; la migración de bases de datos es solo volcado/restauración; y las instantáneas son de nivel VM, locales de la región y no consistentes con la base de datos. Para FinCorp, el gran patrimonio de VMware se resuelve limpiamente: la mayor parte del patrimonio se rehospeda en Private Cloud dedicado a través de VCDA (máquinas virtuales completas, migración gratuita, reversión de fallas, NSX-T L2 VPN que mantiene las direcciones estables en olas faseadas), las bases de datos destinadas a servicios administrados se replataforman a través de volcado/restauración en su propia ola con ventanas, y solo las cargas de trabajo explícitamente modernizadas toman la ruta de conversión de imagen en la superficie de Public Cloud.

Resumen

La migración a IONOS Cloud está diseñada, no importada: sin importación nativa de OVF/OVA, la arquitectura elige uno de tres caminos honestos por Workload (conversión de imagen y carga en la superficie KVM Public Cloud, replicación VCDA en VMware dedicado, o copia de seguridad/restauración), secuenciándolos por dependencia Cluster en olas sobre un enlace híbrido dimensionado, y controlando cada ola con validación y un rollback específico de la ruta. La ola de bases de datos es su propio corte duro por volcado y restauración, y las instantáneas son una red de seguridad a nivel de VM para el paso de corte en lugar de un sustituto de este.

Puntos clave:

• No hay importación nativa de OVF/OVA; la migración está diseñada por Workload, y la plataforma objetivo (VMware vs 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 por error inversa, con solo máquinas virtuales protegidas facturadas a 50 EUR por VM por mes; el appliance de nube se alcanza en TCP 55443.
• NSX-T L2 VPN extiende un segmento de Capa 2 entre sitios para que las olas escalonadas mantengan sus direcciones IP; vMotion es solo intra-Cluster 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 corte offline escalado por tamaño de disco y ancho de banda de enlace.
• Las bases de datos migran por volcado y restauración con una ventana de corte duro; la fuente permanece autoritativa hasta que el objetivo valida, y las instantáneas no son coherentes con la base de datos.

Terminología importante:

• VCDA (VMware Cloud Director Availability): la herramienta de DRaaS nativa de VMware que IONOS proporciona para replicar, migrar, conmutar por error y revertir la conmutación por error de máquinas virtuales entre vCenter en las instalaciones y IONOS 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 estira un segmento NSX entre sitios para que las máquinas virtuales migradas mantengan sus direcciones durante una transición escalonada.
• Disposición: la decisión por Workload (rehospedaje, reemplataforma, refactorización) que selecciona la ruta de migración de infraestructura.
• Ola: un grupo de dependencia Cluster 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 (VMware dedicado) - la plataforma objetivo 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 de volcado/restauración para la ola de bases de datos
• Unidad 3.6: Conectividad híbrida - VPN Gateway y Cross-Connect, los enlaces que llevan el corte híbrido
• Unidad 7.1: Resiliencia y continuidad empresarial - conmutación por error de DNS orquestada por el cliente y las estrategias de recuperación en las que se basa