Qué hacemos · Datos y web: Live migration y salida de hipervisores
Las máquinas virtuales en marcha se mueven entre hosts sin detenerse, y parques enteros salen de VMware o de servidores KVM independientes hacia nuestro private cloud Oracle Linux Virtualization Manager (OLVM). En caliente cuando es seguro hacerlo en caliente, como copia en frío verificada cuando no lo es, y siempre con el original intacto hasta que el lado nuevo está probado.
Qué es
Tres tipos de traslado bajo una misma disciplina:
- Live migration: una máquina virtual KVM en marcha, memoria y disco, movida entre hosts con una pausa medida en milisegundos. Es como hacemos el mantenimiento de hosts y la sustitución de hardware sin programar su downtime.
- Salida de hipervisores: parques VMware y hosts KVM independientes trasladados a OLVM, donde las VM arrancan desde storage all-flash enterprise sobre fabrics Fibre Channel redundantes, con backup y monitorización desde el primer día.
- Traslados de sede: entornos enteros reubicados entre nuestros datacenters, conservando sus direcciones y sus identidades.
Cómo lo construimos
Una regla de decisión antes de mover un solo byte. Si la generación de CPU, la infraestructura de red y la versión del hipervisor siguen siendo compatibles, la VM se mueve en caliente. Cuando todo cambia a la vez, no apostamos: la VM se apaga, se copia, se redefine y se arranca en frío en el destino, y el origen queda intacto como rollback.
Live migration bien hecha. Usamos la ruta de migración directa de libvirt con copia de storage y auto-converge, de modo que las VM ocupadas también convergen. El destino se prepara primero: pools de storage, bridges e interfaces VLAN, y para las disposiciones de disco poco habituales, una imagen creada de antemano con el tamaño exacto del origen.
Reconstruir lo que no tiene estado, replicar lo que lo tiene. Para una salida a menudo preferimos una reconstrucción limpia a partir de especificaciones medidas en vivo. Las capas web y de aplicación se reconstruyen desde la configuración; la base de datos se mueve por replicación, de modo que el cutover es una promoción con segundos de diferencia.
Un appliance de migración construido para ello. Las conversiones se ejecutan en un servidor de migración dedicado con storage all-flash NVMe y SSD, conectado directamente a nuestro fabric. Convierte guests de otros hipervisores y vuelca las imágenes de disco KVM directamente en discos creados por la plataforma de destino, conservando direcciones MAC, modo de firmware y tipo de máquina, de modo que la VM arranca al llegar.
Auditada contra la API, no contra las notas de construcción. Cada VM se comprueba contra el propio gestor de virtualización (topología de CPU, garantías de memoria, interfaces de red, rutas, discos, nombre de host) antes de mover ningún dato. Las VM se dimensionan correctamente y nunca reciben más vCPU que núcleos tiene un socket de CPU.
Windows, resuelto. Los drivers y las herramientas de guest se ordenan, las herramientas del hipervisor antiguo se retiran solo cuando el disco de arranque ya funciona sobre VirtIO, y Active Directory y las licencias se comprueban después del traslado.
Dry runs, con el momento acordado. Cada conversión se ensaya primero sobre una copia. Si un traslado pudiera tocar su tráfico, acordamos el momento con usted antes.
De qué le protege
- Downtime por mantenimiento de hosts, trabajos de firmware o sustitución de hardware.
- Cambios de licencia de los que no tiene salida.
- Una migración que pierde el origen antes de que el destino funcione.
- Un traslado entre generaciones de CPU que rompe un guest en silencio.
- VM que llegan con la topología equivocada, una interfaz ausente o una dirección perdida.
- Renumerar todo su parque solo para cambiar de plataforma.
En la práctica
Un balanceador, movido en caliente. La concurrida VM de balanceo de carga de un editor de noticias se migró en caliente entre hosts, disco incluido, en 3 minutos y 5 segundos, con una pausa de unos 300 milisegundos.
Una cadena de televisión nacional deja VMware. Reconstruimos la plataforma web de una cadena de televisión nacional de VMware a OLVM como VM correctamente dimensionadas, auditamos cada una contra la API y movimos la base de datos por replicación. Un servidor de desarrollo pasó por nuestro appliance de migración y estuvo listo para arrancar en unos siete minutos y medio. El cutover se completó hace meses.
Un host KVM independiente, importado. El servidor KVM independiente de un cliente se importó a OLVM a unos nueve GiB por minuto, con todas las direcciones intactas, porque el dry run ya había resuelto el nombrado de interfaces del nuevo chipset virtual.
Un parque VDI movido entre países. Un entorno de escritorios virtuales se movió de Ámsterdam a Atenas. Llevamos su subred de gestión entera sobre nuestra extensión de capa 2, de modo que cada pool de escritorios y cada asignación llegaron sin cambios, y cada controlador de dominio se verificó sano después.
Por qué EuroVPS
- Una regla escrita para caliente frente a frío, aplicada cada vez.
- El origen conservado como rollback hasta que el destino está probado.
- Un appliance de migración dedicado, no un portátil y un fin de semana.
- Extensión de capa 2 entre nuestras sedes, para que se mueva sin renumerar.
- Cada VM auditada contra la API antes de mover los datos.
Preguntas frecuentes
- ¿Pueden mover nuestras VM sin reconstruirlas? Sí, por conversión, con drivers y herramientas cambiados en un orden probado. Conservamos los originales hasta que usted da el visto bueno.
- ¿Conservarán nuestras VM sus direcciones IP? Pueden. Con la extensión de capa 2, los servidores conservan sus direcciones y se mueven de uno en uno.
- ¿Cuánto detiene a la VM una live migration? Normalmente una fracción de segundo en la conmutación. Los traslados en frío van en una ventana acordada con usted.
- ¿Y si algo sale mal a mitad del traslado? El origen está sin cambios. Volvemos atrás, averiguamos por qué y lo intentamos de nuevo.
- ¿Qué es OLVM? Oracle Linux Virtualization Manager, gestión enterprise para KVM estándar. Sin dependencia de un proveedor propietario.
¿Deja VMware? Hable con un ingeniero.
Su próximo socio de infraestructura
Veamos su infraestructura.
Cuéntenos qué ejecuta hoy y qué necesita mejorar. Un ingeniero revisará su solicitud y le ayudará a planificar el siguiente paso.
+357 222 32280
Empecemos por su infraestructura.
Un poco de contexto nos ayuda a empezar la conversación adecuada.