Hay un número escrito en tus servidores que nadie ha decidido y que crece cada vez que amplías el clúster. No está en la factura, no sale en el panel y no lo comprueba ningún inventario: es el tiempo que tarda Proxmox en darse cuenta de que uno de sus nodos ha muerto. Con los valores de fábrica, ese tiempo sube 650 milisegundos por cada nodo que añades. Proxmox lo corrigió en la versión 9.2, pero el arreglo solo entra en los clústeres que se crean de cero. Si has actualizado el tuyo de la 8 a la 9 estas semanas, sigues con el reloj viejo.
Este post es la continuación declarada de otro. Hace unas semanas escribimos que la alta disponibilidad de Proxmox no evita la caída, la acorta, con el techo que publica la propia documentación: unos dos minutos de detección y conmutación, y de ahí el límite de 99,999 % que el fabricante se pone a sí mismo por escrito. Aquello iba de lo que compras al activar la HA. Esto va de lo que pasa antes de esos dos minutos, en el trozo que casi nadie mira, y de un ajuste nuevo que tu clúster probablemente no ha recibido.
Antes de mover nada, el clúster tiene que ponerse de acuerdo
Cuando un nodo se apaga, lo primero que ocurre no tiene nada que ver con las máquinas virtuales. Los nodos que quedan tienen que rehacer la lista de quién sigue vivo, y de eso se encarga corosync con dos temporizadores. El token es lo que un nodo espera el testigo antes de darlo por perdido: 3.000 milisegundos por defecto. El consensus es lo que esperan después para acordar la nueva membresía; si no lo tocas, se calcula solo a 1,2 × token.
El detalle que cambia el resultado es que esos 3.000 milisegundos no son el valor que se usa. En cuanto el fichero de configuración tiene una lista de nodos con tres o más miembros —o sea, en cualquier clúster real—, corosync calcula el tiempo de verdad así: token + (número de nodos − 2) × token_coefficient. Y ese coeficiente vale 650 milisegundos de fábrica. La documentación explica el porqué sin rodeos: sirve para que «el clúster escale sin tener que cambiar el token a mano cada vez que se añade un nodo». Es una decisión razonable —un clúster grande necesita más margen— con una consecuencia que casi nadie ha calculado.
La suma de los dos temporizadores es, en palabras de la documentación de Proxmox, «the minimum time needed to reestablish a new cluster membership after a node goes offline». Es decir: el suelo de tu conmutación, lo que pasa antes de que el gestor de HA levante un dedo. Con la fórmula y los valores de fábrica, la cuenta sale sola:
La cuenta es nuestra; la fórmula y los valores por defecto son de la documentación oficial de corosync. La comprobación de que la fórmula es la que creemos la da el propio manual de Proxmox, que como ejemplo publica token 4.950 y consensus 5.940 —«10,89 segundos»—, exactamente la fila de cinco nodos. Son temporizadores configurados, no tiempos medidos en tu sala.
No hace falta creerse la tabla. Estos son tus dos números reales, en milisegundos, ahora mismo:
corosync-cmapctl | grep -Ew 'runtime.config.totem.token|runtime.config.totem.consensus'
La carrera: 45 segundos contra 60
Ese número creciente sería una curiosidad si no compitiera con otro que no crece. Proxmox aísla los nodos perdidos por self-fencing: un nodo que se queda sin quórum no puede rearmar su temporizador de guarda y se reinicia solo «after the watchdog has timed out (this happens after 60 seconds)». Ese 60 es fijo. El otro, el de ponerse de acuerdo, sube con cada servidor que compras.
La documentación de Proxmox pone la carrera por escrito. Mantener la suma de token y consensus por debajo de 45 segundos es «especially important» con HA activa, «to ensure that a new cluster membership is formed before the watchdog timeout of 60 seconds expires, which would trigger a node fence». Y pide margen por debajo de esos 45 «so that transient timing variations do not push the cluster past the watchdog threshold». Su escala es explícita: bajar el coeficiente es sugerido por encima de 30 segundos, recomendado por encima de 40 y fuertemente recomendado por encima de 45.
Mira otra vez la última fila de la tabla. Un clúster de 29 nodos con los valores de fábrica da 45,21 segundos: ha cruzado el umbral que la propia documentación marca como «fuertemente recomendado» corregir, y lo ha hecho sin que nadie tocara un fichero, simplemente creciendo. A partir de ahí, un corte de red de unos segundos puede acabar reiniciando nodos que estaban sanos, con sus máquinas funcionando y su almacenamiento accesible. No falló el hierro: el reloj de ponerse de acuerdo llegó tarde al reloj de darse por muerto.
El arreglo de la 9.2 solo llega a los clústeres nuevos
Proxmox ha visto el problema y lo ha corregido. La documentación lo dice en literal: «Since Proxmox VE 9.2, new clusters are created with a lower token coefficient of 125 milliseconds explicitly set in /etc/pve/corosync.conf». El efecto es grande y se mide: con 125 en lugar de 650, el clúster de 29 nodos de la última fila pasa de 45,21 a 14,03 segundos. Tres veces más rápido, y con el watchdog de 60 a una distancia cómoda.
Ahora lee esa frase otra vez, despacio: new clusters are created. El coeficiente se escribe en el fichero al crear el clúster. Si el tuyo lleva años funcionando y lo has actualizado de la rama 8 a la 9 —algo que mucha gente está haciendo justo ahora, porque Proxmox VE 8 llega a fin de soporte este mes—, tu corosync.conf es el que ya tenías: sin coeficiente explícito y, por tanto, con los 650 de siempre. La propia documentación lo confirma por el otro lado, cuando explica cómo bajarlo: hay que añadir la línea a mano. Actualizar no te lo ha dado, y la documentación no menciona ningún aviso que te lo cuente.
Cuándo NO tocar nada
Este post se puede leer como «corre a cambiar el coeficiente». No lo hagas. Si tienes entre tres y ocho nodos, tu suma va de 8 segundos a algo más de 15, muy lejos de los 45, y el valor de fábrica no es tu problema. Tocar corosync.conf por moda significa meter la mano en el único fichero capaz de partirte el clúster en dos mitades que no se hablan, con las máquinas encendidas. Se cambia cuando la cuenta lo pide, siguiendo el procedimiento de la documentación y con una ventana acordada.
Lo que sí conviene hacer hoy, tengas el tamaño que tengas, es la parte barata: ejecutar ese corosync-cmapctl, apuntar los dos números en la documentación del clúster y saber en qué punto de la tabla estás. Cuesta dos minutos y te dice si tienes deberes o no. Además, la documentación es clara en que el margen no se compra solo bajando el coeficiente: exige una red de clúster que aguante, y bajar los tiempos en una red con latencia irregular empeora las cosas en vez de arreglarlas.
El otro reloj que sigue corriendo: el almacenamiento
Si el almacenamiento es Ceph, hay dos temporizadores más y van a otra escala. Un OSD se declara caído cuando deja de dar señales durante osd_heartbeat_grace, 20 segundos por defecto —con el matiz de que el monitor quiere que lo reporten varios OSD de máquinas distintas antes de marcarlo—. Pero caído no equivale a fuera: para marcarlo out y empezar a rehacer las réplicas que faltan, Ceph espera mon_osd_down_out_interval, y ahí son 10 minutos.
Esos diez minutos son deliberados y son buenos: evitan que un reinicio de mantenimiento dispare el movimiento de terabytes por toda la red. Conviene saber que existen porque marcan el momento exacto en que un simulacro deja de ser gratis. Si el nodo vuelve en cinco minutos, no ha pasado nada; si tardas doce en levantarlo, el clúster ya ha empezado a rebalancear y te has llevado una tarde de tráfico de recuperación de regalo. Hay un tercer valor que casi nadie mira y que importa antes de apagar un rack entero: mon_osd_down_out_subtree_limit, por defecto rack, es la unidad más pequeña del mapa CRUSH que Ceph no sacará automáticamente. Un nodo entero sí; un rack entero, no.
Con una condición previa que ya contamos aquí y que vuelve a aparecer: para que ese rebalanceo termine, tiene que caber. Si el clúster va justo de espacio, lo que verás no es una recuperación sino un atasco, y lo desarrollamos en el post sobre por qué en Ceph la capacidad la marca el disco más lleno.
Todo esto solo se sabe apagando algo a propósito
Los números de arriba son el suelo teórico. El número real de tu empresa sale de una sola manera, y tiene nombre desde hace años: «Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system's capability to withstand turbulent conditions in production». Experimentar, confianza, producción. Ni auditar, ni documentar, ni laboratorio.
El método que proponen tiene cuatro pasos y el primero es el que todo el mundo se salta: definir el «steady state», una medida observable que diga que el sistema va bien. Después se formula la hipótesis de que ese estado aguantará, se introduce el evento real —«servers that crash, hard drives that malfunction, network connections that are severed»— y se intenta refutar la hipótesis. Así lo aterrizamos nosotros para una empresa de treinta personas:
- 1.La hipótesis se escribe antes. «Al apagar el nodo 3, el pedido que se está tramitando se completa y el ERP vuelve a responder en menos de X minutos.» Con un número dentro, y firmada por quien lo sostiene.
- 2.Los valores de fábrica, apuntados antes de tocar nada: token y consensus reales, si el watchdog es de hardware o softdog, y los umbrales de Ceph. Media hora que te ahorra discutir después sobre lo que pasó.
- 3.Radio de explosión mínimo. Un nodo, y el que menos servicios críticos tenga. La primera vez se aprende lo mismo y se rompe menos.
- 4.Martes por la mañana. Con la gente que sabe arreglarlo despierta y sin prisa por irse. Un simulacro un viernes a las siete de la tarde es un incidente disfrazado.
- 5.El reloj lo para un usuario, no un panel verde. Y el número se apunta aunque sea feo: el número feo de hoy es el objetivo del trimestre que viene.
Nuestro último simulacro de recuperación completa se cerró en 14 minutos. Lo damos como dato interno y como prueba de que se puede medir, no como promesa contractual: el número de cada empresa depende de su arquitectura, de su aplicación y de cuántas veces lo haya ensayado. El nuestro tampoco fue así el primer día.
Lo que se compra de verdad
El fallo es inevitable: una fuente se muere, un disco se va, alguien tropieza con un cable. Que eso se convierta en avería —que la empresa deje de funcionar— es una decisión de diseño, y parte de esa decisión son unos cuantos números que ya están escritos en tus servidores, puestos por defecto por gente que no conocía tu clúster. Saber cuáles son cuesta una mañana; no saberlos cuesta lo que cuesta un día parado.
En everyWAN operamos Proxmox VE con Ceph en producción repartido en varios centros de datos, y hacemos simulacros de recuperación cronometrados. Por eso miramos estos temporizadores antes de firmar un número de continuidad con nadie: es lo que hay detrás de infraestructura y cloud y de cumplimiento y continuidad, y no una casilla de alta disponibilidad marcada en una propuesta. Cuando el reloj empieza a correr de verdad, lo que ayuda es tener un equipo mirando.
Fuentes (verificadas una a una): valores por defecto de token (3.000 ms) y token_coefficient (650 ms), la condición de que la fórmula solo se aplica con una lista de al menos tres nodos, la fórmula token + (nodos − 2) × token_coefficient y el cálculo automático de consensus a 1,2 × token — corosync.conf(5); coeficiente de 125 ms en clústeres creados desde Proxmox VE 9.2, el umbral de 45 segundos frente al watchdog de 60, la escala 30/40/45, el ejemplo de 4.950 / 5.940 ms y el comando de comprobación — Proxmox VE: Cluster Manager; el self-fencing por watchdog a los 60 segundos — Proxmox VE: High Availability; osd_heartbeat_grace (20 s), mon_osd_down_out_interval (10 min) y mon_osd_down_out_subtree_limit (rack) — Ceph: Monitor/OSD Interaction; definición de chaos engineering y los cuatro pasos del método experimental — Principles of Chaos Engineering. Documentación consultada el 28 de agosto de 2026. La tabla de nodos frente a token+consensus es un cálculo nuestro a partir de la fórmula oficial y de los valores por defecto, contrastado con el ejemplo de cinco nodos que publica la propia documentación de Proxmox; son temporizadores configurados, no tiempos medidos en tu clúster. El simulacro de 14 minutos es un dato interno de everyWAN, no un compromiso de servicio.
¿Sabes qué valor tiene el token de tu clúster?
Miramos tus temporizadores, hacemos la cuenta con tu número de nodos y, si toca, preparamos el simulacro contigo: hipótesis escrita, un solo nodo y cronómetro. Sin humo y con la documentación delante.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN