Modulos rectangulares verdes conectados con cables negros en cluster

Cluster Proxmox de Alta Disponibilidad para Home Server: HA + Ceph desde cero

octubre 20, 2026 Alfonso Moreno | Sysadmin Senior 4 Visitas 16 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 6-10 horas para cluster HA + Ceph funcional (más tiempo si partes de hardware nuevo).
Requisitos: 3 nodos con VT-x/AMD-Vi, 16 GB RAM mínimo cada uno, 2 SSDs por nodo (sistema + OSD), red de cluster dedicada en 10 GbE ideal.
Resultado: Cluster Proxmox VE 9.0 con HA Manager activo, VMs haciendo failover automático en menos de 60 segundos cuando un nodo cae, almacenamiento hiperconvergente Ceph Squid replicado en 3.
Troubleshooting típico: quorum perdido si caen 2 nodos, latencia alta de Ceph por red de 1 GbE compartida, fencing IPMI no configurado deja VMs en estado crashed en lugar de migradas.

Por qué un cluster HA en casa (y cuándo NO vale la pena)

Un cluster de Proxmox con alta disponibilidad significa que si un nodo se cae — falla de hardware, kernel panic, reboot de mantenimiento — las máquinas virtuales que corrían en él migran automáticamente a otro nodo en menos de un minuto. Para una PyME con producción real eso es obligatorio. Para un home server que ejecuta Plex, Nextcloud y Pi-hole, la pregunta es si vale la inversión de tener tres equipos corriendo 24/7.

Mi respuesta honesta: si tienes menos de 5 servicios críticos y puedes tolerar 30 minutos de downtime para restaurar desde un backup, no vale la pena. Mantente en un solo nodo con buenos backups (cubre el caso real con la guía de backups en Proxmox) y duerme tranquilo. El cluster HA entra en juego cuando cumples al menos dos de estas condiciones:

Tienes servicios que tu familia o tu equipo usan 24/7 y no pueden caerse (Jellyfin, Home Assistant, gateway de IoT).
Administras infraestructura para clientes desde el homelab y una caída te cuesta dinero.
Quieres aprender clustering, Ceph y fencing porque tu próximo trabajo es de infra.
Ya tienes hardware empresarial refurbished en desuso (Dell OptiPlex, HP ProDesk, Lenovo ThinkCentre) y darle tres vidas es divertido.

Lo que sigue es la guía que me hubiera gustado leer cuando armé mi primer cluster de tres nodos en 2024, corregida con todo lo que rompí en el camino.

Hardware mínimo: tres nodos que se hablan entre sí

La regla de oro del cluster HA es paridad de hardware entre nodos. Proxmox admite nodos heterogéneos, pero las VMs que hacen failover a un nodo con menos RAM o menos cores pueden no arrancar en el destino. La matriz que armé con precios observados en Chile, Colombia y México a octubre de 2026:

Componente	Mínimo por nodo	Recomendado	Nota LATAM
CPU	4 cores x86_64 con VT-d / AMD-Vi	6-8 cores, mismo modelo en los 3 nodos	Refurbished Dell OptiPlex 5060/7060 con i5-8500 o i7-8700 andan 200-280 USD cada uno.
RAM	16 GB DDR4	32-64 GB ECC si la board lo soporta	16 GB es funcional pero ajustadas; Ceph consume 1-2 GB por OSD daemon.
SSD sistema	128 GB SATA	256 GB NVMe	Aquí corre solo Proxmox y el sistema operativo. Nada de VMs.
Discos para Ceph (OSD)	1 SSD 500 GB + 1 HDD 1 TB	2-3 SSDs 1 TB SATA	Ceph con HDDs es funcional pero lento para VMs con I/O alto. Mezclar SSD (DB/WAL) + HDD (bulk) es válido en 9.x con BlueStore.
Red administrativa	1 GbE	2.5 GbE o 10 GbE	Esta NIC lleva tráfico de cluster, migración de VMs y Ceph. Subir a 10 GbE es la mejora más rentable del cluster.
Red de gestión (UI)	1 GbE dedicada	1 GbE separada	Necesaria para tener IPMI/iDRAC accesible aunque la red principal caiga.
IPMI / iDRAC	No requerido	Recomendado	Sin IPMI no puedes hacer fencing automático; el HA Manager no podrá reiniciar un nodo colgado de forma remota.

