Configuración de HAProxy en VPS:

Configuración

El archivo de configuración principal de HAProxy se encuentra en la ruta /etc/haproxy/haproxy.cfg. Antes de realizar cambios, siempre haga una copia de seguridad del archivo original.

sudo cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak
sudo nano /etc/haproxy/haproxy.cfg

Borre el contenido del archivo haproxy.cfg e inserte la siguiente configuración. Esta configuración incluye ajustes globales, ajustes predeterminados, un frontend para HTTP y HTTPS, así como un backend para nuestros servidores Nginx.

Ejemplo de configuración de HAProxy para HTTP y HTTPS con terminación SSL

Configuraremos HAProxy para manejar el tráfico HTTP (redirección a HTTPS) y el tráfico HTTPS con terminación SSL. Para los certificados SSL, utilizaremos Let's Encrypt a través de Certbot.

Obtención de un certificado SSL con Certbot

Antes de configurar HTTPS, necesitamos un certificado SSL. Instalaremos Certbot y obtendremos un certificado para su dominio (reemplace your_domain.com con su dominio real).

sudo apt install certbot -y   # Instalación de Certbot
sudo certbot certonly --standalone -d your_domain.com -d www.your_domain.com --agree-tos --email [email protected] --non-interactive # Obtención del certificado

Certbot utiliza el puerto 80 por defecto para el modo standalone. Asegúrese de que el puerto 80 esté libre al ejecutar este comando (detenga temporalmente Nginx si ya está escuchando en el 80).

sudo systemctl stop nginx # Detenemos temporalmente Nginx si está escuchando en el 80
# ... ejecutamos el comando certbot ...
sudo systemctl start nginx # Iniciamos Nginx de nuevo

Los certificados se ubicarán en /etc/letsencrypt/live/your_domain.com/. HAProxy requiere un certificado en formato PEM, que combina la clave privada y la cadena completa de certificados. Crearemos dicho archivo:

sudo mkdir -p /etc/haproxy/certs/
sudo cat /etc/letsencrypt/live/your_domain.com/fullchain.pem /etc/letsencrypt/live/your_domain.com/privkey.pem | sudo tee /etc/haproxy/certs/your_domain.com.pem > /dev/null
sudo chmod -R go-rwx /etc/haproxy/certs # Establecimiento de permisos estrictos

Ahora HAProxy podrá utilizar este archivo /etc/haproxy/certs/your_domain.com.pem para la terminación SSL.

Archivo de configuración de HAProxy (/etc/haproxy/haproxy.cfg)

global
    log /dev/log    local0
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
    stats timeout 30s
    user haproxy
    group haproxy
    daemon
    # La actualización de HAProxy a la versión 2.9+ permite usar más núcleos de CPU
    # nbthread 2 # Usa 2 hilos/núcleos de CPU, si están disponibles
    cpu-map 1 0 # Vinculación del hilo 1 al núcleo 0
    cpu-map 2 1 # Vinculación del hilo 2 al núcleo 1 (si nbthread 2)
    maxconn 20000 # Número máximo de conexiones simultáneas

defaults
    mode http
    log global
    option httplog
    option dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option redispatch
    retries 3
    timeout http-request 10s
    timeout queue 1m
    timeout connect 10s
    timeout client 1m
    timeout server 1m
    timeout http-keep-alive 20s
    timeout check 10s
    maxconn 5000 # Número máximo de conexiones por frontend/backend

# Frontend para tráfico HTTP (redirección a HTTPS)
frontend http_in
    bind *:80
    mode http
    redirect scheme https code 301 if !{ ssl_fc } # Redirigimos todo el HTTP a HTTPS

# Frontend para tráfico HTTPS con terminación SSL
frontend https_in
    bind *:443 ssl crt /etc/haproxy/certs/your_domain.com.pem # Reemplace con su dominio
    mode http
    option httplog
    # ACL para determinar qué backend usar
    acl url_static path_beg /static /images /css /js
    acl url_admin path_beg /admin
    # Uso de ACL para seleccionar el backend
    use_backend bk_static if url_static
    use_backend bk_admin if url_admin
    default_backend bk_webservers

# Backend para contenido estático (opcional)
backend bk_static
    mode http
    balance roundrobin # Método de balanceo: roundrobin (por turnos)
    server static_server 127.0.0.1:8082 check # Ejemplo de servidor estático, si existe

# Backend para panel de administración (opcional)
backend bk_admin
    mode http
    balance leastconn # Método de balanceo: menor número de conexiones
    server admin_server 127.0.0.1:8083 check # Ejemplo de servidor de administración

