Clústeres y HA en Proxmox: cómo funciona, qué falla y cómo diseñarlo correctamente

enero 4, 2026 • febrero 3, 2026 • Lectura: 29 min • Views: 6

¿Te fue útil?

La primera vez que el HA de Proxmox te “salva” reiniciando una VM en un nodo que no puede ver su disco,
aprendes una lección útil: la disponibilidad es una propiedad del sistema, no una casilla para marcar.
Clusterizar es fácil. Sobrevivir a fallos es la parte difícil.

Esta es la guía práctica, centrada en producción: cómo funcionan realmente el clustering y el HA en Proxmox,
qué se rompe en entornos reales y cómo diseñar un clúster que no convierta pequeños cortes en una danza interpretativa.

Un modelo mental que refleje la realidad

El clustering en Proxmox no es magia. Son tres problemas separables que la gente suele mezclar:

Plano de control: los nodos acuerdan la membresía y la configuración (corosync + pmxcfs).
Plano de datos: los discos de las VM son accesibles donde se ejecuta la VM (almacenamiento compartido o replicación).
Orquestación de cargas: cuando un nodo falla, algo decide reiniciar VMs en otro sitio (pve-ha-manager + pve-ha-lrm).

El HA solo funciona si los tres están diseñados para fallar con gracia. Puedes tener un clúster perfectamente sano
con un almacenamiento totalmente no-HA. También puedes tener un almacenamiento compartido impecable con un plano de control que entra en pánico ante pérdida de paquetes.
Y puedes tener ambos y sabotearte con “optimizaciones” como timeouts agresivos o un único switch.

La regla operativa es simple: si no puedes explicar dónde vive el disco de la VM durante un failover, no tienes HA.
Tienes “la capacidad de reiniciar VMs en otro sitio”. No es lo mismo.

Qué hay dentro: corosync, pmxcfs, pve-ha-manager

Corosync: membresía y mensajería

Corosync es la capa de comunicación del clúster. Gestiona la membresía de nodos y distribuye el estado del clúster de forma fiable.
Proxmox lo usa para la pregunta “quién está en el grupo”. Es sensible a latencia, jitter y pérdida de paquetes exactamente como lo es el uplink de tu switch más cargado cuando piensas “bah, estará bien”.

pmxcfs: el sistema de archivos de configuración

Proxmox almacena la configuración del clúster en /etc/pve, respaldado por pmxcfs, un sistema de archivos distribuido.
No está pensado para tus imágenes de VM. Es para configuración: definiciones de almacenamiento, configs de VM, ACLs, ajustes del clúster.

Cuando se pierde el quórum, /etc/pve entra en un modo protector. Las escrituras se bloquean porque permitir que dos particiones escriban la configuración independientemente es cómo se consigue una división de la configuración.
Esto es una característica. También es la razón por la que la gente piensa “Proxmox está caído” cuando solo se han bloqueado las escrituras.

pve-ha-manager y pve-ha-lrm: el cerebro del HA y las manos locales

La pila de HA tiene un manager y gestores locales de recursos. El manager decide qué debe ejecutarse dónde. El agente local ejecuta los arranques/paradas.
Usa una mezcla de lógica de watchdog y estado del clúster para evitar ejecutar la misma VM dos veces. Evitar. No garantizar. La garantía requiere fencing.

Una cita para tener en la pared, en el espíritu de la realidad operativa: (idea parafraseada) «La esperanza no es una estrategia.» — atribuida a ingenieros y operadores en general, y correcta sin importar la atribución.

Quórum: la palabra más importante en tu clúster

El quórum responde: ¿tiene esta partición de nodos la autoridad para tomar decisiones del clúster?
Si ejecutas un clúster sin entender el quórum, es como conducir una carretilla elevadora en una cristalería.

Por qué existe el quórum

En una partición de red, puedes acabar con dos grupos de nodos que no pueden verse entre sí.
Sin quórum, ambos lados podrían “hacer lo correcto” localmente y arrancar la misma VM en los dos lados.
Así es como se corrompen sistemas de archivos, bases de datos y tus relaciones con el equipo de finanzas.

Regla práctica: los impares ganan

Un clúster de 3 nodos puede perder 1 nodo y mantener quórum. Un clúster de 2 nodos no puede.
Puedes hacer que 2 nodos funcionen con un dispositivo de quórum (QDevice), pero si intentas hacer HA barato,
descubrirás de la forma cara por qué la gente recomienda 3.

QDevice: el “tercer voto” sin un tercer hipervisor

QDevice añade un voto de quórum externo para que un clúster de 2 nodos pueda seguir operando cuando un nodo cae (o está particionado).
Debe colocarse con cuidado: si el QDevice está en la misma ruta de red que falló, es solo un voto decorativo.
Colócalo donde falle de forma diferente que la interconexión del clúster.

Broma #1 (corta y relevante)

El quórum es como la adultez: si tienes que preguntar si lo tienes, probablemente no lo tienes.

Almacenamiento para HA: qué significa realmente «compartido»

