Proxmox Live Migration: ¿Necesitas Storage Compartido para Migrar VMs sin Apagarlas?


Proxmox Live Migration: ¿Necesitas Storage Compartido para Migrar VMs sin Apagarlas?

Una de las preguntas más frecuentes cuando una empresa evalúa migrar de VMware hacia Proxmox VE es:

¿Necesito almacenamiento compartido para poder hacer Live Migration?

Durante muchos años el concepto de migración en vivo estuvo muy ligado a arquitecturas con SAN, NAS o almacenamiento compartido.

Por eso es común asumir que si cada servidor Proxmox utiliza sus propios discos locales, una máquina virtual necesariamente debe apagarse para pasar de un nodo a otro.

Pero en Proxmox VE la respuesta es más interesante:

No. El almacenamiento compartido facilita y acelera considerablemente una Live Migration, pero Proxmox también puede realizar determinadas migraciones en vivo cuando los discos de la VM se encuentran en almacenamiento local.

La diferencia fundamental es qué información tiene que moverse durante el proceso.

¿Qué es Live Migration en Proxmox?

Live Migration permite trasladar una máquina virtual que está ejecutándose en un nodo Proxmox hacia otro nodo del mismo cluster reduciendo al mínimo la interrupción percibida por los usuarios.

Esta capacidad resulta especialmente útil para tareas como:

  • Mantenimiento de servidores físicos.
  • Actualizaciones.
  • Redistribución de cargas.
  • Reemplazo de hardware.
  • Intervenciones preventivas.
  • Balanceo de CPU y memoria.
  • Retiro temporal de un nodo.

Podemos visualizar el proceso de manera sencilla:

PVE01 → Live Migration → PVE02

La máquina continúa trabajando mientras Proxmox transfiere su estado hacia el nodo destino y realiza finalmente el cambio de ejecución.

Escenario 1: Live Migration con storage compartido

Este es el escenario tradicional y normalmente el más eficiente.

Supongamos que tenemos:

PVE01 + PVE02 + PVE03 → Storage compartido

El almacenamiento podría estar proporcionado, dependiendo de la arquitectura, mediante tecnologías como:

  • SAN.
  • NFS.
  • iSCSI.
  • Fibre Channel.
  • Ceph RBD.
  • Otras plataformas compatibles de almacenamiento compartido.

Los discos de la VM ya se encuentran almacenados en un sistema al que pueden acceder tanto el nodo origen como el nodo destino.

Por ejemplo:

VM01 disk → Storage compartido

Si migramos VM01 de PVE01 hacia PVE02, Proxmox no necesita copiar nuevamente todo el disco virtual.

El almacenamiento continúa en el mismo lugar.

Principalmente debe trasladarse el estado de ejecución de la máquina, incluyendo memoria y otros elementos necesarios para completar la transición.

Por eso las migraciones con almacenamiento compartido pueden ser considerablemente más rápidas.

¿Entonces necesito Ceph para hacer Live Migration?

No.

Ceph es una excelente alternativa para determinadas arquitecturas Proxmox, especialmente cuando buscamos infraestructura hiperconvergente y almacenamiento distribuido.

Pero Ceph no es un requisito obligatorio para Live Migration.

Una empresa que ya dispone de una SAN empresarial puede evaluar conservarla.

También pueden existir diseños con NFS, iSCSI, Fibre Channel u otras tecnologías.

La plataforma de almacenamiento debe elegirse con base en:

  • Rendimiento.
  • IOPS.
  • Latencia.
  • Capacidad.
  • Redundancia.
  • Crecimiento.
  • Disponibilidad.
  • Presupuesto.
  • Infraestructura existente.

No deberíamos implementar Ceph únicamente porque estamos implementando Proxmox.

Consulta nuestras soluciones Proxmox VE

Escenario 2: Live Migration con almacenamiento local

Aquí aparece una de las capacidades que genera más dudas.

Supongamos:

PVE01 → ZFS local → VM01

y queremos llevar la máquina hacia:

PVE02 → ZFS local

El nodo destino no tiene acceso al disco original de VM01.

Por tanto, durante la migración Proxmox debe trasladar también la información almacenada en los discos virtuales.

Conceptualmente ocurre algo similar a:

