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.
Mi resumen corto es este. En casa no reparto VMs para que todo quede equilibrado en una captura. Las reparto para que el cluster aguante mejor cuando algo falla, cuando toca tocar hardware o cuando me entra la brillante idea de probar otra cosa a las once de la noche.
El error de querer repartir por número y no por comportamiento#
Cuando empiezas, es muy fácil caer en la métrica equivocada. Tienes tres nodos, así que te parece lógico poner más o menos las mismas VMs y contenedores en cada uno. El problema es que dos máquinas no pesan lo mismo solo porque ocupen dos filas en la lista.
Una VM de observabilidad, una de Home Assistant y un firewall no juegan el mismo partido. Tampoco lo hacen un contenedor ligero que apenas respira y otro que tira de disco o red sin avisar. Si repartes por contar cajas en vez de por entender comportamiento, el cluster parece equilibrado hasta que la vida real empieza a tocarlo.
Yo ahora me fijo bastante más en estas preguntas.
- Qué servicios son críticos de verdad.
- Qué servicios tragan RAM aunque estén medio quietos.
- Qué cargas hacen ruido de disco o red.
- Qué máquinas puedo mover sin drama y cuáles prefiero dejar quietas.
- Cuánto margen me queda si mañana apago un nodo.
Ese último punto es el que más manda. Un reparto que solo funciona mientras todo está encendido no es un gran reparto. Es una tregua.
Así se ve una parte del reparto real en mi cluster#
Esta captura está saneada, pero sale de un nodo real de mi laboratorio. He cambiado nombres porque no necesito regalar inventario interno, aunque la distribución general sí es de verdad.
Lo interesante no es que haya VMs y contenedores mezclados. Lo interesante es que esa mezcla responde a una lógica concreta. Las VMs que quiero más aisladas o que me interesa tratar con más cuidado van a KVM. Los servicios pequeños, persistentes y relativamente previsibles suelen acabar en LXC. Parece obvio, pero verlo así de claro me costó bastante más de lo que me gustaría admitir.
También me apoyo mucho en el perfil de cada nodo. Este resumen saneado refleja bastante bien el tipo de diferencia con el que convivo.
Cuando ves números así, la fantasía de repartir todo por igual pierde bastante sentido. No tengo tres nodos idénticos, así que no actúo como si lo fueran. Intentarlo solo sirve para pelearte con la realidad.
La regla que más me ha ayudado, el nodo fuerte tiene que notar que lo es#
En mi cluster hay nodos más capaces que otros. Eso no es un problema. El problema sería ignorarlo en nombre de una simetría que solo existe en mi cabeza.
Si un nodo tiene más memoria, más CPU útil o simplemente un comportamiento más sólido para ciertas cargas, lo uso como tal. Ahí coloco las VMs más tragona, la observabilidad más pesada o las piezas que sé que van a tener más actividad. Prefiero que el nodo potente trabaje como nodo potente en vez de infrautilizarlo para que el reparto parezca elegante.
Esto tiene dos ventajas muy claras.
La primera es que reduces migraciones absurdas. No estás moviendo una carga pesada a un nodo peor solo para equilibrar la tabla. La segunda es que dejas muy claro cuál es tu colchón operativo. Si sé qué nodo carga con lo gordo y cuáles van más holgados, sé también qué pasa cuando me llevo uno por delante para mantenimiento.
No todo merece ser una VM#
Otra cosa que cambió mucho mi reparto fue dejar de convertir cada servicio pequeño en una VM por costumbre. Durante una temporada me parecía más limpio meter casi todo en máquinas virtuales. Más aislamiento, más orden mental, más sensación de control. Luego miré consumo, administración y tiempo perdido, y se me pasó bastante el romanticismo.
En un homelab, LXC resuelve muchísimas cosas con menos sobrecarga. AdGuard, un pequeño mirror, algún servicio web ligero, utilidades de red, piezas que quiero tener encendidas siempre y que no necesitan todo el teatro de una VM completa. Ahí LXC me parece fantástico.
Yo reservo VM para varios casos muy concretos.
- Sistemas donde quiero aislamiento más fuerte.
- Appliances que ya vienen pensadas para VM.
- Servicios donde el kernel propio o el stack completo me simplifican la vida.
- Cosas que sé que voy a restaurar, migrar o tocar con una lógica distinta.
Cuanto mejor haces esa separación, mejor sale el reparto. Porque ya no estás jugando al Tetris con bloques equivalentes. Estás colocando piezas con distinto peso y distinto coste operativo.
El reparto real no se diseña para días tranquilos#
Esta es probablemente la idea más importante del artículo. Yo no distribuyo servicios pensando en un martes bonito donde todos los nodos están online y yo no toco nada. Los distribuyo pensando en el día menos simpático.
Ese día puede ser muy normal.
Un NVMe empieza a dar mala espina. Quiero reiniciar un nodo porque he tocado BIOS. Necesito ampliar RAM. Me entra la vena de actualizar Proxmox. O, simplemente, un servicio se pone pesado justo cuando otro nodo no está disponible.
Si el reparto solo tiene sentido en condiciones ideales, no vale gran cosa. Por eso ahora dejo margen. A propósito. No porque me sobre tiempo ni hardware, sino porque he comprobado que el margen compra tranquilidad.
Tener un nodo con respiración suficiente para absorber parte de otra carga es mucho más útil que tener tres nodos aparentemente equilibrados pero todos al límite amable. Ese tipo de equilibrio se rompe en cuanto le quitas una pata.
Cómo decido qué va junto y qué prefiero separar#
Aquí no sigo una fórmula perfecta, pero sí algunos criterios que me funcionan bastante bien.
Junto cosas con ritmos parecidos#
Si dos servicios son tranquilos, persistentes y más o menos previsibles, no me importa que compartan nodo. De hecho lo prefiero, porque así dejo otros nodos para cosas más nerviosas.
Separo las piezas que me pueden fastidiar el mantenimiento#
Hay servicios que no son necesariamente muy pesados, pero me molestaría perder a la vez. Esos los separo aunque el consumo no lo exija. A veces la disponibilidad práctica pesa más que la eficiencia bonita.
No apilo ruido sobre ruido#
Si una VM ya hace bastante disco o bastante red, intento no acompañarla de otra que también tenga picos feos. No hace falta esperar al desastre para entender que dos vecinos ruidosos no mejoran por estar juntos.
Evito enamorarme de un reparto temporal#
Esto me parece importante. Un reparto que hoy funciona puede dejar de tener sentido dentro de dos meses. Nuevos servicios, más datos, cambios de hábitos, otro nodo que mejora, uno que se queda corto. Intento revisar el mapa de vez en cuando y asumir que no estoy diseñando una catedral.
Lo que hago para no convertir un nodo en el pringado permanente#
El título del artículo viene de aquí porque pasa muchísimo. Si no vigilas, siempre hay un nodo que acaba con “lo pesado”, “lo urgente”, “lo que ya moveré” y “lo que no me atrevo a tocar ahora”. De repente tienes un anfitrión esclavo del resto y te preguntas por qué da mala espina reiniciarlo.
Yo intento evitarlo con tres normas bastante simples.
La primera, si un nodo se vuelve el cajón desastre, paro y reviso. No lo dejo escalar por inercia.
La segunda, cualquier servicio nuevo entra con una pregunta previa. Si mañana apago este nodo, qué me llevo por delante y cuánto me fastidia.
La tercera, reservo al menos un poco de dignidad para cada nodo. No todos tienen que estar igual, pero ninguno debería acabar siendo el vertedero donde cae todo lo incómodo.
Parece una tontería de organización, pero en realidad es una forma muy práctica de planificar mantenimiento. Los clusters caseros se degradan mucho más por acumulación de excepciones que por una mala decisión única.
La alta disponibilidad no te salva de un reparto torpe#
Tener HA ayuda, claro. Me gusta mucho y la uso. Pero no conviene venderse cuentos. HA no arregla una mala colocación de cargas. Solo reacciona cuando ya has tenido el problema.
Si un nodo concentra demasiadas cosas importantes, demasiado consumo o demasiadas piezas que preferirías no perder a la vez, la existencia de HA no convierte esa apuesta en una buena idea. Te da una red de seguridad. No te da criterio.
Por eso creo que el reparto sigue siendo una decisión humana y bastante artesanal, incluso en clusters más maduros. La interfaz de Proxmox hace muchas cosas muy bien, pero no sabe qué servicio te duele más si se cae, cuál tolera reinicio o cuál no quieres tocar justo antes de cenar.
Lo que haría si montara hoy el cluster desde cero#
Si empezara mañana con tres nodos, estas serían mis reglas desde el primer día.
- Un nodo claramente orientado a cargas más pesadas.
- Un nodo pensado para servicios persistentes pero tranquilos.
- Un nodo con margen real para mantenimiento y movimientos.
- LXC para servicios pequeños que no necesitan VM.
- Nada de llenar memoria por orgullo estadístico.
- Revisión periódica del reparto antes de que duela.
También documentaría mejor el porqué de cada colocación. No hace falta un tratado. Basta con poder leer dentro de dos meses por qué un servicio vive donde vive. Cuando no lo haces, acabas mirando la lista de VMs como si la hubiera montado otra persona con resaca.
Mi criterio de éxito no es la simetría, es la tranquilidad#
Esto es lo que de verdad ha cambiado mi forma de repartir servicios. Antes quería un cluster equilibrado. Ahora quiero un cluster predecible.
Predecible significa que sé qué nodo tocaría primero si necesito margen. Sé qué servicios puedo mover rápido. Sé cuáles no me conviene juntar. Sé cuál va más holgado y cuál ya está haciendo su trabajo principal. No necesito que la captura quede perfecta. Necesito que el sistema no me haga perder media noche cuando quiero cambiar un SSD o reiniciar por una actualización.
En un laboratorio doméstico, esa paz vale muchísimo más que cualquier equilibrio cosmético.
Mi conclusión después de bastantes pruebas y algún que otro capricho técnico#
Repartir VMs y contenedores en Proxmox no va de hacer justicia matemática entre nodos. Va de entender el carácter de cada carga y el carácter de cada máquina. Cuando aceptas eso, el cluster mejora bastante.
Yo ya no persigo la idea de que todo quede compensado al céntimo. Persigo algo más útil. Que el nodo fuerte haga de nodo fuerte. Que los servicios ligeros no ocupen una VM si no la necesitan. Que siempre quede aire para mantenimiento. Y que ninguna caja se convierta, por pura dejadez, en el pringado oficial de la infraestructura.
¿Es perfecto? Ni de lejos. El reparto cambia, los servicios crecen y yo mismo me traiciono de vez en cuando con alguna decisión cómoda que luego toca deshacer. Pero precisamente por eso me parece importante decirlo claro. Un buen reparto en Proxmox no es una foto final. Es una disciplina pequeña y constante.
Y en casa, donde casi todo empieza como experimento y acaba siendo útil de verdad, esa disciplina marca bastante más diferencia de la que parece.
Referencias#
- Documentación de máquinas virtuales en Proxmox VE
- Documentación de contenedores LXC 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: Proxmox HA: alta disponibilidad para tus VMs sin infraestructura enterprise
- Post relacionado: Ceph en homelab: cuándo merece la pena y cuándo solo te roba horas