Guida passo-passo: configurare un load balancer NGINX ad alta disponibilità con Keepalived e HAProxy

Un bilanciatore di carico NGINX ad alta disponibilità elimina il punto unico di guasto al perimetro di rete, mediante due Linux-nodi che forniscono un indirizzo IP virtuale (VIP) tramite VRRP e che eseguono localmente NGINX e HAProxy per TLS, instradamento e health check. In questo how‑to orientato alla pratica descrivo non solo le configurazioni, ma anche le conseguenze operative, le cause tipiche di errore, comandi di misura e verifica e una strategia di fallback pratica.

Bilanciatore di carico NGINX ad alta disponibilità: architettura e ripartizione delle responsabilità

In breve: Keepalived (VRRP) fornisce una VIP che i client indirizzano. Il nodo attivo ha la VIP legata localmente e risponde alle ARP. NGINX si occupa della terminazione TLS, della policy degli header e dei redirect; HAProxy gira localmente e svolge health check precisi e l’instradamento verso i backend. Questa separazione consente aree di responsabilità chiare: policy TLS e di sicurezza in NGINX, controllo dello stato e delle prestazioni in HAProxy.

Prerequisiti, rete e decisioni di design

Assunzioni essenziali: entrambi i load balancer nella stessa Layer‑2‑domain (VLAN), VIP nello stesso subnet, il traffico VRRP (protocollo IP 112) deve poter fluire tra gli host. Se le applicazioni memorizzano lo stato di sessione localmente, prevedete sticky session o uno store centralizzato delle sessioni (es. Redis) — altrimenti i failover causano la perdita delle informazioni di sessione.

Parametri di esempio

• LB1: 10.10.10.11/24, LB2: 10.10.10.12/24, VIP: 10.10.10.10/24
• Interface: eth0, Backends: 10.10.20.21:8080, 10.10.20.22:8080
• DNS: un A‑Record verso la VIP; il TTL è questione di secondi, il failover della VIP è trasparente per i client

Installazione: pacchetti, servizi, ordine

Installate NGINX, HAProxy e Keepalived su entrambi i nodi. Abilitate e avviate i servizi dopo i controlli di configurazione.

sudo apt-get update
sudo apt-get install -y nginx haproxy keepalived curl iproute2 iputils-arping

sudo systemctl enable --now nginx
sudo systemctl enable --now haproxy
sudo systemctl enable --now keepalived

Ottimizzazione del kernel e ARP: perché è importante

Se Linux risponde in modo errato alle richieste ARP, si verificano blackholing del traffico o split brain. Le seguenti impostazioni sysctl riducono risposte ARP indesiderate; applicatele su entrambi i nodi.

sudo tee /etc/sysctl.d/99-lb-ha.conf >/dev/null <<'EOF'
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.default.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.default.arp_announce = 2
EOF

sudo sysctl --system

Spiegazione: arp_ignore controlla se il sistema risponde a richieste ARP per IP non configurati localmente; arp_announce influenza quale IP sorgente venga usato nelle richieste ARP. Impostazioni errate permettono al nodo di backup di rispondere alle ARP per la VIP e causano split brain.

HAProxy: livello backend locale, health check e metriche

HAProxy fornisce health check robusti (HTTP, TCP, SSL), impostazioni di weight e rise/fall. Utilizzate un binding locale (127.0.0.1), in modo che NGINX possa inoltrare internamente. Le statistiche possono essere utilizzate per il monitoraggio o esportate tramite un Prometheus‑exporter.

# /etc/haproxy/haproxy.cfg
global
  log /dev/log local0
  tune.maxaccept 1000
  maxconn 50000
  daemon

defaults
  mode http
  option httplog
  timeout connect 5s
  timeout client 60s
  timeout server 60s

frontend fe_local
  bind 127.0.0.1:9000
  default_backend be_app

