La replicación ZFS de Proxmox VE 9.2 permite mantener una copia de las máquinas virtuales y los contenedores en un segundo servidor sin recurrir a una cabina de almacenamiento compartido. La función puede ayudar a pequeñas y medianas empresas a recuperar servicios cuando falla un nodo, pero tiene una limitación que conviene conocer antes de diseñar la infraestructura: la copia no está siempre al día y los últimos datos escritos pueden perderse si se produce una caída. Además, para automatizar la recuperación en un clúster de dos nodos hace falta resolver correctamente el quorum con un tercer voto.

Las claves de la replicación ZFS en Proxmox VE 9.2 en 20 segundos

• La replicación utiliza instantáneas de ZFS y transfiere los cambios entre servidores de forma periódica.
• El intervalo predeterminado es de 15 minutos, aunque puede reducirse hasta un minuto.
• Los dos nodos necesitan almacenamiento ZFS local compatible y el mismo identificador de almacenamiento.
• Un QDevice externo aporta el tercer voto necesario para mantener el quorum cuando falla uno de los servidores.
• La replicación no sustituye a las copias de seguridad ni ofrece una recuperación sin pérdida de datos.

La propuesta resulta interesante para empresas que quieren disponer de un segundo servidor preparado para recuperar servicios sin asumir el coste de una infraestructura de almacenamiento compartido. Sin embargo, el resultado depende tanto de la configuración de Proxmox como de la capacidad disponible en el nodo de respaldo, la red y las necesidades de recuperación de cada aplicación.

La documentación de Proxmox VE 9 incorpora cambios en la configuración de la replicación y de la alta disponibilidad que afectan a las guías antiguas. Entre ellos figuran la posibilidad de dedicar una red a la replicación y el uso de reglas de afinidad de nodo en lugar de los grupos de alta disponibilidad que han quedado obsoletos desde la versión 9.0.

Cómo funciona la replicación ZFS entre dos servidores

La herramienta de Proxmox VE encargada de gestionar estos trabajos se llama pvesr. Su funcionamiento se basa en las instantáneas de ZFS, que permiten enviar inicialmente un volumen completo y transmitir después solo los cambios respecto a una instantánea anterior.

En una instalación con dos nodos, uno mantiene activa la máquina virtual y escribe en sus discos locales. El segundo recibe las réplicas y conserva una copia que puede utilizarse para recuperar el servicio si el nodo principal deja de funcionar.

El intervalo predeterminado es de 15 minutos, aunque se puede configurar una programación desde un minuto hasta una semana. Esa frecuencia determina cuánto pueden diferir los datos del servidor activo y los de su réplica. Si el nodo principal falla después de escribir información que todavía no se ha replicado, esos cambios no estarán disponibles en la copia del segundo servidor.

La replicación tampoco convierte los discos locales en almacenamiento compartido. Cada máquina escribe en un único nodo mientras está activa, y el otro mantiene una copia actualizada mediante los trabajos programados.

Otra limitación es la compatibilidad con el almacenamiento. En Proxmox VE 9.2, la replicación integrada admite almacenamiento ZFS local, identificado como zfspool. No funciona de la misma manera con cualquier volumen LVM-thin, directorio o imagen QCOW2, por lo que es necesario comprobar dónde están alojados todos los discos de las máquinas que se quieren proteger.

El tercer voto es imprescindible para la alta disponibilidad

Uno de los aspectos que más condicionan el funcionamiento de un clúster de dos nodos es el quorum. Proxmox utiliza Corosync para coordinar los miembros del clúster y necesita una mayoría de votos para mantener determinadas operaciones.

Con dos nodos que aportan un voto cada uno, la caída repentina de uno deja al otro sin mayoría. Aunque los discos de las máquinas estén replicados en el servidor superviviente, eso no significa que la alta disponibilidad pueda arrancarlas automáticamente.

La solución documentada para este tipo de clúster es un QDevice, un componente que aporta un voto adicional desde una máquina externa. El servicio corosync-qnetd puede ejecutarse en un equipo independiente o en una infraestructura separada, siempre que no dependa de los mismos servidores cuya caída debe ayudar a gestionar.

El QDevice no almacena las máquinas virtuales ni sus datos. Su función es participar en la decisión de quorum. Con dos nodos y ese tercer voto, el clúster puede conservar la mayoría cuando uno de los servidores desaparece.

La configuración requiere instalar corosync-qnetd en el equipo externo y corosync-qdevice en los nodos Proxmox. Después se registra el dispositivo con pvecm qdevice setup y se comprueba el resultado mediante pvecm status.

