Escalabilidad y Despliegue Distribuido

NoxPanel está diseñado para escalar desde un único servidor hasta un clúster de múltiples nodos según las necesidades de cada proveedor. Este documento describe las estrategias de escalado disponibles, desde la configuración más sencilla hasta arquitecturas distribuidas de alta disponibilidad.

Arquitectura Actual

La configuración por defecto de NoxPanel consiste en un despliegue single-node orquestado con Docker Compose. Todos los servicios se ejecutan como contenedores en una única máquina:

Django (Gunicorn) como servidor de aplicación principal.
PostgreSQL 15 como base de datos relacional.
Redis 7 como broker de Celery, caché y backend de Channel Layers.
Celery Worker + Beat para tareas asíncronas y planificación periódica.
Nginx como proxy interno para servir estáticos y reenviar peticiones.
Traefik como reverse proxy externo con SSL/TLS automático (Let’s Encrypt).
Motor de hosting en contenedor dedicado con servicios web, mail, DNS y FTP.

Características del despliegue actual:

Todos los servicios definidos en docker-compose.yml con health checks.
Código montado por volumen para hot reloads en desarrollo.
Redes Docker separadas (traefik-public y noxpanel-internal).
Variables de entorno centralizadas en .env.

Note

Capacidad estimada: ~500 clientes de hosting y ~200 VMs en un nodo de 4 cores y 16 GB de RAM.

Escalado Vertical

La forma más sencilla de aumentar la capacidad es escalar verticalmente el servidor existente. No requiere cambios en la arquitectura ni en la configuración de NoxPanel.

Mejoras de hardware:

Aumentar RAM a 32 GB o más.
Añadir más cores de CPU (8+).
Usar SSDs NVMe para almacenamiento de bases de datos.

Ajustes de PostgreSQL:

# postgresql.conf - ajustes para 32 GB RAM
shared_buffers = 8GB
effective_cache_size = 24GB
work_mem = 256MB
maintenance_work_mem = 2GB
max_connections = 200

Ajustes de Redis:

# redis.conf
maxmemory 4gb
maxmemory-policy allkeys-lru

Ajustes de Celery:

# Aumentar concurrencia del worker
celery -A noxpanel worker --concurrency=4

Note

Capacidad estimada: ~1.000 clientes de hosting y ~500 VMs en un nodo de 8 cores y 32 GB de RAM.

Escalado Horizontal con Docker Swarm

Para superar los límites de un solo servidor, NoxPanel puede desplegarse en un clúster Docker Swarm con múltiples réplicas de los servicios stateless.

Componentes y réplicas:

Componente	Réplicas	Notas
`web` (Django / Gunicorn)	2-3	Stateless. Balanceo vía Traefik. Sesiones en Redis.
`celery_worker` (provisioning)	2	Cola dedicada a operaciones de aprovisionamiento de hosting y VMs.
`celery_worker` (billing)	1	Cola dedicada a facturación, cobros y webhooks de pasarelas de pago.
`celery_worker` (notifications)	1	Cola dedicada a envío de emails, alertas y notificaciones push.
`celery_beat`	1	Siempre una sola instancia (scheduler singleton).
`db` (PostgreSQL)	1 master + N read replicas	Escrituras al master. Lecturas distribuidas vía PgBouncer.
`redis`	3 (Sentinel)	Redis Sentinel para failover automático del broker.
`nginx`	2	Detrás de Traefik. Sirve estáticos desde almacenamiento compartido.
Motor de hosting	1+	Un contenedor por servidor de hosting (ver sección siguiente).

Configuración clave:

Sesiones en Redis: Django almacena sesiones en Redis, permitiendo que cualquier réplica web atienda peticiones de cualquier usuario.
PgBouncer: Connection pooler delante de PostgreSQL para gestionar conexiones de múltiples réplicas web y workers.
Almacenamiento compartido: Volumen NFS o GlusterFS para archivos estáticos y media accesibles por todas las réplicas.
Colas separadas de Celery: Cada tipo de worker consume de su propia cola para evitar interferencias entre módulos.

