Un clúster de dos servidores es la arquitectura que más se pide en empresas pequeñas y medianas: cabe en el presupuesto, cabe en medio armario y, sobre el papel, aguanta la caída de un servidor. La pregunta es qué se hace con el almacenamiento. Una cabina compartida duplica el coste y se convierte en un punto único de fallo. Ceph necesita tres nodos como mínimo para ir con holgura. Lo que queda es lo que ya tienen los dos servidores: sus discos.
Proxmox VE resuelve ese caso con la replicación de almacenamiento, una función que lleva años en el producto y que en la versión 9.2 ha ganado detalles importantes. Este artículo cuenta cómo montarla de principio a fin y, sobre todo, qué esperar de ella. Todo lo que sigue está comprobado contra la documentación de Proxmox VE 9.2 (la última versión, sobre Debian 13, kernel 7.0 y ZFS 2.4).
La herramienta se llama pvesr y la documentación la define sin adornos: replica los volúmenes de una máquina a otro nodo para que los datos estén disponibles sin almacenamiento compartido. Funciona así:
zfs send incremental, normalmente unos pocos megas o gigas por ciclo.El intervalo va de un minuto a una semana, con el formato de eventos de calendario de systemd, y el valor por defecto es cada 15 minutos. Una máquina puede replicarse a varios nodos, pero no dos veces al mismo. Y cada trabajo admite un límite de ancho de banda para no ahogar la red ni los discos.
La tabla de almacenamientos compatibles de la documentación tiene una sola fila: ZFS local (zfspool). Nada de LVM-thin, directorios ni qcow2. La hoja de ruta de Proxmox recoge la intención de extender la replicación más allá de ZFS apoyándose en las nuevas cadenas de instantáneas, pero hoy no existe.
Lo que la replicación no hace es convertir dos discos locales en uno compartido. En cada momento solo hay un nodo que escribe. El otro tiene una copia que se va quedando atrás hasta el siguiente ciclo, y esa distancia es exactamente lo que pierdes si el nodo activo cae.
Para que todo esto funcione hacen falta cuatro piezas:
| Pieza | Para qué sirve | Si falta |
|---|---|---|
| Clúster de dos nodos | Configuración compartida, migración, HA | No hay replicación: es una función de clúster |
| Pool ZFS con el mismo nombre en los dos nodos | Origen y destino de las réplicas | El trabajo falla: el destino no encuentra el almacenamiento |
| QDevice externo | El tercer voto del quorum | El nodo superviviente se queda en minoría y no arranca nada |
| Capacidad sobrante | Que un nodo pueda con las máquinas de los dos | Las máquinas arrancan, pero no caben o van a rastras |
La última fila se olvida con frecuencia. Si cada servidor va al 70 % de memoria, cuando uno cae el otro no puede absorber su carga. Con dos nodos, la regla práctica es que cada uno pueda cargar con todo lo que quieras recuperar. Hay que contar también la caché de ZFS: en instalaciones desde Proxmox VE 8.1, el ARC se limita por defecto al 10 % de la memoria, con un máximo de 16 GiB.
En producción, el pool debería ser al menos un espejo (RAID1) de dos discos por nodo. Un pool de un solo disco funciona para probar, pero convierte una avería de disco en una caída del nodo entera, con su pérdida de datos incluida. La replicación protege contra perder un servidor, no sustituye a la redundancia de discos.
Desde la interfaz web, en el primer nodo:
zfs-vm), nivel de RAID, compresión (deja la que trae, on) y los discos.En el segundo nodo se repite con exactamente el mismo nombre, pero esta vez desmarcando Add Storage. El pool se crea, pero no aparece en el árbol del nodo todavía. Falta decirle al almacenamiento del clúster que también existe ahí: Datacenter → Storage, editar zfs-vm y añadir el segundo nodo en el campo Nodes.
Desde la consola, el equivalente es este. Usa siempre rutas /dev/disk/by-id/ en lugar de /dev/sdX, que pueden cambiar entre arranques:
# En cada nodo: crear el pool en espejo
zpool create -o ashift=12 zfs-vm mirror \
/dev/disk/by-id/nvme-DISCO_A /dev/disk/by-id/nvme-DISCO_B
zfs set compression=on zfs-vm
# Una sola vez, en cualquier nodo: dar de alta el almacenamiento en los dos
pvesm add zfspool zfs-vm --pool zfs-vm --content images,rootdir \
--nodes pve1,pve2 --sparse 1Comprueba que los dos nodos ven lo mismo con zpool list en cada uno y pvesm status en cualquiera.
Este es el paso que más guías se saltan, y el que decide si la alta disponibilidad funcionará el día que haga falta.
Proxmox usa Corosync y un sistema de votos: cada nodo aporta uno y el clúster necesita mayoría para cambiar algo. Con dos nodos, la mayoría son dos votos. Cuando uno desaparece de golpe, el otro tiene uno de dos, que no es mayoría. El clúster pasa a solo lectura y el gestor de HA no puede robar la máquina del nodo caído. Explicamos la aritmética completa en por qué casi todos los clústeres de Proxmox tienen tres nodos.
¿Por qué hay guías en las que la prueba de fallo sale bien sin QDevice? Porque apagar un nodo con orden no es lo mismo que cortarle la corriente, y porque en un laboratorio es fácil haber tocado el quorum a mano sin acordarse. En producción, un clúster de dos nodos sin tercer voto no tiene alta disponibilidad.
La solución que documenta Proxmox para clústeres pares es el QDevice: un demonio, corosync-qnetd, que corre en una máquina fuera del clúster y aporta el voto de desempate. Puede ser un equipo pequeño, una máquina virtual en otra infraestructura o el servidor de copias si está separado del clúster. Lo importante es que no comparta destino con ninguno de los dos nodos: si el QDevice es una VM dentro del propio clúster, cae con él.
# En la máquina externa (Debian o similar)
apt install corosync-qnetd
# En los dos nodos Proxmox
apt install corosync-qdevice
# En uno de los nodos, con los dos en línea
pvecm qdevice setup 192.0.2.50La configuración copia la clave SSH del clúster al QDevice, así que durante el proceso hace falta acceso de root a esa máquina. Al terminar, pvecm status debe mostrar tres votos esperados y la marca Qdevice entre los indicadores.
La documentación añade un aviso que conviene conocer: el QDevice se recomienda solo para clústeres con número par de nodos. Si algún día pasas a tres, retíralo.
Hasta Proxmox VE 8, la replicación viajaba por la red de migración y, si no había, por la de gestión. Desde la 9.0 puede tener su propia red, en Datacenter → Options → Replication Settings o en /etc/pve/datacenter.cfg:
replication: secure,network=10.10.20.0/24secure es el valor por defecto: el tráfico va cifrado por un túnel SSH. Existe insecure, que lo envía sin cifrar y es más rápido, pero solo tiene sentido en un enlace directo entre los dos servidores o en una red totalmente privada.
Con dos nodos, lo más limpio es un cable directo entre ellos para replicación y migración, y que Corosync tenga además dos enlaces independientes. Corosync es muy sensible a la latencia: si comparte cable con una réplica de 200 GB, el clúster puede ver nodos caídos que no lo están.
La máquina virtual o el contenedor deben tener sus discos en el almacenamiento zfs-vm. Si un disco vive en otro almacenamiento que no admite replicación, el trabajo fallará; para excluirlo a propósito, se desactiva la replicación en las opciones avanzadas de ese disco (replicate=0 en la configuración).
El trabajo se crea en Datacenter → Replication → Add (o en la pestaña Replication de la propia máquina) con tres datos: la máquina, el nodo de destino y la programación. Desde la consola:
# VM 100 hacia pve2, cada 5 minutos, con un máximo de 60 MB/s
pvesr create-local-job 100-0 pve2 --schedule "*/5" --rate 60
pvesr list # trabajos definidos
pvesr status # estado, última y próxima ejecución
pvesr schedule-now 100-0 # lanzarlo ya, sin esperar al siguiente cicloCinco detalles que conviene saber:
100-0, 100-1…). Desde la interfaz se asigna solo.zfs-vm no se replica sola. Conviene revisar pvesr list cada vez que se crea algo.VM.Replicate sobre la máquina. Antes bastaba con Datastore.Allocate, así que los roles personalizados pueden necesitar un ajuste tras actualizar.Si algo falla, el trabajo entra en estado de error, se suspende su programación y Proxmox lo reintenta: primero varias veces en poco tiempo y después cada 30 minutos, hasta que vuelve a funcionar. Las causas habituales son tres: red caída, pool lleno en el destino (las instantáneas de replicación también ocupan) o un almacenamiento con el mismo nombre que no existe en el otro nodo. El registro del trabajo dice cuál es.
Sin alta disponibilidad, la réplica es una copia pasiva: si cae el nodo, los discos están en el otro, pero nadie arranca la máquina. Para que lo haga Proxmox hay que darla de alta en el gestor de HA:
ha-manager add vm:100 --state startedAquí está el cambio de Proxmox VE 9 que deja obsoletas muchas guías. Antes se creaba un grupo de HA con los nodos preferidos y la casilla nofailback. Desde la 9.0, los grupos están obsoletos y se migran solos a reglas de afinidad de nodo. La preferencia se expresa con prioridades:
# VM 100 prefiere pve1; si no está, pve2
ha-manager rules add node-affinity vm100-en-pve1 \
--resources vm:100 --nodes "pve1:2,pve2:1"El failback, que antes era una opción del grupo, es ahora una propiedad de cada recurso y viene activada por defecto. Significa que, cuando vuelve el nodo con más prioridad, la máquina migra de vuelta sola. A veces no es lo que quieres: si el nodo volvió tras una avería, puede que prefieras revisarlo antes de devolverle carga. En ese caso:
ha-manager set vm:100 --failback 0Sin ninguna regla de afinidad, la máquina puede arrancar en cualquier nodo y no hay un «nodo de origen» al que volver. Una regla estricta (--strict 1) limitaría la máquina a los nodos de la lista y la dejaría parada si ninguno está disponible, que con dos nodos casi nunca es lo que se busca.
La secuencia real, con las cifras de la documentación:
La frase de la documentación es clara: la alta disponibilidad se permite junto con la replicación, pero puede haber pérdida de datos entre la última sincronización y el momento del fallo. Lo que pve1 escribió en ese intervalo no se recupera al volver; la copia que manda es la de pve2.
Para una web, un servidor de ficheros o una aplicación interna, perder los últimos minutos suele ser aceptable. Para una base de datos de pedidos o de facturación puede no serlo, y entonces hay que cambiar de arquitectura (abajo) o asumir que la base de datos tendrá su propia replicación a nivel de aplicación. La relación entre lo que se pierde y lo que se tarda en volver está explicada en RTO y RPO.
La replicación tiene una ventaja que se nota a diario y no solo en las averías: acelera las migraciones. Si la máquina ya está replicada en el nodo de destino, al migrarla solo hay que enviar los cambios desde la última réplica, no el disco entero. Y la dirección de la replicación cambia sola: si migras la VM 100 de pve1 a pve2, a partir de ese momento se replica de pve2 a pve1.
Es lo que hace viable vaciar un nodo para actualizarlo en minutos, incluso con discos de cientos de gigas. El procedimiento completo, nodo a nodo, está en actualizar un clúster Proxmox sin parar el servicio.
Hay quien prefiere no automatizar el arranque y decidir en persona. Es legítimo, y la documentación de Proxmox describe el procedimiento cuando un nodo con máquinas replicadas no vuelve:
# En el nodo superviviente
pvecm status # ¿hay quorum?
# Mover la configuración de las máquinas al nodo vivo
mv /etc/pve/nodes/pve1/qemu-server/100.conf /etc/pve/nodes/pve2/qemu-server/
mv /etc/pve/nodes/pve1/lxc/200.conf /etc/pve/nodes/pve2/lxc/
qm start 100
pct start 200Si no hay quorum (dos nodos sin QDevice), /etc/pve está en solo lectura y antes hay que forzarlo con pvecm expected 1. La documentación lo reserva para emergencias y pide no hacer ningún otro cambio en el clúster mientras esté así: ni añadir nodos, ni almacenamientos, ni máquinas. Solo arrancar lo vital y arreglar el quorum.
Tres límites que conviene tener escritos antes de vender la arquitectura a nadie:
| Replicación ZFS | Ceph | Cabina compartida | |
|---|---|---|---|
| Nodos mínimos | 2 + QDevice | 3 (mejor 4 o más) | 2 + QDevice |
| Datos perdidos si cae un nodo | Desde la última réplica (1-15 min) | Ninguno | Ninguno |
| Hardware extra | Ninguno, solo discos locales | Red de 10 Gbps o más dedicada, SSD | La cabina y su red |
| Punto único de fallo | No | No | La cabina, si no está duplicada |
| Complejidad | Baja | Alta | Media |
| Encaja con | Pymes, delegaciones, cargas que toleran minutos | Clústeres medianos y grandes | Quien ya tiene cabina |
La replicación ZFS es la opción más barata y sencilla, y para muchas empresas es la correcta. Lo que no puede es prometer lo que solo da el almacenamiento compartido. Si el clúster crece a tres nodos, Ceph pasa a ser una alternativa real. Y si quieres el panorama completo de la alta disponibilidad en Proxmox, está en nuestra guía de HA en producción.
pvecm status con tres votos esperados.En Cloud Privado montamos y operamos clústeres de Proxmox VE de dos nodos con replicación ZFS para empresas que no necesitan RPO cero y sí un presupuesto contenido, y clústeres con almacenamiento local o Ceph cuando la carga pide más. Si estás dudando entre una arquitectura y otra, cuéntanos qué tiene que seguir en pie y cuántos minutos de datos puedes permitirte perder: con esas dos respuestas la decisión suele quedar bastante clara.
No. La replicación de almacenamiento de Proxmox VE solo admite ZFS local (zfspool). La hoja de ruta contempla extenderla a otros almacenamientos, pero en Proxmox VE 9.2 no está disponible.
Lo escrito desde la última réplica completada. Con el intervalo por defecto, hasta 15 minutos; con el mínimo, hasta un minuto. Si la última réplica había fallado, la distancia es mayor, por eso conviene vigilar el estado de los trabajos.
Para la replicación en sí, no. Para la alta disponibilidad, sí: sin un tercer voto, cuando un nodo cae el otro pierde el quorum y no puede arrancar las máquinas del caído. El QDevice debe estar fuera del clúster.
Sí. La replicación busca en el nodo de destino un almacenamiento con el mismo identificador. Si el pool se llama distinto, el trabajo falla.
Tres cosas: los grupos de HA están obsoletos y se sustituyen por reglas de afinidad de nodo, la replicación puede usar su propia red y gestionar trabajos exige el permiso VM.Replicate.
No. Copia también los borrados y los ficheros cifrados por ransomware, y solo conserva el estado reciente. Hacen falta copias con historial y fuera del clúster.
Sí, igual que las máquinas virtuales, siempre que sus volúmenes estén en un almacenamiento ZFS.
pvesr.create-local-job, unidad del límite de ancho de banda y schedule-now.failback.replication con los modos secure e insecure.VM.Replicate), versión 9.2 y planes para extender la replicación.
Un cliente cuenta que su renovación de VMware subió un 700 %, que pagó porque no podía cambiar de plataforma de un día para otro y que esa misma semana empezó a migrar a Proxmox. Separamos lo que se puede comprobar de lo que no: la encuesta de Rimini Street (y quién la paga), los casos con nombre, las cuentas reales de Broadcom y las tres salidas que tiene hoy un cliente atrapado en una renovación.
Gartner ha vuelto a publicar, diez años después, su Magic Quadrant de plataformas de virtualización de servidores, y por primera vez aparece Proxmox. Lo coloca como Niche Player por dos motivos concretos: no lo ve preparado para las aplicaciones empresariales de primer nivel y duda de que una plantilla pequeña garantice el soporte. El segundo empieza a corregirse el 19 de octubre con el soporte 24/7. El primero, no. Explicamos qué significa la etiqueta, qué mide y qué debería mirar una empresa antes de sacar conclusiones.
Óscar de la Cuesta (palentino.es) ha traducido al castellano la Proxmox VE Administration Guide 9.2. Son 437 páginas con los 21 capítulos y los apéndices, bajo la misma licencia libre que el original, así que se puede copiar y compartir. Contamos qué trae, por dónde empezar a leerla según de dónde vengas, qué conviene saber antes de usarla en el trabajo y dejamos el PDF para descargar.