Clúster Proxmox: por qué Corosync parece estar bien mientras tu clúster se degrada

febrero 28, 2026 • febrero 28, 2026 • Lectura: 25 min • Views: 1

¿Te fue útil?

Abres la interfaz web de Proxmox y se queda colgada. Las migraciones se estancan. HA hace flapping. Las máquinas virtuales están funcionando—hasta que dejan de hacerlo.
Entonces revisas lo obvio: el quorum de Corosync. Dice que todo está bien.

Ahí está la trampa. Corosync puede estar “bien” en el sentido estrictamente limitado—membresía y quorum intactos—mientras
el resto del clúster se asfixia por latencia, contención de bloqueos del sistema de archivos, paradas del almacenamiento o deriva del tiempo.
Corosync es el pulso. Tu clúster aún puede estar perdiendo vida.

Qué es Corosync (y qué no es)

Corosync proporciona membresía de clúster y mensajería. En Proxmox VE, es el componente que decide
quién está en el grupo y si el grupo tiene quorum. No garantiza que tu plano de gestión
responda, que tu almacenamiento esté sano, o que tus hipervisores puedan realmente realizar trabajo al ritmo
que necesitas.

Proxmox apila muchas cosas sobre la base de que “los nodos pueden verse entre sí”:
pmxcfs (el sistema de archivos de clúster de Proxmox que almacena el estado de configuración),
pveproxy y pvedaemon (servicios API/UI),
pve-ha-lrm/crm (lógica HA),
pvestatd (estadísticas),
y lo que sea que esté haciendo hoy tu backend de almacenamiento (ZFS, iSCSI, NFS, Ceph, LVM local… escoge tu pesadilla favorita).

La membresía de Corosync puede permanecer estable incluso mientras:

pmxcfs está atascado esperando operaciones FUSE y no puedes confirmar cambios de configuración
la red pierde paquetes o sufre picos de latencia—simplemente no lo suficiente como para perder el quorum
la deriva de tiempo provoca raros fallos de autenticación y fencing
paradas del almacenamiento congelan los hilos de I/O de QEMU y las migraciones expiran
los demonios de gestión están bloqueados por DNS, PAM/LDAP o llamadas al sistema de archivos

Dos hechos secos que salvan carreras

El quorum es binario; la salud no lo es. Puedes tener quorum y aun así ser inutilizable.
La mayoría de los “problemas de clúster” en Proxmox son en realidad problemas de latencia. No siempre es la red—a menudo es el almacenamiento o la contención de CPU que se manifiestan como latidos perdidos en otro lado.

Datos interesantes y contexto histórico (porque los sistemas arrastran equipaje)

Corosync evolucionó desde el proyecto OpenAIS, que buscaba implementar conceptos de especificación de interfaz de aplicación para clustering en Linux.
Totem es la capa de comunicación de grupo de Corosync; su mecanismo de token es por qué el ajuste de “token timeout” te hace sentir poderoso—y luego arrepentido.
El quorum en Corosync es un problema de votación (vía votequorum) más que un sistema de puntuación de salud; no mide la capacidad de respuesta a nivel de servicio.
pmxcfs es un sistema de archivos distribuido basado en FUSE; es excelente para archivos de configuración pequeños y terrible para tu paciencia cuando se bloquea.
El “sistema de archivos de clúster” de Proxmox no es un sistema de archivos general; es un almacén replicado de configuraciones. Tratarlo como almacenamiento compartido es cómo terminas en terapia.
La prevención de split-brain es un sesgo de diseño en la mayoría de pilas de clúster; Proxmox tiende a preferir “detener escrituras” sobre “posiblemente corromper cosas en silencio”.
El punto de dolor histórico de CEPH fue la amplificación de escrituras pequeñas; las versiones modernas mejoraron mucho, pero tu red y tus discos siguen decidiendo si es un Ferrari o un cortacésped.
La planificación del kernel Linux y la presión de I/O pueden crear modos de fallo de “todo parece activo pero nada se mueve”—especialmente en hipervisores sobrecargados.

Una cita que vale la pena tener pegada en el monitor:
La esperanza no es una estrategia. — Gen. Gordon R. Sullivan

Broma #1: Que Corosync diga “quorum” mientras tu GUI se cuelga es como que el detector de humo diga “pilas OK” durante un incendio en la cocina.

Guía de diagnóstico rápido

