Proxmox HA y almacenamiento: migrar el hipervisor no mueve el RTO ni un minuto, mover el disco sí

Viernes, tres de la tarde. El servidor se apaga y con él se van la facturación, el correo y la telefonía. Los discos de las VM vivían dentro del equipo y el backup nocturno se guardaba en ese mismo disco, así que no hay a dónde migrar ni nada que copiar. Se restaura desde cero o no se restaura.

Luis Aguilar abrió con esa escena su masterclass sobre almacenamiento y continuidad en Proxmox, y no la planteó como advertencia sino como el patrón más repetido en las caídas caras. La causa rara vez está en el hardware o en el hipervisor: está en una decisión de arquitectura que nadie tomó de forma consciente, heredada probablemente de quien estuvo antes. La bendita rotación de personal...

Sus palabras, con veinte años de telecom detrás: "Las caídas que más caro salieron no fueron por el enlace ni por el equipo: fueron por un disco que estaba en el sitio equivocado."

Antes de tocar una sola configuración, propone un ejercicio de papel y lápiz. Clientes o servicios afectados, por lo que factura ese servicio a la hora, por las horas que duró tu última caída. Ese número ya lo estás pagando, a plazos y sin factura.

Los dos números que ordenan la conversación

Cualquier discusión sobre continuidad se resuelve con dos cifras. El RPO (Recovery Point Objective) es cuánto dato puedes perder: si el backup corre cada 24 horas, tu RPO son 24 horas, porque todo lo que pasó desde el último se pierde. Lo fija tu calendario de backup. El RTO (Recovery Time Objective) es cuánto tiempo puedes estar caído, y lo fija tu arquitectura.

Aguilar señala un desequilibrio que se repite en las propuestas comerciales: "Casi todo el mundo negocia el RPO con el cliente y nunca menciona el RTO. El RTO es el que aparece en la llamada de las tres de la tarde."

La distancia entre un RTO de ocho horas y uno de dos minutos no se compra con hardware más caro. Depende de dónde vive el disco de la máquina virtual.

Escenario 1: todo dentro del mismo equipo

El punto de partida de la mayoría de los racks. Un nodo Proxmox, los discos de las VM en almacenamiento local y, con suerte, un backup nocturno en otro equipo.

El backup protege el dato: un borrado accidental o un fallo de disco se resuelven restaurando. Lo que no protege es el servicio, porque restaurar a otro equipo lleva entre cuatro y ocho horas y solo funciona si hay un equipo donde restaurar. Existe además una versión peor de este dibujo, más común de lo que parece, en la que el backup se guarda en el mismo disco donde viven las VM. Ahí un fallo de disco se lleva el original y la copia el mismo día. Y también se llevará al responsable de tecnología.

La regla 3-2-1 existe exactamente para ese caso: tres copias, en dos soportes distintos, una fuera de la ubicación. El "1 afuera" es la parte que casi nadie tiene. Un storage en el mismo rack que el cluster es una copia más, y el incendio no distingue equipos.

Proxmox Backup Server (PBS) cubre esa brecha sin coste de licencia. Apareció en 2020, está escrito en Rust y hace deduplicación a nivel de bloque con una compresión efectiva de entre 10 y 50 veces. No pide fulls periódicos, verifica la integridad de cada snapshot de forma programada, y un PBS puede sincronizar contra otro en una sede distinta, que es lo que cierra el "1 afuera" de verdad.

Conviene tener clara la división de roles, porque es la confusión más frecuente: el storage guarda el dato vivo, el PBS guarda las copias. Son dos equipos con dos trabajos distintos, y Proxmox ve al PBS como un storage que únicamente acepta backups.

Una frase de la sesión que resume el bloque: "Un backup que no restauraste es una hipótesis." La restauración de prueba con fecha en el calendario no es un extra, es parte del diseño. Si no está agendada, no existe.

Escenario 2: el disco sale del nodo