La decisión de almacenamiento es la decisión de HA. Todo lo demás es coreografía.

Opción A: almacenamiento verdaderamente compartido (SAN/NFS/iSCSI/FC)

Almacenamiento compartido significa que el disco de la VM es accesible desde varios nodos al mismo tiempo, con locking correcto.
En términos de Proxmox, son tipos de almacenamiento que soportan acceso compartido y las semánticas adecuadas (por ejemplo, NFS bien configurado, iSCSI con LVM, FC con multipath).

El almacenamiento compartido hace que el failover sea rápido: reiniciar la VM en otro nodo, mismo disco. También concentra el riesgo: el array de almacenamiento se convierte en “la cosa” que puede llevarse todo.
Algunas organizaciones lo aceptan porque el array está construido como un tanque. Otras descubren que “el array” es un solo controlador y una contraseña de administrador que no se ha cambiado desde 2018.

Opción B: almacenamiento compartido hiperconvergente (Ceph)

Ceph te da almacenamiento distribuido a través de tus nodos Proxmox (o nodos de almacenamiento dedicados). Excelente cuando se diseña correctamente:
suficientes nodos, suficientes NICs, suficientes discos, suficiente CPU y suficiente humildad.

Ceph no es “HA gratis”. Es un sistema de almacenamiento con sus propios modos de fallo, comportamiento de recuperación y perfil de rendimiento.
Durante la recuperación, Ceph puede comerse tu presupuesto de IO, lo que puede parecer que “el HA de Proxmox está roto” cuando en realidad tu clúster está haciendo exactamente lo que pediste: reconstruir datos.

Opción C: replicación (replicación ZFS) + reinicio

La replicación ZFS puede proporcionar un comportamiento casi-HA: replicar los discos de VM desde nodos primarios a secundarios según un calendario.
Si un nodo muere, inicias la VM en un nodo que tiene una réplica reciente. El intercambio es obvio: el RPO no es cero a menos que hagas replicación síncrona (que es otra bestia).

La replicación es una buena opción para clústeres pequeños que toleran perder unos minutos de datos, o para cargas donde ya existe replicación a nivel de aplicación.
También es mucho más simple de operar que Ceph para muchos equipos. Lo simple es bueno. Lo predecible es mejor.

Qué rompe la HA de almacenamiento en la práctica

Desajuste de locking: el almacenamiento soporta lecturas compartidas pero no escrituras compartidas seguras.
Acoplamiento de red: el tráfico de almacenamiento y corosync comparten el mismo enlace congestionado.
Durabilidad asumida: “es RAID” se convierte en “es seguro” y luego “¿dónde quedó el datastore?”.
Failover sin fencing: dos nodos piensan que poseen el mismo disco.

Fencing: eso que omites hasta que duele

El fencing (STONITH: Shoot The Other Node In The Head) asegura que un nodo fallado o particionado esté realmente detenido antes de que los recursos se ejecuten en otro lado.
En el HA de VM, el fencing es cómo evitas el desastre de “dos escritores activos”.

Sin fencing, dependes de timeouts y de la buena suerte. Los timeouts no son autoridad. Son conjeturas.

Cómo se ve el fencing en el mundo Proxmox

Proxmox soporta auto-fencing basado en watchdog y fencing externo con gestión tipo IPMI/iDRAC/iLO.
En la práctica, para un HA serio:

Habilita y valida el watchdog en cada nodo.
Usa gestión fuera de banda para cortar la alimentación a un nodo que está “vivo pero equivocado”.
Diseña la alimentación y la red para que un nodo pueda ser fenceado incluso si su red primaria está muerta.

Si usas almacenamiento block compartido (iSCSI/FC) y sistemas de archivos en clúster o LVM, el fencing importa aún más.
La corrupción de datos rara vez es inmediata. Suele ser diferida, sutil y perjudicial para la carrera profesional.

Red de clúster: anillos, latencia y pérdida de paquetes

Corosync quiere baja latencia y baja pérdida de paquetes. Tolerará menos rarezas que tu stack de almacenamiento.
El modo clásico de fallo es “la red está mayormente bien”, que es lo que la gente dice cuando la pérdida de paquetes es 0.5% y tu clúster pierde quorum intermitentemente.

Separar redes por función

Corosync: VLAN dedicada o red física si puedes. La latencia predecible importa.
Almacenamiento: también dedicada, especialmente para Ceph o iSCSI.
Tráfico cliente/VM: evita que golpee tu plano de control del clúster.

Los anillos duales no son decoración

Corosync puede usar múltiples anillos (redes separadas) para redundancia. Merece la pena hacerlo.
Si no puedes permitir conmutación redundante, acepta que tu “HA” es “alta ansiedad”.

Broma #2 (corta y relevante)

La pérdida de paquetes es como las termitas: la casa parece bien hasta que de repente no lo está.

Cómo falla: roturas reales y por qué

Modo de fallo: pérdida de quórum detiene las escrituras de configuración