Cuando el clúster se está muriendo, no tienes tiempo para leer logs interpretativos. Necesitas un camino corto hasta el cuello de botella.
Aquí está el orden que encuentra causas raíz rápido en entornos reales.

Primero: ¿es un problema de membresía de red o una parada del plano de gestión?

Comprueba la estabilidad de la membresía de Corosync (pvecm status, corosync-cfgtool -s).
Comprueba si pmxcfs es responsivo (pvecm updatecerts se colgará si el fs de clúster está atascado; además lecturas simples en /etc/pve pueden bloquear).
Comprueba si la API/UI está bloqueada (estado systemd y journal para pveproxy/pvedaemon).

Segundo: ¿cuál es la fuente dominante de latencia ahora mismo?

Latencia/pérdida de paquetes de red (ping -f no es la respuesta; usa mtr, ethtool -S, contadores del switch).
Latencia de almacenamiento (ZFS zpool iostat -v, Ceph ceph -s y slow ops, estadísticas de cliente NFS).
Steal de CPU / cola de ejecución / presión de memoria (el promedio de carga no basta; revisa vmstat, top, pressure-stall-information si está disponible).

Tercero: ¿algo está “reintentando para siempre” de forma “útil”?

Consultas DNS y LDAP (inicios de sesión en la GUI que se quedan colgados, llamadas a la API que se estancan).
Multipath oscilante (rutas iSCSI que mueren y vuelven como una telenovela).
Backfill/recuperación de Ceph saturando el clúster (está “más o menos sano” pero lo suficientemente lento como para que todo expire).

Decisiones rápidas de triaje

Si la membresía es estable pero pmxcfs está bloqueado: trátalo como una interrupción del plano de control. Deja de cambiar la configuración y encuentra el bloqueo.
Si hay picos de latencia en el almacenamiento: detén migraciones, detén backups, detén cualquier cosa que multiplique I/O. Restaura la línea de base primero.
Si hay pérdida/latencia de red: prioriza estabilizar la red del ring antes de “ajustar timeouts de token.” El ajuste es un último recurso, no una cura.

Modos de fallo donde Corosync parece saludable

1) pmxcfs está atascado: Corosync está bien, pero las escrituras de configuración bloquean

pmxcfs es donde Proxmox almacena la configuración a nivel de clúster: definiciones de VM, configuraciones de almacenamiento, reglas de firewall, ámbitos de usuario y más.
Está respaldado por la mensajería de Corosync y se monta en /etc/pve usando FUSE.

Cuando pmxcfs está lento o atascado, verás síntomas como:

Acciones en la GUI se quedan colgadas (crear una VM, editar almacenamiento, cambiar HA)
Comandos qm/pct se congelan cuando tocan configs
SSH funciona; las VMs siguen corriendo; pero la gestión está “bajo el agua”

Causas comunes: presión extrema de CPU, deadlocks en FUSE, paradas de disco que afectan al journaling local, o retrasos en mensajes de corosync que aún no rompen el quorum.

2) Los timeouts de token no están rotos; tu presupuesto de latencia sí

El mecanismo de token de Corosync espera entrega oportuna de mensajes. Puedes tener quorum estable incluso con picos intermitentes de latencia que
no superan tu token timeout—pero esos picos siguen siendo lo bastante largos para congelar migraciones, backups y decisiones de HA.

Un patrón clásico: “arreglaste” corosync aumentando el token timeout. La membresía deja de hacer flapping.
Mientras tanto, el clúster ahora tolera latencias tan malas que todo lo demás sufre. No arreglaste la red.
Solo enseñaste a Corosync a dejar de quejarse.

3) Paradas del almacenamiento congelan el hipervisor, no a Corosync

Los incidentes más desagradables en Proxmox son inducidos por el almacenamiento. Una escritura de VM se bloquea en el kernel o en QEMU,
el host experimenta I/O wait, y de repente todos tus demonios de gestión responden como si estuvieran hablando desde un túnel.

Corosync aún puede intercambiar latidos si la CPU se programa ocasionalmente. Eso basta para mantener el quorum.
Pero no es suficiente para un sistema con respuesta aceptable.

4) Deriva del tiempo: el veneno lento

Problemas de NTP/chrony no siempre rompen el quorum. Pero pueden romper todo aquello que asume monotonicidad temporal:
handshakes TLS, autenticación, correlación de logs, decisiones de fencing, y “¿por qué ese nodo pensó que estaba 5 minutos en el futuro?”