Lo que la máquina virtual ve como su disco duro es, del otro lado del cable, un archivo sobre una carpeta compartida por NFS o un volumen sobre un disco crudo servido por iSCSI. Mover ese archivo al storage externo cambia por completo lo que ocurre cuando el nodo falla.

En el nodo se queda lo que se ejecuta: la CPU, la RAM, el estado de la memoria en ese segundo y las conexiones de red de la VM. Todo eso desaparece con el apagón. En el storage se queda lo que se guarda: el sistema operativo de la VM, sus datos hasta el último segundo antes de la caída, y lo que quepa en el mismo equipo, como ISOs y plantillas. Nada de eso depende del nodo que se apagó.

Por eso arrancar la VM en otro servidor deja de ser una restauración y pasa a ser un arranque. Lo que no cambia todavía es que ese otro servidor lo conectas tú, a mano, cuando llegues.

NAS, SAN y por qué hoy decimos storage

Vale la pena ordenar el vocabulario antes de comparar protocolos, porque las dos palabras se usan como si fueran marcas de equipo. NAS es acceso por archivo: el equipo entrega una carpeta compartida, tiene el sistema de archivos y sabe qué hay dentro. Es lo que hace NFS y SMB/CIFS. SAN es acceso por bloque: el equipo entrega un disco crudo por la red y el sistema de archivos lo pone quien lo monta. Es lo que hacen iSCSI y NVMe-TCP.

La mayoría de los equipos actuales hacen las dos cosas desde el mismo hardware. El TrueNAS del laboratorio sirve el share NFS y el disco iSCSI a la vez, así que la etiqueta importa poco: lo que importa es que el disco de la VM salió del servidor y que el equipo que lo guarda es uno solo.

NFS o iSCSI

NFS entrega una carpeta y Proxmox monta un directorio donde cada VM es un archivo. Como el equipo entiende lo que hay dentro, en el mismo share caben ISOs, plantillas y backups, y los snapshots salen sin configurar nada. Se monta en diez minutos y la migración en vivo viene incluida.

iSCSI entrega un disco crudo que Proxmox formatea con LVM y reparte en un volumen lógico por VM. Hay menos capas entre la VM y el disco, pero solo sirve para discos de VM y los snapshots dependen de Proxmox. Durante años, en cluster con iSCSI directamente no había snapshots; PVE 9 estrena una preview que los encadena sobre el disco iSCSI, con penalización de rendimiento y sin poder migrar una VM que los tenga.

La regla práctica de Aguilar, que él mismo presenta como criterio propio y no como dato de fuente: empieza por NFS y pasa a iSCSI cuando una VM concreta te lo pida por rendimiento demostrado. Aun entonces, deja los backups y las ISOs en NFS.

Hay un detalle de permisos que cuesta tardes enteras. TrueNAS aplica root squash por defecto: las escrituras que llegan como root se degradan a nobody. Proxmox crea los discos de las VM como root, así que el share monta bien, aparece en la interfaz y falla al crear la primera VM. La corrección son dos campos del share: Maproot User = root y Maproot Group = wheel. El síntoma aparece del lado de Proxmox aunque la causa esté en el otro extremo del cable.

Cuando el storage se convierte en el nuevo punto único

Sacar el disco del nodo elimina el punto único del nodo y crea uno nuevo. Si cae el storage, caen todas las VM de todos los servidores que lo usen a la vez: un disco adentro tumbaba un servidor, un storage afuera tumba el rack.

"Mover el punto único no es quitarlo. En este escenario se llama storage", resume Aguilar, "y en el siguiente vamos a ver que también puede llamarse quórum, o router de borde."

Con un solo servidor, el escenario 2 es el 1 con un cable más largo. La pieza que falta no es más storage, es el segundo nodo.

Cómo saber en cinco minutos dónde estás

Antes de planificar nada conviene medir el punto de partida, y son cuatro comandos desde cualquier nodo.

El primero dice si tienes un cluster funcional:

pvecm status