Memoria + Estado + Disco virtual → red de migración → nodo destino

La máquina puede continuar ejecutándose durante gran parte de este procedimiento, mientras Proxmox sincroniza la información necesaria hacia el servidor destino.

Finalmente se produce la transición hacia el nuevo nodo.

¿Cuál es la gran diferencia?

Característica Storage compartido Storage local
Disco accesible desde ambos nodos Sí No
Debe copiarse todo el disco durante la migración Normalmente no Sí
Consumo de red Menor Mayor
Tiempo de migración Generalmente menor Puede ser considerablemente mayor
Diseño de storage central Necesario según arquitectura No necesariamente

El tamaño de la VM cambia completamente el escenario

Migrar una pequeña máquina virtual con almacenamiento local no representa el mismo problema que mover una VM con varios terabytes de información.

Cuando utilizamos storage local debemos considerar:

  • Tamaño de los discos virtuales.
  • Cantidad de datos realmente utilizados.
  • Velocidad del almacenamiento origen.
  • Velocidad del almacenamiento destino.
  • Capacidad de la red.
  • Tráfico generado por la propia VM.
  • Cambios que continúan ocurriendo durante la migración.

Por eso la pregunta no debería ser solamente:

¿Proxmox puede hacerlo?

La pregunta realmente importante es:

¿La arquitectura puede hacerlo dentro de la ventana operativa que necesita la empresa?

La red de migración es crítica

Una infraestructura Proxmox empresarial puede manejar diferentes tipos de tráfico:

  • Management.
  • Máquinas virtuales.
  • Corosync.
  • Storage.
  • Ceph.
  • Backup.
  • Live Migration.

Si utilizamos la misma interfaz y la misma red para todo, una migración de gran tamaño puede competir por ancho de banda con otros servicios.

Proxmox permite definir una Migration Network específica para dirigir el tráfico de migración por una red determinada.

En infraestructuras empresariales esto puede ser especialmente útil para separar el tráfico de migración del tráfico crítico del cluster y de las máquinas virtuales.

No confundamos Live Migration con High Availability

Live Migration y HA solucionan problemas diferentes.

Live Migration

El nodo origen sigue funcionando.

El administrador decide mover una VM hacia otro servidor.

Ejemplo:

“Mañana voy a actualizar PVE01; primero moveré sus VMs.”

High Availability

El nodo puede haber sufrido una falla inesperada.

El cluster debe recuperar las cargas protegidas en los nodos restantes.

Ejemplo:

“PVE01 acaba de fallar físicamente.”

Si el servidor origen ya está muerto, no podemos realizar una Live Migration desde él.

Por eso HA, storage, quorum, capacidad disponible y backup deben diseñarse como una arquitectura completa.

¿Qué ocurre si utilizamos una SAN existente?

Éste es un escenario muy interesante para empresas que actualmente utilizan VMware.

Supongamos:

  • 3 hosts VMware.
  • SAN empresarial.
  • Switches Fibre Channel o red iSCSI.
  • 40 máquinas virtuales.
  • Veeam.

La empresa decide evaluar Proxmox.

No necesariamente deberíamos sustituir todo simultáneamente.

Primero podemos estudiar si la SAN existente puede integrarse correctamente con la nueva arquitectura.

Esto puede reducir inversión y facilitar una migración gradual.

Consulta nuestro servicio de Migración a Proxmox VE

¿Cuándo tiene sentido storage local?

El almacenamiento local puede ser perfectamente válido en determinados escenarios.

Por ejemplo:

  • Clusters pequeños.
  • Ambientes con pocas VMs.
  • Infraestructura donde el costo es crítico.
  • Workloads que pueden tolerar migraciones más largas.
  • Arquitecturas donde existe una estrategia adecuada de backup y recuperación.

ZFS puede proporcionar una plataforma de almacenamiento local muy robusta dentro de un nodo.

Pero debemos recordar:

redundancia local no equivale a almacenamiento compartido.

¿Cuándo preferimos almacenamiento compartido?

Puede resultar especialmente conveniente cuando existen:

  • Muchas máquinas virtuales.
  • VMs de gran tamaño.
  • Mantenimiento frecuente.
  • Necesidad de migraciones rápidas.
  • Alta disponibilidad.
  • Operaciones 24x7.
  • Grandes clusters.
  • Requerimientos estrictos de continuidad.