También perseguirás fantasmas en los logs porque los eventos aparecen fuera de orden. Eso no es “divertido.” Es cómo pierdes horas.

5) HA no está “caída”, está indecisa bajo fallos parciales

HA de Proxmox depende de una visión coherente de recursos, estados de nodos y disponibilidad de almacenamiento.
Con quorum intacto pero latencia subyacente, HA puede quedarse atascada: intentando repetidamente iniciar recursos, esperando bloqueos, o rechazando acciones
porque no puede verificar el estado con seguridad. Desde fuera parece “HA rota.” Desde dentro está siendo cautelosa.

6) La GUI es lenta porque pveproxy espera algo tonto

Culpables comunes: búsquedas DNS inversas, timeouts LDAP/PAM, lecturas bloqueadas en /etc/pve,
o un camino de manejo de peticiones saturado y monohilo en algún punto.

Tareas prácticas: comandos, salidas, decisiones

Estas son las comprobaciones que realmente ejecuto cuando estoy de guardia. Cada tarea incluye qué significa la salida y qué decisión tomar.
Ejecútalas en al menos dos nodos: uno “bueno” y uno “malo.” Las diferencias son tu pista.

Task 1: Verify quorum and expected votes

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

Quorum information
------------------
Date:             Tue Feb  4 10:12:31 2026
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: Corosync ve 3 nodos, el quorum está logrado, los votos coinciden con la expectativa.
Decisión: Si esto es “Yes” pero aún tienes problemas, deja de culpar al quorum y comienza a medir latencia, pmxcfs y almacenamiento.

Task 2: Check Corosync link status and MTU mismatches

cr0x@server:~$ corosync-cfgtool -s
Printing ring status.
Local node ID 1
RING ID 0
        id      = 10.10.10.11
        status  = ring 0 active with no faults
RING ID 1
        id      = 10.10.20.11
        status  = ring 1 active with no faults

Significado: Los rings están arriba. “No faults” no significa “buena latencia.”
Decisión: Si los rings muestran fallos de forma intermitente, arregla primero problemas L2/L3 (bonding, MTU, errores del switch) antes de tocar el ajuste de Corosync.

Task 3: Read Corosync’s own complaints (they’re subtle)

cr0x@server:~$ journalctl -u corosync -S -2h --no-pager | tail -n 30
Feb 04 09:41:02 pve01 corosync[1267]:   [KNET  ] link: host: 2 link: 0 is down
Feb 04 09:41:03 pve01 corosync[1267]:   [KNET  ] host: 2 link: 0 recovered
Feb 04 09:58:19 pve01 corosync[1267]:   [TOTEM ] Token has not been received in 1800 ms
Feb 04 09:58:19 pve01 corosync[1267]:   [TOTEM ] A processor failed, forming new configuration.

Significado: Caídas cortas de enlace y retrasos de token. Puedes permanecer quorate mientras ocurren reconfiguraciones.
Decisión: Si ves advertencias de token, trátalo como un incidente real: investiga errores de red, inanición de CPU o tormentas de IRQ.

Task 4: Confirm pmxcfs is mounted and responsive