backend be_app
  balance roundrobin
  option httpchk GET /healthz
  http-check expect status 200
  default-server inter 2s fall 3 rise 2
  server app1 10.10.20.21:8080 check
  server app2 10.10.20.22:8080 check

listen stats
  bind 127.0.0.1:8404
  stats enable
  stats uri /stats

Verificare HAProxy prima del riavvio:

sudo haproxy -c -f /etc/haproxy/haproxy.cfg
sudo systemctl reload haproxy

NGINX: TLS, percorsi proxy e timeout

NGINX esegue la terminazione TLS. Automatizzate i certificati (p.es. certbot/ACME) o utilizzate la vostra PKI interna. Prestate attenzione a proxy_read_timeout e alle impostazioni dei buffer, in modo che risposte lunghe dal backend non blocchino la connessione.

# /etc/nginx/sites-available/lb.conf
server {
  listen 80;
  server_name _;
  return 301 https://$host$request_uri;
}

server {
  listen 443 ssl http2;
  server_name _;
  ssl_certificate     /etc/ssl/certs/lb.pem;
  ssl_certificate_key /etc/ssl/private/lb.key;
  client_max_body_size 50m;
  proxy_read_timeout 120s;
  location / {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass http://127.0.0.1:9000;
  }
}

Keepalived: configurazione VRRP, script di monitoraggio e timer

Keepalived determina quale nodo detiene la VIP. Gli script di monitoraggio riducono la priorità in caso di guasti di servizio, così un nodo di backup sano può subentrare. I valori Advert‑Interval e Priority controllano i tempi di failover e l’ordine di preferenza.

Script di monitoraggio con codici di uscita

sudo tee /usr/local/sbin/chk_proxy.sh >/dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

# Prüft Dienste und lokales HAProxy Health-Endpoint
systemctl is-active --quiet nginx || exit 1
systemctl is-active --quiet haproxy || exit 1
curl -fsS --max-time 1 http://127.0.0.1:9000/healthz >/dev/null || exit 1
exit 0
EOF
sudo chmod 0755 /usr/local/sbin/chk_proxy.sh

Configurazione Keepalived (Master/Backup)

# /etc/keepalived/keepalived.conf (Beispiel MASTER)
vrrp_script chk_proxy {
  script "/usr/local/sbin/chk_proxy.sh"
  interval 2
  timeout 2
  fall 2
  rise 2
  weight -30
}

vrrp_instance VI_10 {
  state MASTER
  interface eth0
  virtual_router_id 10
  priority 110
  advert_int 1
  authentication { auth_type PASS; auth_pass 7f3c9d2a }
  virtual_ipaddress { 10.10.10.10/24 }
  track_script { chk_proxy }
}

# Backup hat priority 100 und state BACKUP

Nota: l’autenticazione in Keepalived (auth_pass) è un meccanismo semplice; in reti insicure dovreste utilizzare una segmentazione di rete aggiuntiva, dato che VRRP di per sé non fornisce una crittografia robusta.

Cause comuni di comportamenti inaspettati: ARP, funzionalità degli switch, firewall

Cause comuni di comportamenti inaspettati:

• Funzionalità degli switch come Dynamic ARP Inspection (DAI) possono bloccare Gratuitous ARP dopo un failover — in tali reti è necessaria una configurazione dello switch.
• La firewall del host o le Cloud Security Groups possono bloccare il protocollo IP 112 (VRRP) — verificate questo con tcpdump.
• Conntrack (NAT/Firewall stateful): in caso di traduzione NAT un failover può interrompere connessioni esistenti perché la tabella NAT sul nuovo nodo non è presente.

Diagnosi con tcpdump, arping e log

Controlli utili per l’analisi:

# VRRP traffic beobachten (Protocol 112)
sudo tcpdump -n -i eth0 proto 112

# ARP prüfen
sudo tcpdump -n -i eth0 arp

# GARP senden (nach Failover)
sudo arping -U -I eth0 -c 5 10.10.10.10

