HAProxy: Bilanciamento del Carico e Alta Disponibilità per Applicazioni Web (2026)

L’infrastruttura IT moderna è costantemente sotto pressione per garantire alte prestazioni e disponibilità. Un e-commerce che riceve 3.000 richieste al secondo su un singolo server backend è una situazione che ho gestito personalmente. Il server era al 95% di CPU e il rischio di un’interruzione di servizio era imminente. In scenari come questo, un singolo punto di fallimento non è un’opzione. È qui che entrano in gioco soluzioni di bilanciamento del carico come HAProxy, capaci di distribuire il traffico su più server, garantendo scalabilità e resilienza. L’implementazione di HAProxy con tre server backend e l’algoritmo leastconn ha permesso di passare da un’utilizzo della CPU del 95% su un singolo nodo al 30% su ciascuno dei tre nodi, con health check attivi ogni due secondi e failover completamente trasparente per gli utenti. Questo articolo esplorerà come configurare HAProxy per raggiungere questi obiettivi, dalla configurazione base all’alta disponibilità con Keepalived.

Prerequisiti / Ambiente di test

Per seguire questa guida, avrai bisogno di:

• Due o più server Linux (es. Ubuntu 24.04 LTS, CentOS Stream 9) per i backend delle applicazioni.
• Un server Linux dedicato per HAProxy.
• Un server Linux aggiuntivo per Keepalived (se si implementa l’alta disponibilità).
• Accesso sudo su tutti i server.
• Conoscenze base di networking e Linux.

HAProxy vs Nginx come load balancer: confronto pratico

Sia HAProxy che Nginx sono strumenti eccellenti per il bilanciamento del carico, ma hanno filosofie e punti di forza diversi. La scelta dipende dalle esigenze specifiche del tuo ambiente.

HAProxy (High Availability Proxy) è un bilanciatore di carico TCP/HTTP e proxy estremamente performante e robusto. È ottimizzato per la resilienza e la gestione di carichi di traffico elevati. La sua forza risiede nella capacità di gestire migliaia di connessioni concorrenti con un footprint di memoria ridotto. È spesso la scelta preferita per scenari critici dove la pura performance di bilanciamento e l’alta disponibilità sono prioritari.

Nginx è un web server, reverse proxy, HTTP cache e anche un bilanciatore di carico. È estremamente versatile e può svolgere molteplici ruoli. È eccellente per servire contenuti statici, per il caching e come reverse proxy generico. Come load balancer, Nginx è molto capace, ma in scenari di traffico estremamente elevato e con requisiti di alta disponibilità complessi, HAProxy spesso offre un vantaggio in termini di performance e funzionalità specifiche di bilanciamento.

In sintesi: se il tuo obiettivo principale è un bilanciamento del carico ad alte prestazioni e un’alta disponibilità critica, HAProxy è la scelta migliore. Se hai bisogno di un reverse proxy con funzionalità aggiuntive come caching e serving di contenuti statici, Nginx può essere più versatile. In molti ambienti enterprise, è comune trovare entrambi, con HAProxy che bilancia Nginx che a sua volta bilancia i server applicativi.

Installazione e struttura di haproxy.cfg

L’installazione di HAProxy è semplice sulla maggior parte delle distribuzioni Linux.

sudo apt update
sudo apt install haproxy
sudo systemctl enable haproxy
sudo systemctl start haproxy

Il file di configurazione principale di HAProxy è /etc/haproxy/haproxy.cfg. Questo file è diviso in diverse sezioni:

• global: Impostazioni globali per il processo HAProxy (es. log, user/group, numero massimo di connessioni).
• defaults: Impostazioni predefinite applicate a tutte le sezioni listen, frontend e backend a meno che non siano sovrascritte.
• frontend: Definisce come HAProxy ascolta le connessioni in ingresso (IP, porta, protocollo).
• backend: Definisce il gruppo di server a cui HAProxy inoltra le richieste.
• listen: Una combinazione di frontend e backend in una singola sezione, utile per configurazioni semplici.