El diseño puede utilizar SAN, NAS, NFS, iSCSI, Fibre Channel, Ceph u otras alternativas dependiendo del proyecto.

Antes de ejecutar una Live Migration

En una infraestructura productiva recomendamos comprobar:

  • Estado del cluster.
  • Quorum.
  • Capacidad del nodo destino.
  • CPU disponible.
  • Memoria RAM disponible.
  • Storage disponible.
  • Compatibilidad entre nodos.
  • Networking.
  • VLAN de la VM.
  • Velocidad de la red de migración.
  • Backup reciente.
  • Existencia de dispositivos locales asociados a la VM.
  • Ventana operativa.

Una función disponible técnicamente no significa que debamos ejecutarla sin planeación en producción.

Live Migration durante una migración VMware a Proxmox

Cuando diseñamos una migración desde VMware, la capacidad de mover posteriormente VMs entre nodos Proxmox es solamente una parte de la arquitectura.

Antes debemos diseñar:

Compute + RAM + Networking + Storage + Cluster + Quorum + HA + Backup + Operación.

La decisión entre SAN, Ceph, NFS, ZFS o almacenamiento local debe salir de los requerimientos del proyecto, no de una receta universal.

Conoce nuestras soluciones de Virtualización Empresarial

Instalación y Configuración Proxmox VE Empresarial

Conclusión

Proxmox VE no necesita obligatoriamente almacenamiento compartido para realizar determinadas migraciones en vivo.

Con storage compartido, los discos de la máquina virtual ya se encuentran accesibles desde ambos nodos y el proceso puede ser considerablemente más rápido.

Con storage local, Proxmox puede trasladar también los discos, pero eso aumenta el tiempo de migración y el tráfico de red.

Por eso no existe una respuesta universal.

Para una pequeña infraestructura, almacenamiento local con una buena estrategia de backup puede ser suficiente.

Para un cluster empresarial con muchas VMs, operación crítica y mantenimiento frecuente, el storage compartido o distribuido puede ofrecer ventajas importantes.

La pregunta correcta no es:

“¿Necesito storage compartido para Proxmox?”

La pregunta correcta es:

“¿Qué arquitectura de almacenamiento necesito para cumplir mis objetivos de rendimiento, disponibilidad, migración y recuperación?”

¿Estás evaluando Proxmox para tu empresa?

En SISTRO podemos analizar servidores, máquinas virtuales, almacenamiento, networking, backup, RPO, RTO y requerimientos de alta disponibilidad antes de definir la arquitectura.

Podemos implementar Proxmox desde cero o diseñar una migración desde VMware, Hyper-V u otras plataformas.

Consulta las soluciones Proxmox de SISTRO

Preguntas frecuentes

¿Proxmox necesita storage compartido para Live Migration?

No necesariamente. Proxmox puede realizar migración en vivo con almacenamiento local en determinados escenarios, pero los discos deben transferirse además del estado de la VM, aumentando el tiempo y el tráfico de red.

¿Live Migration es más rápida con SAN o Ceph?

Cuando los nodos comparten el mismo almacenamiento, no es necesario trasladar todo el disco virtual durante la migración. Esto generalmente hace que el proceso sea considerablemente más rápido.

¿Necesito Ceph obligatoriamente?

No. Proxmox puede trabajar con Ceph, SAN, NFS, iSCSI, Fibre Channel, ZFS, almacenamiento local y otras tecnologías. La elección depende de la arquitectura.

¿ZFS es almacenamiento compartido?

ZFS utilizado localmente pertenece al nodo que aloja los discos. Puede proporcionar redundancia y snapshots dentro del servidor, pero no se convierte automáticamente en storage compartido entre los nodos.

¿Live Migration reemplaza High Availability?

No. Live Migration mueve una VM mientras el nodo origen continúa funcionando. HA busca recuperar cargas después de determinadas fallas.

¿Qué red debería utilizar para Live Migration?

En ambientes empresariales conviene analizar una red de migración dedicada o adecuadamente segmentada, especialmente cuando se transfieren discos locales de gran tamaño.