Síntoma: puedes iniciar sesión, las VMs pueden seguir ejecutándose, pero no puedes iniciar/detener/migrar y los cambios en la GUI fallan.
Causa raíz: el nodo (o partición) no tiene quórum, así que pmxcfs bloquea las escrituras.
Respuesta correcta: restaura el quórum, no “forces” a menos que estés intencionalmente ejecutando una isla de nodo único y entiendas las consecuencias.

Modo de fallo: HA reinicia VMs pero no arrancan

Síntoma: el manager de HA intenta mover/reiniciar, pero la VM falla con discos faltantes, almacenamiento offline o errores de IO.
Causa raíz: el almacenamiento no estaba realmente compartido/disponible en el nodo destino; o la red de almacenamiento falló junto con el nodo.
Respuesta correcta: trata el almacenamiento como parte del dominio de fallo; rediseña la diversidad de caminos de almacenamiento; asegúrate de que las definiciones de almacenamiento sean coherentes y estén disponibles en todos los nodos.

Modo de fallo: split brain o riesgo de “doble arranque”

Síntoma: el mismo servicio aparece ejecutándose dos veces, o el disco compartido muestra corrupción, o el HA hace flapping.
Causa raíz: partición de red sin fencing efectivo, votos esperados mal configurados, o QDevice colocado en un mal sitio.
Respuesta correcta: arregla el diseño de quórum y añade fencing. No ajustes timeouts hasta que hayas diseñado la autoridad.

Modo de fallo: la recuperación de Ceph hace que todo parezca muerto

Síntoma: tras la caída de un nodo, las VMs tartamudean, la latencia de IO se dispara, el clúster “parece caído”.
Causa raíz: Ceph está reequilibrando/recuperando, saturando discos y red.
Respuesta correcta: planificación de capacidad, redes rápidas y ajustes de recuperación sensatos. Además: acepta que el “almacenamiento autocurativo” gasta recursos para curarse.

Tareas prácticas: comandos, salidas y decisiones

Estos son los chequeos que realmente ejecuto. Cada uno incluye qué significa la salida y qué decisión tomar.
Ejecútalos en un nodo salvo que se indique lo contrario.

Tarea 1: Comprobar membresía del clúster y quórum

cr0x@pve1:~$ pvecm status
Cluster information
-------------------
Name:             prod-cluster
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Sun Dec 28 12:10:41 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2c
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2
Flags:            Quorate

Significado: Quorate: Yes significa que esta partición puede cambiar el estado del clúster de forma segura (iniciar VMs HA, editar configuración).

Decisión: Si Quorate: No, deja de hacer cambios y arregla la conectividad/dispositivo de quórum antes de tocar el HA.

Tarea 2: Mostrar la vista por nodo y votos

cr0x@pve1:~$ pvecm nodes
Membership information
----------------------
Nodeid      Votes Name
0x00000001      1 pve1 (local)
0x00000002      1 pve2
0x00000003      1 pve3

Significado: Confirma quién está en la lista de miembros y cuántos votos tiene cada uno.

Decisión: Si falta un nodo inesperadamente, investiga los enlaces de corosync y la salud del nodo antes de culpar al HA.

Tarea 3: Verificar salud del anillo de corosync (enlaces knet)

cr0x@pve1:~$ corosync-cfgtool -s
Local node ID 1, transport knet
LINK ID 0 udp
        addr    = 10.10.10.11
        status  = ok
LINK ID 1 udp
        addr    = 10.10.20.11
        status  = ok

Significado: Ambos anillos están arriba. Si un enlace está down, has perdido redundancia.

Decisión: Si la redundancia de anillos está rota, trátalo como un sev-2: el siguiente fallo de switch se convertirá en un incidente de clúster.

Tarea 4: Comprobar temporización y membresía de corosync desde estadísticas en tiempo de ejecución

cr0x@pve1:~$ corosync-quorumtool -s
Quorum information
------------------
Date:             Sun Dec 28 12:11:22 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          1
Ring ID:          1.2c
Quorate:          Yes

Significado: Confirma la perspectiva de votequorum; útil cuando la UI miente o los logs están ruidosos.

Decisión: Si esto dice no quórum, deja de perseguir fantasmas de almacenamiento/rendimiento y arregla primero las comunicaciones del clúster.

Tarea 5: Confirmar que pmxcfs está sano y no atascado en modo solo-lectura

cr0x@pve1:~$ pvesh get /cluster/status
[
  {
    "type": "cluster",
    "name": "prod-cluster",
    "version": 42,
    "quorate": 1
  },
  {
    "type": "node",
    "name": "pve1",
    "online": 1,
    "ip": "10.10.10.11"
  },
  {
    "type": "node",
    "name": "pve2",
    "online": 1,
    "ip": "10.10.10.12"
  },
  {
    "type": "node",
    "name": "pve3",
    "online": 1,
    "ip": "10.10.10.13"
  }
]

Significado: "quorate": 1 indica que el sistema de archivos del clúster puede aceptar escrituras normalmente.

Decisión: Si quorate es 0, no intentes editar /etc/pve; no se conservarán (o peor, crearás un lío durante la recuperación).