Las líneas que importan son Expected votes, Total votes y Quorate. Si expected dice 2, ahí tienes trabajo. pvecm nodes lista los miembros y corosync-quorumtool -ls detalla quién vota y cuánto pesa cada voto.

El segundo dice si tus discos pueden sobrevivir al nodo:

pvesm status

La columna que decide todo es Shared. Un storage con Shared = Yes es uno que los otros nodos también ven, y por tanto uno desde el que se puede arrancar una VM en otro equipo. local y local-lvm no la tienen: solo existen en un nodo. Para descubrir lo que ofrece un equipo de storage sin salir de Proxmox:

pvesm scan nfs 10.10.11.4
pvesm scan iscsi 10.10.11.4

El tercero confirma que la VM concreta está donde crees:

qm config 100

La línea del disco tiene que apuntar al storage compartido, no a local-lvm. Es el chequeo que más veces desmonta una suposición.

Y el cuarto, si ya hay cluster, comprueba que los latidos tienen más de un camino:

corosync-cfgtool -n

Los dos links deberían aparecer como enabled y connected.

Escenario 3: cluster, quórum y alta disponibilidad

Tres nodos con storage compartido es donde la resiliencia empieza a ser real, y la pieza que lo habilita lleva disponible desde 2012 en el paquete base: la alta disponibilidad sobre Corosync, que llegó con la versión 2.0.

"La alta disponibilidad está en el paquete base desde 2012. Lo que te falta para tenerla no es licencia. Es diseño."

Según Proxmox, hoy hay más de 1,6 millones de hosts desplegados en 142 países, con la empresa todavía independiente y sin inversores externos. La HA nunca fue una función premium.

Tres configuraciones que no son lo mismo

Conviene separarlas, porque en la conversación se mezclan. La replicación ZFS mantiene una copia de la VM en otro nodo sobre disco local; no necesita storage compartido, pero la copia siempre va atrasada y el RPO se configura desde 15 minutos. La migración en vivo mueve la VM entre nodos con su memoria y sus conexiones, sin apagarla, y la decides tú - es una migración manual -. El failover automático no lo decides tú: un nodo falla y el cluster arranca la VM en otro.

Las dos últimas exigen lo mismo, que el disco esté en un storage con Shared = Yes. Sirven NFS, iSCSI con LVM shared thick y Ceph. No sirven el disco local, local-lvm ni LVM-thin, que hace snapshots pero deja de ser compartido.

Por qué dos nodos no son un cluster

Corosync no mueve datos, mueve latidos y votos. Le importa la latencia y no el ancho de banda, por lo que conviene que comparta cable con el storage lo menos posible y que tenga un segundo camino como suplente.

El cluster decide por mayoría, y ahí está la regla que más se ignora. Con dos nodos, uno caído deja al otro en minoría: el superviviente entra en solo lectura y no arranca nada, ni siquiera lo que sobrevivió al apagón, aunque el storage esté perfectamente accesible. La salida es un tercer nodo, aunque sea pequeño, o un QDevice (sobre cualquier Linux) que aporte un voto externo desde un equipo modesto sin ser parte del cluster.

El daño peor no es quedarse quieto. Es que dos nodos que dejaron de verse se crean dueños del mismo volumen y escriban a la vez. Eso no se restaura, y es lo que evita el fencing: el nodo que pierde quórum se reinicia solo.

El comando pvecm expected 1 fuerza el quórum a mano. Sirve para levantar un cluster caído cuando solo queda un nodo vivo, y sirve también para corromperlo si el otro sigue en pie. Es un bisturí.

Poner una VM bajo HA y romperla a propósito

Con el cluster quorate y el disco en storage compartido, declarar una VM como gestionada es un solo comando desde cualquier nodo:

ha-manager add vm:100 --state started

No hace falta repetirlo en los demás. La configuración de HA vive en /etc/pve, que es un sistema de archivos replicado entre los miembros del cluster, así que lo que declaras en uno lo ven los otros al instante. Los dos comandos que siguen solo leen:

ha-manager status
ha-manager config

Las reglas de afinidad son opcionales. Sin ninguna, el recurso puede correr en cualquier nodo y el manager elige entre los que quedan vivos, que es justo lo que se quiere en una prueba. En PVE 9 se llaman HA Rules, no HA Groups, y una regla mal puesta puede dejar la VM sin nodo elegible.

Cuando el nodo pierde la corriente, la secuencia es esta: su watchdog detecta que se quedó sin quórum y lo apaga solo, y solo entonces el HA Manager de otro nodo arranca la VM. Esos son los dos tiempos que hay que cronometrar por separado. La salida de ha-manager status después del corte lo cuenta todo: quorum OK con dos nodos vivos, un master activo en el nodo que tomó el CRM, fencing armed, el LRM del caído marcado con timestamp viejo, y el servicio started bajo otro nodo.

Para mantenimiento planificado no interviene HA. Se migra a mano y sin ventana:

qm migrate 100 pve2 --online
qm migrate 100 pve2 --online --bwlimit 100000

Si la migración se cae a medias y la VM queda bloqueada, qm unlock 100 es el que la libera.

Un detalle sobre el regreso: cuando el nodo caído vuelve a encender, se reincorpora al cluster y suma su voto, pero la VM se queda donde el manager la arrancó. No hay retorno automático salvo que exista una regla de afinidad con preferencia de nodo, y para una demo eso estorba más que ayuda.

Los números medidos en el laboratorio

El entorno de la sesión eran tres nodos con PVE 9.2.2 y un TrueNAS 25.10.4 sirviendo NFS e iSCSI, con cuatro redes separadas: management, Corosync, storage y una reservada para Ceph que todavía está vacía. Aguilar declaró en voz alta que los tres nodos corren anidados sobre un mismo baremetal, algo que sirve para enseñar y no para producción.

El failover del laboratorio tardó unos tres minutos, por encima del rango de referencia. El anidamiento y el temporizador propio del watchdog explican la diferencia, y el número honesto es mejor argumento que el optimista: el que vale para tu propuesta es el que midas en tu entorno.

Lo que falló montando el laboratorio

Siete cosas fallaron durante el montaje. Estas son las que más se repiten fuera de él.

Proxmox no puede crear VM sobre el NFS aunque el share está montado. La causa es el root squash de TrueNAS y la corrección son los dos campos de Maproot. Es el error número uno de cualquier laboratorio Proxmox y se pierden tardes leyendo logs del lado equivocado.

iscsiadm devuelve "No portals found" con el portal respondiendo en el 3260. El wizard de TrueNAS había puesto la red en el campo Initiators, que espera un IQN. Se vacía ese campo y se deja que la autorización la haga la segmentación de red.

500 Can't connect to 10.10.10.1:8006 (hostname verification failed) al unir un nodo. El certificado está emitido para el hostname, no para la IP. Se resuelve usando pvecm add con hostname y /etc/hosts poblado en los tres nodos.

Los storages LVM sobre iSCSI aparecen con un signo de interrogación en dos de tres nodos. pvcreate y vgcreate corrieron solo en el nodo desde el que se agregó el storage; los otros ven el disco pero no el volumen activo. Se arregla nodo por nodo:

pvscan --cache
vgscan --cache
vgchange -ay vg-iscsi

Proxmox no lo hace solo a propósito: activar un storage compartido sin querer es una vía directa a corromper datos.

El borde, que en la nube entra al esquema

En un despliegue local, el router y el firewall son equipos físicos fuera de la plataforma de virtualización, y la alta disponibilidad se ocupa solo de las máquinas virtuales. En la nube no hay acceso al hardware de red del proveedor, la IP pública llega al nodo y el router-firewall se muda hacia adentro como una VM más.

