Hay comandos que uso para entender el cluster. Y luego hay comandos que uso para dejar de discutir con él.
corosync-cfgtool -s está claramente en el segundo grupo.
Cuando la red del cluster da mala espina, cuando un nodo tarda en reaparecer, cuando pvecm status sale bien pero yo sigo desconfiando o cuando me planteo tocar interfaces de Corosync, este comando me ayuda a responder una pregunta muy concreta. Desde este nodo, ¿el enlace de Corosync sigue conectado a sus vecinos o solo estoy suponiéndolo?
No tiene glamour. No es agradable a la vista. Tampoco te lo explica todo. Pero en un cluster Proxmox eso me parece una virtud. Los problemas serios de red suelen empeorar cuando intentamos resolverlos sin leer primero algo tan básico como el estado del propio enlace.
Ya conté hace unos días por qué me tomo muy en serio la red de Corosync en Corosync en Proxmox: por qué la red del cluster no puede ir mezclada con todo. También hablé de revisar el servicio en systemctl status corosync en Proxmox: cómo confirmo si el servicio del cluster está bien antes de tocar red o quorum. Este artículo va un paso más abajo. No el servicio. No el quorum global. El enlace visto desde el nodo local.
Y ahí corosync-cfgtool -s me parece buenísimo.
qué hace exactamente corosync-cfgtool -s#
La manpage de Corosync lo resume bastante bien. La opción -s muestra el estado de los enlaces actuales en este nodo. En configuraciones con KNET, además da información extendida. Traducido a lenguaje menos seco, te enseña qué link está usando este nodo y si ve conectados a los otros miembros por ese camino.
A mí me interesa por tres motivos.
- confirma el transporte que está usando Corosync
- me enseña la dirección local del enlace
- me dice si los otros nodeid salen como
connected
Eso no reemplaza la lectura global del cluster. Pero la complementa de maravilla.
La documentación de Proxmox insiste bastante en que Corosync necesita latencia baja y una red estable. También recomienda una NIC dedicada y enlaces redundantes si de verdad quieres fiabilidad. Todo eso suena correcto sobre el papel. corosync-cfgtool -s es donde yo miro si esa historia sigue sosteniéndose desde el nodo que tengo delante.
una salida real que me gusta porque no vende humo#
He preparado esta captura a partir de una salida real de mi cluster, saneada en IPs y nombres internos para no publicar detalles privados.
La salida es cortísima. Y precisamente por eso me parece útil.
Local node ID 3, transport knetLINK ID 0 udp- una dirección local para ese enlace
- dos vecinos marcados como
connected - el propio nodo marcado como
localhost
Si lo que quiero es una validación rápida del enlace local, esto me basta para orientarme.
la primera línea ya me dice bastante#
Local node ID#
Me gusta empezar aquí porque me deja claro desde qué miembro del cluster estoy leyendo el estado. Parece obvio, pero en sesiones con varias terminales abiertas y saltos SSH, agradecer un recordatorio visible del nodo local me parece totalmente razonable.
Además, cuando comparas salidas de varios nodos, esta línea te evita mezclar perspectivas. En Corosync eso importa. Una cosa es cómo se ve el enlace desde un nodo sano. Otra muy distinta es cómo se ve desde el que sospechas que está cojeando.
transport knet#
Esta parte también pesa.
KNET es el transporte habitual en clusters modernos de Proxmox y Corosync. Verlo aquí me recuerda qué capa de comunicación estoy observando. No es una línea de relleno. Si luego aparece una rareza en latencia, pérdida de conectividad o problemas con enlaces redundantes, saber qué transporte estaba usando en esa salida ayuda mucho a no mezclar conceptos.
También sirve para no inventarse películas. Si el comando te enseña KNET, la conversación va por ahí. No por lo que recuerdas haber configurado hace meses.
LINK ID 0 es más importante de lo que parece#
Debajo aparece el identificador del enlace.
En mi captura sale LINK ID 0 udp porque estoy enseñando un caso sencillo con un único enlace activo y una configuración bastante normal para un homelab pequeño. Eso no significa que siempre vaya a ser así. Si tienes más enlaces de Corosync, pueden aparecer varios bloques. Y ahí la lectura se vuelve todavía más interesante.
¿Por qué me importa este LINK ID?
Porque aterriza la comprobación. Ya no estoy hablando de la red del cluster en abstracto. Estoy hablando de un enlace concreto que Corosync cree tener levantado en este nodo.
Si ese enlace viene mal, ya tengo una base bastante mejor para sospechar de red. Si viene bien, puedo seguir buscando en otro sitio con algo más de criterio.
la línea addr parece humilde, pero da contexto#
La dirección local del enlace me sirve para dos cosas.
La primera es confirmar que el nodo está usando la interfaz o la IP que espero para Corosync. En entornos con varias redes, VLANs o cambios recientes, esto importa mucho más de lo que parece cuando lees la salida rápido.
La segunda es evitar un error bastante humano. Tocar la red equivocada creyendo que era la del cluster.
He visto más de una vez diagnósticos que se enredan simplemente porque alguien tenía en mente una IP distinta de la que Corosync estaba usando de verdad. corosync-cfgtool -s no te deja mucho espacio para esa fantasía. Ahí está la dirección. La lees y sigues.
la parte buena de verdad es status#
Aquí está el corazón del comando.
En mi salida aparecen tres entradas.
- el nodeid local como
localhost - dos nodeid remotos como
connected
Ese patrón es justo el que quiero ver en un cluster sano desde el nodo local.
localhost#
No tiene misterio, pero sí valor. El nodo sabe quién es y muestra su presencia local dentro del enlace que estás inspeccionando.
connected#
Esta palabra es la que más me importa de toda la salida.
Si los vecinos salen como connected, significa que desde este nodo el enlace KNET está viendo conectividad con ellos. No es una garantía universal de felicidad, pero sí una señal muy fuerte de que la comunicación base de Corosync sigue viva por ese camino.
Y eso, antes de tocar red, es oro.
lo que connected sí significa y lo que no#
Aquí conviene no pasarse de listo.
Que un vecino salga como connected significa, básicamente, que el enlace está operativo desde la perspectiva de este nodo. Es buena noticia. Muy buena, de hecho.
Pero no significa automáticamente que todo el cluster esté perfecto.
No me dice, por ejemplo, que el quorum global sea correcto. Para eso sigo queriendo pvecm status.
No me dice que no haya latencia. No me dice que un segundo enlace redundante esté sano si el activo ya responde. No me dice que Ceph vaya feliz, ni que HA esté cómoda, ni que el resto del sistema vaya sobrado.
Lo que sí me dice es esto. Si yo sospechaba que el enlace local de Corosync estaba roto del todo, esta salida me obliga a afinar esa sospecha. Igual el problema es otro. Igual es más arriba. Igual es intermitente. Igual fue transitorio y ahora ya pasó. Pero desde luego ya no estoy mirando a ciegas.
por qué me gusta tanto antes de tocar red#
Porque me corta una tentación muy peligrosa. La de cambiar cosas para ver si mejora.
Con la red del cluster ese enfoque me parece bastante suicida. Si vas a tocar una interfaz, mover una IP, retocar Corosync o reconfigurar enlaces, lo mínimo es comprobar primero el estado actual con algo directo.
En varios hilos del foro de Proxmox aparece justo esa recomendación. Verifica con corosync-cfgtool -s que al menos otro enlace sigue conectado antes de reconfigurar nada delicado. Me parece una norma de supervivencia bastante sensata.
Incluso cuando solo tienes un enlace, como en el ejemplo de esta captura, el comando te ayuda a no entrar a lo loco. Si el link está connected, igual no necesitas desmontar media red. Si no lo está, ya sabes que la conversación se pone seria.
dónde encaja respecto a otros comandos#
Yo no lo uso solo.
Mi secuencia habitual cuando quiero revisar la parte de cluster y red suele ser esta.
pvecm statuspvecm nodescorosync-cfgtool -ssystemctl status corosyncjournalctl -u corosyncsi algo sigue oliendo raro
Cada pieza responde a una pregunta distinta.
pvecm statusme dice si hay quorum y cómo está el marco generalpvecm nodesme enumera miembroscorosync-cfgtool -sme enseña el enlace local y sus vecinossystemctl status corosyncme dice cómo está el servicio- el journal me da la novela completa si la necesito
Lo importante para mí es no pedirle a uno lo que debe responder otro. corosync-cfgtool -s no sustituye a pvecm status. Pero en la capa de enlace me parece mucho más directo.
qué me haría parar en seco#
Si al lanzar este comando veo algo distinto de un patrón razonable de localhost y vecinos connected, bajo el ritmo.
Me preocuparían bastante cosas como estas.
- vecinos que no salen como
connected - enlaces que desaparecen de la salida cuando deberían existir
- una dirección local que no cuadra con la red prevista para Corosync
- diferencias raras entre la perspectiva de un nodo y la de otro
Aquí ya no me pongo creativo. Empiezo a contrastar.
Lanzo la misma comprobación desde otros nodos. Reviso pvecm status. Miro el journal de Corosync. Compruebo si ha habido cambios recientes en red. Si toca, dejo de lado la tarea original y me centro en estabilizar el cluster.
Porque si el enlace del cluster viene mal, seguir haciendo mantenimiento como si nada me parece una forma excelente de fabricarme una avería más incómoda.
qué pasa si tienes varios enlaces#
Aunque la captura de este artículo enseña un caso simple, merece la pena decirlo. Si tu cluster usa más de un enlace para Corosync, corosync-cfgtool -s puede mostrar varios bloques de LINK ID.
Y ahí la lectura cambia de nivel.
No solo te interesa ver que el cluster respira. Te interesa comprobar qué links están realmente conectados y desde qué nodo. Porque un segundo enlace configurado pero mal resuelto no te da la redundancia que creías tener. Solo te da una falsa sensación de seguridad bastante cutre.
En ese escenario yo soy muy partidario de revisar la salida nodo por nodo. No hace falta montar una tesis doctoral. Basta con confirmar que los enlaces que deberían ser redundantes realmente existen y aparecen conectados.
también me sirve para desmontar sospechas injustas#
Esto me pasa más de lo que esperaba.
A veces un problema parece de red porque el síntoma huele a cluster. Una migración tarda. Un nodo responde raro. La interfaz fue lenta. La gente empieza a mirar Corosync con cara acusadora. Entonces lanzas corosync-cfgtool -s y ves el enlace perfectamente conectado desde el nodo local.
No significa que la red quede absuelta para siempre. Pero sí obliga a dejar de culparla sin pruebas.
Y esa parte me encanta. Los clusters ya generan suficiente ruido como para encima meterle sospechosos inventados.
lo que el comando no me resuelve#
Igual que con otros comandos pequeños, aquí también conviene recordar sus límites.
corosync-cfgtool -s no me explica por sí solo un problema de quorum. No me enseña eventos históricos. No me cuenta si hubo flaps hace media hora. No me da métricas de latencia bonitas ni sustituye al journal cuando toca entrar en detalle.
Tampoco me certifica toda la salud del cluster. Solo me da una verdad muy concreta y muy útil. El estado de los enlaces que este nodo ve en este momento.
A mí con eso me basta para lo que le pido.
mi conclusión#
corosync-cfgtool -s me parece uno de esos comandos pequeños que merecen estar mucho más presentes en la rutina de cualquier cluster Proxmox. No porque sea espectacular, sino porque responde una pregunta esencial sin rodeos. Desde este nodo, ¿los enlaces de Corosync están vivos o no?
La salida real de esta captura es justamente la que quiero ver antes de tocar nada delicado en red. Transporte claro, enlace identificado, dirección coherente y vecinos en connected.
No sustituye al resto de comprobaciones, pero sí evita una cantidad bastante seria de suposiciones malas. Y con Corosync, las suposiciones malas salen caras muy rápido.
Si administras Proxmox y todavía no lo tienes en la mochila, yo le haría hueco. En cuanto un nodo te dé esa sensación rara de “todo parece bien, pero no me fío”, este comando suele hablar bastante más claro que tu intuición.
referencias#
- Documentación oficial de Proxmox VE sobre Cluster Manager
- Manpage de corosync-cfgtool en Debian
- Post relacionado: Corosync en Proxmox: por qué la red del cluster no puede ir mezclada con todo
- Post relacionado: systemctl status corosync en Proxmox: cómo confirmo si el servicio del cluster está bien antes de tocar red o quorum
- Post relacionado: pvecm status en Proxmox: cómo leo quorum, votes y ring ID antes de tocar un nodo