Total realista para un cluster de 3 nodos nuevo: 800-1200 USD comprando refurbished de calidad. Para una caja más ambiciosa con 64 GB de RAM y 10 GbE: 1800-2500 USD. La diferencia entre las dos opciones no es rendimiento bruto sino latencia de Ceph: con 1 GbE compartida, una VM con discos en Ceph ve 80-120 MB/s de lectura; con 10 GbE dedicada al tráfico Ceph, saltas a 400-700 MB/s. En mi cluster de casa pasé de 1 GbE a 2.5 GbE con un switch Mikrotik CRS305-4G+ (250 USD) y la diferencia se notó en cuanto monté la primera VM con Ceph.

Instalación del primer nodo y red privada de cluster

El primer nodo se instala como cualquier Proxmox standalone: ISO desde proxmox.com, ext4 en el SSD de sistema, red de gestión con IP estática. La diferencia aparece cuando creas una segunda NIC dedicada al tráfico de cluster.

Antes de seguir, hay una decisión importante de red: una sola NIC de 10 GbE con VLANs, o dos NICs físicas separadas. La segunda opción es más simple de entender y debuggear; la primera ahorra hardware. En este artículo asumo la primera: una sola NIC de 10 GbE con dos subinterfaces VLAN (10 = Ceph, 20 = migración de VMs), y otra NIC de 1 GbE para la UI de gestión.

Después del primer reboot, configura las dos redes en /etc/network/interfaces:

# /etc/network/interfaces — nodo1 (asume IP .11 para Ceph, .21 para migración)
auto lo
iface lo inet loopback
auto eno1
iface eno1 inet manual
# Gestión: 1 GbE, salida a tu LAN
auto eno2
iface eno2 inet static
    address 192.168.5.11/24
    gateway 192.168.5.1
# Tráfico Ceph y migración: 10 GbE, sin gateway
auto eno1.10
iface eno1.10 inet static
    address 10.10.10.11/24
auto eno1.20
iface eno1.20 inet static
    address 10.10.20.11/24
# Bridge para las VMs
auto vmbr0
iface vmbr0 inet manual
    bridge-ports eno2
    bridge-stp off
    bridge-fd 0

En cada nodo siguiente, incrementas el último octeto (nodo2 = .12, nodo3 = .13). Reinicia networking con systemctl restart networking y verifica que las tres interfaces tengan la MAC correcta y respondan a ping. Un detalle que pifié la primera vez: si tu switch maneja VLANs, asegúrate de que los puertos estén en modo trunk con las VLANs 10 y 20 permitidas. Un Mikrotik CRS305 lo configura en cinco líneas; un switch no administrable simplemente no soporta VLANs y necesitas hardware dedicado.

Crear el cluster con pvecm

Desde el primer nodo, ejecuta:

# Crear cluster (nodo1)
pvecm create home-cluster --link0 10.10.20.11/24 --link1 10.10.10.11/24
# Esto genera un join ticket que muestras en los otros dos nodos.
# El comando imprime algo como:
#   Please enter this node on the other nodes:
#   pvecm add 192.168.5.11 -ticket0 AABBCCDDEEFF...
# En nodo2 (vía SSH):
pvecm add 192.168.5.11 -link0 10.10.20.12/24 -link1 10.10.10.12/24 
    -ticket0 AABBCCDDEEFF...
# En nodo3:
pvecm add 192.168.5.11 -link0 10.10.20.13/24 -link1 10.10.10.13/24 
    -ticket0 AABBCCDDEEFF...

La opción -link0 es el tráfico de corosync (quorum y latidos del cluster); -link1 lo dejamos para Ceph en este setup. Si ves el error cluster not ready - no quorum después del join, casi siempre es que el firewall del nodo1 está bloqueando UDP 5404-5406 (puertos de corosync). Lo más rápido es permitir esas reglas con iptables -A INPUT -p udp --dport 5404:5406 -j ACCEPT en los tres nodos antes de crear o unirse al cluster.

Verifica que el cluster está sano:

pvecm status
# Expected:
#   Cluster information
#   -------------------
#   Name: home-cluster
#   Config Version: 3
#   ...
#   Quorum information
#   ------------------
#   Date: ...
#   Quorum provider: corosync_votequorum
#   Nodes: 3
#   Expected votes: 3

