Migración de VMware a OpenShift con Cisco Isovalent, en olas, conservando sus direcciones IP.
Red Hat OpenShift Virtualization ejecuta sus máquinas virtuales actuales en Kubernetes, junto a contenedores. Cisco Isovalent conecta las redes de vSphere y OpenShift para que las aplicaciones se muevan en olas sin cambiar de dirección IP. Los ingenieros sénior de Ngenium evalúan su entorno, diseñan el destino en Cisco UCS, migran con Migration Toolkit for Virtualization de Red Hat y aseguran el resultado. Solo servicios: usted adquiere la plataforma a través de su socio o distribuidor; nosotros hacemos la ingeniería de la migración.
Todo lo que hay entre un entorno vSphere y una plataforma OpenShift en funcionamiento.
Mover máquinas virtuales es la parte fácil. Lo que decide si una migración tiene éxito es saber qué se mueve con facilidad y qué no, mantener intacta la identidad de red y reimplementar la intención de seguridad en la nueva plataforma.
Sepa qué se mueve con facilidad y qué no.
Inventario con RVTools y el OpenShift migration advisor gratuito de Red Hat, dependencias de aplicaciones y un scorecard tipo semáforo: verde para VM estándar de Windows y Linux, ámbar para discos grandes, clústeres de disco compartido y GPU pass-through, replantear para funciones sin equivalente directo.
Una plataforma que puede dimensionar y adquirir.
OpenShift Virtualization en Cisco UCS con gestión del ciclo de vida en Intersight, almacenamiento con FlexPod y NetApp, FlashStack con Pure Storage u OpenShift Data Foundation, y Cisco Unified Edge para sucursales y plantas.
Mueva hoy la VM 12 de 40 y conserve su IP.
Cilium como red del clúster con Cisco Isovalent. Private Networks da a las VM redes aisladas al estilo VLAN; el Network Bridge conecta vSphere y OpenShift en capa 3, sin extender un dominio de capa 2, para que una VM conserve su dirección mientras el resto de su grupo espera.
La intención de NSX, reimplementada, no copiada.
La base de reglas actual clasificada en necesarias, duplicadas, demasiado amplias y obsoletas, y luego reimplementada como políticas de red de Cilium con plantillas de aplicación reutilizables, con evidencia de flujos de Hubble antes y después de cada corte.
Olas controladas con Red Hat MTV.
Mapeos de red y de almacenamiento, migración en caliente o en frío elegida por carga de trabajo, secuencia por grupo de dependencias, runbooks de corte y criterios de reversión. La migración en caliente acorta la interrupción pero no la elimina, y lo decimos desde el primer día.
Termine la migración y luego retire VMware.
Validación posterior al corte frente a la línea base de flujos, plantillas de políticas y monitoreo de flujos exportados a Splunk, patrones de respaldo y recuperación ante desastres en OpenShift, y un plan para retirar las dependencias del bridge y desmantelar los hosts cuando cada ola esté estable.
Antes, durante, después: un solo equipo responsable.
Los mismos ingenieros sénior llevan el trabajo desde el primer inventario hasta el último host desmantelado. Tras la puesta en marcha, la plataforma puede pasar a operaciones de seguridad gestionadas gracias a nuestra alianza estratégica con Port53.
Lo que su equipo de VMware ya conoce, en OpenShift.
- vCenter → la consola web de OpenShift, con Advanced Cluster Management para flotas
- Host ESXi → un nodo trabajador bare metal que ejecuta KVM, aprovisionado desde Intersight
- DRS y HA → el planificador, la salud de los nodos y las políticas de desalojo, configurados por VM
- vMotion → migración en vivo, sobre almacenamiento compartido de lectura y escritura múltiple
- Port group y switch distribuido → una network attachment definition con Cilium e Isovalent Private Networks
- Datastore → una storage class y un persistent volume claim, mapeados uno a uno por MTV
- Firewall distribuido de NSX → políticas de red de Cilium: la intención se reimplementa, no se convierte regla por regla
- VMware Tools → el agente invitado de QEMU, instalado durante o después de la conversión
Por qué los equipos recurren a Ngenium.
- Solo ingenieros sénior — el ingeniero que evalúa su entorno es quien ejecuta el corte.
- Solo servicios — nunca revendemos hardware ni software y no tenemos margen de producto, así que nuestro consejo sobre si migrar y qué migrar sigue su entorno, no una cuota.
- Profundidad en redes y seguridad — redes Cisco e Isovalent junto a Red Hat OpenShift, NetApp, Pure Storage y Splunk; la red es donde las migraciones de VMware suelen fallar.
- Honestos sobre las concesiones — la migración en caliente sigue necesitando una ventana de corte, algunas cargas deben quedarse o rediseñarse, y operar dos plataformas cuesta dinero hasta la última ola.
Sobre la migración de VMware a OpenShift.
¿Nuestras máquinas virtuales pueden ejecutarse en OpenShift sin convertirse en contenedores?
Sí. Red Hat OpenShift Virtualization ejecuta máquinas virtuales en KVM, gestionadas a través de OpenShift, junto a contenedores. Los sistemas operativos invitados y las aplicaciones se mantienen como están. Red Hat también ofrece la edición OpenShift Virtualization Engine como punto de entrada solo para VM, que puede pasar después a la plataforma completa.
¿Las aplicaciones conservarán sus direcciones IP?
Pueden hacerlo. El Network Bridge de Cisco Isovalent conecta las redes de vSphere y OpenShift en capa 3, sin extender un dominio de capa 2, para que una VM conserve su dirección al moverse y sus dependencias sigan funcionando mientras el resto de su grupo espera. Validamos el diseño del bridge frente a la matriz de soporte vigente durante la evaluación.
¿Cuánta interrupción debemos esperar?
Alguna, por cada VM. La migración en caliente copia los discos mientras la VM sigue funcionando y luego apaga el origen para una sincronización final en el corte, lo que acorta la interrupción pero no la elimina. Registramos la tolerancia a la interrupción de cada aplicación en la evaluación, elegimos migración en caliente o en frío por carga y programamos los cortes dentro de sus ventanas de cambio.
¿Ngenium vende OpenShift, Isovalent o el hardware?
No. Ngenium es una firma de solo servicios. Usted adquiere Red Hat OpenShift, Cisco Isovalent y Cisco UCS a través de su socio o distribuidor; Ngenium evalúa, diseña, migra y asegura. Los socios de canal de Cisco también recurren a nosotros para entregar migraciones a sus clientes, incluidos proyectos de marca blanca bajo NDA.
¿Qué no debería moverse, o debería moverse al final?
Las VM estándar de Windows y Linux sobre almacenamiento compartido suelen moverse con facilidad. Los discos grandes, los clústeres de disco compartido, el GPU y PCI pass-through, las cadenas largas de snapshots y los invitados con condiciones especiales de software requieren más planificación, y las funciones sin equivalente directo se rediseñan en lugar de copiarse. El scorecard de preparación clasifica cada grupo de cargas en verde, ámbar o replantear antes de hacer un plan.
¿Planea dejar VMware?
Hable con los ingenieros sénior que evaluarían y migrarían su entorno — no con un vendedor.