🔄 Replanteando el plan (otra vez)

🌐 También en: English · Deutsch · Français

Pues nada… ha vuelto a pasar 😄

Después de escribir el plan original y darle unas cuantas vueltas a la arquitectura, empecé a cuestionar algunas de mis decisiones. Eso es lo bonito de un homelab: nada está escrito en piedra. La gracia está precisamente en iterar, aprender y, a veces, reconstruirlo todo desde cero.

Así que sí: el plan de reconstrucción ha cambiado. Otra vez.

Se parece muchísimo a ese momento clásico del Monopoly: estás delante del tablero, caes en «Vuelve a la casilla de salida», refunfuñas y te das cuenta de que te toca montarlo todo de nuevo desde el principio… 😅🎲

🪟 La verdad es que Windows funcionaba genial

Windows 11 en mis ordenadores de sobremesa funcionó de maravilla. El soporte de hardware era excelente, había drivers para todo y la integración con la infraestructura de Windows Server se comportaba tal como esperaba. Active Directory, DNS, carpetas compartidas y GPO siguen siendo un ecosistema muy maduro, y técnicamente todo funcionaba a la perfección.

De hecho, tuve esta configuración de Windows funcionando durante semanas sin ningún problema. Llegué a plantearme en serio montar una infraestructura informática doméstica híbrida: Windows 11 y Windows Server para clientes y servicios de servidor, y Linux y Kubernetes para otras cargas de trabajo.

Sin embargo, me di cuenta de que quiero volver a Linux como núcleo de mi homelab. Linux me resulta simplemente más familiar: a lo largo de los años he acumulado mucha más experiencia con él. Windows y Windows Server pertenecen a otro mundo, uno en el que nunca he tenido demasiada experiencia práctica, y ahora mismo no quiero abrir un nuevo «proyecto» en ese terreno. Quizá en otra vida. 😄

Así que esta no es la historia de «Windows fracasó»: funcionó de lujo. Pero en mi camino personal con el homelab, el protagonista será Linux. 🐧

🌍 Vuelta a Linux y soberanía digital

Mi homelab está muy ligado a unos cuantos principios personales:

• 🐧 Software de código abierto
• 🔐 Control sobre mi propia infraestructura
• 🌍 Menos dependencia de los grandes ecosistemas centrados en EE. UU.
• 🧠 Aprender tecnologías alineadas con las plataformas Linux modernas

Aunque Windows funciona muy bien, poco a poco va arrastrando la infraestructura de vuelta al ecosistema de Microsoft. Para mi camino de aprendizaje y mi filosofía personal, prefiero quedarme en el mundo del código abierto.

Así que Microsoft vuelve a salir del homelab. Del todo. 🐧

🧠 Otra observación: mi tercer servidor se aburría

Al repasar el diseño original me di cuenta de que uno de mis servidores iba a pasarse la mayor parte del tiempo de brazos cruzados. Dedicar una máquina solo al almacenamiento y a un par de servicios no justifica el hardware.

Los servidores tienen que sudar un poco. 💻🔥

En lugar de asignar un rol fijo a cada máquina física, decidí pasarme a una arquitectura más flexible.

🧱 Clúster Proxmox sin sistema de archivos compartido

Para mi homelab estoy montando un clúster Proxmox de tres nodos, pero sin un sistema de archivos distribuido como CephFS. Cada nodo usará su almacenamiento SSD local para los datos de las VM. Uno de mis servidores tiene un pool RAID5 para almacenamiento de mayor tamaño, pero ahí estoy dispuesto a hacer algunas concesiones.

Otra razón para prescindir de CephFS: mi red doméstica va a solo 1 Gbit/s, muy por debajo del ancho de banda recomendado para que CephFS rinda bien (normalmente >10 Gbit/s). Un clúster de almacenamiento compartido sería más un cuello de botella que una ventaja.

El motivo principal del clúster es la gestión centralizada: una única interfaz web con un solo inicio de sesión para los tres servidores. Más adelante también quiero migrar VM entre nodos en modo offline para repartir la carga y aprovechar mejor el hardware, sin tocar ningún almacenamiento compartido.

En resumen: clúster = comodidad + flexibilidad, no almacenamiento distribuido. 💻⚡

🖥️ Hardware y arquitectura de servidores

