El stack completo: arquitectura de referencia para un DC pequeño

Cómo se conecta todo y por qué cada pieza importa

La vista completa

Los cinco artículos anteriores construyeron cada capa de forma independiente. Este muestra la arquitectura completa: componentes, interacciones y las decisiones de diseño detrás de cada elección.

Figura 6 — Arquitectura completa: capas de cómputo, backup, servicios y VMs. IPs de ejemplo (10.0.x.x).

Inventario del stack

• nodo1 (10.0.0.11), nodo2 (10.0.0.12), nodo3 (10.0.0.13) — Cluster Proxmox VE + Ceph
• pbs01 (10.0.0.20) — Proxmox Backup Server dedicado, fuera del cluster
• ipam01 (10.0.0.30) — phpIPAM
• pdns01 (10.0.0.31) — PowerDNS Authoritative + Recursor
• ca01 (10.0.0.40) — Step-CA, ACME interno para *.lab.internal

El flujo cuando creás una VM nueva

1. Proxmox asigna la VM al nodo con menos carga
2. El disco se crea en el pool Ceph — replicado en los 3 nodos automáticamente
3. SDN asigna una IP desde phpIPAM (subred correcta según VLAN)
4. El plugin PowerDNS registra el A record en pdns01 (nombre → IP)
5. Al primer boot, el agente puede solicitar certificado a ca01 via ACME
6. PBS hace backup en el horario configurado con verificación automática

Todo sin intervención manual. El operador solo define nombre, VLAN y tamaño de disco.

Decisiones de diseño y sus trade-offs

¿Por qué Ceph y no NFS?

NFS introduce un SPOF. Ceph distribuye los datos entre todos los nodos — si uno cae, el storage sigue disponible. El costo: complejidad de operación y consumo de RAM por OSD.

¿Por qué PBS separado del cluster?

Un backup que vive en el mismo cluster que protege no es un backup real. Si el cluster tiene un problema grave, PBS debe ser independiente. El hardware dedicado también permite discos más baratos y de mayor capacidad.

¿Por qué Step-CA y no Let’s Encrypt?

Los dominios *.lab.internal no son accesibles desde internet — Let’s Encrypt no puede validarlos. Step-CA actúa como Let’s Encrypt privado: misma experiencia operativa sin exposición pública.

¿Por qué phpIPAM + PowerDNS en lugar de /etc/hosts?

A partir de 20+ VMs, /etc/hosts es inmanejable. phpIPAM + PowerDNS dan trazabilidad, previenen colisiones de IP y permiten resolución por nombre desde cualquier nodo del lab.

Requisitos de hardware para este stack

• 3 nodos Proxmox: mínimo 32GB RAM, 1 disco SO, 1+ discos OSD para Ceph, 2 NICs 10G
• 1 nodo PBS: 16GB RAM, 1 disco SO, 4+ discos de alta capacidad para storage ZFS
• VMs de infraestructura (pdns, phpIPAM, ca01): 2–4 vCPU y 2–4GB RAM cada una, corriendo en el propio cluster

Este stack puede correr perfectamente en hardware de segunda mano o servidores de rack generación 12–14. El costo de entrada es bajo comparado con soluciones comerciales equivalentes.

Lo que este stack no hace

• No tiene HA geográfica — todos los nodos en el mismo rack o datacenter
• Ceph con 3 nodos no aguanta 2 fallas simultáneas (replica size=3, min_size=2)
• PBS no hace backup offsite automático — para eso se necesita S3/rsync a destino externo
• No hay monitoreo integrado en esta arquitectura — material para otra serie

Conclusión

Construir este stack desde cero toma tiempo, pero cada componente tiene una razón de ser. No es overengineering para un homelab o una PyME — es la diferencia entre una infraestructura que aguanta y una que da trabajo cuando más molesta.

Si llegaste hasta acá leyendo la serie completa, tenés todo lo necesario para replicarlo. Si tenés preguntas sobre algún paso específico, te invito a me contactes.