Cuando una infraestructura virtual crece, el almacenamiento suele convertirse en uno de los principales puntos de dependencia. Discos locales, cabinas tradicionales o sistemas que funcionaban correctamente con pocos servidores pueden empezar a limitar la movilidad de las máquinas virtuales, la alta disponibilidad y la capacidad de crecimiento del clúster.
En entornos Proxmox VE, Ceph permite construir una capa de almacenamiento distribuido accesible desde los distintos nodos del clúster. Esto facilita escenarios de alta disponibilidad y movilidad de cargas, evitando que una máquina virtual quede ligada al almacenamiento físico de un único host. Proxmox considera Ceph RBD almacenamiento compartido, y el acceso común a los discos es precisamente uno de los elementos que permite realizar migraciones en vivo entre nodos sin tener que copiar primero toda la imagen del disco.
Pero migrar una infraestructura existente a Ceph requiere planificación. El objetivo no debe ser simplemente “mover discos”, sino hacerlo manteniendo integridad de datos, rendimiento y posibilidad de regresar al estado anterior si aparece algún problema.
¿Realmente se puede migrar a Ceph sin downtime?
En determinados escenarios, sí.
Si la máquina virtual ya se encuentra dentro de un entorno Proxmox compatible y el almacenamiento de origen y destino admiten la operación correspondiente, Proxmox puede mover almacenamiento mientras la VM continúa funcionando. Una vez que las cargas se encuentran sobre almacenamiento compartido, las migraciones en vivo entre nodos pueden realizarse sin detener la VM porque todos los nodos tienen acceso al mismo almacenamiento.
Sin embargo, “cero downtime” no debe considerarse una garantía para cualquier arquitectura. El método depende del origen de los datos, tipo de almacenamiento, versión de Proxmox, carga de trabajo, red disponible y características de la máquina virtual.
Por ejemplo, incluso el mecanismo de live import de Proxmox para determinadas migraciones desde VMware está diseñado para reducir considerablemente el tiempo de interrupción, pero la documentación advierte que la VM de origen todavía debe apagarse durante una parte del procedimiento.
Por tanto, un proyecto profesional debe clasificar primero cada VM en una de estas categorías:
- migración online viable;
- migración con interrupción mínima;
- migración que requiere una ventana de mantenimiento.
1. Verifica la salud de Ceph antes de mover la primera VM
Una migración no debe comenzar simplemente porque el pool de Ceph ya aparece disponible en Proxmox.
Primero hay que validar que el clúster de almacenamiento se encuentra estable, que los OSD están operativos, que no existen procesos inesperados de recuperación o rebalanceo y que la redundancia definida responde al diseño previsto.
Ceph recomienda trabajar con el clúster en estado saludable antes de realizar operaciones sobre RBD.
También deben comprobarse:
- espacio disponible real;
- política de réplica o erasure coding;
- distribución de los OSD;
- latencia entre nodos;
- rendimiento de lectura y escritura;
- MTU y configuración de red;
- ausencia de errores persistentes en discos o enlaces.
Mover datos hacia un clúster que todavía no está estable únicamente traslada el riesgo desde el almacenamiento anterior hacia Ceph.
2. Evalúa la red antes que los discos
En una arquitectura hiperconvergente con Ceph, la red forma parte directa del sistema de almacenamiento.
Una migración de varios cientos de gigabytes o varios terabytes puede consumir una cantidad considerable de ancho de banda. Si ese tráfico comparte indiscriminadamente el mismo enlace con usuarios, backups, administración del clúster o Corosync, puede afectar la operación.
Proxmox recomienda mantener una conexión de Corosync estable y de baja latencia y advierte específicamente que operaciones relacionadas con almacenamiento o backup pueden saturar enlaces y afectar la comunicación del clúster.
Antes de comenzar conviene verificar:
- capacidad de los enlaces entre nodos;
- separación lógica o física del tráfico cuando corresponda;
- latencia sostenida;
- errores, drops y retransmisiones;
- utilización existente durante horas de producción.
En una migración, la velocidad máxima posible no siempre es el objetivo. Una transferencia controlada que mantenga estable la producción suele ser preferible a saturar la infraestructura para terminar unos minutos antes.
3. Crea y valida el almacenamiento Ceph en Proxmox
Con el clúster Ceph saludable, el siguiente paso es exponer correctamente el pool de RBD a Proxmox VE.
Antes de incorporar cargas productivas, valida con una VM de prueba:
- creación de discos;
- snapshots cuando correspondan;
- escritura sostenida;
- lectura;
- eliminación de volúmenes;
- migración entre nodos;
- comportamiento durante reinicios controlados.
Ceph RBD es almacenamiento de bloques y Proxmox lo trata como almacenamiento compartido, lo que lo convierte en una base adecuada para entornos donde se busca movilidad de las VMs y alta disponibilidad.
Si necesitas una explicación previa sobre esta arquitectura, puedes consultar nuestro artículo Ceph en Proxmox VE: qué es y cómo funciona.
4. Migra primero una VM de bajo riesgo
No empieces por el controlador de dominio, ERP, base de datos principal o sistema más crítico.
El primer candidato debería ser una VM:
- representativa del entorno;
- con un tamaño razonable;
- con actividad real;
- pero con impacto operativo limitado si hubiera que regresar al almacenamiento anterior.
En Proxmox, la operación de movimiento del almacenamiento permite trasladar el disco hacia otro backend. En los escenarios compatibles esto puede realizarse manteniendo la VM activa, lo que reduce considerablemente la necesidad de ventanas de mantenimiento.
Durante la transferencia hay que vigilar simultáneamente:
- IOPS;
- latencia;
- utilización de red;
- carga de los nodos;
- estado de Ceph;
- comportamiento de la aplicación dentro de la VM.
No evalúes la migración únicamente porque la tarea llegue al 100 %. Lo importante es que la aplicación siga respondiendo dentro de parámetros aceptables mientras ocurre.
5. Migra por lotes, no todo el clúster a la vez
Después de validar la primera carga, la migración debe escalarse progresivamente.
Una secuencia razonable puede ser:
- VMs de baja criticidad.
- Servicios internos no críticos.
- Servidores de aplicaciones.
- Infraestructura intermedia.
- Bases de datos y servicios críticos al final.
El volumen de operaciones simultáneas debe definirse según la capacidad real del almacenamiento y de la red, no según cuántas tareas permita iniciar la interfaz.
Proxmox hace una recomendación similar al importar múltiples VMs: incrementar indiscriminadamente el paralelismo puede saturar conexiones, memoria y almacenamiento; por ello aconseja serializar las operaciones tanto como sea razonable.
6. No confundas migración de almacenamiento con alta disponibilidad
Tener los discos en Ceph es una parte fundamental de una arquitectura de alta disponibilidad, pero no significa que HA ya esté correctamente implementado.
Para que una VM pueda recuperarse en otro nodo deben estar disponibles también los recursos necesarios para ejecutarla: red, CPU compatible, configuración del clúster y cualquier dispositivo especial utilizado por el guest.
Proxmox señala que para HA los discos de las VMs deben estar disponibles en los nodos de recuperación, normalmente mediante almacenamiento compartido.
Después de migrar el almacenamiento conviene validar también:
- live migration entre nodos;
- comportamiento ante mantenimiento de un nodo;
- grupos y políticas de HA;
- conectividad de las VLAN;
- recursos mapeados;
- capacidad restante del clúster.
7. Define un rollback antes de comenzar
Una migración no está bien diseñada si el plan de regreso se piensa después de que aparece un problema.
Antes de mover una carga crítica hay que definir:
- backup verificado;
- punto de recuperación aceptable;
- almacenamiento anterior que se conservará temporalmente;
- criterios que obligarían a abortar la migración;
- procedimiento para devolver el servicio al estado previo;
- responsables de aprobar el cambio.
Proxmox integra mecanismos de backup y Proxmox Backup Server, incluyendo posibilidades como live restore para reducir el tiempo necesario para volver a poner una VM en servicio durante determinadas recuperaciones.
La eliminación de los datos originales debe realizarse solo cuando la nueva plataforma haya sido validada durante el período definido por el proyecto.
8. Valida después de cada migración
Una VM que arranca no necesariamente está correctamente migrada.
Después de moverla a Ceph revisa:
- sistema operativo;
- servicios;
- logs;
- aplicaciones;
- latencia del almacenamiento;
- backups;
- snapshots;
- monitoreo;
- comunicaciones con otras VMs;
- tareas programadas;
- rendimiento durante carga real.
Para servicios críticos también conviene establecer una línea base antes de la migración y compararla después. Así puede determinarse si la nueva plataforma está realmente funcionando mejor, igual o peor que el almacenamiento anterior.
Errores frecuentes al migrar almacenamiento a Ceph
Entre los problemas más habituales se encuentran:
Migrar mientras Ceph está recuperando datos.
Añadir una transferencia masiva mientras el clúster está realizando recovery o rebalance puede deteriorar innecesariamente el rendimiento.
Subestimar la red.
Ceph puede disponer de discos rápidos y aun así ofrecer resultados deficientes si el tráfico entre nodos está limitado por la red.
Mover demasiadas VMs simultáneamente.
La migración deja de ser transparente cuando compite agresivamente con las cargas productivas.
Eliminar inmediatamente el almacenamiento de origen.
Mantener temporalmente una vía de retorno reduce el riesgo durante las primeras horas o días de operación.
Prometer cero downtime sin analizar la arquitectura.
Hay escenarios donde es técnicamente viable y otros donde debe planificarse una interrupción breve. El objetivo profesional es determinarlo antes de comenzar.
Ceph permite migrar sin detener el negocio, pero la arquitectura importa
La combinación de Proxmox VE y Ceph permite construir una infraestructura donde el almacenamiento deja de depender de un único servidor y las máquinas virtuales pueden desplazarse entre nodos con mucha mayor flexibilidad.
En un entorno correctamente diseñado, parte de la migración puede realizarse manteniendo activas las cargas y, una vez que las VMs están sobre almacenamiento compartido, Proxmox puede aprovechar las capacidades de live migration del clúster.
Pero la diferencia entre una migración transparente y una interrupción inesperada está en la planificación: salud de Ceph, capacidad de red, estrategia por lotes, backups, validaciones y rollback.
En QbaNet diseñamos e implementamos entornos Proxmox y Ceph, incluyendo evaluación de infraestructura, arquitectura de almacenamiento, migración de cargas y validación operativa. Si estás evaluando pasar tu almacenamiento actual a una arquitectura distribuida, puedes conocer nuestros servicios de virtualización y Proxmox