cr0x@server:~$ mount | grep /etc/pve
pve on /etc/pve type fuse.pve (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

Significado: El montaje existe. Aun así puede ser lento.
Decisión: A continuación, prueba la capacidad de lectura/escritura.

Task 5: Test whether /etc/pve operations hang

cr0x@server:~$ time ls -l /etc/pve/nodes/pve01/qemu-server | head
total 8
-rw-r----- 1 root www-data 1324 Feb  4 09:55 101.conf

real    0m0.012s
user    0m0.002s
sys     0m0.004s

Significado: Una respuesta rápida es lo normal. Si esto tarda segundos o se cuelga, pmxcfs está ahogándose.
Decisión: Si es lento/colgado en un solo nodo, sospecha presión local de recursos. Si es lento en todos los nodos, sospecha latencia de corosync o contención de pmxcfs a nivel de clúster.

Task 6: Check pmxcfs and pve services health

cr0x@server:~$ systemctl status pve-cluster pvedaemon pveproxy --no-pager
● pve-cluster.service - The Proxmox VE cluster filesystem
     Loaded: loaded (/lib/systemd/system/pve-cluster.service; enabled)
     Active: active (running) since Tue 2026-02-04 08:01:12 UTC; 2h 11min ago
   Main PID: 1123 (pmxcfs)
      Tasks: 13 (limit: 154263)
     Memory: 52.4M
        CPU: 2min 1.911s

● pvedaemon.service - Proxmox VE API Daemon
     Active: active (running)

● pveproxy.service - Proxmox VE API Proxy Server
     Active: active (running)

Significado: Los servicios están “running.” Eso no significa que sean responsivos.
Decisión: Si están “active” pero la UI cuelga, inspecciona logs y llamadas bloqueantes (tareas siguientes).

Task 7: See if pveproxy is timing out on auth/DNS

cr0x@server:~$ journalctl -u pveproxy -S -2h --no-pager | tail -n 25
Feb 04 10:01:18 pve02 pveproxy[2044]: proxy detected vanished client connection
Feb 04 10:02:41 pve02 pveproxy[2044]: authentication failure; rhost=10.10.30.50 user=admin@pam msg=timeout
Feb 04 10:02:41 pve02 pveproxy[2044]: failed login attempt; user=admin@pam

Significado: Timeouts de autenticación pueden ser lentitud en LDAP/PAM/DNS, no contraseñas erróneas.
Decisión: Si ves timeouts, prueba resolución de nombres y accesibilidad del directorio; no “reinicies servicios al azar” todavía.

Task 8: Validate time sync and drift across nodes

cr0x@server:~$ chronyc tracking
Reference ID    : 192.0.2.10
Stratum         : 3
Ref time (UTC)  : Tue Feb 04 10:11:32 2026
System time     : 0.000347812 seconds slow of NTP time
Last offset     : -0.000112345 seconds
RMS offset      : 0.000251901 seconds
Frequency       : 12.345 ppm fast
Leap status     : Normal

Significado: Un buen sincronismo muestra offsets pequeños y estado de leap “Normal”.
Decisión: Si el offset es grande o el estado de leap no es normal, arregla el tiempo ahora. No investigues comportamiento del clúster hasta que los relojes coincidan.

Task 9: Detect CPU pressure and I/O wait that starves everything

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 812344  54212 9248120    0    0     4    21  920 1800  6  2 88  4  0
 3  1      0 790112  54180 9249008    0    0   120  8020 1100 2100  9  3 44 44  0
 4  2      0 780004  54140 9249912    0    0   200  9100 1200 2400  8  4 36 52  0

Significado: Un wa alto (I/O wait) indica que el sistema está bloqueado en almacenamiento. Un b alto sugiere procesos bloqueados.
Decisión: Si wa es consistentemente alto durante el incidente, deja de perseguir configuraciones de Corosync y pasa a diagnóstico de almacenamiento.

Task 10: ZFS health and latency on a node using local ZFS

cr0x@server:~$ zpool status -x
all pools are healthy

Significado: No hay errores conocidos en el pool. Aún así no te dice la latencia.
Decisión: Si las cosas están lentas, revisa iostat y comportamiento de sync a continuación.

cr0x@server:~$ zpool iostat -v 1 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
rpool       320G   1.45T     80   1200  5.4M   98.2M
  mirror    320G   1.45T     80   1200  5.4M   98.2M
    nvme0n1    -      -      40    610  2.7M   49.1M
    nvme1n1    -      -      40    590  2.7M   49.1M

Significado: Escritos intensivos. Si esto se correlaciona con cuelgues del plano de gestión, puede que estés saturando el almacenamiento.
Decisión: Considera limitar backups/replicación y verifica escrituras sync (bases de datos, NFS sync, o ZFS mal ajustado).

Task 11: Ceph cluster state (if you run it)

cr0x@server:~$ ceph -s
  cluster:
    id:     1b2c3d4e-5555-6666-7777-88889999aaaa
    health: HEALTH_WARN
            12 slow ops, oldest one blocked for 38 sec
  services:
    mon: 3 daemons, quorum a,b,c (age 2h)
    mgr: x(active, since 2h)
    osd: 9 osds: 9 up (since 2h), 9 in (since 2h)
  data:
    pools:   6 pools, 512 pgs
    usage:   12 TiB used, 18 TiB / 30 TiB avail
    pgs:     512 active+clean

Significado: “slow ops” es Ceph diciéndote educadamente que tu almacenamiento está sufriendo.
Decisión: Trata slow ops como un incidente de producción. Pausa operaciones intensivas de I/O. Investiga latencia de OSD, red y ajustes de recuperación/backfill.

Task 12: Check for network errors on Corosync interfaces

cr0x@server:~$ ip -s link show dev bond0
3: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:aa:bb:cc brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    1234567890  987654      12      0       0       0
    TX:  bytes packets errors dropped carrier collsns
    2233445566  876543       0      0       0       0

Significado: Errores RX no nulos son una pista. Doce errores pueden ser “nada” o la punta de un iceberg—correlaciona con el tiempo.
Decisión: Si los errores aumentan durante incidentes, revisa cableado, ópticas, firmware de NIC, puertos de switch y consistencia de MTU extremo a extremo.

Task 13: Measure latency and loss between nodes (without fooling yourself)

cr0x@server:~$ mtr -r -c 50 -n 10.10.10.12
Start: 2026-02-04T10:12:01+0000
HOST: pve01                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 10.10.10.12               0.0%    50    0.4   0.6   0.3   2.1   0.3

Significado: Bueno: promedio bajo, peor caso bajo, sin pérdida.
Decisión: Si el peor caso sube a decenas/centenas de ms o aparece pérdida, Corosync puede seguir viéndose “bien” mientras el resto expira. Arregla la calidad del camino de red.

Task 14: Check for stuck tasks and why migrations/backs ups don’t finish

cr0x@server:~$ pvesh get /cluster/tasks --limit 5
[
  {
    "endtime": 0,
    "id": "UPID:pve02:0000A1B2:00C3D4E5:67A1B2C3:vzdump:105:root@pam:",
    "node": "pve02",
    "pid": 41394,
    "starttime": 1707040801,
    "status": "running",
    "type": "vzdump",
    "user": "root@pam"
  }
]

Significado: Un backup corriendo “por siempre” a menudo se correlaciona con paradas de almacenamiento o commits de snapshot que no pueden vaciarse.
Decisión: Revisa logs del nodo específico y latencia del almacenamiento subyacente. No mates la tarea a la ligera a menos que entiendas si está sosteniendo bloqueos o snapshots.

Task 15: Spot HA manager indecision

cr0x@server:~$ ha-manager status
quorum OK
master pve01 (active, Tue Feb  4 10:12:12 2026)
lrm pve01 (active, Tue Feb  4 10:12:11 2026)
lrm pve02 (active, Tue Feb  4 10:12:10 2026)
lrm pve03 (active, Tue Feb  4 10:12:09 2026)

service vm:101 (started)
service vm:102 (freeze) (request_stop)
service ct:203 (started)

Significado: “freeze” indica que HA no puede avanzar—a menudo por contención de bloqueos, indisponibilidad de almacenamiento o acciones de agente atascadas.
Decisión: Investiga el almacenamiento del recurso afectado y los bloqueos de configuración. No “forces” acciones de HA hasta saber qué espera.

Task 16: Find config lock contention (the quiet killer)

cr0x@server:~$ ls -l /var/lock/pve-manager
total 0
-rw-r----- 1 root www-data 0 Feb  4 10:08 vzdump.lock
-rw-r----- 1 root www-data 0 Feb  4 10:09 pve-storage-lock

Significado: Los locks existen durante operaciones normales, pero si persisten mucho tiempo, algo está atascado.
Decisión: Correlaciona la antigüedad del lock con la lista de tareas y el rendimiento de almacenamiento. Si un lock está obsoleto por un proceso caído, resuelve la tarea atascada de forma segura antes de eliminar locks.

Tres micro-historias corporativas desde las trincheras

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana corría un clúster Proxmox de tres nodos para servicios internos. Todo era “redundante”: NICs duales, dos switches,
RAID en los hipervisores. Estaban orgullosos. Se lo habían ganado.

Entonces, un lunes por la mañana, la GUI se congelaba de forma intermitente. Las migraciones colgaban. Backups que normalmente tomaban minutos tardaban horas.
El de guardia hizo el ritual: comprobó pvecm status. Quorate. Ningún nodo fuera. Corosync parecía limpio.
Así que supusieron que la red del clúster estaba bien y se pusieron a buscar en los logs de la UI de Proxmox.

La suposición equivocada: “Si Corosync tiene quorum, la red del clúster está sana.”
El quorum solo significaba que los nodos todavía podían intercambiar suficientes mensajes para ponerse de acuerdo sobre la membresía. No decía nada sobre la latencia de cola.

La causa real fue un puerto de switch que fallaba de una manera que no caía totalmente el enlace. Introdujo microburstes intermitentes y errores CRC.
Los enlaces knet de Corosync se recuperaban rápido, así que la membresía se mantuvo estable. Pero las escrituras de pmxcfs se retrasaban, y la API estaba continuamente esperando respuestas del sistema de archivos de clúster.

La solución fue aburrida: reemplazaron el cable y el SFP sospechoso, movieron el puerto y verificaron que los contadores de error se mantuvieran planos.
El “misterio” desapareció al instante. El postmortem añadió una línea que importaba: mide contadores de error de red y latencia, no solo el quorum.

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

Otra organización tenía una implementación Proxmox+Ceph. Querían menos advertencias de “Corosync token timeout” durante ventanas de carga intensa.
Alguien sugirió aumentar token timeout y los timeouts de consenso para que Corosync resistiera la lentitud temporal.
El cambio redujo el ruido en los logs. Todos celebraron. Por un tiempo.

Semanas después, un mantenimiento de almacenamiento disparó una recuperación de Ceph que saturó la red backend.
El clúster permaneció quorate. Ese fue el problema. Los nodos se mantuvieron como miembros mientras se volvían progresivamente no responsivos por I/O wait.
Las decisiones de HA se retrasaron. Las migraciones se acumularon. La GUI funcionaba a medias—lo suficiente para crear falsa confianza.

La “optimización” empeoró el modo de fallo al ampliar la ventana en la que todo estaba técnicamente conectado pero prácticamente inutilizable.
Los operadores esperaron más tiempo antes de declarar un incidente porque “Corosync es estable.” Mientras tanto, el impacto al negocio creció.

La solución final no fue solo revertir los timeouts. Separaron el tráfico: Corosync en una red de baja latencia y no congestionada;
recovery de Ceph ajustado para no saturar; y añadieron alertas sobre latencia de cola y slow ops en lugar de flaps de membresía.
Los token timeouts volvieron cerca de los valores por defecto. El ruido en logs aumentó; los incidentes reales disminuyeron.

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

Un entorno regulado ejecutaba Proxmox para cargas de negocio. El equipo era conservador hasta el punto de resultar molesto.
Mantenían una regla estricta: cada nodo tenía gestión fuera de banda configurada, un procedimiento documentado de “apagado seguro”,
y un simulacro trimestral donde practicaban recuperar fallos parciales sin improvisar.

Durante un evento de energía, un nodo volvió con un pool de almacenamiento degradado y errores de I/O intermitentes. El quorum de Corosync se mantuvo,
pero las operaciones de gestión se volvieron poco fiables: cambios de configuración a veces colgaban, backups se estancaban, y HA dudaba en reubicar cargas.

En lugar de entrar en pánico, siguieron el playbook: congelaron cambios, identificaron el nodo malo, evacuaron VMs que podían moverse con seguridad,
y mantuvieron el resto estable. Usaron acceso fuera de banda para confirmar errores de hardware, luego quitaron el nodo de la programación.

La práctica aburrida—pasos documentados, un orden conocido de operaciones y negarse a “simplemente hacer clic”—impidió que un problema de hardware desordenado
se convirtiera en un incidente de clúster. El negocio apenas lo notó. El equipo volvió a estar molesto por su propio proceso,
que es exactamente la vibra que quieres en trabajo de fiabilidad.

Broma #2: Si tu clúster funciona con “conocimiento tribal”, felicidades—has inventado un punto único de fallo con sentimientos.

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

1) Síntoma: Quorum es “Yes”, pero acciones de la GUI cuelgan