Tarea 6: Inspeccionar el estado del HA manager

cr0x@pve1:~$ ha-manager status
quorum OK
master pve2 (active, Sat Dec 27 23:14:02 2025)

service vm:101 (running, node=pve1)
service vm:120 (running, node=pve3)

lrm pve1 (active, Sat Dec 27 23:14:11 2025)
lrm pve2 (active, Sat Dec 27 23:14:02 2025)
lrm pve3 (active, Sat Dec 27 23:14:07 2025)

Significado: Muestra qué nodo es el master de HA y si los gestores locales de recursos están activos.

Decisión: Si los LRM están inactivos o el master hace flapping, céntrate en la estabilidad de quórum y corosync antes de tocar VMs individuales.

Tarea 7: Explicar por qué una VM HA específica no se mueve

cr0x@pve1:~$ ha-manager status --verbose
quorum OK
master pve2 (active, Sat Dec 27 23:14:02 2025)

service vm:101 (running, node=pve1)
  state: started
  request: none
  last_error: none

service vm:130 (error, node=pve2)
  state: stopped
  request: start
  last_error: unable to activate storage 'ceph-vm' on node 'pve2'

Significado: El HA no está “roto”, está bloqueado por la activación del almacenamiento en el nodo destino.

Decisión: Cambia a depuración de almacenamiento (Ceph/NFS/iSCSI), no ajustes de HA.

Tarea 8: Comprobar pérdida/latencia de red de clúster rápidamente

cr0x@pve1:~$ ping -c 20 -i 0.2 10.10.10.12
PING 10.10.10.12 (10.10.10.12) 56(84) bytes of data.
64 bytes from 10.10.10.12: icmp_seq=1 ttl=64 time=0.355 ms
64 bytes from 10.10.10.12: icmp_seq=2 ttl=64 time=0.420 ms
...
--- 10.10.10.12 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 3815ms
rtt min/avg/max/mdev = 0.312/0.401/0.612/0.081 ms

Significado: Un ping limpio no prueba que corosync esté contento, pero pérdida/jitter aquí es una prueba contundente.

Decisión: Si existe pérdida de paquetes, detente. Arregla la red primero. Corosync bajo pérdida causa fallos fantasma en todas partes.

Tarea 9: Revisar logs de corosync por churn de membresía

cr0x@pve1:~$ journalctl -u corosync -S -2h --no-pager | tail -n 20
Dec 28 10:41:03 pve1 corosync[1203]:   [KNET  ] link: host: 2 link: 0 is down
Dec 28 10:41:06 pve1 corosync[1203]:   [QUORUM] This node is within the primary component and will provide service.
Dec 28 10:41:11 pve1 corosync[1203]:   [KNET  ] link: host: 2 link: 0 is up
Dec 28 10:41:12 pve1 corosync[1203]:   [TOTEM ] A new membership (1.2b) was formed. Members joined: 2

Significado: Los enlaces que hacen flapping provocaron reformaciones de membresía. Eso es turbulencia de clúster.

Decisión: Trata los cambios repetidos de membresía como precursor de un incidente. Investiga NICs, switches, bonding, configuración de VLAN, MTU y congestión.

Tarea 10: Validar disponibilidad del watchdog (prerrequisito de auto-fencing)

cr0x@pve1:~$ dmesg | grep -i watchdog | tail -n 10
[    1.842113] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[    1.842205] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)

Significado: Hay un driver de watchdog hardware presente. Esa es la base para el auto-fencing.

Decisión: Si no hay watchdog, no finjas que tienes HA seguro. Añade soporte hardware o fencing fuera de banda.

Tarea 11: Confirmar visibilidad de almacenamiento en un nodo destino (ejemplo NFS)

cr0x@pve2:~$ pvesm status
Name         Type     Status           Total       Used        Avail     %
local        dir      active         19660800    2457600     17203200   12%
nfs-vmstore  nfs      active       1048576000  734003200    314572800   70%

Significado: El almacenamiento está active en este nodo. Si está inactive, el HA no puede arrancar discos allí.

Decisión: Si está inactivo, arregla montaje/red/autenticación antes de permitir que el HA coloque cargas allí.

Tarea 12: Confirmar backend del disco de una VM y si es migrable

cr0x@pve1:~$ qm config 101
boot: order=scsi0;net0
cores: 4
memory: 8192
name: app-prod-01
net0: virtio=12:34:56:78:9a:bc,bridge=vmbr0
scsi0: ceph-vm:vm-101-disk-0,iothread=1,size=80G
scsihw: virtio-scsi-pci
vmgenid: 0b0b0b0b-1111-2222-3333-444444444444

Significado: El disco está en ceph-vm. Eso es compartido (suponiendo que Ceph esté sano).

Decisión: Si ves local-lvm o un dataset ZFS local del nodo sin replicación, no esperes que el HA lo reinicie con éxito en otro nodo.

Tarea 13: Comprobar la salud de Ceph (si lo usas)