También es necesario que el servidor superviviente tenga recursos suficientes para ejecutar las cargas del nodo caído. Si ambos equipos trabajan cerca de su capacidad máxima, la replicación no evitará problemas de memoria, CPU o rendimiento durante la recuperación.

Qué cambia en Proxmox VE 9 y qué se pierde durante una caída

La versión 9 introduce ajustes que conviene revisar al configurar la infraestructura. La replicación puede utilizar una red específica, independiente de la gestión y de la migración, y la alta disponibilidad emplea reglas de afinidad de nodo para expresar las preferencias de ubicación de las máquinas.

También cambia la gestión del failback, el retorno de una máquina a su nodo preferido cuando vuelve a estar disponible. Desde Proxmox VE 9, esta opción se configura por recurso y está activada por defecto. Las empresas que prefieran comprobar primero el estado del servidor recuperado pueden desactivarla para evitar un retorno automático.

En una caída, la alta disponibilidad detecta el problema, comprueba las condiciones necesarias para recuperar la máquina y la arranca desde la última réplica disponible. La documentación citada en el material de partida estima un tiempo de recuperación del orden de dos minutos, aunque el resultado real depende de la configuración y de las cargas de trabajo.

El tiempo de recuperación, conocido como RTO (Recovery Time Objective), no debe confundirse con el punto de recuperación, o RPO (Recovery Point Objective). El primero mide cuánto tarda en volver el servicio; el segundo representa la cantidad de datos que puede perderse. Reducir el intervalo de replicación puede limitar esa pérdida, pero no garantiza un RPO cero.

Por eso, las aplicaciones con operaciones que no pueden perderse deben contar con mecanismos adicionales. Una base de datos, por ejemplo, puede necesitar replicación propia o una arquitectura de almacenamiento síncrono, según los requisitos de consistencia y disponibilidad.

La replicación tampoco sustituye a las copias de seguridad. Si un usuario elimina archivos por error o un ataque cifra los datos de una máquina virtual, esos cambios pueden llegar al segundo nodo en el siguiente ciclo. Para recuperar versiones anteriores hacen falta copias con historial, almacenadas fuera del clúster y verificadas mediante pruebas de restauración.

ZFS, Ceph o almacenamiento compartido: qué opción conviene

La replicación ZFS destaca por aprovechar los discos locales de los dos servidores, lo que permite evitar la compra de una cabina externa. Es una alternativa razonable para empresas que aceptan perder los cambios posteriores a la última réplica y pueden tolerar una breve interrupción durante la recuperación.

Ceph ofrece otra aproximación, basada en almacenamiento distribuido, pero requiere una arquitectura más amplia y una planificación cuidadosa de la red y los recursos. Una cabina compartida puede encajar en instalaciones que ya disponen de ella, aunque su diseño debe contemplar la redundancia para evitar que se convierta en un punto único de fallo.

La decisión depende del tipo de servicio que se quiera proteger. Una aplicación interna puede tolerar varios minutos de diferencia entre la copia y el sistema activo. Una plataforma de facturación, una base de datos transaccional o un servicio que no pueda perder operaciones puede necesitar una solución diferente.

Antes de poner en producción un clúster de dos nodos conviene comprobar que los pools ZFS tienen el mismo nombre, que el QDevice está fuera del clúster, que la red de replicación no interfiere con Corosync y que cada máquina importante dispone de un trabajo de replicación. También es recomendable simular una caída real, medir el tiempo de recuperación y comprobar qué datos se pierden.

Preguntas frecuentes

¿Se puede replicar una máquina virtual en Proxmox sin ZFS?

La replicación de almacenamiento integrada en Proxmox VE 9.2 admite ZFS local. Los discos alojados en otros tipos de almacenamiento no pueden utilizar esta función de la misma forma.

¿Cuántos datos se pueden perder si cae un nodo?

Depende del tiempo transcurrido desde la última réplica completada. Con el intervalo predeterminado de 15 minutos, los cambios posteriores pueden perderse; con un intervalo de un minuto, esa ventana se reduce, pero no desaparece.

¿Hace falta un QDevice para replicar dos nodos?

No para ejecutar la replicación ZFS en sí. Sí es necesario resolver el quorum para que un clúster de dos nodos pueda mantener la alta disponibilidad cuando uno falla de forma inesperada.

¿La replicación ZFS sustituye a las copias de seguridad?

No. La replicación transmite también los cambios no deseados, incluidos borrados y archivos cifrados por ransomware. Es necesario mantener copias de seguridad independientes, con historial y fuera del clúster.