Causa raíz: Latencia o contención de bloqueos en pmxcfs; llamadas API bloqueadas esperando /etc/pve.
Solución: Prueba latencia de ls /etc/pve en varios nodos; revisa CPU/I/O wait; reduce carga; resuelve tareas atascadas que mantienen locks.

2) Síntoma: HA muestra “freeze” o intentos repetidos de reinicio

Causa raíz: HA no puede confirmar estado por timeouts de almacenamiento, locks o actualizaciones retrasadas del sistema de archivos de clúster.
Solución: Revisa ha-manager status, tareas y salud de almacenamiento; estabiliza el almacenamiento primero; evita forzar starts hasta que el estado sea consistente.

3) Síntoma: Las migraciones arrancan y luego se quedan atascadas en un porcentaje fijo

Causa raíz: El backend de almacenamiento no puede seguir el ritmo (Ceph slow ops, latencia NFS, presión de sync en ZFS), o el throughput de red colapsa bajo contención.
Solución: Mide latencia de almacenamiento, revisa slow ops de Ceph, revisa errores de NIC; pausa otras actividades intensivas en I/O; asegura que la red de migración no comparta tramo con almacenamiento saturado.

4) Síntoma: Logs de Corosync muestran advertencias de token pero el quorum se mantiene

Causa raíz: Picos de latencia de cola por congestión, problemas de IRQ o inanición de CPU; se dan reconfiguraciones sin pérdida total de membresía.
Solución: Trátalo como incidente de red/host; revisa ip -s link, ethtool -S, mtr y espera de CPU; arregla el camino subyacente.

