Hay un momento muy concreto en el que me gusta lanzar systemctl status corosync en Proxmox. Justo cuando el cluster parece suficientemente bien como para confiarse, pero no tan bien como para que yo quiera tocar algo sin mirar antes debajo del capó.
Porque una cosa es que la interfaz web cargue. Otra que pvecm nodes siga enseñando miembros. Y otra muy distinta que el servicio de Corosync esté realmente tranquilo. No medio vivo. No “bueno, parece que aguanta”. Tranquilo.
A mí este comando me sirve para eso. Para una lectura rápida del estado local del servicio del cluster. Si está activo, desde cuándo, con qué consumo anda y, sobre todo, qué viene diciendo en las últimas líneas del journal.
Y aquí está el matiz importante. Muchas veces lo más útil no es ver active (running). Lo más útil es lo que aparece justo debajo.
por qué miro systemctl status corosync si ya tengo pvecm status#
Porque no responden a la misma pregunta.
pvecm status me encanta para una foto global de quorum, votos, ring ID y membresía. De hecho ya hablé de esa rutina en Cómo reviso la salud de un cluster Proxmox en dos minutos antes de tocar nada. Pero systemctl status corosync me da otra clase de contexto. Uno mucho más pegado al sistema.
Me enseña si el servicio sigue arriba desde hace días o si acaba de reiniciar. Me deja ver memoria, CPU y unas cuantas líneas recientes del journal sin tener que abrir aún un journalctl más largo. Para mí eso es perfecto como primer vistazo local.
Dicho de forma menos técnica. pvecm status me dice cómo pinta el cluster. systemctl status corosync me dice cómo va respirando este nodo dentro del cluster.
Las dos miradas juntas valen bastante más que separadas.
una captura real que explica muy bien por qué no me basta con ver “running”#
He sacado la siguiente captura de tres nodos reales de mi cluster. Está saneada en hostnames y detalles internos, pero los avisos y tiempos son reales.
Y para mí resume una lección muy útil.
Los tres nodos aparecen con Active: active (running). Bien. Si me quedara solo con eso, podría cerrar la terminal y seguir con mi vida.
Pero debajo cambia bastante el tono.
node-benseña un servicio activo y bastante aburrido, que es justo lo que quiero vernode-amuestra avisos de KNET y unToken has not been received in 4237 msnode-crepite varias veceshost 6 has no active links
O sea, el servicio está arriba en los tres. Sí. ¿Está igual de cómodo en los tres? Ni de broma.
Y eso es lo que me interesa detectar antes de reiniciar un nodo, tocar una red de cluster o asumir que el quorum está tan feliz como parece.
qué leo exactamente cuando abro systemctl status corosync#
Loaded#
No es la parte más emocionante, pero me gusta verla limpia.
Aquí confirmo que el servicio está cargado desde donde toca y habilitado. Si aquí ya hubiera rarezas, presets extraños o cualquier invento poco habitual, la revisión cambiaría de tono desde el principio. Normalmente no es donde aparecen los problemas, pero tampoco me cuesta nada echar un vistazo.
Active#
Esta línea manda mucho, pero no manda sola.
Claro que me importa ver active (running). Si no aparece eso, ya no estamos en una revisión preventiva. Ya estamos en otra película. Pero además me fijo mucho en el “since”.
En la captura, node-a y node-c llevan activos desde el 11 de abril. node-b desde el 14. Esa diferencia no es mala por sí misma. Puede ser perfectamente normal si un nodo reinició después de una tarea de mantenimiento. Lo relevante es que el dato existe y me obliga a recordar que no todos vienen con la misma historia reciente.
Yo agradezco mucho estas pequeñas pistas. En homelab solemos recordar regular cuándo reinició cada host y excelente cuándo nos conviene inventarnos que lo recordamos.
Main PID, memoria y CPU#
No saco conclusiones heroicas de estos números, pero sí contexto.
Si el servicio lleva pocos minutos arriba y ya me sale con un consumo raro o con un historial de CPU extraño, me despierta curiosidad. En la captura los tres nodos van razonables, con memorias en la banda de 150 a 178 MB y CPU acumulada coherente con varios días de uptime.
Eso, por sí solo, no demuestra salud. Pero ayuda a que la historia tenga sentido.
las líneas del journal#
Aquí está la verdadera salsa del comando.
Muchísima gente se queda en active (running) y no baja la vista. Yo hago justo lo contrario. Bajo la vista antes de confiarme.
Porque Corosync te puede decir cosas muy útiles sin obligarte todavía a abrir un journalctl -u corosync -n 100.
En la captura hay dos señales que yo me tomo en serio.
host ... has no active linksToken has not been received in 4237 ms
No significan automáticamente desastre, pero desde luego tampoco significan calma.
por qué me preocupan tanto los mensajes KNET y TOTEM#
Porque suelen aparecer cuando la conversación ya no va solo de “el servicio está arriba”.
KNET es la capa de transporte de Corosync. TOTEM es la parte de mensajería y token que mantiene la coherencia del cluster. Si en las últimas líneas ya veo avisos de enlaces pasivos, enlaces sin actividad o tokens tardando demasiado, mi postura cambia bastante rápido.
No entro en pánico. Pero tampoco sigo como si nada.
En el caso de node-a, ver host 6 has no active links seguido de un Token has not been received in 4237 ms y luego un reset de MTU me parece el ejemplo perfecto de servicio que sigue vivo mientras te está diciendo que ha tenido una mala tarde.
En node-c, la repetición de host 6 has no active links tampoco me parece decoración. Que el nodo esté arriba no borra el hecho de que ha estado viendo algo feo en la conectividad del cluster.
Ese matiz importa mucho. Sobre todo si estás valorando tocar red, reiniciar otro host o mover cargas confiando en que el plano de cluster va fino.
el error clásico, confundir servicio activo con cluster cómodo#
Lo he visto muchas veces. También me lo he aplicado a mí mismo, claro.
Abres systemctl status corosync, ves verde, ves running, cierras terminal. Luego minutos después aparece el típico comportamiento gris que no sabes si es red, quorum, storage o simplemente una ventana mala de conectividad.
A mí este comando me gusta precisamente porque me ayuda a no cometer ese error. running es el primer requisito, no el veredicto final.
Si debajo hay KNET quejándose, TOTEM avisando o reseteos extraños, la lectura correcta no es “todo bien”. La lectura correcta es “el servicio sigue arriba, pero el nodo tiene cosas que contar”.
Y cuando Corosync tiene cosas que contar, yo prefiero escucharlas antes de tocar nada más.
cómo cruzo este comando con el resto de comprobaciones#
Mi secuencia rápida suele ser así.
systemctl status corosyncpvecm nodespvecm statusha-manager statussi ese host me importa para HAjournalctl -u corosync -n 50si las líneas del status ya me han dado mala espina
El orden me funciona bien porque empiezo en local, bajo luego a membresía y cierro con quorum y detalle.
Si lo hago al revés, a veces me pierdo en la vista global y olvido mirar una pista muy terrenal que el propio nodo ya me estaba dejando en bandeja.
cuándo me hace frenar#
Hay varias situaciones en las que este comando, por sí solo, ya me cambia el plan.
el servicio acaba de reiniciar y no sé por qué#
No siempre es malo, pero no me gusta avanzar sin contexto. Si Corosync lleva arriba mucho menos de lo que yo esperaba, quiero saber qué pasó.
aparecen avisos repetidos de KNET#
Un aviso puntual puede ser ruido. Repeticiones, no tanto. Si veo varias líneas sobre enlaces sin actividad, ya sé que el cluster no está tan relajado como parecía.
aparece un aviso de TOTEM sobre el token#
Esto me hace bajar revoluciones muy rápido. Puede ser transitorio, sí. Pero el token es demasiado importante como para tratar el aviso como anécdota.
el status local no cuadra con mi sensación global#
Si el cluster “parece bien” pero el nodo local va dejando señales raras, me creo antes al nodo que a mi sensación.
cuándo me tranquiliza de verdad#
Me tranquiliza cuando veo esto.
active (running)desde un tiempo razonable- consumo y PID estables
- journal reciente aburrido o directamente sin sustos
- coherencia con lo que luego me enseñan
pvecm nodesypvecm status
La palabra clave aquí es aburrido. En clusters, lo aburrido es buenísimo.
Si el status me aburre, sonrío. Si me entretiene, mala señal.
el caso concreto de la red del cluster#
Este comando me parece especialmente útil cuando vengo de tocar o sospechar de red. Si Corosync depende de una red del cluster que ya expliqué por qué conviene aislar en Corosync en Proxmox: por qué la red del cluster no puede ir mezclada con todo, cualquier aviso de KNET o TOTEM se vuelve bastante más interesante.
Porque aquí no estamos hablando solo de un servicio de sistema. Estamos hablando de la base sobre la que el cluster mantiene su conversación interna. Si esa conversación tose, prefiero enterarme antes de encadenar otro cambio.
De hecho, una de las cosas que más me gusta de systemctl status corosync es que me ayuda a separar dos escenarios.
- el servicio está limpio y el problema probablemente va por otro lado
- el servicio está arriba, pero ya deja huellas de que el plano de cluster ha sufrido
No parece una diferencia enorme. En la práctica lo es.
lo que este comando no me resuelve#
Tampoco conviene idolatrarlo.
systemctl status corosync no me da una foto completa del cluster. No me dice por sí solo si sigo quorate, ni qué opina el resto de nodos, ni si HA está tranquila, ni si el storage compartido arrastra su propio drama. Mucho menos reemplaza revisar logs con más profundidad cuando hay señales feas.
Pero no le pido eso.
Le pido una lectura rápida y local que me diga si el servicio está simplemente levantado o si está levantado mientras me manda avisos que merece la pena tomar en serio.
Y para eso va de maravilla.
dónde me ha dado más valor#
No en caídas completas, curiosamente. Ahí ya sabes que hay un problema y vas de cabeza a logs, quorum y red. Donde más me compensa es en las situaciones ambiguas. El cluster sigue funcionando, las VMs siguen arriba, pero algo ha hecho un ruido raro, una migración tardó más, un nodo volvió de un reinicio o simplemente tengo la intuición de que no está todo tan fino como ayer.
Ahí systemctl status corosync me da una pista rapidísima.
Si lo veo limpio, sigo mirando otras capas. Si veo KNET protestando o TOTEM avisando, ya sé que la revisión no debe empezar por otro sitio. Debe empezar por el propio plano de cluster.
Eso evita mucho diagnóstico ornamental, que es una de mis especialidades menos favoritas cuando son las dos de la mañana.
mi conclusión#
systemctl status corosync es uno de esos comandos que parecen demasiado simples hasta que entiendes qué pregunta responde de verdad. No te dice solo si Corosync vive. Te deja ver si vive cómodo o si sigue trabajando mientras arrastra avisos que conviene escuchar.
La captura real de estos tres nodos me parece muy clara. Los tres están en running, pero no cuentan la misma historia. Uno está aburrido, que es perfecto. Los otros dos dejan señales de KNET y TOTEM que yo no ignoraría antes de tocar red, reiniciar otro nodo o confiarme con el quorum.
Si administras Proxmox y quieres una comprobación rápida antes de meter mano al cluster, yo abriría este comando bastante más de lo que suele recomendarse. No sustituye a pvecm status, ni a journalctl, ni a una revisión seria. Pero sí te da una pista excelente sobre el tono real del nodo.
Y cuando el tono del nodo cambia, más vale enterarte antes de hacer el siguiente movimiento.
referencias#
- Cluster Manager en la documentación oficial de Proxmox VE
- Manual de Corosync en Debian
- Post relacionado: pvecm nodes en Proxmox: la comprobación corta que hago para confirmar quién sigue dentro del cluster
- Post relacionado: Corosync en Proxmox: por qué la red del cluster no puede ir mezclada con todo
- Post relacionado: Cómo reviso la salud de un cluster Proxmox en dos minutos antes de tocar nada