Si me pilla un problema de cluster en Proxmox y necesito una respuesta rápida a la pregunta importante, suelo ir a una frase muy concreta.
¿Hay quorum o no lo hay?
Todo lo demás viene después.
Por eso corosync-quorumtool -s me gusta tanto. No tiene el barniz cómodo de pvecm status. No intenta ser amable. Te suelta la información bastante en seco y se acabó.
Y, sinceramente, a ciertas horas eso me parece perfecto.
El comando es este.
| |
Cuando Corosync empieza a oler raro, yo quiero saber tres cosas cuanto antes.
- cuántos nodos siguen contando de verdad
- cuántos votos esperaba el cluster
- si con lo que queda sigue habiendo quorum
Esta herramienta me responde justo eso con muy poca ceremonia.
por qué lo sigo usando si ya existe pvecm status#
Porque me gusta ver la fuente seca.
pvecm status me encanta y lo sigo usando muchísimo. De hecho ya le dediqué un post entero porque para una lectura general del estado del cluster sigue siendo de lo mejor que hay. Pero corosync-quorumtool -s me parece útil por otra razón. Me baja un nivel y me deja delante la lectura de votequorum con menos capa alrededor.
No es necesariamente mejor. Es más desnudo.
Y hay momentos en los que quiero justo eso.
Si el panel va raro, si un nodo acaba de caer, si estoy mirando un mantenimiento o si sospecho que me estoy contando una película amable, esta salida me obliga a centrarme en lo importante sin adornos.
la captura real que quería para este post#
La salida que ves aquí sale de un nodo real de mi laboratorio, saneada en los nombres para no regalar detalles internos.
Y me parece una captura muy buena porque no sale el caso bonito de tres nodos vivos y todos felices.
Sale algo más real. Un cluster con tres votos esperados, dos nodos presentes y quorum todavía válido.
Eso, por sí solo, ya enseña una lección importante. Perder un nodo no significa automáticamente perder el cluster. Depende de cuántos votos quedan y de qué quorum exige la configuración.
lo primero que leo siempre#
Quorate: Yes#
Voy directo ahí. Sin glamour y sin vergüenza.
Si pone Yes, respiro un poco. No cierro el diagnóstico, pero ya sé que el cluster no está fuera de juego por falta de mayoría.
Si pusiera No, la prioridad cambia al instante. A partir de ahí ya no estoy revisando una molestia o un susto visual. Estoy mirando un problema serio que afecta a la capacidad del cluster para operar con normalidad.
Me gusta mucho empezar por esa línea porque me quita el ruido emocional. Hay mil cosas que pueden verse feas en Proxmox. La pregunta de quorum sigue siendo brutalmente simple. ¿Sigue habiendo mayoría funcional o no?
Nodes, Expected votes, Total votes y Quorum#
Estas cuatro líneas se leen juntas. Separarlas me parece mala idea.
| |
Aquí está el centro de la historia.
En este ejemplo, el cluster esperaba tres votos. Ahora mismo solo tiene dos presentes. ¿Es suficiente? Sí, porque el umbral de quorum es dos y esos dos siguen dentro.
Esto parece básico, pero es justo donde veo errores bastante a menudo. Gente que ve que falta un nodo y ya habla como si el cluster estuviera muerto. O al revés. Gente que ve dos nodos y se relaja sin mirar si el quorum exigido era mayor.
Yo intento no caer ni en una cosa ni en la otra.
La regla práctica para mí es esta. No interpretes Nodes solo. Léele al lado qué votos esperaba el cluster, cuántos suma ahora y qué quorum necesita. Sin esa combinación, la lectura cojea.
Node ID y por qué no lo ignoro#
| |
Esta línea parece secundaria, pero no lo es.
Me recuerda desde qué perspectiva estoy leyendo la salida. Igual que en otros comandos de cluster, la perspectiva importa. No estoy mirando un oráculo neutral fuera del sistema. Estoy mirando lo que ve un nodo concreto.
Cuando todo va bien, esto importa poco. Cuando algo va mal, importa bastante.
Si el nodo local es el que está aislado, si está viendo una membresía parcial o si sospecho un problema de red asimétrico, saber desde qué Node ID estoy leyendo ayuda a no mezclar puntos de vista.
Por eso me gusta cruzarlo con el post de grep -nE "nodeid|ring0_addr|name:" /etc/pve/corosync.conf en Proxmox: cómo reviso el cableado lógico del cluster antes de tocar Corosync. Ese grep me dice rápidamente qué nombre y qué IP de cluster corresponden a cada nodeid. Y así, cuando corosync-quorumtool me habla en números, yo ya sé a quién le está poniendo cara.
el valor real del Ring ID#
| |
No es la primera línea que miro, pero tampoco la trato como decoración.
El Ring ID me interesa sobre todo cuando comparo salidas entre nodos o cuando quiero saber si ha habido cambios de membresía y reconfiguración del anillo. No suelo diagnosticar una avería solo con este campo porque sería pasarse de listo, pero sí lo uso como pista de contexto.
Si el ring cambia en mitad de una incidencia o si dos nodos no parecen estar leyendo la misma película, esta línea puede ayudarte a confirmar que la composición del cluster se ha movido.
No la convertiría en protagonista de un diagnóstico rápido, pero tampoco la ignoraría. Está ahí por algo.
la tabla de miembros es donde aterriza todo#
| |
Aquí ya no estás leyendo abstracciones. Ya estás viendo qué miembros siguen dentro desde la perspectiva del nodo local.
Y esto me encanta.
Si esperaba tres miembros y solo veo dos, no necesito adornar nada. El tercero está fuera de esta membresía. Eso no me explica todavía por qué cayó, pero ya me dice que el cluster actual se está sosteniendo con los que ves aquí y no con una promesa imaginaria de que el ausente “igual sigue medio dentro”.
También me gusta porque une dos mundos. El de los IDs y el de los nombres. Cuando leo Nodeid 6, ya no es un número suelto. Es un nodo concreto. Y eso vuelve mucho más llevadera la lectura de logs y correlaciones posteriores.
algo que me parece importante decir claro#
Quorum no significa salud perfecta.
Lo repito porque es de las trampas favoritas del cerebro. Ves Quorate: Yes y ya te relajas como si el cluster estuviera impecable. No. Significa algo mucho más concreto. Significa que, con los votos presentes ahora mismo, el cluster conserva mayoría suficiente para seguir operando.
Eso está muy bien. Pero puedes seguir teniendo un nodo caído, una red de cluster con ruido, reinicios de Corosync, latencia fea o servicios a medias.
Quorum no es la bendición divina. Es una condición mínima importantísima. Nada más y nada menos.
dónde me parece especialmente útil este comando#
antes de reiniciar un nodo por mantenimiento#
Esta es de las más obvias. Si voy a tocar un nodo, quiero saber con una lectura seca cuántos votos hay en juego y si el cluster aguanta la jugada sin perder quorum.
cuando un nodo desaparece y no quiero dramatizar antes de tiempo#
Aquí me gusta muchísimo. En vez de imaginar si ya he roto media casa, pregunto lo simple. ¿Qué votos quedan y sigue habiendo quorum?
cuando la web de Proxmox va lenta o rara#
Hay veces que el panel te hace dudar de todo. En esos momentos, una salida de texto sin maquillaje sienta fenomenal.
cuando quiero confirmar membresía real sin pasar todavía por los logs#
Si todavía no estoy en fase de journalctl, este comando me orienta muy bien.
con qué lo cruzo casi siempre#
Yo rara vez dejo el diagnóstico en corosync-quorumtool -s y me voy tan feliz. Lo normal es encadenarlo con otras piezas.
pvecm status#
Sigue siendo la vista general que más uso. Si corosync-quorumtool me da la lectura seca, pvecm status me da una visión de conjunto muy cómoda para seguir.
corosync-cfgtool -s#
Si sospecho problemas de enlace reales, aquí es donde quiero ver si los links del cluster siguen vivos de verdad. Ya publiqué otro post sobre eso y me parece la pareja natural cuando el problema deja de ser solo de mayoría y empieza a oler a red.
journalctl -u corosync -n 40 --no-pager#
Cuando ya necesito causa y no solo estado, me voy al journal. Ahí es donde salen KNET, pérdidas de enlace, cambios de membresía y mensajes que explican por qué la tabla de quorum terminó como terminó.
cat /etc/pve/.members#
Me gusta cruzarlo porque une la membresía de Corosync con la vista que está exponiendo pmxcfs. Si ambas lecturas cuentan una historia parecida, cojo confianza. Si no, sé que tengo que mirar más abajo.
errores bastante típicos que intento no cometer#
mirar solo Nodes y sacar conclusiones#
No. Nodes: 2 no te dice casi nada sin Expected votes, Total votes y Quorum. El número suelto es carne de malentendidos.
ver Quorate: Yes y darlo todo por bueno#
Ya lo dije antes y lo repito porque merece insistencia. Quorum sí no equivale a cluster sano al cien por cien.
olvidar que esta salida es local#
La perspectiva importa. Si tengo dudas serias, comparo con otro nodo. Una lectura aislada puede no contar toda la película cuando la red anda partida o asimétrica.
tocar expected votes a la ligera#
Esto ya no es diagnóstico. Esto es intervención. Y en un cluster real, tocar votos esperados sin entender exactamente qué haces puede arreglarte una urgencia o dejarte una trampa preciosa para más tarde. Yo aquí soy bastante conservador.
una diferencia práctica con pvecm status#
pvecm status me parece mejor para enseñar el panorama a otra persona o para leer de un vistazo un estado más completo. corosync-quorumtool -s me parece mejor cuando quiero el núcleo duro sin demasiada envoltura.
No compiten tanto como parece. Se complementan.
De hecho, muchas veces hago esto. Primero corosync-quorumtool -s para saber si sigo de pie o no. Luego pvecm status para leer el resto con más calma. Me funciona bien y me evita dramatismos innecesarios.
un caso práctico muy real#
El ejemplo de la captura me gusta justo porque enseña un caso intermedio. No es el cluster perfecto ni el desastre total.
Hay tres votos esperados.
Solo dos nodos presentes.
Quorum exigido de dos.
Resultado, el cluster sigue quorate.
¿Qué saco yo de ahí?
Primero, que el nodo ausente importa y hay que investigarlo.
Segundo, que no necesito entrar en pánico operativo instantáneo por pérdida de mayoría.
Tercero, que el siguiente paso razonable ya no es preguntarme si hay quorum, porque eso ya lo sé. El siguiente paso es averiguar por qué falta el tercero y si la pérdida viene de red, de servicio o de caída del nodo.
Ese orden mental me parece muy sano. Y este comando ayuda bastante a mantenerlo.
algo que me gusta de votequorum#
Va al grano.
No intenta venderte una experiencia amable. No te cuenta un relato. No te maquilla nada. Te pone delante proveedor de quorum, votos esperados, votos presentes, umbral y miembros. Luego ya tú te las apañas con tu criterio.
A mí esa sequedad me gusta. En cluster, demasiada amabilidad a veces confunde.
mi conclusión#
corosync-quorumtool -s es uno de esos comandos que no parecen gran cosa hasta que necesitas separar rápido lo importante del ruido. Para mí sirve justo para eso. Confirmar si el cluster conserva mayoría, cuántos votos siguen realmente dentro y qué miembros forman parte de esa foto local.
No sustituye a pvecm status. No explica causa raíz. No te dice si KNET está sufriendo ni si pmxcfs va fino. Pero sí responde la pregunta más bruta y más útil al principio de muchas incidencias.
¿Sigue habiendo quorum o estamos ya fuera del carril?
Si la respuesta es sí, sigo diagnosticando con algo más de aire. Si la respuesta es no, la conversación cambia por completo.
Y por eso este comando se ha ganado un hueco fijo en mi caja de herramientas de Proxmox.
referencias#
- Documentación oficial de Cluster Manager en Proxmox VE
- Man page de corosync-quorumtool
- Man page de votequorum en Debian
- Post relacionado: pvecm status en Proxmox: cómo leo quorum, votes y ring ID antes de tocar un nodo
- Post relacionado: corosync-cfgtool -s en Proxmox: cómo confirmo si los enlaces del cluster siguen vivos de verdad
- Post relacionado: journalctl -u corosync -n 40 –no-pager en Proxmox: cómo leo knet, quorum y nodos que se quedan sin enlaces