Tres nodos es el mínimo absoluto para HA. Con dos nodos, si cae uno pierdes quorum y el otro nodo entra en modo read-only; las VMs no migran, no arrancan nuevas. Un tercer nodo barato (incluso un mini PC con un Atom Celeron y 4 GB de RAM) basta como votante de quorum mientras corres las VMs serias en los otros dos.

Ceph Squid como almacenamiento hiperconvergente

Ceph es el componente que diferencia un cluster Proxmox de tres servidores independientes. En lugar de tener un NAS con NFS que sirve almacenamiento a las VMs, cada nodo del cluster aporta discos al pool Ceph, y Ceph replica los datos entre los nodos. La VM vive como imagen en el pool compartido y puede arrancar en cualquier nodo que tenga quorum.

La versión que viene con Proxmox VE 9.0 es Ceph Squid (19.x), instalada desde los repos oficiales de Proxmox. En cada nodo instalas los paquetes y creas el cluster Ceph:

# En cada nodo
apt update
apt install -y ceph
# Inicializar Ceph desde la UI: Datacenter → Ceph → Install (elige la red 10.10.10.0/24)
# O vía CLI en nodo1:
pveceph install --version squid
pveceph init --network 10.10.10.0/24
# En nodo2 y nodo3:
pveceph install --version squid
pveceph join --mon-address 10.10.10.11
# Crear OSDs (uno por disco que quieres aportar al pool)
# Desde UI: Ceph → OSD → Create OSD, seleccionas el disco
# O CLI:
ceph-volume lvm create --bluestore --data /dev/sdb

Una vez que los tres nodos tienen OSDs, creas el pool que las VMs van a consumir:

# Crear pool replicado en 3 (tolerancia a 1 falla de nodo)
pveceph pool create vm-pool --size 3 --min_size 2 --pg_num 128
# Verificar estado
ceph -s
ceph osd tree
ceph health detail

El parámetro --pg_num 128 es el número de placement groups. La regla empírica para pools pequeños (menos de 100 OSDs) es (OSDs_total * 100) / size, redondeado a potencia de 2. Con 6 OSDs (2 por nodo) y replicación 3, da 200 placement groups → 256 para tener holgura. No te obsesiones; Ceph te avisa si está muy bajo o muy alto.

Ahora crea el almacenamiento Proxmox que apunta al pool. En la UI: Datacenter → Storage → Add → RBD, con Pool = vm-pool, Content = Disk image. A partir de acá, cuando creas una VM nueva y eliges el storage vm-pool, la imagen vive replicada en los tres nodos y puede arrancar en cualquiera.

HA Manager: configurar grupos y fencing

El HA Manager es el servicio que decide qué hacer cuando un nodo cae. Tiene tres daemons: pve-ha-crm (Cluster Resource Manager, corre en todos los nodos, mantiene el estado), pve-ha-lrm (Local Resource Manager, corre en cada nodo, controla las VMs locales), y fence-pve (agente de fencing).

El flujo cuando nodo1 se cae es: corosync declara nodo1 perdido → CRM calcula que las VMs marcadas como HA en nodo1 deben migrar → LRM en nodo2 y nodo3 las levantan en orden de prioridad → si nodo1 sigue respondiendo parcialmente, el fencing lo apaga de forma abrupta para evitar split-brain.

Configurar el fencing es la parte que casi nadie hace bien y por la que luego el cluster no recupera VMs después de un crash. Hay tres opciones:

Método	Costo	Configuración	Cuándo usarlo
Watchdog software	0 USD	3 líneas en `/etc/pve/ha-manager.cfg`	Nodos sin IPMI. Funciona si el kernel cuelga pero no si el hardware se congela.
IPMI / iDRAC	Requiere hardware compatible	`fence_ipmilan` + dirección BMC	Servidores empresariales refurbished con iDRAC/iLO. La opción correcta.
PDU inteligente	100-300 USD por PDU	`fence_apc` o `fence_eaton`	Cuando tienes varias VMs críticas y quieres garantía física de corte de energía.

Si tu hardware tiene iDRAC (Dell) o iLO (HP), configúralo así. Asume que la IP del iDRAC de nodo1 es 192.168.5.111, usuario root, password ipmi-password:

# Verificar que fence_ipmilan está disponible (viene con fence-agents)
fence_ipmilan -a 192.168.5.111 -l root -p ipmi-password -o status
# Configurar fencing para nodo1 (repetir para nodo2 y nodo3 con sus IPs)
ha-manager fencing add ipmi-node1 
    --type ipmi 
    --ip 192.168.5.111 
    --username root 
    --password ipmi-password

