Hay una clase de susto de Proxmox que siempre llega mal.
No tienes un error bonito. No tienes un botón rojo. No tienes una frase útil que te diga “mira aquí”. Lo que tienes es una sensación rara. Un nodo tarda. El cluster parece vivo pero no termina de sonar limpio. pvecm status da una foto, sí, pero te falta la película.
Por eso tiro mucho de esto.
| |
No es el comando con mejor marketing de la serie. Tampoco el más cómodo de leer. Pero cuando quiero entender qué está haciendo la red del cluster en los últimos segundos o minutos, pocas cosas me resultan más útiles.
systemctl status corosync --no-pager me dice si el servicio está arriba. Este comando me cuenta cómo ha llegado hasta ahí.
Y esa diferencia, cuando Corosync está por medio, importa bastante.
por qué prefiero el journal cuando la cosa ya huele a red de cluster#
Porque Corosync rara vez falla de forma elegante.
Cuando va bien, casi ni piensas en él. Cuando va mal, el síntoma puede aparecer a veinte metros del origen. La web tarda. Un nodo sale raro. Un servicio parece activo pero no da confianza. /etc/pve empieza a inspirar dudas. El problema no siempre se presenta con un mensaje amable que diga “hola, soy Corosync y hoy vengo torcido”.
El journal es el sitio donde esa vergüenza desaparece.
Ahí empiezas a ver KNET, TOTEM, cambios de membership, quorum, enlaces que caen y vuelven, o nodos que pasan unos segundos sin links activos antes de reenganchar. No siempre es agradable. Pero al menos es honesto.
la captura real que me parece buena para explicar cómo se lee esto#
Esta salida viene de un nodo real de mi laboratorio, saneada para que aquí no salgan nombres ni direcciones internas que no pintan nada.
Me gusta esta captura porque enseña algo que pasa mucho y se interpreta mal.
Aparecen varias líneas feas de has no active links. Si te quedas solo con eso, puedes pensar que el cluster está hecho unos zorros. Pero si lees la secuencia completa, ves otra historia.
Primero se configura el link local. Después aparecen hosts pasivos sin enlaces activos todavía. Luego entra membership nueva. Luego quorum. Luego los hosts se unen. Luego cambia el MTU efectivo. Y al final el nodo entra en el componente primario y presta servicio.
Eso no describe una catástrofe. Describe un arranque o una reincorporación que todavía se estaba ordenando.
Y ese matiz es justo por lo que me gusta leer Corosync en secuencia, no línea a línea como si cada mensaje viviera solo.
qué me dice Configured link number 0#
Esta parte me gusta porque es de las pocas líneas que no se pone críptica antes de tiempo.
| |
Aquí yo leo tres cosas.
La primera, que Corosync ha levantado el enlace de cluster que espera usar.
La segunda, que sé desde qué dirección local está hablando el nodo.
La tercera, que ya puedo empezar a cruzar mentalmente si esa red es la que yo esperaba para el tráfico de cluster.
Esto parece menor, pero no lo es. Proxmox insiste en su propia documentación en que la red de cluster necesita latencia consistente y que conviene dedicarle una interfaz o, al menos, tratarla como una red sensible. Si aquí veo una dirección que no me encaja con mi diseño, ya tengo una pista más seria que media docena de popups vagos.
lo que significa de verdad host has no active links#
Esta es la línea que más sustos inútiles provoca.
| |
Leída sola, suena fatal. A veces lo es. Otras veces es solo un fotograma intermedio.
En la captura, por ejemplo, aparece justo antes de que los otros nodos terminen de unirse. No es raro. Corosync está arrancando, ve miembros pasivos, todavía no tiene enlace activo con ellos, y lo escribe. Segundos después la historia cambia.
Por eso intento no diagnosticar Corosync leyendo una sola línea como si fuera sentencia judicial.
Lo que me pregunto siempre es esto.
¿Esa línea se queda sola y luego todo se recompone, o se repite en bucle mientras quorum, membership y servicio siguen rotos?
La diferencia lo cambia todo.
Si aparece un has no active links breve y después ves miembros sincronizados, quorum sano y primary component, yo no monto un drama. Lo trato como parte del proceso de convergencia.
Si sigue apareciendo una y otra vez, si no llegan los miembros, si no hay quorum, o si el journal se queda atascado repitiendo el mismo patrón, entonces sí me pongo serio.
por qué KNET me interesa más de lo que pensaba al principio#
Al principio KNET me parecía otra sopa de siglas más.
Ahora no.
Cuando leo journalctl -u corosync, KNET me da justo la parte física del chisme. Qué host tiene link. Cuál no lo tiene. Qué enlace se resetea. Qué pasa con el MTU. Es la parte menos filosófica del problema.
Y me encanta por eso.
En homelab uno tiende a volverse demasiado abstracto. Que si quorum. Que si cluster state. Que si la interfaz se comporta raro. KNET te baja al barro. Hay link o no hay link. Se ha reajustado el MTU o no. El host sigue pasivo o ya entró.
A menudo necesito justamente ese aterrizaje.
cómo leo yo los cambios de membership#
Estas líneas me importan muchísimo:
| |
Aquí la película ya no va de enlaces sueltos. Va de cluster recuperando forma.
Cuando veo membership nueva formada, miembros unidos y confirmación de que el nodo está dentro del componente primario, mi lectura cambia bastante. Ya no estoy en un escenario donde el journal solo enseña pérdida. Estoy en un escenario donde también enseña recuperación y convergencia.
Esto es importante porque mucha gente abre un journal, ve una línea fea al principio, y deja de leer justo antes de la parte que aclara todo.
Yo intento hacer lo contrario.
No me quedo con el susto inicial. Leo hasta ver si la secuencia se cierra bien o mal.
la línea que a mí me tranquiliza más aquí#
Si tengo que elegir una, es esta:
| |
No lo resuelve todo, claro. No me garantiza que el mundo sea perfecto. Pero me da una señal muy clara de que el nodo ya no está flotando en tierra de nadie.
Está dentro del componente primario y tiene base para prestar servicio.
Después de varios mensajes de has no active links, esa línea cambia por completo la lectura del bloque.
qué me cuentan los cambios de PMTUD#
La parte de PMTUD suele pasar desapercibida porque parece relleno técnico.
| |
A mí me parecen bastante útiles. No porque vaya a ponerme a diagnosticar MTU a mano cada vez, sino porque me confirman que Corosync sigue negociando y ajustando el tamaño efectivo de tráfico entre nodos.
Eso encaja bien con una escena de red que se está asentando. Si veo esto después de la reincorporación de miembros, suelo interpretarlo como parte normal del reajuste.
Otra cosa sería ver cambios raros de MTU una y otra vez mezclados con pérdida de enlaces y sin estabilización posterior. Ahí ya cambia el tono.
cuándo esta salida me parece normal y cuándo me parece peligrosa#
me parece razonable cuando la secuencia cierra bien#
En la captura pasa eso.
Hay unos segundos de incertidumbre. Hosts sin enlaces activos todavía. Membership parcial. Después se unen los miembros, vuelve quorum y el nodo entra en el componente primario.
No me parece bonito. Me parece normal.
me preocupa cuando la parte fea no desemboca en recuperación#
Si el journal enseña has no active links, pero no aparecen luego members, quorum o primary component, ya me cambia la cara.
Ahí empiezo a pensar en red rota, nodo aislado, servicio arrancado pero sin comunicación real o una de esas alegrías que te obligan a mirar switches, NICs, VLANs o la propia configuración de Corosync.
me preocupa mucho si el patrón se repite durante bastante tiempo#
Un mensaje feo en el arranque no es lo mismo que un journal que vuelve a escribir lo mismo cada pocos segundos o minutos. La repetición sostenida es la que me hace dejar de tratarlo como transición y empezar a tratarlo como incidencia.
el error más típico al leer Corosync#
Leerlo sin contexto temporal.
Corosync no siempre genera logs elegantes. A veces necesitas mirar tres o cuatro líneas más abajo para entender las de arriba. Si te quedas con el primer has no active links, te puedes inventar un problema gigante que ya se resolvió cuatro segundos después.
También pasa al revés. Si solo te quedas con el final bonito y no ves que el journal lleva media hora entrando y saliendo de membership, te puedes ir demasiado tranquilo.
La clave es leer la secuencia completa, aunque sea corta.
Eso es lo que de verdad separa una interpretación útil de una lectura histérica.
qué cruzo yo después de este comando#
Casi nunca me quedo solo aquí. Suelo saltar a tres sitios.
systemctl status corosync --no-pager#
Porque quiero la foto rápida del servicio, aunque luego el journal me cuente la película. Ya hablé de eso en systemctl status corosync en Proxmox: cómo confirmo si el servicio del cluster está bien antes de tocar red o quorum.
pvecm status#
Porque si el journal me sugiere recuperación o pérdida de miembros, quiero verlo reflejado en quorum, votos y membership actual. Ese cruce me sigue pareciendo el más útil para no interpretar Corosync como si fuera literatura experimental.
corosync-cfgtool -s#
Porque me deja ver el estado de enlaces desde otra capa y confirmar si lo que el journal sugiere sigue ocurriendo ahora o fue solo un instante pasado. Ya lo conté en corosync-cfgtool -s en Proxmox: cómo confirmo si los enlaces del cluster siguen vivos de verdad.
Y si lo que veo ya huele a impacto en pmxcfs, entonces remato con journalctl -u pve-cluster -n 40 –no-pager en Proxmox: cómo leo pmxcfs cuando Corosync se rompe y /etc/pve deja de inspirar confianza.
lo que este comando sí me da#
Me da secuencia.
Me da contexto de red.
Me da señales de si los nodos siguen pasivos, si entran, si negocian MTU, si hay membership nueva, y si el nodo vuelve al componente primario.
No me da toda la solución. Pero me da la historia reciente real. Y con Corosync, eso ya es muchísimo.
mi regla práctica para no volverme loco con estos logs#
Si veo líneas feas al arranque, sigo leyendo.
Si después llegan membership, quorum y primary component, bajo el drama.
Si las líneas feas se repiten y la recuperación no aparece, entonces sí, toca ponerse serio.
No es un comando para admirar. Es un comando para entender si el cluster solo estaba despeinándose o si realmente acaba de empezar una mañana de mierda.
Y entre una cosa y otra hay unos pocos segundos de journal. Conviene leerlos enteros.