Dopo ogni modifica al file haproxy.cfg, è fondamentale verificare la sintassi e ricaricare il servizio:

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

Frontend e backend: routing del traffico

Il cuore della configurazione di HAProxy risiede nelle sezioni frontend e backend.

Un frontend definisce l’interfaccia pubblica di HAProxy, specificando su quale IP e porta ascoltare e quali regole applicare per instradare il traffico. Un backend è un gruppo di server reali (i tuoi server web, applicativi, database) che HAProxy utilizzerà per distribuire il carico.

Ecco un esempio di configurazione base:

# haproxy.cfg base
frontend http_front
    bind *:80
    mode http
    default_backend http_back

backend http_back
    mode http
    balance roundrobin
    server web1 192.168.1.10:80 check
    server web2 192.168.1.11:80 check
    server web3 192.168.1.12:80 check

In questo esempio, frontend http_front ascolta sulla porta 80 su tutte le interfacce (*:80) e inoltra tutto il traffico al backend http_back. Il backend http_back contiene tre server (web1, web2, web3) con i rispettivi IP e porte. La direttiva mode http indica a HAProxy di operare a livello 7 (HTTP), consentendo funzionalità avanzate come l’analisi degli header HTTP. Per il bilanciamento a livello 4 (TCP), si userebbe mode tcp.

Algoritmi di bilanciamento: roundrobin, leastconn, source

HAProxy offre diversi algoritmi per distribuire il traffico. La scelta dell’algoritmo giusto è cruciale per ottimizzare le prestazioni e l’equità del carico.

• roundrobin: L’algoritmo predefinito. Le richieste vengono distribuite ai server in modo sequenziale. È semplice ed efficace per server con capacità simili e richieste di durata omogenea.
• leastconn: Inoltra la richiesta al server con il minor numero di connessioni attive. Ideale per server con tempi di elaborazione variabili, in quanto tende a bilanciare il carico in base all’attività reale dei server. Ho usato questo algoritmo nel caso dell’e-commerce per ottimizzare la distribuzione del carico sui nodi backend.
• source: Utilizza l’indirizzo IP del client per determinare a quale server inoltrare la richiesta. Questo assicura che un determinato client sia sempre indirizzato allo stesso server, utile per applicazioni che richiedono “sticky sessions” senza dover gestire i cookie.
• first: Inoltra le richieste al primo server disponibile nella lista, passando al successivo solo se il primo è inattivo. Utile per scenari attivo/passivo.

La direttiva balance nel backend definisce l’algoritmo. Ad esempio, balance leastconn.

Health check attivi e passivi

I health check sono fondamentali per l’alta disponibilità. HAProxy verifica regolarmente lo stato dei server backend e rimuove automaticamente dal pool quelli che non rispondono, prevenendo disservizi. Appena un server torna online, viene reintegrato.

• Check attivi: Specificati con la parola chiave check accanto alla definizione del server. HAProxy invia richieste specifiche (es. TCP connect, HTTP GET) ai server e valuta la risposta.

    server web1 192.168.1.10:80 check inter 2s fall 3 rise 2

Qui, inter 2s indica un intervallo di 2 secondi tra i controlli, fall 3 significa che il server sarà marcato come down dopo 3 fallimenti consecutivi, e rise 2 che sarà reintegrato dopo 2 successi consecutivi.

• Check passivi: HAProxy monitora il comportamento dei server basandosi sulle connessioni reali. Se un server risponde con troppi errori o timeout, può essere temporaneamente rimosso.

SSL termination con Let’s Encrypt

Terminare la connessione SSL/TLS su HAProxy è una pratica comune. Questo riduce il carico sui server backend, che non devono più gestire la crittografia, e semplifica la gestione dei certificati, concentrandola in un unico punto. Per i certificati, Let’s Encrypt è una soluzione gratuita e automatizzata.

