Un cluster Proxmox VE de 31 nodos que conserve el token_coefficient histórico de Corosync puede tener configurados aproximadamente 48,07 segundos entre token y consensus para restablecer una nueva membresía después de perder un nodo. Sigue estando por debajo del watchdog de 60 segundos de Proxmox HA, pero supera el umbral de 45 segundos a partir del cual la propia documentación de Proxmox recomienda con especial énfasis reducir estos temporizadores.
Las claves de Corosync en un cluster Proxmox de 31 nodos en 30 segundos
- Con el coeficiente tradicional de 650 ms, 31 nodos elevan el
tokenefectivo hasta unos 21,85 segundos. - El
consensusautomático alcanza aproximadamente 26,22 segundos, dejando la suma en 48,07 segundos. - Proxmox considera especialmente importante permanecer por debajo de 45 segundos cuando HA está activa.
- Los nuevos clusters de Proxmox VE 9.2 utilizan un coeficiente de 125 ms, que reduce la misma suma a unos 14,58 segundos.
- Una actualización desde versiones anteriores no debe darse por equivalente a crear de nuevo el cluster.
El ejemplo de 31 nodos resulta además bastante realista para una infraestructura Proxmox de cierto tamaño. No entra todavía en el terreno de clusters extraordinariamente grandes y queda justo por debajo de otro límite interesante de Corosync: su documentación señala que send_join normalmente no es necesario en configuraciones de menos de 32 nodos.
Por tanto, 31 servidores permiten observar con claridad un problema que puede aparecer simplemente como consecuencia del crecimiento de un cluster: los temporizadores que parecían irrelevantes cuando había cinco o diez hosts terminan acercándose a los mecanismos de fencing de Proxmox cuando el número de miembros aumenta.
De 3 segundos de base a un token efectivo de 21,85 segundos
Corosync utiliza un protocolo de paso de token para coordinar los miembros del cluster. El parámetro token establece cuánto tiempo puede transcurrir sin recibirlo antes de considerarlo perdido.
El valor base actual documentado por Corosync es de 3.000 milisegundos. Cuando existe una lista de al menos tres nodos, entra en juego token_coefficient.
Si ese coeficiente no se configura explícitamente, Corosync utiliza históricamente 650 milisegundos y calcula el token efectivo así:
token = 3.000 + (número de nodos − 2) × token_coefficient
La finalidad del mecanismo es que el cluster pueda crecer sin que el administrador tenga que modificar manualmente el token cada vez que incorpora un servidor.
En un cluster de 31 nodos:
3.000 + (31 − 2) × 650
Los 29 miembros adicionales respecto a los dos primeros aportan:
29 × 650 = 18.850 ms
El resultado es:
3.000 + 18.850 = 21.850 ms
Es decir, un token efectivo de 21,85 segundos.
Corosync calcula además el consensus a partir del token cuando no se establece manualmente. La documentación fija como mínimo 1,2 veces el token, y utiliza automáticamente esa relación cuando el administrador no define otro valor.
Para 31 nodos:
21.850 × 1,2 = 26.220 ms
Al sumar ambos temporizadores:
21.850 + 26.220 = 48.070 ms
El total queda por tanto en 48,07 segundos.
| Parámetro | Cluster de 31 nodos con 650 ms |
|---|---|
| Token base | 3.000 ms |
| Incremento por tamaño | 18.850 ms |
| Token efectivo | 21.850 ms |
| Consensus | 26.220 ms |
| Token + consensus | 48,07 s |
La precisión del término es importante. Esos 48,07 segundos no son el tiempo de recuperación de una máquina virtual.
Proxmox define la suma de token y consensus como el tiempo mínimo configurado necesario para restablecer una nueva membresía después de que un nodo quede fuera. Después todavía entran en juego HA Manager, fencing, almacenamiento, selección del host destino, arranque de la VM y recuperación de la propia aplicación.
48 segundos frente a un watchdog de 60
El dato empieza a resultar preocupante al compararlo con el funcionamiento de Proxmox HA.
Un nodo que pierde quorum y tiene servicios HA activos deja de poder mantener correctamente su watchdog. Si la situación persiste, Proxmox documenta que el watchdog provoca un reinicio tras 60 segundos para garantizar el self-fencing del servidor.
Con una suma teórica de 48,07 segundos quedan aproximadamente:
60 − 48,07 = 11,93 segundos
de margen respecto al timeout documentado.
Proxmox no espera a llegar a 60 segundos para recomendar actuar. Su documentación actual establece tres referencias para token + consensus:
| Suma de temporizadores | Recomendación de Proxmox |
|---|---|
| Más de 30 s | Reducir el coeficiente es una optimización sugerida |
| Más de 40 s | Reducción recomendada |
| Más de 45 s | Reducción fuertemente recomendada |
Con 48,07 segundos, un cluster de 31 nodos con los valores históricos ya está en la última categoría.
La razón no es que 48 segundos sean automáticamente incompatibles con los 60 del watchdog. Todavía existe margen.
El problema es que una infraestructura real no funciona con los tiempos perfectos de una hoja de cálculo. Puede haber jitter, pérdida de paquetes, congestión momentánea, retrasos de scheduling o una incidencia de red que afecte simultáneamente a varios enlaces.
Proxmox recomienda precisamente conservar margen por debajo de los 45 segundos para evitar que pequeñas variaciones temporales acerquen la formación de la nueva membresía al límite de fencing.
Proxmox VE 9.2 cambia mucho la cuenta
Los nuevos clusters creados desde Proxmox VE 9.2 configuran explícitamente un token_coefficient de 125 milisegundos.
Con los mismos 31 servidores:
3.000 + 29 × 125 = 6.625 ms
El consensus queda en:
6.625 × 1,2 = 7.950 ms
Y la suma:
6.625 + 7.950 = 14.575 ms
Es decir, aproximadamente 14,58 segundos.
La comparación muestra hasta qué punto aumenta el efecto del coeficiente conforme crece el cluster:
| Configuración | Token | Consensus | Total |
|---|---|---|---|
| 31 nodos, coeficiente 650 ms | 21,85 s | 26,22 s | 48,07 s |
| 31 nodos, coeficiente 125 ms | 6,63 s | 7,95 s | 14,58 s |
La diferencia es de unos 33,50 segundos en esta parte concreta del proceso.
Eso no significa que el tiempo completo de failover vaya a reducirse exactamente en 33,5 segundos. HA tiene más etapas y Proxmox habla de tiempos típicos de detección y conmutación cercanos a los dos minutos para el conjunto del proceso.
Sí significa que Corosync dispone de bastante más margen frente al watchdog y puede reconstruir antes la membresía en condiciones adecuadas.
El detalle importante para clusters actualizados
La documentación de Proxmox utiliza una formulación muy concreta: desde Proxmox VE 9.2 los clusters nuevos se crean con token_coefficient: 125 dentro de /etc/pve/corosync.conf.
Por tanto, no conviene suponer que un cluster que nació años atrás y acaba de actualizarse a una versión reciente tenga automáticamente ese parámetro.
Antes de modificar nada, Proxmox propone consultar los valores efectivos de Corosync:
corosync-cmapctl | grep -Ew 'runtime.config.totem.token|runtime.config.totem.consensus'Lenguaje del código: JavaScript (javascript)En el escenario de 31 nodos con el comportamiento histórico, los valores calculados serían próximos a:
runtime.config.totem.token = 21850
runtime.config.totem.consensus = 26220Si el coeficiente efectivo es de 125 ms, deberían aproximarse a:
runtime.config.totem.token = 6625
runtime.config.totem.consensus = 7950Lo adecuado es utilizar siempre los valores obtenidos del propio cluster y no inferirlos únicamente a partir de la versión instalada.
Tampoco debería interpretarse este análisis como una recomendación de editar inmediatamente corosync.conf.
La documentación de Proxmox indica que antes de reducir el coeficiente deben cumplirse los requisitos de red, especialmente en materia de latencia. Corosync también advierte de que los temporizadores deben mantenerse coherentes en todos los nodos y que una configuración incorrecta puede generar comportamientos impredecibles.
En una plataforma de 31 hosts habría que revisar latencia entre miembros, pérdida de paquetes, redundancia de caminos, interfaces dedicadas o correctamente aisladas, switching y posibles situaciones de congestión antes de endurecer los tiempos.
Hay además una peculiaridad favorable en este ejemplo: 31 nodos siguen estando por debajo del límite de 32 a partir del cual la documentación de Corosync empieza a considerar necesario prestar atención a send_join para evitar una avalancha de mensajes durante la formación de un nuevo anillo.
Por eso 31 nodos representan un escenario bastante interesante. El cluster todavía no entra en algunas consideraciones adicionales asociadas a anillos mayores, pero los temporizadores históricos ya han superado claramente el nivel de 45 segundos que Proxmox recomienda revisar.
Y queda otra cuestión que ningún ajuste de Corosync puede solucionar: la capacidad del cluster después del fallo.
Si los otros 30 nodos están cerca de su límite de CPU o RAM, conseguir que Corosync reconstruya la membresía en 14 segundos en vez de 48 no hará aparecer los recursos necesarios para recuperar las máquinas.
Lo mismo sucede con el almacenamiento y la red.
Un cluster de 31 nodos con HA debe dimensionarse también para que la pérdida de un host pueda absorberse sin saturar los restantes, que el almacenamiento siga disponible y que el switching no introduzca otro punto único de fallo.
Los temporizadores son una pieza del diseño, pero una bastante fácil de comprobar. En un cluster que haya ido creciendo con los años, ejecutar un comando y encontrar 48 segundos donde se esperaban unos pocos segundos puede ser una buena razón para revisar qué otros valores heredados continúan funcionando con criterios establecidos cuando la infraestructura era mucho más pequeña.
Preguntas frecuentes
¿Cuánto suman token y consensus en un cluster Proxmox de 31 nodos?
Con token base de 3.000 ms y el coeficiente histórico de 650 ms, el cálculo da aproximadamente 48,07 segundos. Es un tiempo configurado de Corosync para restablecer la membresía, no el tiempo completo de recuperación de una VM.
¿Cuánto baja con el coeficiente de 125 ms de Proxmox VE 9.2?
Para 31 nodos, el token queda en unos 6,63 segundos y el consensus en 7,95 segundos. La suma se reduce a aproximadamente 14,58 segundos.
¿48 segundos son peligrosos si el watchdog está en 60 segundos?
No implican automáticamente un fallo, pero superan el nivel de 45 segundos a partir del cual Proxmox recomienda fuertemente bajar el coeficiente. El fabricante aconseja dejar margen suficiente frente al watchdog para absorber variaciones temporales.
¿Actualizar a Proxmox VE 9.2 cambia automáticamente un cluster antiguo a 125 ms?
No debe darse por supuesto. La documentación especifica el valor de 125 ms para clusters nuevos. En instalaciones existentes conviene comprobar los valores efectivos antes de decidir cualquier modificación.
