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.
En mi caso, la lección llegó justo así. No por un desastre épico ni por una caída de película. Llegó por pequeñas fricciones. Un aviso raro. Un nodo que tarda más de lo que debería en reaccionar. La sensación de que todo está bien, pero no tan bien como me gustaría cuando mezclo tráfico de cluster con tráfico que no tiene nada que hacer ahí.
Mi opinión ahora es muy simple. Si montas un cluster de Proxmox y te tomas Corosync medio en serio, no deberías tratar su red como un carril compartido para todo. Puedes arrancar así, claro. Mucha gente lo hace. Yo también. El problema es que una cosa es que funcione y otra muy distinta es que sea buena idea.
Qué hace Corosync y por qué se pone nervioso#
Corosync es la pieza que mantiene a los nodos de acuerdo sobre quién está, quién falta y si el cluster sigue teniendo quorum. Dicho de forma menos solemne, es el sistema que evita que tu infraestructura se comporte como tres cajas sueltas con interfaz bonita.
Cuando Corosync va fino, apenas piensas en él. Los nodos se ven, votan, mantienen quorum y Proxmox puede tomar decisiones con normalidad. Cuando la red se ensucia, la cosa cambia. No hace falta un corte total para que empiecen los problemas. A veces basta con latencia irregular, pérdida de paquetes o tráfico que compite con lo importante en el peor momento.
Ese es justo el matiz que más se infravalora en homelab. Como estamos en casa y no en un CPD, tendemos a pensar que todo el tráfico local es más o menos amistoso. No lo es. Una copia grande, un rebalanceo de almacenamiento o un servicio muy charlatán puede fastidiar bastante más de lo que parece cuando comparte camino con el tráfico que decide si el cluster sigue teniendo mayoría.
La captura que me recuerda por qué no conviene improvisar#
Esta es una captura saneada del estado real de quorum de mi cluster. He cambiado nombre e IPs, pero la foto viene de una máquina real de mi lab.
Lo importante aquí no es el postureo de tener tres nodos. Lo importante es que Corosync ve tres votos, el cluster está quorate y todo se apoya en una comunicación estable. Esa estabilidad no sale gratis. Se construye con una red que no le pone zancadillas.
También me gusta esta otra captura porque enseña algo todavía más básico.
Corosync no necesita una novela. Necesita conectividad limpia. Si el enlace está bien, casi ni se nota. Si el enlace se degrada, el cluster empieza a ponerse creativo. Y la creatividad en infra, como casi siempre, es mala señal.
El error clásico de mezclarlo todo porque “ya que está”#
Yo este error lo entiendo perfectamente porque es cómodo. Tienes una red funcionando, las interfaces responden, el switch no parece dar guerra y total, todo está dentro de casa. Así que metes Corosync por ahí mismo, junto con administración, backups, tráfico de VMs, copias, quizá algo de almacenamiento compartido y lo que vaya cayendo.
Arranca. Funciona. Incluso puede funcionar durante bastante tiempo. Ese es el problema, de hecho. Como no falla de inmediato, parece una decisión válida. Luego llega el día en que haces una copia gorda o una migración pesada justo cuando otro servicio está tragando ancho de banda, y descubres que la red no tenía tanto margen como creías.
En un servidor único, una red mediocre suele darte lentitud o alguna molestia puntual. En un cluster, una red mediocre también puede darte dudas de quorum, latencias raras entre nodos o un ambiente general de desconfianza que te quita las ganas de tocar nada en hora punta.
Y eso es justo lo contrario de lo que quiero de un cluster doméstico. Yo monto varias máquinas para tener más flexibilidad, no para vivir con más supersticiones.
Lo que cambió cuando dejé de verlo como un detalle#
El cambio importante no fue comprar hardware raro ni ponerme en modo enterprise. Fue mental. Dejé de pensar “Corosync es poco tráfico, da igual por dónde vaya” y empecé a pensar “Corosync es poco tráfico, precisamente por eso no debería competir con porquería”.
Hay una diferencia enorme entre ambas frases.
Cuando lo miras así, muchas decisiones se vuelven bastante obvias.
La primera es separar funciones. Si puedes darle una NIC dedicada, mejor. Si no puedes, al menos una VLAN muy clara y un trayecto lo más predecible posible. La segunda es evitar que esa red comparta alegrías con backups pesados, replicaciones o tráfico de almacenamiento que se come el ancho de banda sin pedir permiso. La tercera es asumir que el switch también importa. En casa nos obsesionamos con CPUs, NVMe y mini PCs, y luego hay un switch de fondo haciendo de árbitro silencioso de todo el cluster.
No hace falta gastarse un dineral. Hace falta respetar el camino crítico.
Qué síntomas me hacen sospechar antes de que el desastre se note#
Aquí prefiero ser muy práctico. No espero a ver el cluster roto. Si empiezo a notar alguno de estos patrones, ya sé que toca revisar red antes de echarle la culpa a cualquier otra cosa.
- Avisos de quorum que aparecen y desaparecen sin una causa clara.
- Migraciones que a veces van bien y a veces se vuelven raras.
- Nodos que siguen online, pero tardan más en reflejar cambios.
- Picos de tráfico que coinciden con sensaciones de inestabilidad general.
- Mantenimiento sencillo que da más respeto del que debería.
Ese último punto me parece bastante claro. Cuando un cluster está bien parido, apagar un nodo para tocarlo no debería sentirse como un ritual. Si cada intervención te pone el pulso raro, normalmente no es solo manía. A veces el sistema te está diciendo, con bastante educación, que no confía del todo en sus cimientos.
Lo que haría hoy en un cluster pequeño de casa#
Si empezara mañana con tres nodos Proxmox en mini PCs, haría esto sin pensarlo demasiado.
Primero, daría a Corosync su propio carril si el hardware lo permite. Aunque sea una red sencilla y poco glamourosa. Cuanto menos tráfico ajeno vea, mejor.
Segundo, evitaría mezclarlo con storage distribuido o con copias grandes. Ceph, replicación, PBS, rsync gordo o lo que toque puede convivir en tu red, pero no hace falta que se suba al mismo ascensor que la parte que sostiene el quorum.
Tercero, probaría comportamiento real, no solo el arranque feliz del primer día. Reiniciar un switch, tumbar un enlace, hacer una copia pesada mientras observas el cluster. Cosas normales. Cosas que luego pasan de verdad.
Cuarto, documentaría qué interfaz o qué VLAN usa Corosync. Parece una obviedad, pero la cantidad de homelabs que dependen de una configuración medio recordada es bastante indecente.
Cuándo acepto compartir red y cuándo no#
No voy a fingir que todo homelab necesita una ingeniería de museo. Hay casos donde compartir red tiene sentido, sobre todo cuando arrancas.
Si tienes dos o tres nodos pequeños, poco tráfico, nada de storage distribuido y un uso bastante tranquilo, puedes empezar con una sola red. Yo no lo prohibiría como idea inicial. Sería ridículo ponerse purista con un cluster recién nacido que todavía mueve cuatro servicios modestos.
Ahora bien, en el momento en que el cluster empieza a hacer cosas de verdad, yo dejaría de aplazarlo. Si ya estás migrando cargas, metiendo HA, lanzando copias pesadas o trasteando con almacenamiento compartido, esa red merece más cariño. Ahí es donde muchos homelabs pasan de hobby simpático a infraestructura doméstica real, y la red del cluster debería reflejar ese cambio.
Mi regla mental es esta. Si una saturación puntual de red te puede poner a dudar de quorum, esa red ya no está bien diseñada para lo que le estás pidiendo.
Lo que no compraría del discurso más optimista#
Hay una corriente muy habitual en foros y vídeos que reduce el tema a “Corosync consume poco, así que no importa”. No compro esa idea. Precisamente porque consume poco, lo que necesita es regularidad. No una autopista llena de camiones.
Tampoco compro el argumento de que “si no ha fallado aún, entonces está bien”. En redes de cluster eso me parece una trampa mental bastante cutre. Muchas configuraciones son aparentemente correctas hasta que un día coinciden varias cosas normales y dejan de serlo. Esa falsa sensación de seguridad es peor que un fallo temprano, porque te convence de que el diseño era sólido cuando solo era afortunado.
Y tampoco creo que separar la red de cluster sea obsesión enterprise. Me parece simple higiene técnica. Igual que no metería mis backups en el mismo disco que quiero proteger, tampoco me entusiasma jugar a la ruleta con la comunicación que mantiene vivo el quorum.
Mi recomendación real para un homelab con Proxmox#
Yo haría esto.
- Un carril dedicado para Corosync si el equipo lo permite.
- Si no, una VLAN propia y bien identificada.
- Nada de tráfico pesado mezclado por comodidad.
- Pruebas reales de red antes de confiarle cosas importantes.
- Documentación mínima para no depender de memoria borrosa.
También intentaría que la red de cluster fuese aburrida en el mejor sentido. Sin inventos, sin pasos innecesarios, sin rutas raras, sin compartir protagonismo con tráfico que cambia mucho de un día a otro. Corosync no necesita emoción. Necesita rutina.
Dónde creo que está el equilibrio sano#
No hace falta montar un laboratorio empresarial para hacer esto bien. Un homelab puede seguir siendo casero, razonable y hasta barato sin tratar la red del cluster como una servilleta. Ese es el punto que a mí me faltó ver con claridad al principio.
La gente invierte bastante tiempo eligiendo mini PCs, RAM, NVMe y modelos de CPU. Luego la comunicación entre nodos se resuelve con un “ya lo afino después”. Yo ya no haría eso. He visto suficiente para saber que Proxmox aguanta bastante, sí, pero también sé que Corosync tiene memoria y te acaba cobrando la falta de mimo en el peor momento.
Si algo saco en claro después de convivir con un cluster doméstico es esto. La red del cluster no es el sitio donde rascar simplicidad a lo bruto. Si quieres simplificar, simplifica otras cosas. Quita servicios. Reduce capas. Aplaza Ceph. Lo que te apetezca. Pero no conviertas el canal de quorum en un carril compartido con tráfico que no tiene ningún respeto por tus votos.
Porque al final ese es el asunto. Un cluster no se rompe siempre por falta de potencia. A veces se rompe por una red a la que nadie concedió la importancia que tenía.
Y eso fastidia bastante más cuando el problema lo has diseñado tú mismo por comodidad.
Referencias#
- Cluster Manager de Proxmox
- Requisitos de red en Proxmox VE
- Post relacionado: Proxmox cluster de 3 nodos en mini PCs: lo que haría distinto después de montarlo en casa
- Post relacionado: Ceph en homelab: cuándo merece la pena y cuándo solo te roba horas
- Post relacionado: Proxmox HA: alta disponibilidad para tus VMs sin infraestructura enterprise