Con eso hereda el problema de continuidad de cualquier VM, y uno peor: en él viven la IP pública, las reglas de NAT y el destino al que apunta el registro DNS. Si cae su nodo, la VM de la aplicación revive en otro y sigue sin poder alcanzarse desde fuera.

La solución es VRRP, siempre que el router que uses lo soporte: una instancia en cada nodo con el mismo VRID, una sola IP pública virtual y una MAC virtual compartida. La prioridad decide quién es master y los demás esperan; cuando el master cae, otro toma la IP y el DNS no se entera. VRRPv2 está en la RFC 3768 y VRRPv3 en la RFC 5798, sobre el protocolo IP 112 y multicast a 224.0.0.18.

Ceph resuelve el disco y VRRP resuelve el borde. Un cluster con HA y sin redundancia en el router tiene el punto único movido de sitio, no eliminado.

HA no es backup

Un cluster de tres nodos con storage compartido y HA activo aguanta la caída de hardware. No aguanta un ransomware.

"Un ransomware infecta los tres nodos a la vez, porque para el cluster es una escritura legítima. La replicación hace su trabajo perfectamente y por eso te destruye."

HA protege de que falle un servidor o un disco. El backup protege del ransomware, del borrado de las cinco de la tarde, de la corrupción lógica que nadie nota en tres días y del incendio. Son dos problemas distintos y ninguna de las dos piezas sustituye a la otra.

La arquitectura completa tiene tres componentes que responden a tres preguntas diferentes: el cluster HA responde a la caída de un nodo, el storage externo la hace posible, y el PBS remoto en otra sede cubre todo lo que el cluster no puede cubrir.

Puesto en términos de fallas concretas: si cae un nodo, el cluster arranca la VM en otro en segundos. Si hay ransomware o borrado, se restaura desde el PBS de la otra sede. Si cae la sede entera, se levanta en otro sitio con lo de anoche. Si cae la VPN, la aplicación ni se entera y lo que se atrasa es la copia de esa noche. Si cae el storage externo, se para todo: es la fila que este escenario deja sin resolver.

Ceph, cuando el storage pasa a ser el eslabón débil

Ceph elimina ese punto único repartiendo los discos entre los propios nodos. Cada disco de cada nodo levanta su propio OSD, el cliente calcula dónde está el dato con el mapa CRUSH en vez de preguntarle a un servidor central, y tres monitores bastan para repartir ese mapa en un cluster de cualquier tamaño. El ACK de escritura vuelve cuando las tres copias están confirmadas, y ninguna de las tres vive en el mismo nodo que otra. Eso sustituye al RAID y al storage externo a la vez.

El requisito de entrada son tres nodos y un disco extra - como mínimo - en cada uno además del que corre Proxmox, más una red propia. El costo real está en otra parte: unos 4 GiB de RAM por OSD activo, lo que en producción sitúa a los nodos entre 32 y 64 GiB, y un salto claro en complejidad operativa.

"Ceph resuelve el SPOF (único punto de falla) e introduce complejidad operativa importante", lo dice Aguilar sin adornarlo. Es el escalón siguiente, no la solución inmediata para todo el mundo. Lo sabrás cuando llegues ahí.

Tres preguntas para llevarse

¿Dónde vive el disco de tus VM? Con nombre de storage, no "en el servidor". Si la respuesta es el nodo, tu RTO se mide en horas y no lo cambia el hipervisor.

¿Cuánto duró tu última caída? Medida, no recordada. Ese número por tu facturación horaria es lo que ya estás pagando.

¿Cuándo restauraste un backup por última vez? Con fecha, restaurado de verdad hasta ver el servicio levantar, no solo verificado.

El servidor va a fallar un viernes a las tres, y eso no lo decides tú. Lo que decides hoy es si eso genera una llamada o no genera nada. Cambiar de hipervisor no mueve tu RTO ni un minuto; mover el disco fuera del nodo lo mueve de horas a segundos, con la misma factura de hardware.

La grabación completa de la masterclass está disponible en el canal de YouTube de Ekoinos.