Ahora todos los nodos participan de lleno en el clúster y aportan cómputo y almacenamiento según haga falta.

💾 Instalación de Proxmox: ZFS en el disco del sistema

Para los propios hosts Proxmox elegí ZFS en el disco del sistema operativo.

• Opciones de sistema de archivos: ext4, XFS, ZFS → elegí ZFS
• Un solo SSD por host para el sistema operativo
• Pool RAID0 (un solo disco, sin redundancia) para las VM

ZFS trae funciones de almacenamiento de nivel empresarial incluso a un homelab pequeño. 💾

⚙️ Ajustes de ZFS

• Compresión: lz4 → rápida, con una sobrecarga de CPU mínima, ahorra un 20–40 % de espacio
• Ashift: 12 → bloques de 4K, lo mejor para SSD modernos
• Sumas de comprobación: activadas → protegen contra la corrupción silenciosa (bitrot)

🧹 Activar TRIM en los SSD

zpool set autotrim=on vmdata

Mantiene el rendimiento de los SSD a lo largo del tiempo liberando los bloques que no se usan. 🚀

🧠 Nodo Proxmox 1 (PVE1)

• Sistema: HP DL20 Gen10+
• RAM: 64 GB
• iLO: 192.168.10.x
• Host Proxmox: 192.168.10.x

Almacenamiento

• SSD de 512 GB – SO / VM de infraestructura
• SSD de 2 TB – datos de las VM (pool ZFS RAID0)

VM de infraestructura

☸️ Clúster Kubernetes – parte 1

🧠 Nodo Proxmox 2 (PVE2)

• Sistema: HP DL20 Gen10+
• RAM: 32 GB
• iLO: 192.168.10.x
• Host Proxmox: 192.168.10.x

Almacenamiento

• SSD de 512 GB – SO / VM de infraestructura
• SSD de 2 TB – datos de las VM (pool ZFS RAID0)

VM de infraestructura

☸️ Clúster Kubernetes – parte 2

🧠 Nodo Proxmox 3 (PVE3)

• Sistema: HP MicroServer Gen10+ V2
• Rol: nodo del clúster Proxmox + almacenamiento de VM

Almacenamiento

• 3 SSD de 2 TB – pool ZFS RAIDZ1

Servicios de infraestructura

☸️ Clúster Kubernetes – parte 3

💾 Crear los pools ZFS para el almacenamiento de las VM

Resumen de los pools de almacenamiento:

• PVE1 & PVE2 → un solo SSD, ZFS RAID0 (sin redundancia)
• PVE3 → un solo SSD, ZFS RAID0 (sin redundancia) + tres SSD, ZFS RAIDZ1 (protegido por paridad)

En las secciones anteriores tienes los comandos completos y el tuning (compresión lz4, ashift=12, sumas de comprobación activadas, atime desactivado).

🏁 Clúster y migración offline de VM

Los tres nodos forman ya un único clúster Proxmox. Cada uno conserva su pool ZFS local: no hace falta almacenamiento compartido. La migración offline de VM permite repartir la carga y aprovechar mejor el hardware, mientras que la interfaz central hace que la administración sea cómoda. 💻⚡

🔁 Planificando la replicación y las copias de seguridad de las VM

En el próximo artículo me meteré a fondo con la replicación y las copias de seguridad de las VM:

• Replicar todas las VM de PVE1 → PVE2 y viceversa
• Hacer copia de seguridad de todas las VM en el Proxmox Backup Server de PVE3

Ahora mismo estoy pensando en usar primero Terraform para volver a desplegar las VM. La replicación vendrá después. Sus principales ventajas: las VM arrancan más rápido al mover cargas de trabajo y hay redundancia adicional antes incluso de las copias de seguridad. 😎

🏁 Conclusión actualizada

• 🐧 Infraestructura solo con Linux
• 🧱 Clúster Proxmox de 3 nodos
• ☸️ Kubernetes como plataforma central de aprendizaje
• 📦 Mejor aprovechamiento del hardware
• 🧠 Fuerte apuesta por herramientas de código abierto

Menos Microsoft. Más Linux. Más contenedores.

La frase «esta será la arquitectura definitiva del homelab» suele ser el comienzo de la siguiente reconstrucción. 😄

📝 Nota: el nombre del juego de mesa de la imagen destacada está difuminado a propósito, ya que es una marca registrada de terceros.