Ahora marca las VMs que quieres como altamente disponibles. Cada VM que pongas en el grupo HA migra automáticamente si su nodo se cae:

# Marcar VM 100 como HA con prioridad normal
ha-manager add vm:100 --group default --max_relocate 1 --max_restart 1
# El grupo default permite a la VM arrancar en cualquier nodo con recursos
# Para restringir a nodos específicos:
ha-manager group add prod:node2,node3 --nofailback on
ha-manager add vm:100 --group prod

verifica la configuración completa con ha-manager config. La salida tiene que listar cada VM HA, su grupo y las opciones de fencing.

Probar el failover: simular una caída real

Un cluster HA que no probaste no es un cluster HA. Es una esperanza. La prueba mínima es tirar abajo un nodo en condiciones controladas y verificar que las VMs migran y vuelven a estar disponibles en menos de 60 segundos.

# Identificar qué VM está corriendo dónde
ha-manager status
# Verás algo como:
#   service vm:100 (node1, running)
#   service vm:101 (node2, running)
# En nodo1, simular un crash de kernel (la VM 100 debería migrar a nodo2 o nodo3)
ssh nodo1 "echo 1 > /proc/sys/kernel/sysrq && echo c > /proc/sysrq-trigger"
# Desde otro terminal, monitorear la migración:
watch -n1 'ha-manager status'
# Después de 30-90 segundos, vm:100 debería aparecer como running en nodo2 o nodo3
# Verificar que la VM es accesible
ping 
ssh  "uptime"

Si la VM no migró, lo más probable es que el fencing no esté configurado y el cluster está esperando confirmación de que nodo1 está realmente caído. Vuelve a la sección anterior y revisa ha-manager fencing list.

Una prueba más agresiva es tirar abajo el switch de la red de cluster:

# Apagar la NIC de cluster en nodo1 (desde IPMI para no perder acceso)
ipmitool -I lanplus -H 192.168.5.111 -U root -P ipmi-password 
    chassis power off
# El cluster pierde un voto de tres, queda con quorum (2 de 3),
# las VMs de nodo1 migran a nodo2 o nodo3.
# Restaurar nodo1 (manual desde IPMI):
ipmitool -I lanplus -H 192.168.5.111 -U root -P ipmi-password 
    chassis power on
ssh nodo1 "pvecm status"

Anota los tiempos que observes en tu prueba. En mi cluster de casa, la migración típica es de 25-45 segundos con VMs de 8 GB RAM sobre 10 GbE; con 1 GbE compartida tarda 90-120 segundos porque la memoria RAM se copia por la red lenta.

Mantenimiento del cluster: updates sin downtime

Con un cluster HA puedes actualizar Proxmox sin ventana de mantenimiento: evacua un nodo, lo actualiza, lo devuelve al cluster, repites con el siguiente. Proxmox automatiza esto en versiones recientes con el comando pve7to8 o su equivalente para 9.x:

# Antes de actualizar, verificar compatibilidad
pve5to6 --dry-run # versión según lo que tengas instalado
# Migrar VMs fuera de nodo1 (HA Manager las reubica automáticamente)
pvecm migrateall node2
# Actualizar nodo1
ssh nodo1 "apt update && apt full-upgrade -y"
# Reiniciar si el kernel cambió
ssh nodo1 "reboot"
# Esperar a que vuelva al cluster y vuelva a tomar VMs
pvecm status
ha-manager status
# Repetir con nodo2 y nodo3, uno por uno

Para Ceph, la actualización es más delicada porque requiere actualizar todos los nodos en una ventana coordinada. Proxmox 9.0 trae Ceph Squid con ceph-deploy y la documentación oficial cubre el proceso de Reef → Squid paso a paso. La regla es nunca actualizar Ceph con VMs activas usando pools antiguos; primero apaga las VMs, actualiza los paquetes en los tres nodos, después las vuelve a levantar.

Monitoreo mínimo que tienes que tener andando:

Dashboard Proxmox → Summary por nodo (CPU, RAM, temperatura, SMART).
Alertas de Ceph: ceph health detail en cron diario, notificar a Telegram o email si sale HEALTH_WARN o HEALTH_ERR.
Latencia de red del cluster: un script que pingue los otros nodos cada minuto y alerte si la latencia sube de 1 ms en LAN / 5 ms en 10 GbE.
Estado del quorum: pvecm status cada 5 minutos, alerta si Expected votes y Total votes divergen.