# Backend para servidores web principales
backend bk_webservers
    mode http
    balance roundrobin # Método de balanceo: roundrobin (por turnos)
    option httpchk GET /healthz # Verificación de salud por URL /healthz
    # En un entorno real, aquí estarán las direcciones IP y los puertos de sus servidores backend
    # Por ejemplo: server web1 192.168.1.10:80 check
    #           server web2 192.168.1.11:80 check
    server web1 127.0.0.1:8080 check inter 2s fall 3 rise 2 weight 100
    server web2 127.0.0.1:8081 check inter 2s fall 3 rise 2 weight 100

# Estadísticas de HAProxy
listen stats
    bind *:8000 # Puerto para acceder a las estadísticas de HAProxy
    mode http
    stats enable
    stats uri /haproxy_stats # URL para las estadísticas
    stats realm Haproxy\ Statistics # Nombre del área de autorización
    stats auth admin:PASSWORD_HA_PROXY # Usuario y contraseña para el acceso (¡obligatorio cambiar!)
    stats refresh 10s # Actualización de estadísticas cada 10 segundos

Notas importantes sobre la configuración:

• Reemplace your_domain.com con su dominio real en la línea bind *:443 ssl crt /etc/haproxy/certs/your_domain.com.pem.
• Reemplace PASSWORD_HA_PROXY con una contraseña segura para acceder a la página de estadísticas.
• En la sección backend bk_webservers:
  • balance roundrobin: Método de balanceo que distribuye las solicitudes por turnos. Otros métodos populares: leastconn (menor número de conexiones activas), source (basado en la dirección IP del cliente para sesiones "pegajosas").
  • option httpchk GET /healthz: HAProxy enviará una solicitud HTTP GET a la ruta /healthz a cada backend para verificar su estado. Sus backends deben responder a esta URL con 200 OK.
  • server web1 127.0.0.1:8080 check inter 2s fall 3 rise 2 weight 100:
    • web1: Nombre del servidor.
    • 127.0.0.1:8080: Dirección IP y puerto del backend. En un entorno real, estas serán las direcciones IP de sus otros VPS.
    • check: Habilita la verificación de salud.
    • inter 2s: Intervalo entre verificaciones de salud (2 segundos).
    • fall 3: El servidor se considerará inoperable después de 3 verificaciones fallidas.
    • rise 2: El servidor se considerará operativo después de 2 verificaciones exitosas.
    • weight 100: Peso relativo del servidor en el balanceo (cuanto mayor, más tráfico recibe).

Verificación de la configuración de HAProxy

Siempre verifique la sintaxis de la configuración antes de reiniciar HAProxy.

sudo haproxy -c -f /etc/haproxy/haproxy.cfg # Verificación de la sintaxis del archivo de configuración

Si no hay errores, verá el mensaje "Configuration file is valid". Ahora reinicie HAProxy:

sudo systemctl restart haproxy # Reinicio del servicio HAProxy
sudo systemctl status haproxy  # Verificación del estado

Configuración de Nginx para /healthz

Para que HAProxy pueda verificar la salud de nuestros backends, Nginx debe responder a /healthz. Agregue la siguiente location dentro del bloque server en cada archivo de configuración de Nginx (/etc/nginx/sites-available/backend1.conf y backend2.conf):

location /healthz {
    return 200 'OK';
    add_header Content-Type text/plain;
}

Después de modificar cada archivo de Nginx, verifique y reinicie Nginx:

sudo nginx -t
sudo systemctl restart nginx

Verificación de la operatividad

1. Acceso a HTTP/HTTPS

Abra su dominio (your_domain.com) en el navegador. Debería ser redirigido automáticamente a HTTPS, y el contenido debería cargarse. Si actualiza la página varias veces, verá cómo X-Backend-Server cambia entre "Backend 1" y "Backend 2", confirmando el funcionamiento del balanceo de carga.

curl -I http://your_domain.com # Verificación de la redirección
curl -I https://your_domain.com # Verificación de HTTPS y el encabezado del backend

2. Acceso a las estadísticas de HAProxy

Abra en el navegador http://SU_DIRECCIÓN_IP_VPS:8000/haproxy_stats. Ingrese el usuario admin y la contraseña que configuró. Verá la página de estadísticas, donde se mostrarán los estados de sus backends, el número de conexiones y otras métricas. Esta es una excelente herramienta para la monitorización.

Copias de seguridad y mantenimiento

Un sistema de copias de seguridad fiable y un mantenimiento regular son cruciales para cualquier entorno de producción.

¿Qué respaldar?

Para HAProxy, los elementos principales a respaldar son:

• Archivos de configuración de HAProxy: /etc/haproxy/haproxy.cfg y cualquier otro archivo al que haga referencia (por ejemplo, listas ACL si están en archivos separados).
• Certificados SSL: El directorio /etc/letsencrypt/live/your_domain.com/ y el archivo PEM combinado /etc/haproxy/certs/your_domain.com.pem. Estos archivos contienen claves privadas y deben guardarse de forma segura.

Script simple de copia de seguridad automática

Crearemos un script simple que archivará los archivos importantes y los enviará a un lugar seguro. Como ejemplo, usaremos rsync para copiar a un servidor remoto o almacenamiento compatible con S3 (por ejemplo, MinIO, Wasabi u otro VPS). Para el almacenamiento compatible con S3, se requerirá la instalación de awscli u otro cliente S3.

Supongamos que tiene un servidor remoto para copias de seguridad con el usuario backupuser y una clave SSH configurada.

sudo nano /usr/local/bin/backup_haproxy.sh

Contenido del script (reemplace backupuser@backup_server_ip y /path/to/remote/backups):

#!/bin/bash

# Directorio para copias de seguridad temporales
BACKUP_DIR="/tmp/haproxy_backup"
DATE=$(date +%Y%m%d%H%M%S)
ARCHIVE_NAME="haproxy_config_${DATE}.tar.gz"
REMOTE_DEST="backupuser@backup_server_ip:/path/to/remote/backups" # Reemplace con su servidor remoto

mkdir -p "$BACKUP_DIR"

echo "Iniciando la copia de seguridad de la configuración de HAProxy y los certificados SSL..."

# Copiando configuraciones de HAProxy
cp /etc/haproxy/haproxy.cfg "$BACKUP_DIR/"
cp -R /etc/haproxy/certs "$BACKUP_DIR/" # Copiando el archivo PEM combinado
# Copiando los certificados originales de Let's Encrypt
cp -R /etc/letsencrypt/live/your_domain.com "$BACKUP_DIR/letsencrypt_certs" # Reemplace con su dominio

# Creando archivo
tar -czf "$BACKUP_DIR/$ARCHIVE_NAME" -C "$BACKUP_DIR" .

echo "Archivo creado: $BACKUP_DIR/$ARCHIVE_NAME"

# Enviando archivo al servidor remoto
if rsync -avz "$BACKUP_DIR/$ARCHIVE_NAME" "$REMOTE_DEST"; then
    echo "Copia de seguridad enviada con éxito a $REMOTE_DEST"
else
    echo "Error al enviar la copia de seguridad a $REMOTE_DEST"
    exit 1
fi

# Limpiando archivos temporales
rm -rf "$BACKUP_DIR"

echo "Copia de seguridad completada."

Haga el script ejecutable:

sudo chmod +x /usr/local/bin/backup_haproxy.sh

Configuración de Cron para ejecución automática

Agregue el script a Cron para una ejecución diaria o semanal.

sudo crontab -e

Agregue la siguiente línea para una ejecución diaria a las 3:00 de la mañana:

0 3 * * * /usr/local/bin/backup_haproxy.sh > /var/log/haproxy_backup.log 2>&1

Dónde almacenar las copias de seguridad

• Servicio externo compatible con S3: Almacenamientos en la nube como Amazon S3, DigitalOcean Spaces, Backblaze B2, MinIO (autoalojado) son una opción fiable y escalable.
• VPS separado: Puede usar otro VPS menos potente específicamente para almacenar copias de seguridad.
• NAS/almacenamiento local: Para uso doméstico o pequeñas empresas.

Regla principal: las copias de seguridad deben almacenarse por separado del servidor principal, preferiblemente en una ubicación geográfica diferente.

Actualizaciones: Rolling vs. Ventana de Mantenimiento

Las actualizaciones regulares de software son importantes para la seguridad y para obtener nuevas funciones. Para HAProxy, hay varios enfoques:

• Ventana de Mantenimiento: Un enfoque tradicional donde las actualizaciones se aplican en un momento predefinido cuando el tráfico es mínimo. Esto puede resultar en un breve tiempo de inactividad, pero es más fácil de implementar para un HAProxy único. Para ello, basta con ejecutar sudo apt update && sudo apt upgrade -y y reiniciar HAProxy.
• Actualizaciones Continuas (Rolling Updates): Para sistemas de alta disponibilidad con dos o más instancias de HAProxy. Actualice un balanceador a la vez. Primero actualice uno, redirija todo el tráfico a él, luego actualice el segundo. Esto garantiza cero tiempo de inactividad, pero requiere una arquitectura más compleja con múltiples HAProxy (por ejemplo, usando Keepalived para VIP).