cr0x@pve1:~$ ceph -s
  cluster:
    id:     2f4a9d2e-aaaa-bbbb-cccc-111122223333
    health: HEALTH_WARN
            1 osds down
            Degraded data redundancy: 12/3456 objects degraded

  services:
    mon: 3 daemons, quorum pve1,pve2,pve3 (age 7m)
    mgr: pve1(active, since 2h)
    osd: 9 osds: 8 up (since 1m), 9 in (since 30d)

  data:
    pools:   3 pools, 128 pgs
    objects: 1152 objects, 4.5 GiB
    usage:   220 GiB used, 1.8 TiB / 2.0 TiB avail
    pgs:     12 active+undersized+degraded, 116 active+clean

Significado: Ceph está arriba pero degradado; el rendimiento puede ser malo y los reinicios HA lentos.

Decisión: Durante estados degradados, evita migraciones masivas y no provoques reinicios evitables. Estabiliza Ceph primero.

Tarea 14: Confirmar el estado de replicación para configuraciones de replicación ZFS

cr0x@pve1:~$ pvesr status
JobID  Type  State    Last Sync              Duration  Error
1000   local ok       2025-12-28 11:55:02    00:01:42  -
1001   local failed   2025-12-28 11:40:02    00:00:11  ssh connection failed

Significado: El job 1001 falló; las réplicas pueden estar obsoletas en el nodo destino.

Decisión: No declares cobertura HA para VMs en un job de replicación que está fallando. Arregla transporte/autenticación y valida el RPO.

Tarea 15: Comprobar si el clúster está falto de recursos (síntomas CPU steal, IO wait)

cr0x@pve1:~$ pvesh get /nodes/pve1/status
{
  "cpu": 0.71,
  "loadavg": [2.15, 2.07, 1.94],
  "memory": {
    "total": 68719476736,
    "used": 51234567890,
    "free": 17484908846
  },
  "swap": {
    "total": 8589934592,
    "used": 2147483648
  },
  "uptime": 123456
}

Significado: Estás usando swap. En clústeres, hacer swap convierte un “pequeño fallo de red” en “por qué todo se colgó”.

Decisión: Si el swap se usa materialmente en condiciones normales, arregla la presión de memoria antes de diagnosticar flaps de HA.

Tarea 16: Verificar sincronización de tiempo (sí, importa)

cr0x@pve1:~$ timedatectl status
               Local time: Sun 2025-12-28 12:14:55 UTC
           Universal time: Sun 2025-12-28 12:14:55 UTC
                 RTC time: Sun 2025-12-28 12:14:55
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Significado: El reloj está sincronizado. Bien. La deriva de tiempo hace que los logs sean inútiles y puede desestabilizar sistemas distribuidos de formas sutiles.

Decisión: Si no está sincronizado, arregla NTP/chrony en todos los nodos antes de intentar interpretar el orden de eventos en un incidente.

Guía de diagnóstico rápido

Cuando un clúster Proxmox “actúa raro”, quieres velocidad y prioridades correctas. Aquí el orden que encuentra el cuello de botella rápido.

Primero: ¿el plano de control es autoritativo?

Ejecuta pvecm status: ¿tienes quórum?
Ejecuta corosync-cfgtool -s: ¿los enlaces están arriba? ¿algún anillo caído?
Escanea journalctl -u corosync: ¿hay membresías repetidas?

Si el quórum es inestable, detente aquí. Arregla la red del clúster y la membresía antes de investigar HA, almacenamiento o síntomas de VM.

Segundo: ¿puede el nodo destino ver el almacenamiento de la VM?

pvesm status en el nodo destino: ¿almacenamiento active?
qm config <vmid>: ¿dónde está realmente el disco?
Si Ceph: ceph -s y vigila degradado/backfill.

Si el almacenamiento no está disponible en todos los sitios necesarios, el HA hará flapping o reiniciará hacia el fracaso.

Tercero: ¿está el HA atascado o se niega a hacer algo inseguro?

ha-manager status --verbose: lee el error, no adivines.
Revisa readiness de watchdog/fencing si ves riesgo de doble arranque o comportamientos tipo fencing repetidos.

Cuarto: ¿es esto realmente falta de recursos?

pvesh get /nodes/<node>/status: swap, carga, uso de CPU.
Comprueba pérdida y latencia de red entre nodos; luego revisa la red de almacenamiento por separado.

Errores comunes: síntoma → causa raíz → solución

1) “El HA está roto, no arranca VMs”

Síntomas: acciones de HA fallan; la GUI muestra errores; algunos nodos aparecen “desconocidos.”

Causa raíz: pérdida de quórum, o churn de membresía de corosync.

Solución: Restaura la conectividad estable de corosync (red dedicada, anillos redundantes). Añade QDevice para 2 nodos. No cambies timeouts primero.

2) “La VM se reinició en otro nodo pero falta el disco”

Síntomas: la VM arranca y luego falla; errores de almacenamiento; disco no encontrado.

Causa raíz: el disco estaba en almacenamiento local del nodo (o almacenamiento compartido no montado/activo en el destino).

