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:** .. code-block:: ini # 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:** .. code-block:: ini # redis.conf maxmemory 4gb maxmemory-policy allkeys-lru **Ajustes de Celery:** .. code-block:: bash # 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:** .. list-table:: :header-rows: 1 :widths: 25 15 60 * - 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. .. code-block:: yaml # 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:** .. list-table:: :header-rows: 1 :widths: 20 25 20 35 * - 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: .. code-block:: bash # 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 ----------------------- .. list-table:: :header-rows: 1 :widths: 20 20 15 45 * - 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.