Artículos Guías Manuales Sistemas Linux Windows Redes MySql Binario 0 Binario Cero
En entornos de producción, garantizar la alta disponibilidad (HA) y el balanceo de carga es crucial para mantener servicios web confiables y escalables. Una solución práctica es utilizar dos servidores Nginx en paralelo, asegurando que si uno falla, el otro continúe atendiendo solicitudes sin interrupciones.
Este artículo describe las arquitecturas posibles, sus ventajas, desventajas y un ejemplo de configuración mínima para un entorno de alta disponibilidad.
Objetivo
El objetivo es implementar dos servidores Nginx trabajando en paralelo para:
- Garantizar alta disponibilidad: el servicio sigue activo aunque uno de los nodos falle.
- Proveer balanceo de carga: distribuir el tráfico de manera eficiente entre ambos nodos.
- Mantener un punto de acceso único para los clientes mediante una IP virtual o balanceador.
Arquitecturas Posibles
1. Keepalived + VRRP (Activo/Pasivo)
Una solución común en entornos On-Premises y VPS consiste en configurar Keepalived para gestionar una IP virtual (VIP) compartida entre los dos nodos Nginx.
Arquitectura:
IP Virtual (VIP)
│
┌─────────┴─────────┐
│ │
Nginx-1 (MASTER) Nginx-2 (BACKUP)
Ventajas:
- Failover automático en segundos
- Sencillo y estable
- No depende de hardware externo
Desventajas:
- No balancea tráfico en paralelo, solo activo/pasivo
- Para balanceo real se necesitaría un componente adicional
2. HAProxy + Nginx + Keepalived (Activo/Activo con Balanceo Real)
Para entornos empresariales, una arquitectura robusta combina HAProxy como balanceador frente a los servidores Nginx, con Keepalived gestionando la VIP de HAProxy:
IP Virtual
│
┌──────────┴──────────┐
│ │
HAProxy-1 (MASTER) HAProxy-2 (BACKUP)
│ │
└──────────┬──────────┘
│
┌────────┴────────┐
│ │
Nginx-1 Nginx-2
Ventajas:
- Balanceo real activo/activo
- Alta disponibilidad completa
- Escalable y monitorizable
Desventajas:
- Más complejidad
- Más nodos que mantener
3. DNS Round Robin (No recomendado)
Se puede usar DNS Round Robin para distribuir solicitudes entre Nginx-1 y Nginx-2. Sin embargo, presenta limitaciones críticas:
- No detecta fallos reales de nodos
- Caché DNS puede generar inconsistencias
- No garantiza alta disponibilidad efectiva
Este método no se recomienda en entornos de producción críticos.
Recomendación
Para un entorno profesional y seguro, especialmente considerando experiencia previa en infraestructura, Kubernetes y proxy inverso, la configuración más adecuada es:
HAProxy + Keepalived + 2×Nginx
- Permite balanceo activo/activo
- Proporciona alta disponibilidad real
- Escalable y compatible con monitoreo y TLS offloading
Ejemplo de Configuración: Keepalived + 2 Nginx
Requisitos
- Dos servidores Linux en la misma red
- Nginx instalado en ambos nodos
- IP virtual libre para el servicio
Configuración mínima de Keepalived
Nodo MASTER (/etc/keepalived/keepalived.conf)
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass MiPasswordSegura
}
virtual_ipaddress {
192.168.1.100
}
}
Nodo BACKUP
vrrp_instance VI_1 {
state BACKUP
interface eth0
virtual_router_id 51
priority 90
advert_int 1
authentication {
auth_type PASS
auth_pass MiPasswordSegura
}
virtual_ipaddress {
192.168.1.100
}
}
Con esta configuración, el tráfico siempre se dirige a la VIP, y si el nodo MASTER falla, el BACKUP asume automáticamente la IP.
Buenas Prácticas y Extras
- Configurar health checks de Nginx desde Keepalived
- Implementar monitorización con Prometheus y Grafana
- Gestionar TLS en HAProxy (offloading)
- Restringir acceso externo solo a la VIP
- Sincronizar configuraciones con Ansible o herramientas de CI/CD
Conclusión
Implementar dos Nginx en paralelo con Keepalived y, opcionalmente, HAProxy permite construir una infraestructura robusta, escalable y altamente disponible. Esta arquitectura es ideal para entornos críticos donde la continuidad del servicio y el balanceo eficiente son prioritarios.
Con las configuraciones mostradas, es posible asegurar que los servicios web continúen operando incluso ante fallos de nodos individuales, manteniendo un acceso transparente y confiable para los usuarios finales.