Solución: Pon VMs HA en almacenamiento verdaderamente compartido (Ceph/NFS/iSCSI/FC) o implementa replicación con RPO definido y prueba restaurar/failover.

3) “El clúster se congela durante backups/migraciones”

Síntomas: timeouts de corosync, HA haciendo flapping, GUI lenta durante IO intenso.

Causa raíz: la red de corosync comparte un enlace congestionado con tráfico VM/almacenamiento; o CPU agotada por cifrado/compresión/backups.

Solución: Separa redes; limita la tasa de trabajos pesados; fija corosync a rutas de baja latencia; planifica capacidad de CPU para ventanas de backup.

4) “Clúster de dos nodos: a veces simplemente deja de gestionar cosas”

Síntomas: tras la caída de un nodo, el nodo restante no inicia recursos HA ni edita configuración.

Causa raíz: sin QDevice; votos esperados mal alineados; quórum no alcanzable en solitario.

Solución: Añade QDevice en un dominio de fallo independiente; verifica votos esperados; prueba escenarios de “un nodo abajo”.

5) “Ceph está más o menos sano pero todo va lento”

Síntomas: latencia alta de IO, VMs se congelan, failovers lentos tras una falla.

Causa raíz: degradado/backfill/recuperación saturando IO; red infra-dimensionada (1GbE) o discos inadecuados; pocos OSDs.

Solución: Ingeniería correcta de Ceph: 10/25GbE, suficientes OSDs, redes públicas/cluster separadas donde aplique, y planifica el impacto de la recuperación.

6) “Afinamos timeouts de corosync y ahora el HA está peor”

Síntomas: más pérdida de quórum, muertes falsas de nodos, failovers aleatorios.

Causa raíz: timeouts configurados por debajo del jitter real bajo carga; el clúster se vuelve propenso a dispararse solo.

Solución: Vuelve a valores sensatos; arregla la red; mide el jitter en picos; solo entonces considera tuning cuidadoso.

7) “Después de un reinicio, un nodo no puede unirse al clúster”

Síntomas: el nodo aparece offline; corosync no arranca; errores de mismatch de configuración.

Causa raíz: mapeo incorrecto en /etc/hosts, corosync config obsoleta, mismatch de MTU o reglas de firewall.

Solución: Valida resolución de nombres, MTU consistente, puertos abiertos requeridos en redes de clúster y confirma consistencia de corosync.conf vía /etc/pve.

Listas de verificación / plan paso a paso

Checklist de diseño: construir un clúster con el que puedas dormir

Elige el tamaño del clúster: Prefiere 3+ nodos. Si son 2, planifica QDevice y fencing desde el primer día.
Define dominios de fallo: switches, circuitos de alimentación, racks, pares de ToR, caminos de almacenamiento. Escríbelos.
Separa redes: corosync en su VLAN/tejido físico; almacenamiento en el suyo; tráfico cliente separado.
Redundancia: anillos corosync duales; conmutación redundante; NICs bondadas solo si entiendes la configuración del switch.
Estrategia de almacenamiento: compartido (Ceph/SAN/NFS/iSCSI) para HA real; replicación para “reinicio con RPO.” No mezcles expectativas.
Fencing: watchdog + control de alimentación fuera de banda probado. Documenta cómo fencear manualmente.
Capacidad: N+1 en cómputo. HA sin capacidad de reserva es solo decepción automatizada.
Pruebas operativas: reinicio planificado de nodo, corte de alimentación, shutdown de puerto de switch, fallo de camino de almacenamiento, pérdida de QDevice (si se usa).

Plan de implementación: de cero a estable

Construye nodos idénticos (kernel, drivers NIC, ajustes BIOS para virtualización, controladores de almacenamiento).
Asigna direcciones estáticas para redes corosync; asegura resolución de nombres estable.
Crea el clúster; configura inmediatamente corosync de anillo dual si tienes las redes.
Valida el comportamiento de quórum aislando temporalmente un nodo (prueba controlada).
Levanta el almacenamiento y valida desde cada nodo (pvesm status debe ser aburridamente consistente).
Habilita watchdog y valida que aparezca en logs en cada nodo.
Crea grupos HA con restricciones sensatas (no permitas que todo se amontone en el nodo más pequeño).
Pon una VM no crítica en HA, prueba fallo de nodo, confirma que arranca en otro con disco y red correctos.
Despliega HA por clase de servicio; mantén un pool “no HA” para pets y experimentos.

Checklist de operaciones: rutina semanal “mantener sano”

Chequea pvecm status en un nodo aleatorio: confirma quórum estable.
Escanea logs de corosync por flaps de enlace y churn de membresía.
Si Ceph: comprueba ceph -s y atiende avisos antes de que sean incidentes.
Valida jobs de replicación (pvesr status) si dependes de ellos.
Confirma sincronización horaria en todos los nodos.
Realiza una migración controlada ocasionalmente en horario laboral (sí, a propósito) para detectar deriva temprano.

Tres micro-historias del mundo corporativo

