De VMware a OpenShift Virtualization: un runbook de migración

Empiece por la decisión, no por la herramienta

Este runbook parte de una decisión ya tomada: parte o la totalidad de sus cargas de VMware funcionarán como máquinas virtuales en Red Hat OpenShift Virtualization. Si esa elección sigue abierta, resuélvala primero. Nuestro marco de decisión para la cuestión de VMware repasa las opciones, y cada una lleva a un plan distinto.

Red Hat respalda el cambio con el Migration Toolkit for Virtualization (MTV), un Operator que se ejecuta en el clúster OpenShift de destino. MTV se conecta a vCenter, copia los discos, convierte cada sistema invitado para KVM y crea la VM en OpenShift. Hace bien ese trabajo. No decide qué VM deben moverse, en qué orden, a qué redes y almacenamiento, ni qué ocurre si un corte sale mal. Eso es el runbook.

Inventariar y clasificar cada VM

Liste cada VM con su sistema operativo, responsable, dependencias, tamaño de discos, tasa de cambio y tiempo de inactividad tolerado. El sistema operativo invitado debe estar certificado para OpenShift Virtualization y admitido para la conversión a KVM con virt-v2v. Compruebe cada uno en ambas listas en lugar de suponer que una familia de sistemas común está cubierta.

Algunas VM necesitan un tratamiento especial o no pueden moverse con MTV. Los discos conectados a varias VM en modo multi-writer solo pueden migrarse en frío; esto se aplica a discos compartidos entre VM, no a toda VM cuyos discos estén en almacenamiento compartido. MTV documenta que no puede migrar VM de Microsoft Windows que usan Measured Boot; la alternativa de Red Hat es recrearlas en OpenShift Virtualization. Los invitados cifrados se admiten con condiciones: los volúmenes LUKS necesitan que se proporcionen sus frases de contraseña o que se configure el desbloqueo con Clevis y Tang, y BitLocker se admite, pero Red Hat documenta fallos de conversión en algunas versiones de Windows, así que pruebe primero compilaciones representativas. La validación de MTV señala los problemas conocidos de cada VM antes de migrar, y su opción Deep Inspection analiza las imágenes de disco para detectar lo que la inspección estándar no ve. Ejecute ambas pronto, mientras aún hay tiempo para corregir lo que encuentren.

Después, agrupe las VM en olas. Mantenga en la misma ola los niveles de aplicación que se comunican constantemente, y ponga primero las VM cuyos responsables toleran una interrupción más larga.

Elegir en frío o en caliente para cada VM

Una migración en frío copia una VM apagada. Funciona desde todos los orígenes que admite MTV y es el camino más sencillo, pero la interrupción dura toda la copia y la conversión. Una migración en caliente mantiene la VM en marcha mientras se mueve la mayor parte de los datos. Solo está disponible desde VMware vSphere y Red Hat Virtualization.

La migración en caliente tiene dos etapas. En la etapa de precopia la VM sigue funcionando mientras MTV copia sus discos de forma incremental mediante instantáneas de changed block tracking (CBT), con un intervalo de precopia predeterminado de 60 minutos que puede cambiarse. La etapa de corte empieza en el momento que usted programe o active: la VM se apaga, se copian los cambios restantes y se convierte el sistema invitado. Una migración en caliente sigue necesitando ese apagado, así que no es una migración en vivo. La duración del corte depende de cuántos datos cambiaron desde la última instantánea, así que las bases de datos con mucha actividad necesitan una ventana de corte calculada a partir de mediciones, no de esperanzas.

La migración en caliente desde VMware tiene requisitos previos. CBT debe estar activado en la VM y en sus discos, y VMware Tools debe estar instalado. Las VM de Windows necesitan además los servicios Volume Shadow Copy y VMware Snapshot Provider activados, en modo Manual o Automático, o la creación de instantáneas falla. La migración en vivo, casi sin inactividad, existe en MTV solo entre clústeres de OpenShift Virtualization o entre namespaces de un mismo clúster, a partir de MTV 2.10 con OpenShift Virtualization 4.20. No está disponible desde VMware.

Construir la zona de aterrizaje antes de la primera copia

Primero el almacenamiento. Cada datastore de origen se asigna a una storage class de OpenShift, así que las clases deben existir con el rendimiento, la capacidad y los modos de acceso que necesitan las cargas. Una base de datos que funcionaba sobre flash rápido en vSphere lo notará si aterriza en una clase de uso general.