# Ejemplo docker-compose.swarm.yml (fragmento)
services:
  web:
    image: noxpanel:latest
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
        delay: 10s
      restart_policy:
        condition: on-failure

  celery_provisioning:
    image: noxpanel:latest
    command: celery -A noxpanel worker -Q provisioning --concurrency=4
    deploy:
      replicas: 2

  celery_billing:
    image: noxpanel:latest
    command: celery -A noxpanel worker -Q billing --concurrency=2
    deploy:
      replicas: 1

Note

Capacidad estimada: 1.000-5.000 clientes de hosting y ~2.000 VMs con un clúster de 3 nodos.

Motor de Hosting Distribuido

El motor de hosting soporta nativamente una arquitectura multi-servidor donde cada función se ejecuta en un nodo dedicado. NoxPanel se comunica exclusivamente con la API del panel master; el motor de hosting se encarga de distribuir la carga entre los nodos de cada rol.

Roles y nodos:

Rol	Imagen Docker	Recursos estimados	Función
Panel Master	`hosting-core:latest`	2 cores, 4 GB RAM	API de control. NoxPanel se conecta aquí.
Web Node	`hosting-web:latest`	4 cores, 8 GB RAM	Apache/Nginx, PHP-FPM. Sirve los sitios web.
Mail Node	`hosting-mail:latest`	2 cores, 4 GB RAM	Postfix + Dovecot. Envío y recepción de correo.
DNS Node	`hosting-dns:latest`	1 core, 1 GB RAM	BIND. Resolución de nombres para dominios alojados.
DB Master	`hosting-db:latest`	4 cores, 8 GB RAM	MySQL/MariaDB para las bases de datos de los clientes.

Conexión entre nodos:

Cada nodo se configura mediante variables de entorno que apuntan al panel master y definen su rol:

# Variables de entorno del nodo Web
DB_HOST=db-master.internal
PANEL_HOST=panel.internal
SERVER_TYPE=web

# Variables de entorno del nodo Mail
DB_HOST=db-master.internal
PANEL_HOST=panel.internal
SERVER_TYPE=mail

Funcionamiento:

NoxPanel solo necesita conocer la URL de la API del panel master.
El panel master coordina la distribución de sitios, cuentas de correo, zonas DNS y bases de datos entre los nodos correspondientes.
Se pueden añadir nodos adicionales de cada rol según la demanda.

Warning

Las herramientas de despliegue distribuido del motor de hosting están actualmente en desarrollo. La documentación de esta sección describe la arquitectura objetivo.

Note

Capacidad estimada: 10.000+ clientes de hosting con un clúster de 5-10 nodos especializados por rol.

Clúster Proxmox

Para el módulo de VMs, Proxmox VE soporta nativamente clustering, lo que permite escalar la capacidad de virtualización sin cambios en NoxPanel.

Características del clúster Proxmox:

API REST unificada: NoxPanel se comunica con la API REST de Proxmox. Añadir nodos al clúster Proxmox es transparente para NoxPanel.
Migración en caliente: Las VMs pueden migrarse entre nodos del clúster sin downtime.
Alta Disponibilidad (HA): Proxmox HA gestiona el failover automático de VMs. Si un nodo cae, las VMs se reinician automáticamente en otro nodo.
Almacenamiento distribuido: Ceph o ZFS replicado para que las VMs sean accesibles desde cualquier nodo del clúster.

Integración con NoxPanel:

Cada nodo Proxmox se registra en NoxPanel como un recurso disponible.
Los planes de VMs pueden asignarse a nodos o pools específicos.
NoxPanel consulta el estado de los nodos vía API para balancear la creación de nuevas VMs.
No se requieren cambios en el código de NoxPanel para añadir nodos Proxmox.

Note

Capacidad estimada: 10.000+ VMs distribuidas en múltiples nodos Proxmox con alta disponibilidad.

Resumen de Capacidades

Modo	Clientes Hosting	VMs	Requisitos
Single Node	~500	~200	4 cores, 16 GB RAM
Vertical	~1.000	~500	8 cores, 32 GB RAM
Swarm	1.000-5.000	~2.000	3 nodos (mínimo)
Distribuido	10.000+	10.000+	5-10 nodos especializados

Las cifras son estimaciones orientativas basadas en cargas de trabajo típicas de hosting compartido y VMs pequeñas/medianas. El rendimiento real depende del perfil de uso de cada instalación.