Micro-historia 1: El incidente causado por una suposición errónea

Una empresa mediana montó un clúster Proxmox de tres nodos para “HA”. El equipo hizo lo que muchos hacen: clusterizar nodos,
habilitar HA y sentirse bien. El almacenamiento era “compartido”, decían, porque cada nodo podía alcanzar el NAS por NFS.
Nadie hizo la pregunta poco sexy: ¿está NFS montado y sano en cada nodo durante el fallo exacto que estamos planeando?

La primera caída real fue el reinicio de un switch top-of-rack. Los nodos siguieron arriba, pero la VLAN del NAS tuvo un fallo.
Corosync estaba en la misma ruta de switching, así que empezó el churn de membresía. El quórum parpadeó.
HA vio un nodo como no saludable y reinició dos VMs en un nodo que, en ese momento, no tenía montado el share NFS.

Las VMs no arrancaron. Las aplicaciones cayeron. El equipo, mirando la GUI, lo interpretó como “el HA de Proxmox es buggy.”
Reiniciaron nodos en nombre de “estabilizar”, lo que lo empeoró porque aumentó el churn y los arranques fallidos.

Tras el polvo, la postmortem reveló la suposición errónea: “NFS alcanzable” se trató como “almacenamiento HA”.
La solución no fue exótica. Separaron corosync en una red dedicada, hicieron los montajes de almacenamiento más resilientes y monitorizados,
y añadieron una regla firme: no etiquetar una VM como HA a menos que su disco viva en un almacenamiento probado como accesible desde cualquier nodo destino en pruebas de fallo.

La lección no es romántica: el HA es un contrato. Si el almacenamiento puede desaparecer durante la misma clase de fallo que desencadena el failover,
tu sistema HA reiniciará cargas en un vacío y lo llamará éxito.

Micro-historia 2: La optimización que salió mal

Otra organización usaba Proxmox con Ceph y tenía alertas intermitentes de “nodo perdido”. Alguien decidió “apurar la detección”
reduciendo los timeouts del clúster. Detección más rápida significa failover más rápido, razonaron. Querían que el sistema fuera “más ágil”.

Funcionó en laboratorio. En producción, se encontró con la realidad: ventanas de backup, IO de vecinos ruidosos y una red que estaba bien
hasta que el tráfico de recuperación de Ceph decidió ser ambicioso. Durante carga pico, los paquetes de corosync se retrasaron lo justo.
Con los timeouts más estrictos, esos retrasos cruzaron la línea de “tolerado” a “nodo declarado muerto”.

HA empezó a mover VMs. Ceph ya estaba ocupado. Ahora tenía que servir IO de VMs además de manejar recuperación y absorber tormentas de migraciones/reinicios.
El clúster se espiraló en dolor autoinfligido: failovers falsos causando carga real, provocando más failovers falsos.

La solución fue algo embarazosa y totalmente efectiva: revertir los timeouts, y luego arreglar la latencia y la congestión subyacentes.
Separaron el tráfico, limitaron los trabajos más ruidosos y ajustaron expectativas: la velocidad de failover no vale la inestabilidad del clúster.

La lección profunda: los timeouts no son perillas de rendimiento. Son detectores de fallo. Si los ajustas por debajo de tu jitter peor caso,
no estás mejorando la disponibilidad. Estás generando caos más rápido.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Una compañía con requisitos de cumplimiento ejecutaba un clúster Proxmox con iSCSI compartido y un QDevice.
Su diseño no era llamativo. Era simplemente meticulosamente cuidadoso: red corosync dedicada, switches redundantes,
fencing documentado vía gestión fuera de banda y pruebas trimestrales de “tirar el cable”.

Durante un mantenimiento programado, una actualización de firmware en un switch salió mal y el switch dejó de reenviar tráfico correctamente.
El anillo 0 de corosync se comportó raro. El anillo 1 se mantuvo sano. El clúster no perdió quórum.
Las VMs no hicieron flapping. El sistema de monitorización se encendió, pero el negocio apenas lo notó.

El on-call siguió el runbook: confirmar quórum, confirmar estado de anillos de corosync, confirmar caminos de almacenamiento y luego aislar el switch malo.
Movieron algunas cargas deliberadamente en lugar de permitir que HA hiciera thrash. No reiniciaron nodos por pánico.

Tras el incidente, el equipo no recibió puntos de héroe porque no pasó nada dramático. Ese es el sueño.
La práctica aburrida—anillos redundantes más diagnósticos ensayados—convirtió un posible apagón en un mantenimiento controlado.

Si quieres un HA que parezca competencia en vez de adrenalina, necesitas estos hábitos aburridos. El drama no es un KPI.

Hechos interesantes y contexto histórico