Después las redes. Cada port group de vSphere se asigna a una red de destino: la red de pods, o una network attachment definition de Multus que conecta la VM a una VLAN existente. Decida el direccionamiento IP por ola. Las interfaces de red virtuales cambian durante la migración, así que una configuración de IP estática ligada al nombre de la interfaz dentro del invitado puede perderse. Seleccione la opción de conservar las IP estáticas, asegúrese de que la información de las interfaces de red de la VM de origen esté disponible para MTV y valide la red después de cada migración. Las reglas de firewall, los registros DNS y las licencias ligados a una dirección MAC o IP necesitan la misma atención.

Para el rendimiento de la transferencia, cree una imagen de VMware Virtual Disk Development Kit (VDDK). Red Hat recomienda encarecidamente usar VDDK al transferir discos desde vSphere, y es obligatorio cuando las VM de origen están en vSAN. Una red de migración dedicada en el proveedor de origen mantiene el tráfico de copia lejos del tráfico de producción. Si esa red usa una MTU distinta de la predeterminada, la red de transferencia de OpenShift debe usar el mismo valor.

Mapas, planes y hooks

En MTV, los network maps y storage maps registran cómo las redes y datastores de origen aterrizan en el destino, y un plan de migración vincula un conjunto de VM con esos mapas, un namespace de destino y un tipo de migración. Un plan por ola mantiene cada ola revisable y repetible.

Los hooks previos y posteriores a la migración ejecutan automatización alrededor de cada VM: poner en reposo una aplicación, actualizar el DNS o un balanceador de carga, registrar la nueva VM en la monitorización y las copias de seguridad. Todo lo que una persona haría a mano a las 2 de la madrugada es un buen candidato para un hook. Tenga en cuenta que un hook previo a la migración necesita VMware Tools en la VM de origen. MTV también permite dar a usuarios no administradores permisos para crear mapas y planes en sus propios namespaces sin poder crear proveedores ni cambiar la configuración del sistema, lo que encaja con equipos de aplicación responsables de sus propias olas.

Ejecutar una ola piloto y medirla

Elija una ola piloto que se parezca a producción, con los mismos sistemas operativos, almacenamiento y redes, pero cuyos responsables toleren un problema. Mígrela de principio a fin y mida aquello de lo que depende el plan: rendimiento de transferencia, duración de la precopia, duración del corte por VM y tiempo para validar cada aplicación.

Valide la operación, no solo el arranque. ¿Se pueden respaldar y restaurar las nuevas VM? ¿Las ven la monitorización y las alertas? ¿Puede el equipo parchearlas, redimensionarlas y recuperar una tras un fallo? Un piloto que solo demuestra que las VM arrancan ha probado la parte fácil.

Corte con vuelta atrás

Programe cada corte dentro de una ventana de mantenimiento acordada, congele los cambios en las VM de la ola y deje por escrito quién puede detener el corte y ante qué señales. Tras el corte, compruebe que cada VM arranca, tiene sus discos y direcciones y supera sus pruebas de aplicación antes de que nadie declare el éxito.

Mantenga intactas las VM de origen, apagadas, hasta que la ola se acepte formalmente. En el flujo normal de MTV la VM de origen permanece en vSphere después de copiar sus datos, pero confírmelo para su proveedor y para cualquier hook que actúe sobre el origen. Un origen apagado no contiene nada de lo escrito en la nueva VM después del corte. Por eso, volver atrás significa detener o aislar la nueva VM, decidir cómo se recuperan o concilian los datos escritos desde el corte y solo entonces encender el origen y devolver el DNS o el balanceador. Acuerde de antemano cuánto tiempo puede durar una ola antes de revertir, para que la decisión se tome según el plan y no bajo presión.

Dónde pierden tiempo las migraciones

Unos pocos problemas explican la mayoría de los retrasos: CBT no activado en las VM o discos previstos para migración en caliente, falta de imagen VDDK, un network map o storage map al que le falta un port group o datastore, almacenamiento de destino más lento que el de origen, y reglas de firewall o licencias ligadas a direcciones antiguas. Cada uno es barato de detectar en la fase de inventario y caro de descubrir durante una ventana de corte.

Planifique también el desmantelamiento. Las licencias, hosts y contratos de soporte de VMware solo dejan de costar dinero cuando el entorno de origen se retira de verdad, así que la última ola no es el final del proyecto.

Cómo lo abordamos

Esta es la secuencia que seguimos: primero inventario y validación, una zona de aterrizaje construida y probada antes de la primera copia, un plan de migración por ola, un piloto medido y cortes con una vuelta atrás documentada. Nuestro Sprint de evaluación de dos semanas entrega una arquitectura objetivo por escrito y una secuencia de migración con planes de vuelta atrás, para que la migración parta de hechos revisados y no de estimaciones.