5) Síntoma: “Permiso denegado” aleatorio o problemas TLS/auth tras “no cambiar nada”

Causa raíz: Deriva del tiempo entre nodos; validación de certificados violada por ventanas temporales; Kerberos/LDAP sensible al tiempo falla.
Solución: Arregla chrony/NTP, valida deriva en todos los nodos y luego prueba los flujos de autenticación. No rote certificados como primer paso.

6) Síntoma: Solo un nodo está “lento”, pero no abandona el clúster

Causa raíz: Problemas locales de hardware o kernel: errores de disco, degradación ZFS, errores de NIC, presión de memoria.
Solución: Compara métricas y logs con un nodo sano; evacua cargas; investiga hardware; no dejes que un nodo enfermo envenene el plano de control.

7) Síntoma: Todo empeora durante los backups

Causa raíz: I/O de backups satura almacenamiento o red; commits de snapshot lentos; locks mantenidos más tiempo; operaciones de gestión se acumulan.
Solución: Escalonar backups, limitar ancho de banda de backups, separar tráfico de backups y asegurar que el almacenamiento tenga margen. Los backups deben ser aburridos, no una prueba de carga.

Listas de verificación / plan paso a paso

Checklist A: Cuando el clúster “se siente lento” pero el quorum está bien

Congelar cambios. No nuevas configuraciones de almacenamiento, no ediciones de firewall, no reordenamientos de HA hasta entender el bloqueo.
Elige un nodo “malo” y uno “bueno”. Ejecuta las mismas comprobaciones; las diferencias son oro.
Confirma estabilidad de membresía: pvecm status, corosync-cfgtool -s, journal de Corosync.
Prueba la capacidad de respuesta de pmxcfs: un rápido ls en /etc/pve con temporización.
Revisa locks y tareas atascadas: pvesh get /cluster/tasks, inspecciona archivos de lock.
Mide presión del host: vmstat, carga, I/O wait, presión de memoria.
Mide calidad de la red: contadores de errores + mtr entre nodos en el ring de Corosync.
Mide salud del almacenamiento: ZFS iostat/status o slow ops de Ceph.
Solo entonces considera ajustes. Ajustar sin medir es cómo construyes un desastre “estable” pero lento.

