Montar un cluster Proxmox con mini PCs es una de esas ideas que parecen redondas en la cabeza. Bajo consumo, poco ruido, varios nodos, migraciones, alta disponibilidad, almacenamiento distribuido, panel único y esa sensación de tener una mini infraestructura seria en casa. Sobre el papel suena casi demasiado bien.
Luego aparece la realidad: adaptadores de red que no rinden igual, discos NVMe con temperaturas alegres, cables que parecen inocentes, quorum, Ceph, backups, actualizaciones, nodos que no arrancan cuando deberían y una pregunta que vuelve cada cierto tiempo: ¿esto lo monté para resolver un problema o para fabricarme uno más bonito?
No me arrepiento de haberlo hecho. He aprendido muchísimo montando clusters Proxmox con mini PCs. Pero si lo plantease ahora, cambiaría varias cosas desde el día uno.
Error 1: empezar por el cluster en vez de por las cargas#
El primer error es pensar en nodos antes que en servicios.
Un cluster no debería existir porque tienes tres mini PCs. Debería existir porque tus cargas se benefician de estar en un cluster. Parece una diferencia pequeña, pero cambia todo.
Si lo que quieres correr son cuatro contenedores, un gestor de contraseñas, un DNS, un dashboard y alguna VM puntual, quizá no necesitas cluster. Necesitas un nodo estable, buenas copias y una forma clara de restaurar. Si quieres mover VMs entre nodos, mantener servicios durante mantenimiento, probar HA o repartir cargas reales, entonces sí empieza a tener sentido.
Yo ahora haría una lista antes de instalar nada:
- Qué servicios son críticos.
- Qué servicios pueden estar caídos unas horas.
- Qué servicios necesitan migración en caliente.
- Qué datos no puedo perder.
- Qué cargas consumen CPU, RAM o disco de verdad.
- Qué cosas son solo laboratorio.
Sin esa lista, el cluster se diseña para una fantasía. Y las fantasías escalan fatal.
Error 2: subestimar la red#
Proxmox funciona con una red normal. Un cluster Proxmox serio no debería depender de una red improvisada.
En mini PCs, la tentación es usar lo que viene: una o dos interfaces Ethernet, quizá 2.5 GbE, quizá algún adaptador USB si falta algo. Para servicios simples vale. Para cluster con almacenamiento distribuido, backups y migraciones, la red empieza a importar muchísimo.
Corosync quiere estabilidad. Ceph quiere latencia baja y ancho de banda. Las migraciones agradecen una red que no se ahogue. Los backups no deberían pelearse con el tráfico normal de casa. Si todo va por la misma interfaz y el mismo switch sin pensar, funcionará hasta que un día haga algo pesado y empiece el festival.
Mi planteamiento actual sería separar al menos tres planos lógicos:
- Gestión y acceso al panel.
- Tráfico de cluster.
- Tráfico de almacenamiento y backups.
No siempre hace falta separarlo físicamente con tarjetas dedicadas, pero sí pensarlo. VLANs, switches decentes, MTU coherente si se cambia, cables buenos y nombres claros. Lo importante es no descubrir la arquitectura de red cuando algo ya está fallando.
Y evitaría depender de adaptadores USB para lo serio. Pueden salvar una prueba, pero no me gusta que el corazón del cluster dependa de un dongle que un día decide desaparecer.
Error 3: creer que Ceph es gratis porque viene integrado#
Ceph en Proxmox es comodísimo de desplegar. Eso es bueno y peligroso.
Es bueno porque baja la barrera de entrada. En pocos pasos puedes tener almacenamiento distribuido, replicación y migraciones con una sensación muy potente. Es peligroso porque Ceph no deja de ser Ceph. Necesita discos adecuados, red adecuada, memoria, CPU, monitorización y una cabeza que entienda qué está pasando cuando el estado no es verde.
En mini PCs, Ceph puede tener sentido si cada nodo tiene NVMe decente, buena red y aceptas el coste. Pero no lo montaría por defecto. Para muchos homelabs, un NAS con backups buenos o almacenamiento local replicado de forma simple puede ser más sensato.
El error no es usar Ceph. El error es usarlo sin una razón clara.
Yo me haría estas preguntas antes:
- ¿Necesito migración en caliente de VMs con disco compartido?
- ¿Acepto perder capacidad útil por la réplica?
- ¿Tengo red suficiente para no odiarlo?
- ¿Sé recuperar el cluster si un OSD cae?
- ¿Tengo backups fuera de Ceph?
La última pregunta es la más importante. Ceph no sustituye backups. Ceph te protege de ciertos fallos de disco o nodo, no de borrar datos, romper una VM, cifrado accidental, corrupción lógica o una mala decisión humana a medianoche.
Error 4: confundir HA con tranquilidad#
La alta disponibilidad en Proxmox mola. Ver una VM moverse o reiniciarse en otro nodo cuando algo falla da una sensación estupenda. Pero HA no elimina problemas. Los mueve.
Para que HA tenga sentido, necesitas que la VM pueda correr bien en otro nodo, que el almacenamiento esté disponible, que la red esté bien, que el quorum aguante y que las prioridades estén pensadas. Si metes todo en HA sin criterio, puedes conseguir que un fallo pequeño provoque una coreografía absurda.
En casa, no todo merece HA. DNS quizá sí, aunque muchas veces prefiero redundancia simple con dos instancias. Home Assistant depende. Un gestor de contraseñas puede merecer más cuidado, pero también necesita backups y pruebas de restauración. Un dashboard bonito no necesita HA. Una VM de pruebas tampoco.
Mi regla actual: HA solo para servicios donde el reinicio automático en otro nodo aporta más que la complejidad que introduce.
Y aun así, probaría fallos reales. Apagar un nodo de forma controlada, cortar una ruta de red de laboratorio, reiniciar durante mantenimiento, validar que las VMs vuelven y revisar qué se rompe. Si no lo has probado, no tienes HA. Tienes esperanza configurada.
Error 5: no tratar los mini PCs como máquinas con límites#
Los mini PCs modernos son una barbaridad para lo que consumen. Pero tienen límites físicos.
El primero es temperatura. Un NVMe dentro de una caja pequeña puede calentarse mucho más de lo que parece. Si encima le pides trabajo constante con VMs, backups o Ceph, las temperaturas importan. No basta con que el sistema arranque. Tiene que sostener carga.
El segundo es expansión. Muchos mini PCs tienen uno o dos NVMe, quizá SATA interno, quizá 2.5 GbE, quizá USB4. Está genial para un nodo compacto, pero no puedes pedirles que se comporten como servidores con bahías, HBA, NICs múltiples y refrigeración generosa.
El tercero es fuente de alimentación. En un rack casero acabas con varias fuentes pequeñas, regletas, UPS y cables. No es grave, pero conviene ordenarlo. Una infraestructura de tres nodos puede depender de tres ladrillos de corriente bastante poco elegantes.
Si empezase hoy, compraría menos modelos distintos. Tener nodos parecidos simplifica RAM, discos, fuentes, BIOS, consumo, temperaturas y repuestos. Mezclar hardware es divertido. Mantenerlo no tanto.
Error 6: backups pensados después#
Este es el clásico. Montas el cluster, te emocionas con migraciones, storage, redes y paneles. Los backups quedan para después porque todavía estás “probando”. Ese después es una trampa.
Los backups deberían diseñarse antes de meter servicios importantes. No al final.
En un cluster Proxmox, para mí lo mínimo es tener copias programadas fuera del almacenamiento principal, retención razonable y pruebas de restauración. No solo ver que el job termina en verde. Restaurar una VM o un contenedor en un entorno de prueba y confirmar que arranca.
También separaría tipos de datos. No es lo mismo una VM completa que documentos familiares, fotos, bases de datos o configuraciones. Una copia de VM puede ser cómoda, pero algunas aplicaciones necesitan dumps consistentes o exportaciones propias.
Y guardaría documentación de recuperación fuera del propio cluster. Si la guía para restaurar vive en una VM caída dentro del cluster roto, enhorabuena, has inventado el candado dentro de la caja.
Error 7: no poner límites al laboratorio#
Un cluster invita a probar. Esa es la gracia. También es el peligro.
Si producción y laboratorio viven demasiado cerca, un experimento acaba tocando algo que no debería. Una VLAN mal puesta, una regla de firewall demasiado generosa, una VM con acceso a almacenamiento bueno, un contenedor que empieza a consumir más de la cuenta. No hace falta un desastre enorme. Basta con pequeñas molestias repetidas.
Yo ahora separaría desde el principio:
- Recursos para producción doméstica.
- Recursos para laboratorio.
- Red de pruebas.
- Almacenamiento de pruebas.
- Backups de servicios reales.
No hace falta comprar otro rack. Hace falta poner límites. Nombres claros, pools claros, etiquetas, permisos y reglas. El laboratorio debe poder arder sin llevarse las fotos, el DNS o los documentos.
Error 8: documentar cuando ya se ha complicado#
La documentación del homelab siempre parece menos urgente que montar algo nuevo. Hasta que necesitas recordar por qué un nodo tiene una BIOS distinta, qué VM dependía de qué storage, qué VLAN era la de backups o qué servicio no se podía mover sin cambiar una ruta.
No hablo de escribir una enciclopedia. Hablo de una página viva con:
- Nodos y hardware básico.
- Redes y VLANs.
- Servicios críticos.
- Ubicación de backups.
- Dependencias raras.
- Procedimiento de restauración.
- Cosas que no tocar sin revisar antes.
Esa página vale oro cuando estás cansado. Y casi todos los errores caros pasan cuando estás cansado.
Cómo lo plantearía ahora#
Si tuviera que montar un cluster Proxmox con mini PCs desde cero, empezaría pequeño.
Primero un solo nodo bien elegido, con RAM suficiente, NVMe decente, red fiable y backups funcionando. Ahí montaría los servicios base y validaría consumo, ruido, temperaturas y restauración.
Después añadiría un segundo nodo si necesito mantenimiento más cómodo o separación de cargas. No para decir que tengo cluster, sino para resolver algo concreto.
El tercer nodo lo añadiría cuando el quorum, HA o Ceph lo justifiquen. Y antes de Ceph, probaría si realmente necesito almacenamiento distribuido. Muchas veces un diseño más aburrido gana: storage central, backups buenos, replicación sencilla y servicios preparados para reconstruirse.
Para red, usaría switch gestionable desde el principio, VLANs mínimas y nombres humanos. Para HA, pocos servicios y pruebas reales. Para laboratorio, separación clara. Para monitorización, alertas escasas y útiles.
La compra de hardware la haría con una regla: si un nodo no tiene un rol definido antes de llegar, no lo compro todavía.
Lo que sí volvería a hacer#
Volvería a usar Proxmox. Sigue siendo una herramienta fantástica para homelab. El panel es claro, las copias están bien integradas, LXC y VMs conviven muy bien, y el cluster te da margen para aprender cosas que en un servidor único no aparecen.
Volvería a usar mini PCs, pero con más criterio. Consumo bajo, poco ruido y potencia suficiente son argumentos fuertes en casa. Solo evitaría convertirlos en algo que no son. No son servidores enterprise diminutos. Son máquinas compactas muy capaces si respetas sus límites.
Volvería a montar laboratorio, porque romper cosas controladamente enseña mucho. Pero lo aislaría mejor desde el inicio.
Y volvería a priorizar backups por encima de cualquier arquitectura elegante. Un cluster precioso sin restauración probada es una maqueta cara.
Mi conclusión#
Un cluster Proxmox con mini PCs merece la pena si sabes qué problema resuelve. Si lo montas solo porque puedes, también aprenderás, pero pagarás en horas, dudas y pequeñas averías.
La versión que más sentido me hace hoy es menos heroica: empezar por servicios, datos y red. Luego elegir nodos. Luego decidir si cluster. Luego decidir si HA. Luego decidir si Ceph. En ese orden.
La tecnología buena no te obliga a usar todas sus funciones. A veces el homelab mejora justo cuando dejas algunas sin tocar.