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.
Hay días en los que abro pvecm status porque quiero una foto completa del cluster. Y hay días en los que no necesito toda la película. Necesito saber una cosa muy concreta y la necesito ya. Qué nodos siguen dentro del cluster, con qué voto aparecen y desde cuál estoy consultando. Para eso pvecm nodes me parece bastante mejor de lo que mucha gente le concede.
No vende humo. No da métricas elegantes. No pretende ser un panel de salud. Es una comprobación corta, seca y muy útil cuando el objetivo no es admirar el cluster, sino evitar una tontería antes de tocarlo.
Hay comandos que parecen un trámite y luego están los que te evitan una noche de mierda. pveversion -v está en el segundo grupo.
Yo lo uso antes de actualizar un nodo Proxmox, antes de reiniciarlo y también cuando algo ya huele raro y quiero saber si el problema viene de una capa más aburrida de lo que me gustaría admitir. Porque sí, en homelab nos encanta echarle la culpa a Ceph, a Corosync, al storage compartido o a esa VM caprichosa que siempre aparece en el momento menos elegante. Pero muchas veces el drama empieza antes, en algo tan poco glamuroso como una versión que no cuadra, un kernel viejo todavía dando vueltas o un paquete medio roto que nadie miró con calma.
La alta disponibilidad en homelab tiene una capacidad especial para volvernos optimistas cuando no toca. Montas HA, ves que una VM arranca en otro nodo, te vienes arriba y empiezas a pensar que el cluster ya se cuida solo. Luego llega una noche cualquiera, abres una shell, ves cuatro líneas en verde y decides reiniciar un host porque total, para eso está la magia. Ahí suele empezar la parte divertida.
No me preocupa actualizar Proxmox. Lo que me preocupa es hacerlo con esa falsa tranquilidad de quien ve cuatro checks verdes y piensa que ya está todo bajo control. En un nodo suelto ya hay margen para liarla. En un cluster pequeño, todavía más. No porque Proxmox sea frágil, sino porque en casa solemos mezclar infra razonable con decisiones que tomamos medio dormidos.
Mi experiencia con esto es bastante simple. Los upgrades salen bien cuando llegas con contexto. Se tuercen cuando entras con prisa, ejecutas apt full-upgrade porque hoy te viene bien y solo después descubres que había un paquete raro, un nodo con quorum justo o una VM donde no tocaba.
Una de las cosas que más me gustan de Proxmox es que te deja ver bastante verdad si preguntas bien. Una de las cosas que más me fastidian es que también te deja interpretar mal esa verdad si vas demasiado deprisa. local-lvm es un ejemplo perfecto.
Esta madrugada estuve comparando el estado de almacenamiento de tres nodos del mismo cluster. En dos de ellos, local-lvm aparecía activo, con su thin pool funcionando y varios discos locales viviendo ahí. En el tercero, la historia era otra. local-lvm salía inactivo y el sistema escupía un mensaje bastante poco ambiguo. no such logical volume pve/data.
Hay días en los que Proxmox te mira con cara de niño bueno. Todo verde, ninguna alarma fea, la interfaz carga rápido y uno empieza a pensar que quizá hoy sí puede tocar cosas sin pagar peaje. A mí ese momento me da exactamente la reacción contraria. Cuando un cluster parece demasiado tranquilo, me obligo a revisar lo básico antes de hacer nada que pueda mover piezas importantes.
Lo digo porque ya he aprendido que el desastre raro casi nunca empieza con una explosión cinematográfica. Empieza con una confianza tonta. Un reinicio que parecía inocente. Una actualización lanzada deprisa. Una VM que mueves de nodo porque sí. Dos minutos después estás preguntándote por qué HA no se comporta como esperabas o por qué Corosync decide ponerse estupendo justo hoy.
Una de las ideas más engañosas cuando montas un cluster de Proxmox en casa es pensar que repartir cargas significa dejar todos los nodos parecidos. Mismo número de máquinas, memoria parecida, CPU más o menos compensada y una satisfacción estética bastante sospechosa cuando miras la interfaz. Yo he pasado por ahí y no lo recomiendo demasiado.
Con el tiempo he acabado prefiriendo otra cosa. Menos simetría bonita y más intención. Un nodo puede ser el más fuerte y cargar con lo pesado. Otro puede quedarse con servicios persistentes pero tranquilos. Otro puede ser el comodín para mantenimiento, failover o experimentos. Eso, en la práctica, me ha dado un cluster mucho más cómodo que intentar jugar a la igualdad perfecta.
Hay una fase muy concreta en cualquier homelab con Proxmox en la que uno se viene arriba. Montas el cluster, ves los nodos juntos en la interfaz, pruebas una migración y piensas que ya está, que lo serio era llegar hasta ahí. Luego pasan unas semanas, metes más carga, empiezas a mover backups, storage, tráfico de servicios, alguna copia pesada, algún reinicio tonto de switch, y descubres la parte menos sexy del asunto. El cluster no vive de la ilusión. Vive de red estable.
Hay un punto en todo homelab un poco serio en el que un solo servidor deja de tener gracia. No porque no sirva, sino porque se convierte en un cuello de botella para todo. Mantenimiento, pruebas, reinicios, cambios de disco, errores tontos, ganas de experimentar. De repente cualquier cosa toca demasiado. Ahí es donde un cluster de Proxmox empieza a tener sentido.
Yo llevo tiempo con un cluster pequeño de tres nodos y la experiencia me ha convencido de algo bastante concreto. Para casa, tres mini PCs bien elegidos me parecen una de las mejores formas de entrar en clustering de verdad sin irte al absurdo del rack enterprise ni al caos de reciclar hardware que nunca quiso trabajar junto.
Ceph tiene muy buena prensa en el mundo homelab. Es normal. Sobre el papel suena brillante. Almacenamiento distribuido, replicación, tolerancia a fallos, integración muy seria con Proxmox y la sensación de que estás montando algo que se parece a un entorno de verdad. El problema es que, cuando bajas del PowerPoint al salón de casa, Ceph también te recuerda muy rápido que no le importan tus ilusiones.
Yo no lo digo desde fuera. Lo tengo corriendo en un cluster pequeño de Proxmox y me gusta. De hecho, me sigue pareciendo una de las piezas más potentes que puedes montar en casa si sabes muy bien por qué la estás montando. Pero también creo que muchísima gente lo recomienda demasiado pronto, como si fuera el siguiente paso natural después de instalar tres nodos y aprender a pronunciar “quorum” sin pestañear.
Durante mucho tiempo tuve Proxmox con varios nodos pero sin HA configurado. Cada nodo vivía su vida: si se caía el nodo donde estaba corriendo mi agente de Gemology, ese servicio desaparecía hasta que yo me daba cuenta y lo encendía manualmente. Con dos o tres VMs es tolerable. Con más de diez servicios corriendo, te quedas sin noches tranquilas.
Proxmox High Availability es el mecanismo que permite que cuando un nodo falla, las VMs que tenía ese nodo se reinicien automáticamente en los nodos que siguen vivos. No es migración en caliente, que eso requiere hardware y configuración diferente. Es reinicio: la VM se apaga en el nodo que falla y se arranca en otro nodo del cluster. Para la mayoría de servicios del homelab, eso es suficiente.