Checklist B: Estabilizar primero, luego recuperar funcionalidad

Detén los multiplicadores de carga: pausa migraciones, pospone backups, limita recuperación/backfill si estás en Ceph (con cuidado).
Aísla el nodo enfermo: si un nodo tiene errores/latencia, migra lo que puedas y quítalo de decisiones HA hasta arreglarlo.
Verifica sincronización de tiempo: asegúrate de que los relojes coincidan antes de interpretar logs y eventos de fencing.
Restaura la red a la línea base: elimina pérdida de paquetes, errores CRC, desajustes de MTU y enlaces congestionados.
Restaura el almacenamiento a la línea base: limpia errores de disco, repara pools degradados, aborda slow ops y asegura espacio libre suficiente.
Vuelve a habilitar operaciones gradualmente: migraciones/backups de una en una, observa latencia y logs.

Checklist C: Endurecimiento para que esto no vuelva a pasar

Separa clases de tráfico: Corosync en enlaces de baja latencia; almacenamiento en su propia red; migraciones separadas si es posible.
Alerta sobre latencia de cola, no solo “arriba/abajo”. Las alarmas de quorum son necesarias pero insuficientes.
Planifica capacidad para backups y recuperación. Si tu clúster no puede manejar un evento de recuperación más la carga normal, no es resiliente.
Prueba simulacros de fallo. Practica “un nodo lento”, “un enlace oscilante”, “slow ops de almacenamiento.” Los incidentes reales no deberían ser tu primer ensayo.