Hecho 1: Proxmox VE construye sus comunicaciones de clúster sobre Corosync, un proyecto open-source de larga trayectoria también usado en stacks clásicos de Linux HA.
Hecho 2: El concepto de “quórum” precede a la virtualización moderna; tiene raíces en la seguridad de sistemas distribuidos: solo una mayoría puede decidir de forma segura.
Hecho 3: El split brain no fue inventado por la virtualización; clústeres de almacenamiento y replicación de bases de datos lo han combatido durante décadas.
Hecho 4: pmxcfs es un sistema de archivos de configuración, no un sistema de archivos distribuido de propósito general; tratarlo como “almacenamiento compartido” es un malentendido común.
Hecho 5: El movimiento de Corosync al transporte knet mejoró el manejo de enlaces y las opciones de redundancia comparado con configuraciones antiguas.
Hecho 6: STONITH como término suena antiguo y a broma, pero la idea es extremadamente seria: asegurar que exista solo un escritor.
Hecho 7: “HA” originalmente significaba failover de nivel de servicio para procesos; la virtualización convirtió la unidad de failover en una máquina completa, pero las reglas de seguridad se mantuvieron.
Hecho 8: La popularidad de Ceph en setups hiperconvergentes vino de resolver un problema real: escalar almacenamiento sin un array monolítico, a costa de complejidad operativa.
Hecho 9: Los clústeres de dos nodos son históricamente incómodos en sistemas basados en quórum; el tercer voto (humano, testigo o qdevice) es un patrón bien consolidado.

Preguntas frecuentes (FAQ)

1) ¿Necesito tres nodos para HA en Proxmox?

Si quieres un comportamiento de quórum sensato sin componentes especiales, sí. Dos nodos pueden funcionar con QDevice, pero son menos tolerantes y más fáciles de mal diseñar.

2) ¿Qué pasa cuando el clúster pierde quórum?

Los nodos sin quórum bloquearán las escrituras de configuración en /etc/pve. Las VMs en ejecución pueden seguir, pero las operaciones gestionadas por el clúster (especialmente acciones HA) pueden estar restringidas.

3) ¿Puedo tener HA si los discos de mis VMs están en almacenamiento local?

No es un failover HA real. Proxmox solo puede reiniciar una VM en otro nodo si el disco es accesible allí (almacenamiento compartido) o está replicado y puede promoverse con un RPO conocido.

4) ¿La replicación ZFS es “HA”?

Es “reinicio automatizado con replicación.” Genial para muchas cargas, pero no es RPO cero. Si eso es aceptable y probado, es un diseño válido.

5) ¿Realmente necesito fencing?

Si usas almacenamiento compartido y te importa la integridad de los datos, sí. Sin fencing, una partición de red puede llevar a dos escritores activos.
A veces tienes suerte. Otras veces tienes una base de datos corrupta y un fin de semana largo.

6) ¿Debe corosync ejecutarse en la misma red que Ceph o NFS?

Evítalo. Corosync quiere latencia predecible; el tráfico de almacenamiento es explosivo y eventualmente lo presionará. Sepáralos salvo que tu entorno sea pequeñísimo y aceptes el riesgo.

7) ¿Cómo sé si el HA falla por almacenamiento o por comunicaciones del clúster?

Comprueba el quórum primero (pvecm status). Si hay quórum, revisa si el almacenamiento está active en el destino (pvesm status) y lee ha-manager status --verbose para errores explícitos.

8) ¿Por qué Proxmox HA a veces se niega a mover una VM aunque un nodo parezca no saludable?

Porque intenta evitar acciones inseguras: arrancar sin almacenamiento, arrancar dos veces o actuar sin quórum. “Negarse” suele ser el comportamiento correcto.

9) ¿Puedo estirar un clúster Proxmox entre dos sitios?

Puedes, pero te estás inscribiendo a latencia, riesgo de partición y replicación de almacenamiento compleja. Si lo haces, diseña quórum, fencing y almacenamiento como un sistema distribuido, no como una LAN.

10) ¿Cuál es el diseño HA más simple y fiable para equipos pequeños?

Tres nodos, red corosync dedicada, almacenamiento verdaderamente compartido (o replicación con RPO explícito), watchdog habilitado y escenarios de fallo probados. Manténlo aburrido.

Conclusión: próximos pasos prácticos

El clustering y el HA en Proxmox funcionan bien cuando los tratas como ingeniería de sistemas: autoridad (quórum), ejecución segura (fencing)
y accesibilidad de datos (almacenamiento) diseñados en conjunto. Si cualquiera de estos se deja de lado, el clúster acabará cobrando la factura.

Próximos pasos que puedes hacer esta semana:

Ejecuta las comprobaciones de diagnóstico rápido ahora, mientras todo está “bien”, y registra salidas base.
Clasifica cada VM: HA real (almacenamiento compartido + fencing), reinicio con RPO (replicación) o esfuerzo razonable (local).
Separa el tráfico de corosync del tráfico de almacenamiento y VM, o al menos demuestra que la red puede soportar el peor jitter bajo carga.
Prueba un fallo real (apaga un nodo, o deshabilita un puerto de switch) en una ventana controlada y verifica: comportamiento de quórum, decisiones HA, disponibilidad de almacenamiento.
Documenta cómo fencear un nodo y practícalo. No quieres que tu primer intento de fencing sea durante una corrupción.