Cuándo NO armar un cluster HA

Para terminar de ahorrarte el esfuerzo: si tu home server ejecuta Plex, Pi-hole, un par de LXC con Docker y un backup nocturno, un cluster HA te da problemas que no tienes con un nodo único. Los Ceph OSDs en SSDs consumen 3-5 W cada uno en idle, así que tres nodos con dos OSDs cada uno suman 25-35 W extra las 24 horas. En zonas con cortes frecuentes, la UPS que necesitas para mantener el cluster funcionando crece en proporción.

La decisión que más impacto tiene en mi setup es cuándo migrar de un nodo a un cluster. La señal más clara: cuando ya tienes un backup verificado que restaura VMs en menos de una hora y quieres bajar ese tiempo a menos de un minuto. Antes de eso, mejor invertir en hardware más confiable (fuente de calidad, SSDs empresariales, UPS online) que en un segundo y tercer nodo.

Si después de leer todo esto sigues con ganas de armar el cluster, arranca con dos nodos pequeños y un tercero barato solo como votante de quorum. Prueba la migración manual con ha-manager migrate antes de activar el fencing automático. Y cuando todo funcione, escribe qué te rompió en los comentarios — los gotchas de cluster cambian con cada release mayor de Proxmox.

Resumen y hoja de ruta

Tu plan para el próximo mes: (1) conseguir tres nodos con hardware parejo, (2) instalar Proxmox 9.0 en el primero con dos redes separadas, (4) crear el cluster con pvecm create y unir los otros dos con tickets, (5) instalar Ceph Squid en los tres y crear el pool replicado, (6) configurar IPMI fencing si tu hardware lo soporta, (7) marcar las VMs críticas como HA, (8) probar failover con echo c > /proc/sysrq-trigger y medir tiempos. Con eso tienes un cluster HA funcional que puede tolerar la caída de cualquier nodo sin perder servicios.

Preguntas frecuentes

¿Por qué necesito 3 nodos y no 2 para HA en Proxmox?

Porque con 2 nodos, si uno cae, el otro pierde quorum (la mitad menos uno de los votos) y entra en modo read-only. Ninguna VM arranca ni migra. Con 3 nodos, la caída de uno deja 2 de 3 votos activos, suficiente quorum y el cluster sigue operando. La opción de 2 nodos + QDevice existe pero agrega complejidad que en home lab no vale la pena.

¿Cuánta RAM consume Ceph en cada nodo?

Cada OSD daemon consume 1-2 GB de RAM por defecto. Con 6 OSDs en 3 nodos (2 por nodo), eso son 2-4 GB por nodo dedicados a Ceph, más el OS y las VMs. Recomendado mínimo: 16 GB de RAM por nodo si vas a correr VMs además de Ceph; 32 GB si las VMs son pesadas.

¿Funciona HA con Ceph y 1 GbE?

Funciona, pero la migración de VMs en vivo copia la RAM por la red y Ceph usa la misma red para replicación. Con 1 GbE compartida, una VM de 8 GB tarda 90-120 segundos en migrar; con 10 GbE dedicada, baja a 25-45 segundos. Para VMs chicas (2-4 GB) la diferencia se nota menos; para VMs grandes es la mejora más rentable del cluster.

¿Qué pasa si dos nodos caen al mismo tiempo?

El cluster pierde quorum (1 de 3 votos) y todas las VMs se pausan. Los servicios no migran porque ningún nodo tiene mayoría. Cuando al menos un nodo vuelve y se reestablece la red, el cluster retoma automáticamente. Por eso los UPS y la redundancia de red son obligatorios en producción.

¿Cómo migro un cluster existente de Proxmox 8.x con Ceph Reef a 9.0 con Ceph Squid?

Primero actualiza Proxmox de 8.x a 9.0 en los tres nodos (uno por uno, evacuando VMs). Después sigue la guía oficial de Ceph Reef a Squid en pve.proxmox.com/wiki/Ceph_Reef_to_Squid. El cambio principal es actualizar paquetes en los tres nodos y reiniciar los daemons Ceph. Mantén replicación 3 durante toda la migración; bajarla a 2 temporalmente es válido pero arriesgado.