Cuando un cluster Proxmox empieza a oler raro, hay una tentación muy humana y muy mala.
Abrir corosync.conf, ver muchas llaves, ponerse serio y empezar a tocar cosas sin haber leído antes el mapa.
Yo intento no hacerlo.
Antes de pensar en cambios, lo que quiero es una lectura corta del cableado lógico del cluster. Qué nodo es cuál. Qué nodeid tiene cada uno. Qué dirección ring0_addr usa el cluster para hablar con él. Y si el nombre que aparece ahí sigue correspondiendo con la historia que yo me estoy contando.
Para eso tiro de este comando muchísimo más de lo que imaginaba cuando empecé con Proxmox.
| |
No me da el estado real del cluster. No me dice si ahora mismo hay quorum. No sustituye a pvecm status ni al journal. Pero me da algo igual de valioso al principio del diagnóstico. Me dice cómo está descrito el cluster en el archivo que sostiene Corosync.
Y cuando la red del cluster está dando mala espina, leer bien el mapa antes de perseguir fantasmas me parece obligatorio.
por qué este comando me gusta tanto#
Porque me ahorra leer el archivo entero cuando todavía no hace falta.
/etc/pve/corosync.conf no es precisamente ilegible, pero tampoco es el tipo de fichero que apetece contemplar con ojos medio dormidos mientras intentas recordar qué IP iba por qué interfaz. El grep me corta la grasa y me deja lo que suelo querer ver primero.
namenodeidring0_addr- y muchas veces también
cluster_name
Con eso ya puedo responder varias preguntas muy útiles.
¿Siguen estando los nodos que espero?
¿Cada nombre sigue apuntando a la IP correcta de cluster?
¿Hay un nodeid raro o duplicado?
¿Estoy mirando la red buena o me he montado una película con otra interfaz?
La documentación oficial de Proxmox insiste en dos cosas que aquí importan mucho. La primera, que conviene referenciar los nodos por IP dentro de la configuración del cluster. La segunda, que cambiar hostname o IP después de crear el cluster no es una buena idea. Pues bien, este comando es justo la forma rápida de comprobar si tu realidad actual sigue casando con esas reglas o si el cluster va ya con memoria antigua.
la captura real que yo quería usar#
Esta salida sale de un nodo real de mi laboratorio, saneada para no enseñar nombres internos ni direcciones privadas que aquí no sirven de nada.
Me parece una captura muy buena porque resume lo importante sin perderme en todo el fichero.
Aquí ya veo tres nodos, sus nodeid, sus ring0_addr y el nombre del cluster. Eso me basta para varias comprobaciones rápidas.
Primero, confirmar que sigo teniendo tres miembros definidos.
Segundo, ver que cada nodo tiene su identidad numérica y su IP de cluster bien separadas.
Tercero, detectar enseguida si una IP me chirría o si un nombre no encaja con el nodo que creo estar viendo.
Y esa clase de comprobación, cuando Corosync anda sospechoso, vale muchísimo.
cómo lo leo yo de arriba abajo#
name#
| |
Parece poca cosa, pero para mí es donde empieza todo. El nombre es la etiqueta mental con la que vas a interpretar el resto.
Si aquí ya aparece un nodo que no reconoces, o un nombre que creías retirado, o un naming que ya no corresponde con la realidad del cluster, mala señal. No porque el nombre roto rompa Corosync por sí solo en todos los casos, sino porque demuestra que tu mapa mental y la configuración ya no están alineados.
En cluster, esa desalineación trae disgustos.
Me interesa mucho también porque hay momentos en los que el problema no es de conectividad pura, sino de identificación. Crees que el nodo que falla es uno, pero en la configuración estás mirando otro. O crees que el nodo se creó con una IP y el fichero está usando otra.
El nombre es la primera ancla para no hacerte trampas.
nodeid#
| |
El nodeid es una de esas piezas que no lucen nada hasta que algo falla.
A mí me gusta pensar en él como la identidad interna seria del nodo dentro de Corosync. No es el nombre amigable. No es la IP. Es el identificador numérico que el cluster usa para saber quién es quién cuando la conversación se pone técnica.
Por eso me fijo bastante en dos cosas.
Una, que cada nodo tenga el suyo y no haya nada raro.
Dos, que si estoy leyendo journals o estados de quorum donde aparecen IDs numéricos, pueda traducirlos rápido a nodos reales sin andar adivinando.
Eso es muy práctico. Si el journal me habla del host 6 y aquí veo que nodeid: 6 corresponde a proxmox-node-2, ya no estoy leyendo mensajes abstractos. Estoy leyendo la avería con nombres y apellidos.
por qué ring0_addr me importa tanto#
Porque aquí está la red de cluster de verdad. O al menos, la que Corosync cree que debe usar.
| |
Esta parte me parece la más valiosa del comando.
Cuando Proxmox recomienda una red dedicada para tráfico de cluster, baja latencia y bastante mimo con Corosync, todo eso termina aterrizando en algún sitio. Ese sitio, para la configuración principal, es ring0_addr.
Aquí es donde confirmo si los nodos están apuntando a la red que yo esperaba. No a la de gestión que uso para entrar por SSH por costumbre. No a la que me suena de memoria. A la que está escrita en la configuración del cluster.
Si esta IP no coincide con la red que tú creías dedicada al cluster, ya tienes una pista seria.
No una sospecha vaga. Una pista seria.
Y eso cambia por completo el siguiente paso.
lo que este grep me ahorra en cinco segundos#
Me ahorra abrir el fichero entero y leerlo con mentalidad de arqueólogo.
Me ahorra perseguir un nodo por nombre cuando el journal lo está nombrando por ID.
Me ahorra culpar a la red equivocada.
Me ahorra meterme en pvecm status sin saber todavía a qué IP debería corresponder cada miembro.
Y sobre todo me ahorra tocar nada antes de haber confirmado el dibujo básico.
En cluster, tocar sin dibujo es un deporte carísimo.
cosas concretas que detecto con esta salida#
un nodo que sigue definido aunque tú jurabas que ya no pintaba nada#
Esto pasa más de lo que nos gustaría. Alguien hizo limpieza a medias, o sacó un nodo, o cambió una topología y tu cabeza ya lo da por cerrado. El grep a corosync.conf te devuelve a la realidad enseguida. Si el nodo sigue aquí, sigue formando parte del mapa lógico del cluster hasta que se demuestre lo contrario.
una IP de cluster que no encaja con la red que creías usar#
Esta es de mis favoritas porque suele explicar muchas cosas a la vez. Si esperabas una red dedicada y ring0_addr apunta a otra interfaz o a otra subred, deja de tener sentido culpar al switch equivocado o al NIC equivocado. Primero corrige la película.
un nodeid que necesitas traducir rápido#
Cuando estás leyendo journalctl -u corosync o alguna salida donde aparecen hosts numerados, esta traducción corta vale oro. No quiero pensar. Quiero mapear rápido host 5, host 6 o host 3 a nodos concretos.
un nombre que ya huele a pasado#
Si el naming no coincide con los nombres reales del entorno, mal. No siempre rompe por sí solo, pero casi siempre es un síntoma de que algo cambió y la configuración no fue detrás con suficiente cariño.
lo que este comando no me dice#
No me dice si el nodo está ahora mismo online.
No me dice si hay quorum en este instante.
No me dice si KNET anda perdiendo links.
No me dice si la interfaz física está levantada o si la latencia se fue al infierno.
No me dice si el cluster ya está roto o solo despeinado.
Por eso nunca cierro un diagnóstico aquí. Este grep es mapa, no estado.
Y esa distinción me parece importante de verdad.
qué cruzo justo después#
Mi siguiente parada casi siempre depende de lo que me haya contado este fichero.
si quiero ver estado real de cluster#
Voy a pvecm status en Proxmox: cómo leo quorum, votes y ring ID antes de tocar un nodo.
Ahí dejo de leer configuración y paso a leer situación actual.
si sospecho problema de servicio o de red del cluster#
Voy a systemctl status corosync en Proxmox: cómo confirmo si el servicio del cluster está bien antes de tocar red o quorum y luego a journalctl -u corosync -n 40 –no-pager en Proxmox: cómo leo knet, quorum y nodos que se quedan sin enlaces.
Ahí es donde la película deja de ser estática.
si la duda es si la capa compartida del cluster sigue respirando#
Entonces salto a 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.
Porque una cosa es el mapa de Corosync y otra lo que pmxcfs consigue hacer con él.
una opinión clara que tengo aquí#
Corosync no se toca a ciegas. Nunca.
Ya sé que esto suena un poco severo, pero me da igual. Me parece una de esas reglas que ahorran estupideces.
Si vas a tocar la red del cluster, cambiar IPs, renombrar nodos, revisar enlaces o meterte en quorum, lo mínimo es que antes hayas leído quién es quién dentro de corosync.conf. Y este grep me parece la forma más barata y razonable de hacerlo.
No necesitas montar un ritual. No necesitas abrir tres wikis. No necesitas interpretar todo el fichero entero en frío. Necesitas un mapa corto y fiable.
Este comando te lo da.
errores bastante comunes que intento no cometer#
confundir la IP de gestión con la IP de cluster#
Es más habitual de lo que parece. Entras por una interfaz, ves que funciona, y das por hecho que Corosync usa esa misma. Error clásico. ring0_addr está para recordarte la verdad.
tocar el fichero porque una IP no te gusta sin revisar antes la red real#
Que una dirección te sorprenda no significa que esté mal. Primero confirma qué interfaz existe, qué bridge la levanta y qué topología querías realmente. Tocar por intuición aquí puede convertir una duda en una avería bastante real.
asumir que porque corosync.conf está bien, el cluster está bien#
Ojalá. Pero no. Puedes tener una configuración correcta y, aun así, tener un nodo caído, un enlace mal, latencia absurda o quorum tocado. El fichero es mapa, no parte meteorológico.
olvidar que Proxmox desaconseja cambiar hostname e IP después de crear cluster#
La documentación lo deja bastante claro. Si ya cambiaste algo importante a posteriori, este grep es de las primeras cosas que yo revisaría para ver si la configuración sigue describiendo la realidad o se quedó viviendo en otra semana.
cuándo lo uso casi sin pensar#
después de una incidencia de red del cluster#
Si hubo corte, reinicio raro o sospecha de enlace malo, quiero releer el mapa antes de interpretar el resto.
cuando journalctl -u corosync nombra hosts por número#
Traducir host 6 o host 3 es mucho más rápido si ya tienes delante nodeid y nombre.
cuando una IP del cluster me chirría#
No discuto con mi memoria. Miro ring0_addr y se acabó el debate.
antes de intervenir en configuración#
Esto me parece básico. Leer antes de tocar. A veces olvidamos lo sencillo y luego vienen las historias tristes.
algo que también miro de reojo, cluster_name#
| |
No lo uso tanto para diagnóstico técnico puro, pero me gusta que salga ahí. Sobre todo si gestionas varios entornos o si te has acostumbrado a entrar por costumbre en demasiados nodos distintos.
Confirmar el nombre del cluster evita una clase de error ridícula pero bastante humana. Creer que estás revisando un sitio mientras en realidad estás en otro.
En homelab también pasa. Y cuando pasa, suele ser de una forma bastante tonta.
mi conclusión#
grep -nE "nodeid|ring0_addr|name:" /etc/pve/corosync.conf me parece de los mejores comandos de lectura corta para Proxmox cuando sospechas de la red del cluster. No arregla nada. No te da estado vivo. No sustituye a pvecm status, a corosync-cfgtool -s ni al journal. Pero hace algo importantísimo antes de todo eso.
Te enseña el mapa lógico con el que Corosync cree que está jugando.
Y si no lees bien ese mapa, lo demás se vuelve bastante más torpe. Puedes culpar a la NIC equivocada, interpretar mal un host 6, perseguir una IP que no era la del cluster o tocar configuración sin haber entendido siquiera quién es quién.
Yo prefiero invertir cinco segundos aquí y ahorrarme media hora de romanticismo técnico después.
referencias#
- Documentación oficial de Cluster Manager en Proxmox VE
- Documentación oficial de Proxmox Cluster File System
- Post relacionado: pvecm status en Proxmox: cómo leo quorum, votes y ring ID antes de tocar un nodo
- 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: journalctl -u corosync -n 40 –no-pager en Proxmox: cómo leo knet, quorum y nodos que se quedan sin enlaces