# Keepalived logs
sudo journalctl -u keepalived -f

Se tcpdump non mostra pacchetti VRRP, spesso la causa è un firewall o uno switch interposto. Se il GARP dal master non passa, i client compaiono nelle tabelle ARP con l’associazione MAC obsoleta e devono reimparare.

Effetti di conntrack e NAT in caso di failover

In ambienti con NAT o firewall stateful la tabella conntrack è specifica per host. Dopo un failover del VIP mancano le voci conntrack consolidate sul nuovo nodo, con conseguenti sessioni interrotte. Possibili contromisure:

• Eseguire Keepalived con sincronizzazione della conntrack (es. conntrackd) — aumenta la complessità.
• Accettare la rinegoziazione delle connessioni: tollerare brevi riconnessioni e lasciare che i client si riconnettano.
• Valutare un’architettura attivo/attivo se la continuità delle sessioni è determinante.

Aspetti di sicurezza e gestione dei certificati

I certificati TLS devono essere identici su entrambi i load balancer (LB). Automatizzate il deployment con Certbot (ACME) o con la vostra PKI interna e verificate le chiavi private tramite permessi sui file. Conservate i certificati versionati in un repository di artefatti sicuro o in un secret store.

# Beispiel Certbot (Let's Encrypt) - nicht für private PKI
sudo apt-get install -y certbot
sudo certbot certonly --standalone -d lb.example.com
# Verteilen Sie das resultierende PEM sicher auf beide Nodes (scp/Ansible)

Rollout- und Patch-Prozess — konkretes Runbook

Una procedura tipica e testata per patch o aggiornamenti di configurazione minimizza il rischio:

1. Pianificazione: comunicare la finestra di manutenzione, ridurre temporaneamente gli alert di monitoring.
2. Deviare il traffico sul backup: arrestare Keepalived sul master oppure ridurre la sua priority.
3. Validazione: verificare sul backup che il VIP sia stato assunto e che latenza/errori siano nei limiti normali.
4. Patchare il master, testare (verificare NGINX/HAProxy localmente), reinserire nel pool.
5. Patchare il secondo nodo.
6. Controlli post-intervento: test di failover, health check, analisi dei log.

# Beispiel: Traffic auf Backup bringen
# Auf Master:
sudo systemctl stop keepalived
# Auf Backup prüfen:
ip -br addr show dev eth0
sudo curl -I --resolve lb.example.com:443:10.10.10.10 https://lb.example.com/
# Nach Patch:
sudo systemctl start keepalived

Monitoring, Kennzahlen und Alerts

Metriche importanti da monitorare:

• Transizioni VRRP di Keepalived (switchover frequenti indicano instabilità)
• Istante di binding del VIP ed eventi GARP
• Rate 4xx/5xx di NGINX
• Stato dei backend di HAProxy, tempi di risposta e queueing
• Metriche di sistema: file descriptors, netstat per socket aperti, loadavg

Esportate le statistiche di HAProxy tramite un exporter per Prometheus oppure utilizzate l’endpoint stats interno per le regole di alerting.

Alternative di design avanzate

Se serve maggiore scalabilità o disponibilità globale, valutate altri pattern:

• Cloud pubblica: i load balancer gestiti evitano problemi di ARP/VRRP.
• Anycast/BGP: per distribuzione globale e latenza più bassa, richiede expertise in routing di rete.
• Attivo/attivo: entrambi i load balancer gestiscono traffico; richiede sincronizzazione delle sessioni o applicazioni stateless.

Checklist prima della messa in produzione