Para un VPS único con HAProxy, como en este tutorial, el enfoque de ventana de mantenimiento es el más práctico. Asegúrese de verificar siempre la configuración de HAProxy (haproxy -c) después de cualquier cambio o actualización, antes de reiniciar el servicio.

Renovación de certificados Let's Encrypt

Certbot configura automáticamente una tarea cron para la renovación de certificados. Puede verificarlo:

sudo systemctl list-timers | grep certbot

Si los certificados se han renovado con éxito, deberá combinarlos de nuevo en un archivo PEM para HAProxy y recargar HAProxy:

# Este script se puede añadir a cron después de la renovación automática de Certbot
#!/bin/bash
DOMAIN="your_domain.com" # Reemplace con su dominio
CERT_PATH="/etc/letsencrypt/live/$DOMAIN"
HAPROXY_CERT_PATH="/etc/haproxy/certs/$DOMAIN.pem"

if [ -f "$CERT_PATH/fullchain.pem" ] && [ -f "$CERT_PATH/privkey.pem" ]; then
    sudo cat "$CERT_PATH/fullchain.pem" "$CERT_PATH/privkey.pem" | sudo tee "$HAPROXY_CERT_PATH" > /dev/null
    sudo chmod -R go-rwx /etc/haproxy/certs
    sudo systemctl reload haproxy
    echo "Certificado SSL de HAProxy actualizado y HAProxy recargado."
else
    echo "Error: Certificados Let's Encrypt no encontrados para $DOMAIN."
fi

Guarde este script, por ejemplo, como /usr/local/bin/renew_haproxy_cert.sh, hágalo ejecutable y agréguelo a cron para que se ejecute después de la renovación de Certbot (por ejemplo, semanalmente).

Solución de problemas + Preguntas frecuentes

En esta sección, abordaremos problemas comunes que pueden surgir al configurar HAProxy y responderemos a las preguntas más frecuentes.

HAProxy no se inicia o muestra un error de configuración

Problema: Después de cambiar haproxy.cfg, HAProxy no se inicia, o systemctl status haproxy muestra errores.

Qué verificar:

• Sintaxis de la configuración: Esta es la causa más común. Use sudo haproxy -c -f /etc/haproxy/haproxy.cfg para verificar la sintaxis. Cualquier error tipográfico o sangría incorrecta puede llevar a un error.
• Registros de HAProxy: Verifique los registros del sistema: sudo journalctl -u haproxy o sudo tail -f /var/log/syslog. HAProxy suele describir la causa del fallo con gran detalle.
• Disponibilidad de puertos: Asegúrese de que los puertos que HAProxy intenta escuchar (por ejemplo, 80, 443) no estén ocupados por otro proceso (por ejemplo, Nginx). Use sudo ss -tulpn | grep -E "80|443".
• Permisos de archivos: Asegúrese de que el usuario haproxy (o el usuario con el que se ejecuta) tenga permisos de lectura para el archivo de configuración y los certificados SSL.

Cómo solucionarlo: Corrija los errores en haproxy.cfg, libere los puertos ocupados, verifique los permisos. Después de cada cambio en la configuración de HAProxy, ejecute sudo haproxy -c -f /etc/haproxy/haproxy.cfg y solo entonces sudo systemctl restart haproxy.

Error "503 Service Unavailable" o "No servers are available"

Problema: El navegador muestra un error 503, o los registros de HAProxy indican que los backends no están disponibles.

Qué verificar:

• Estado de los backends: Verifique si sus servidores backend (Nginx, Apache, su aplicación) están en ejecución y escuchando en los puertos correctos. Use sudo systemctl status nginx (o su aplicación).
• Disponibilidad de backends desde HAProxy: Desde el servidor HAProxy, intente conectarse directamente al backend: curl http://127.0.0.1:8080/healthz (reemplace la IP y el puerto con los backends reales). Asegúrese de que el firewall en los backends (si están en otros VPS) permita las conexiones entrantes desde la dirección IP de HAProxy.
• Configuración de salud (health checks): Asegúrese de que option httpchk y la ruta /healthz estén configurados correctamente tanto en HAProxy como en los backends.
• Página de estadísticas de HAProxy: Abra la página de estadísticas de HAProxy (http://SU_DIRECCIÓN_IP_VPS:8000/haproxy_stats) y verifique el estado de los servidores backend. Allí se indicará la razón por la cual los servidores están marcados como DOWN.

Cómo solucionarlo: Resuelva los problemas en los backends, verifique la conectividad de red, ajuste la configuración de las comprobaciones de salud. Si los backends están en VPS separados, asegúrese de que sus firewalls permitan las conexiones entrantes desde HAProxy.

Rendimiento lento o alta latencia

Problema: La aplicación funciona lentamente, o las solicitudes se procesan con una gran latencia al pasar por HAProxy.

Qué verificar:

• Carga en HAProxy: Verifique el uso de CPU y RAM en el VPS con HAProxy (htop, top). Una alta carga de CPU puede indicar un cuello de botella, especialmente con una terminación SSL intensiva.
• Ancho de banda de red: Asegúrese de que la red no sea un cuello de botella. Use iftop o nload.
• Tiempos de espera de HAProxy: Verifique la configuración de timeout client, timeout server, timeout connect en haproxy.cfg. Tiempos de espera demasiado cortos pueden interrumpir conexiones lentas.
• Carga en los backends: Verifique la carga en los propios servidores backend. Es posible que el problema no esté en HAProxy, sino en la falta de recursos en los backends o en una aplicación no optimizada.

Cómo solucionarlo: Aumente los recursos del VPS para HAProxy (CPU/RAM) si está sobrecargado. Optimice la configuración de los tiempos de espera. Considere agregar más servidores backend u optimizar su aplicación.

Dirección IP de cliente incorrecta en los registros de los backends

Problema: En los registros de sus servidores backend (Nginx, Apache) se muestra la dirección IP de HAProxy, no la dirección IP real del cliente.

Qué verificar: Asegúrese de que en la sección defaults o frontend de HAProxy esté habilitada la opción option forwardfor. HAProxy agrega el encabezado X-Forwarded-For con la IP real del cliente.

Cómo solucionarlo: Configure su servidor backend para leer el encabezado X-Forwarded-For. Por ejemplo, para Nginx, agregue al bloque log_format:

log_format combined_proxy '$remote_addr - $remote_user [$time_local] '
                          '"$request" $status $body_bytes_sent '
                          '"$http_referer" "$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log combined_proxy;

O use el módulo real_ip, si HAProxy está en su red interna.

Los certificados SSL no funcionan o han caducado

Problema: Los navegadores muestran advertencias de seguridad, o HTTPS no funciona.

Qué verificar:

• Fecha de caducidad del certificado: Verifique la fecha de caducidad del certificado: sudo openssl x509 -in /etc/haproxy/certs/your_domain.com.pem -noout -dates.
• Ruta al certificado: Asegúrese de que la ruta al archivo PEM en haproxy.cfg (bind *:443 ssl crt /etc/haproxy/certs/your_domain.com.pem) sea correcta.
• Formato del certificado: HAProxy requiere un archivo PEM combinado. Asegúrese de haber combinado correctamente fullchain.pem y privkey.pem.
• Renovación automática: Verifique si la tarea cron de Certbot para la renovación de certificados y su script para actualizar el archivo PEM de HAProxy están funcionando.

Cómo solucionarlo: Renueve el certificado usando Certbot (sudo certbot renew --force-renewal, si es necesario con urgencia). Corrija las rutas o el formato del archivo. Asegúrese de que el script de actualización de certificados para HAProxy se ejecute después de la renovación de Certbot.

¿Qué configuración mínima de VPS es adecuada?

Para HAProxy, actuando como balanceador de carga para un proyecto pequeño o mediano (hasta varios cientos de conexiones simultáneas), un VPS con 1 núcleo de CPU, 1 GB de RAM, 20-40 GB de SSD y un canal de red de 100 Mbps o más será mínimamente adecuado. Si se planea una terminación SSL intensiva o un tráfico muy alto, se recomienda aumentar la CPU a 2 núcleos y la RAM a 2 GB. También es importante asegurarse de que los servidores backend a los que HAProxy redirigirá el tráfico tengan recursos suficientes.

¿Qué elegir — VPS o dedicado para esta tarea?

La elección entre un VPS y un servidor dedicado para HAProxy depende de la escala y la criticidad de su proyecto. Para la mayoría de las aplicaciones y servicios web, incluso con miles de usuarios simultáneos, un VPS potente será más que suficiente. HAProxy es muy eficiente y puede manejar un volumen significativo de tráfico en una máquina virtual. Un servidor dedicado solo debe considerarse en casos de carga extrema (decenas y cientos de miles de conexiones simultáneas), cuando el rendimiento de la CPU o el ancho de banda de la red del VPS se convierte en un cuello de botella debido a las limitaciones de virtualización, o cuando se requiere un control total sobre el hardware y el máximo aislamiento físico. Para empezar, siempre se recomienda comenzar con un VPS bien configurado y luego escalar a un dedicado si es realmente necesario.