Per abilitare SSL termination su HAProxy, sarà necessario:

1. Ottenere un certificato Let’s Encrypt (es. con certbot).
2. Combinare il certificato e la chiave privata in un unico file .pem.
3. Configurare il frontend per ascoltare sulla porta 443 e usare il certificato.

# Esempio di SSL termination
frontend https_front
    bind *:443 ssl crt /etc/haproxy/certs/mydomain.pem
    mode http
    default_backend http_back

backend http_back
    # ... (server backend)

Il file mydomain.pem dovrebbe contenere il certificato completo (certificato del dominio, certificati intermedi) e la chiave privata, concatenati in quest’ordine.

Stats page: monitoring in tempo reale

HAProxy include una pagina di statistiche integrata (stats page) che fornisce una panoramica in tempo reale sullo stato dei frontend, backend e server, inclusi il numero di connessioni, i byte trasferiti, gli errori e lo stato degli health check. È uno strumento indispensabile per il troubleshooting e il monitoraggio.

Per abilitarla, aggiungi una sezione listen specifica:

listen stats
    bind *:8080
    mode http
    stats enable
    stats uri /haproxy?stats
    stats realm Haproxy\ Statistics
    stats auth admin:password123
    stats refresh 10s

Accedendo a http://:8080/haproxy?stats e inserendo le credenziali, potrai visualizzare i dati. Per un monitoraggio più granulare o per l’integrazione con sistemi esterni, è possibile interrogare lo socket di HAProxy:

# Stats via socket
echo 'show stat' | socat stdio /var/haproxy/admin.sock | cut -d',' -f1,2,18

Questo comando mostra le statistiche, filtrando per server e stato, utile per script di automazione o integrazione con Grafana/Prometheus. Ho utilizzato spesso questo metodo per creare dashboard personalizzate in ambienti enterprise con centinaia di server.

Alta disponibilità con Keepalived e VIP

Per eliminare il singolo punto di fallimento rappresentato da HAProxy stesso, è fondamentale implementare un meccanismo di alta disponibilità. Keepalived è la soluzione più comune e robusta per questo scopo.

Keepalived utilizza il protocollo VRRP (Virtual Router Redundancy Protocol) per assegnare un IP virtuale (VIP) a un cluster di server. Un server è il MASTER, gli altri sono BACKUP. Se il MASTER fallisce, il BACKUP prende il suo posto e assume il VIP, garantendo che HAProxy sia sempre disponibile. Questo è un requisito fondamentale per la NIS2, che enfatizza la resilienza dei sistemi critici. Secondo il Verizon DBIR 2025, il downtime imprevisto costa alle aziende milioni di euro all’anno; prevenire questi scenari è un investimento irrinunciabile.

Installazione di Keepalived:

sudo apt install keepalived

Configurazione di esempio (/etc/keepalived/keepalived.conf) sul nodo MASTER:

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass mysecretkey
    }
    virtual_ipaddress {
        192.168.1.200/24
    }
    track_script {
        chk_haproxy
    }
}

vrrp_script chk_haproxy {
    script "/usr/bin/killall -0 haproxy"
    interval 2
    weight -20
}

Sul nodo BACKUP, la configurazione sarà simile, ma con state BACKUP e una priority inferiore (es. 90). Il virtual_ipaddress è il VIP che i client useranno per connettersi ad HAProxy. Lo track_script chk_haproxy assicura che Keepalived monitori il processo HAProxy: se HAProxy fallisce, Keepalived declassa il nodo, consentendo al backup di subentrare.

Errori comuni e troubleshooting