Preguntas frecuentes

1) ¿Por qué `pvecm status` muestra “Quorate: Yes” cuando la GUI es inutilizable?

Porque el quorum trata sobre membresía y votación, no sobre capacidad de respuesta. La GUI depende de pmxcfs y demonios API que pueden bloquearse por I/O, locks, DNS o latencia de almacenamiento.

2) Si Corosync no muestra fallos, ¿puede la red seguir siendo el problema?

Sí. Picos cortos, microburstes, errores CRC y jitter pueden arruinar la latencia de cola sin perder la membresía. Revisa contadores y mtr, no solo el estado del ring.

3) ¿Debo aumentar el token timeout de Corosync para dejar de hacer flapping?

Solo después de probar que la red y la planificación del host son estables y aún así lo necesitas. Aumentar timeouts puede ocultar problemas reales de latencia y retrasar la detección de fallos.

4) ¿Cuál es la forma más rápida de saber si pmxcfs es el cuello de botella?

Cronometra un simple ls en /etc/pve en varios nodos. Si es lento o se cuelga, pmxcfs está involucrado. Luego revisa CPU e I/O wait.

5) ¿De verdad los problemas de almacenamiento pueden afectar a Corosync y la gestión del clúster?

Absolutamente. Las paradas de almacenamiento generan I/O wait, que retrasa procesos y planificación. Corosync puede seguir intercambiando suficientes mensajes, pero pmxcfs y llamadas API sufrirán.

6) ¿Cómo rompe la deriva del tiempo un clúster Proxmox si el quorum está bien?

La deriva puede romper TLS/auth, confundir logs y provocar decisiones inconsistentes en workflows de HA o fencing. Arregla la sincronización de tiempo antes de profundizar en el diagnóstico.

7) ¿Por qué las migraciones se cuelgan más a menudo que el “runtime normal” de una VM durante incidentes?

Las migraciones amplifican requisitos de ancho de banda y almacenamiento y son sensibles a la latencia. Una VM puede seguir funcionando con cachés y reintentos; una migración es un bucle estricto que expira.

8) ¿Qué debo hacer si un nodo está lento pero sigue siendo parte del clúster?

Trátalo como una falla parcial: evacua cargas donde sea seguro, reduce lo que depende de ese nodo e investiga hardware/red/almacenamiento en ese host específicamente.

9) ¿Es seguro reiniciar corosync o pmxcfs durante un incidente?

A veces, pero no es una primera medida. Reiniciar puede causar cambios de membresía y churn de locks. Estabiliza red/almacenamiento primero, luego reinicia con un objetivo claro.

10) ¿Cuál es la mejor “métrica única” para alertar sobre estos problemas?

No existe una. Combina: capacidad de respuesta de pmxcfs (chequeos sintéticos), pérdida/jitter de red, latencia de almacenamiento/slow ops y I/O wait del host. El quorum por sí solo es una métrica reconfortante.

Próximos pasos que puedes hacer esta semana

Si ejecutas Proxmox en producción, aquí está el camino práctico que realmente cambia resultados:

Añade una comprobación sintética de pmxcfs: mide y alerta si ls /etc/pve supera un umbral pequeño en cualquier nodo.
Alerta sobre errores de red en las interfaces de Corosync: errores CRC, drops, flaps de enlace. Esto detecta degradaciones “quorum está bien” temprano.
Alerta sobre latencia de almacenamiento: anomalías de iostat en ZFS, slow ops de Ceph, retransmisiones cliente NFS. El almacenamiento es la mayoría silenciosa de estos incidentes.
Mantén timeouts de Corosync sensatos: no uses ajuste como vendaje para una red mala. Si debes ajustar, documenta por qué y qué medición lo justificó.
Haz un simulacro de fallo: simula una red de almacenamiento congestionada o un enlace oscilante y practica “estabilizar primero.” Tu yo futuro lo agradecerá y estará un poco menos cansado.

Corosync no te está mintiendo. Solo responde a una pregunta más pequeña que la que estás haciendo.
Si quieres un clúster que sobreviva, mide todo el organismo—calidad de red, latencia de almacenamiento, capacidad de respuesta del plano de control—y trata “quorum: yes” como el inicio del diagnóstico, no como el final.