• VRRP (IP 112) zwischen LBs und im Netz durch Firewall/Switch erlaubt?
• sysctl‑ARP‑Einstellungen auf beiden Knoten gesetzt und geladen?
• Keepalived Track‑Skript funktioniert und Exit‑Codes sind valide?
• HAProxy Health Checks erzielen erwartete Antworten (200/OK)?
• TLS‑Zertifikate auf beiden Knoten installiert und synchronisiert?
• Switch‑Features (DAI, Port Security) geprüft und ggf. angepasst?
• Monitoring und Alerting für VRRP‑Transitions und Backend‑Health eingerichtet?
• Rollback‑Plan getestet (manuelles ip addr add, Keepalived Start/Stop)?

Insidie tipiche e contromisure rapide

Split Brain: Controllare i pacchetti VRRP, gli auth‑token, il virtual_router_id e le priorità. Se gli switch hanno DAI attivo, configurare binding DHCP/ARP appropriati o mettere in whitelist le MAC dei LB.

Tempi di commutazione lenti: advert_interval troppo elevato, caching ARP su client/switch o GARP bloccato. Ridurre advert_int e testare il comportamento di invio GARP, ma considerare che intervalli molto brevi generano più traffico VRRP.

Conclusione e rilevanza operativa

Un NGINX‑Load‑Balancer ad alta disponibilità con Keepalived e HAProxy è una soluzione pragmatica per ridurre i rischi di interruzione al bordo della rete. Non sono determinanti solo i file di configurazione corretti, ma anche le impostazioni di rete e degli switch, il comportamento ARP, health check robusti e un processo di rollout testato. Investite tempo in monitoring, runbook documentati e test di failover regolari — questo garantisce una maturità operativa prevedibile.

Comandi di controllo avanzati (Riferimento rapido)

# Wer hat die VIP?
ip -br addr show dev eth0 | grep 10.10.10.10 || true

# VRRP‑Traffic live beobachten
sudo tcpdump -n -i eth0 proto 112

# Prüfen ob Keepalived Track‑Skript läuft und Exit‑Code liefert
/usr/local/sbin/chk_proxy.sh && echo OK || echo FAIL

# GARP senden (Master)
sudo arping -U -I eth0 -c 5 10.10.10.10

# HAProxy Stats (lokal)
curl -sS http://127.0.0.1:8404/stats

Sicurezza operativa: gestione delle configurazioni, test e recupero rapido

Dopo la messa in servizio tecnica, il change management determina la stabilità a lungo termine. Depositare tutte le configurazioni di Keepalived, NGINX e HAProxy in un repository Git, versionare i template e generare artefatti idempotenti da pipeline CI automatizzate. In questo modo i rollback risultano tracciabili per commit e si evitano drift di configurazione.

Complementi pratici:

• Canary‑Rollout: Distribuire le modifiche di configurazione prima sul nodo di backup, verificare gli health check e i log, quindi sul master.
• Ripristino rapido: Passaggi documentati per l’impostazione manuale della VIP, accesso SSH d’emergenza e ripristino delle configurazioni da Git minimizzano i tempi di inattività.
• Rilevamento avanzato dei guasti: Utilizzare BFD (Bidirectional Forwarding Detection) oltre a VRRP per rilevare più rapidamente la perdita di link, soprattutto per requisiti di latenza critica.
• Segmentazione di rete: Trasmettere la segnalazione VRRP su un HA‑VLAN/VRF dedicato per ridurre la superficie d’attacco — VRRP non fornisce una crittografia forte.
• Integrazione del monitoring: Inviare gli stati VRRP, gli hash di configurazione e gli eventi di modifica configurazione nel vostro sistema centrale di alerting/ticketing, in modo che le modifiche siano immediatamente visibili.

Questi elementi operativi riducono gli errori umani, accelerano il ripristino e rendono l’operatività del LB riproducibile e verificabile — cruciale per soluzioni aziendali orientate ai processi con requisiti di alta disponibilità.

Per questo tema sono inoltre rilevanti Haproxy, l’alta disponibilità e il bilanciamento del carico Layer 4 e Layer 7. Il contributo inquadra questi aspetti in modo comprensibile e mostra su cosa conta nella pratica quotidiana.