• haproxy -c -f /etc/haproxy/haproxy.cfg fallisce: Controlla attentamente la sintassi. Spesso sono errori di battitura, spazi extra o direttive fuori posto. Il messaggio di errore è quasi sempre molto specifico.
• Backend server non raggiungibile: Verifica che gli IP e le porte dei server nel backend siano corretti e che non ci siano firewall (sul server HAProxy o sui backend) che bloccano le connessioni. Usa telnet IP PORTA dal server HAProxy per testare la connettività.
• SSL handshake fallito: Assicurati che il file .pem contenga il certificato completo (dominio + intermedi) e la chiave privata, nell’ordine corretto. Controlla i log di HAProxy per errori specifici.
• Problemi con Keepalived: Verifica i log di Keepalived (journalctl -u keepalived) su entrambi i nodi. Assicurati che il virtual_router_id sia lo stesso, l’auth_pass corrisponda e che le priorità siano configurate correttamente (MASTER > BACKUP). Un errore comune è che il VIP non venga assegnato correttamente a causa di conflitti di IP o firewall.

FAQ — Domande Frequenti

Qual è la differenza principale tra mode http e mode tcp in HAProxy?

mode http opera al livello 7 (applicazione) del modello OSI, consentendo a HAProxy di ispezionare e manipolare gli header HTTP, gestire cookie, terminare SSL e applicare regole di routing basate sul contenuto della richiesta. mode tcp opera al livello 4 (trasporto), bilanciando le connessioni TCP senza ispezionare il contenuto. È più veloce ma meno flessibile, ideale per database o altri servizi non-HTTP.

Come posso aggiungere nuovi server backend senza downtime?

HAProxy supporta il ricaricamento della configurazione senza interruzioni del servizio (sudo systemctl reload haproxy). Puoi aggiungere o rimuovere server nel file haproxy.cfg e poi ricaricare. HAProxy gestirà le connessioni esistenti in modo trasparente e inizierà a bilanciare le nuove richieste con la configurazione aggiornata. Per un controllo più granulare, HAProxy Enterprise offre funzionalità di gestione dinamica dei backend.

È possibile usare HAProxy per bilanciare database come PostgreSQL o MySQL?

Sì, assolutamente. Per bilanciare database, si userebbe mode tcp e un algoritmo come leastconn o roundrobin. È fondamentale configurare health check specifici per i database, ad esempio verificando la connettività alla porta del database o eseguendo una query di base, per assicurarsi che il database sia realmente operativo e non solo in ascolto sulla porta.

Qual è l’impatto di HAProxy sulle performance complessive?

HAProxy è estremamente performante e il suo overhead è minimo. In scenari tipici, l’impatto sulla latenza è nell’ordine di microsecondi. La sua efficienza è uno dei motivi per cui è scelto in ambienti ad altissimo traffico. Il beneficio di una migliore distribuzione del carico e dell’alta disponibilità supera di gran lunga il piccolo overhead introdotto.

Conclusioni con takeaway operativi

HAProxy è uno strumento indispensabile per qualsiasi ambiente IT che richieda scalabilità, performance e alta disponibilità per le applicazioni web. La sua configurazione, sebbene dettagliata, offre un controllo granulare sul flusso di traffico e sulla gestione dei server backend. Ho visto in prima persona come l’implementazione corretta di HAProxy possa trasformare un’infrastruttura fragile in un sistema robusto e resiliente, in grado di gestire picchi di traffico imprevisti senza disservizi. Ricorda sempre di verificare la configurazione, monitorare le statistiche e testare i failover. L’alta disponibilità non è un costo, ma un investimento essenziale per la continuità operativa.

Leggi anche: Docker Sicurezza Produzione: 10 Best Practice Ignorate (2026)

Leggi anche: Linux: Liberare Spazio Disco con 12 Comandi (Guida SysAdmin 2026)

Leggi anche: Cisco IOS Troubleshooting: Metodología y Comandos para Redes (2026)

Per approfondire la configurazione e le funzionalità avanzate, consulta la documentazione ufficiale di HAProxy.

Aggiornato: luglio 2026