Listino Supporto Partner Contatti Lavora con noi

Vai al Video

Implementare un Web Load balancer con HAproxy

Quando si allestisce un server e soprattutto un server per il web, uno dei problemi più rilevanti è il bilanciamento del carico, inteso come il lavoro di elaborazione delle CPU, il consumo di risorse o, nel caso delle connessioni di rete e Internet, del traffico dati.
Fortunatamente esistono degli strumenti che aiutano il system integrator e lo sviluppatore nel compito di bilanciare i carichi, eventualmente ripartendoli tra attività, fra macchine virtuali o server differenti.
Tra questi vale la pena di citare HAProxy, che è un bilanciatore di carico software cui è dedicato questo tutorial. Grazie a questo strumento possiamo in modo semplice crearci il nostro bilanciatore di traffico e, usare due o più server per gestire le nostre richieste.

Che cos’è HAProxy

Partiamo dallo spiegare che cos’è HAProxy: si tratta di un bilanciatore di carico software, che permette di creare in maniera piuttosto semplice un nostro bilanciatore di traffico dati e di utilizzare due o più server per gestire le richieste effettuate dai client che vi si connettono. Con esso possiamo anche definire tutta una serie di regole che ottimizzano il bilanciamento del carico, che riguardano il back-end e via di seguito.
È quindi un software che potete installare su un server fisico o su una macchina virtuale e non siete vincolati ad acquistare appliance o altro; inoltre è un software di libero utilizzo basato su Linux.

Possibilità di utilizzo

Possiamo usare HAPproxy per bilanciare qualsiasi tipo di connessione, sia essa relativa a Web Server, mySQL ecc. quindi lo possiamo utilizzare non solo per il bilanciamento di server web (che è quello che faremo nell’esempio proposto in questo tutorial) ma anche impiegare per fare il bilanciamento di qualsiasi tipo di connessione; per esempio possiamo applicarlo a dei server di posta elettronica, dove in alcuni casi è capitato di vederlo utilizzato a monte di sistemi anti-spam: per esempio due o tre macchine virtuali per il sistema anti-spam affacciate a un unico punto di ingresso vengono precedute da HAProxy, con la funzione di smistare i dati verso i server anti-spam per bilanciare il carico e rendere tutto molto più veloce.

Altra applicazione pratica è il bilanciamento del traffico verso dei database di mySQL messi in cluster con Galera, dove si mette HAProxy davanti per bilanciare il carico di lavoro di ciascuno. I database possono anche essere messi in cluster con i cluster di mySQL.

Quindi possiamo utilizzare HAProxy non solo come bilanciatore di carico per il nostro sito web, come verrà fatto nell’esempio proposto in questo tutorial, ma in generale come bilanciatore di carico per qualsiasi tipo di connessione.

Installazione e configurazione di HAproxy

L’installazione e la configurazione sono abbastanza semplici; poi dipende sempre dal tipo di carico che andiamo a bilanciare. In questo tutorial vedremo l’installazione predefinita valida se lavoriamo in Linux Ubuntu, per il quale è disponibile il relativo pacchetto nei repository ufficiali e non.
Possiamo utilizzare i repository ufficiali dove, però, in Ubuntu potrebbe esserci la versione 1.6.3 (che non è l’ultima) invece che la nuova, che è la 1.8.5.
Con riferimento al repository ufficiale, il comando per installare HAProxy è il seguente:

apt-get install haproxy

Oppure, in alternativa, potete utilizzare un repository differente inserendo i seguenti comandi:

apt-get install software-properties-common
add-apt-repository ppa:vbernat/haproxy-1.8
apt-get update
apt-get install haproxy


Con questi comandi viene installato Haproxy da un repository alternativo e in particolare, Ubuntu va alla ricerca della versione 1.8 (aggiungendo il repository con il comando add-apt-repository ppa:vbernat/haproxy-1.8); il comando apt-get install haproxy installa il pacchetto, mentre apt-get update predispone l’aggiornamento nel caso venga trovata nel sistema una precedente versione di HAproxy. Va comunque precisato che il comando di installazione:

  • installa HAproxy da zero se nel computer non esiste una precedente installazione;
  • aggiorna la versione esistente se nel serve è già presente una precedente versione del pacchetto.

Completata l’installazione bisogna fare la configurazione, la quale si divide in due parti, sebbene ce ne sarebbe una terza, che riguarda l’accesso al sito delle statistiche di HAProxy, che sostanzialmente è la sua pagina dove fa vedere le statistiche di accesso.
Ad ogni modo le cose da configurare sono essenzialmente quelle della parte dove lavoreremo, ossia

  1. FRONT-END -> ovvero l’HAProxy che riceve la richiesta e il tipo di richiesta;
  2. BACK-END -> e server a cui far puntare la richiesta.

La parte di front-end è l’accesso del nostro servizio, quindi il Web Server; perciò la porta 80 la facciamo arrivare sul nostro HAProxy e poi configuriamo quello che sarà il suo comportamento. Quindi la richiesta arriva ad HAProxy, che deve fare il log eccetera e poi la deve smistare a un backend. Perciò andiamo a configurare qual è il backend cui la deve smistare; per esempio in configurazioni più avanzate possiamo fare in modo che se la richiesta arriva per un determinato nome host che andiamo a intercettare, la fa andare ad un backend, mentre se arriva su un altro nome host la facciamo dirigere ad un altro back-end.

Ecco quindi che con davanti un unico HAProxy potete andare a configurare più servizi, più siti web, più Server Web da gestire in base alla richiesta che vi sta arrivando, perciò potete avere situazioni tipo quella in cui se un utente va sul back-end del vostro sito c’è un server web dedicato per fare il back-end e tramite HAProxy lo dirigete verso quel back-end.

Poi c’è la parte di back-end di HAProxy dove praticamente andate a definire quali sono di fatto i server ai quali HAProxy girare le richieste. Il prodotto, se non date delle direttive specifiche entra in modalità Round Robin, quindi rifirige le richieste in arrivo una volta ad uno, una volta all’altro server e via di seguito. In questa modalità, HAProxy gestisce in maniera autonoma il bilanciamento del carico.
In più nella relativa configurazione, di fianco al nome del server, se andiamo ad attivare l’opzione check il prodotto va a verificare che i server (o servizi) rispondano; in caso affermativo, per HAProxy il server interrogato è operativo e disponibile, mentre in caso contrario le richieste non le passa a tale server ma le invierebbe solo al server superstite, vale a dire a quello a a quelli che rispondono.

Configurazione di un Web Server interno con HAProxy

In questa prima parte dimostrativa configuriamo un Web Server interno per vedere le statistiche di utilizzo di HAProxy e monitorare che i Web Server del back-end siano raggiungibili; i comandi da eseguire sono quelli elencati qui di seguito.

listen haproxy-monitoring
bind 10.134.252.212:8080
mode http
stats enable
stats show-legends
stats refresh 5s
stats uri /
stats realm Haproxy\ Statistics
stats auth admin:webinar12.
stats admin if TRUE
timeout connect 3500ms
timeout client 10800s
timeout server 10800s


Nella parte iniziale, che riguarda il monitoraggio di HAProxy, facciamo il bind del nostro indirizzo IP privato sulla porta predefinita (il prodotto lavora per default sulla porta 8080) poi andiamo a metterci username e password per l’accesso al sito (a questa pagina di statistica); il resto della configurazione è standard che esce con HAProxy è già così potete modificare il bind e la parte di autorizzazione per l’accesso alla schermata delle statistiche.
Quest’ultima è una schermata molto semplice dove vedete il nome del vostro backend e del vostro frontend.

Dato che potete lavorare con più frontend e con più backend all’interno dello stesso HAProxy (per non stare a implementare più macchine, soprattutto se poi avete un unico punto di accesso ai servizi, ossia un unico IP pubblico da cui si accede al vostro servizio) è buona regola dare ai vari front-end e back-end dei nomi abbastanza esplicativi del servizio che stanno facendo, allo scopo di non fare confusione.

Vediamo adesso la parte il configurazione del nostro front-end e back-end; partiamo dal front-end, le cui istruzioni sono quelle elencate qui di seguito:

frontend HTTP_FRONTEND
bind 10.134.252.212:80
maxconn 4000
option httplog
log global
mode http
default_backend HTTP_BACKEND
timeout client 1m


Come vedete, la parte relativa al front-end è molto semplice: nella prima riga assegniamo il nome del front-end (HTTP_FRONTEND, nel caso dell’esempio) poi comandiamo il bind sulla porta 80, impostiamo il numero massimo di connessioni (maxconn 4000) quindi diciamo di effettuare il log dell’HTTP (log global); con il comando mode http impostiamo la modalità HTTP. È importante aver specificato che si tratta di una modalità HTTP e non TCP e vedremo poi il perché.
Nella penultima riga specifichiamo qual è il suo back-end predefinito (HTTP_BACKEND) e nell’ultima il time-out del client, stabilito in 1 minuto.

Andiamo ora alla configurazione del back-end, che al solito inizia con la definizione del nome assegnato:

backend HTTP_BACKEND
mode http
log global
option http-pretend-keepalive
option http-server-close
option forwardfor header X-Real-IP


Notate alla seconda riga il comando che imposta la modalità HTTP, fondamentale perché dev’essere la stessa del front-end; se non si imposta mode HTTP, il log HTTP richiesto non verrebbe accettato.

Abbiamo poi tre righe contenenti altrettante opzioni: option http-pretend-keepalive, option http-server-close e option forwardfor header X-Real-IP; queste spiegano perché è importante definire la modalità HTTP, in quanto se non andate a specificare che la modalità del back-end e del front-end è HTTP, ma stabilite che è TCP (perché ad esempio possiamo usarla per la porta 25 e sostanzialmente per tutti i servizi ) succede che queste opzioni non vengono riconosciute e HAProxy ci risponde che non sono opzioni valide per questo tipo di modalità e quindi poi non gira (non ne fa il forward) il Real-IP al nostro Server Web.

Ma perché è importante che HAProxy giri il Real-IP (ossia l’IP effettivo) al Web Server? La risposta è nel fatto che che il Real-IP serve quando andiamo a vedere le statistiche, piuttosto che quando vogliamo conoscere da quale IP address si è collegato un determinato utente, ad esempio perché abbiamo a che fare con un sito di e-commerce e gli utenti si loggano, quindi dobbiamo conoscere da quali IP si sono collegati (per un discorso legato alla sicurezza); se non impostiamo l’opzione HTTP e poi nella configurazione lato sito indichiamo di usare il Real-IP, praticamente vedremmo sempre un unico IP che corrisponde a quello dell’HAProxy.
Questo perché il traffico finisce su HAProxy e da questo viene ripartito ai server; in pratica è HAProxy che comunica con il nostro server ed è quello che gestisce la connessione (quindi non connette gli IP privati dei server al proprio), quindi il nostro Web Server di provenienza si troverebbe eventualmente l’IP privato di HAProxy o eventualmente l’IP pubblico.
Parliamo di IP pubblico perché facendo questo tipo di configurazione potete mettere i vostri Web Server sparsi in giro per il mondo: potete averne uno in casa, uno ad esempio su Amazon, uno su IWH ed uno su Coretech, quindi mettete HAProxy davanti a tutti i vostri server, impostate gli IP pubblici dei vari server e smistate così le varie richieste localmente.

Citiamo questa situazione perché può essere un metodo per servire l’utenza in base alla regione geografica da cui un client si connette: per esempio se avete preso un server IWH in Germania, chi si connette dalla Germania viene diretto sul server web che avete messo in Germania. Potete quindi fare geolocalizzazione con qualcosa di questo tipo, analizzando i DNS e ridirigendo le richieste verso i server più vicini.

Il Real-IP è quindi importante perché altrimenti vedremo sempre l’IP di HAProxy e quindi avremmo tutte le statistiche e tutte le login sfalsate perché risulterebbe che è sempre HAProxy ad autenticarsi e non avremo mai il match con l’IP pubblico reale dell'utente.

Detto questo vediamo la parte di istruzioni scritte per definire i server cui girare le richieste:

####SERVER A CUI GIRARE LE RICHIESTE####
server web01 10.134.252.210:80 check
server web02 10.134.252.213:80 check

timeout server 1m
timeout connect 30s

In ciascuna delle istruzioni server andiamo a mettere ad esempio server web 01, l’indirizzo IP privato e la porta 80 (ma potrebbe essere un’altra porta, in base a quale è stata configurata in ascolto per il server in oggetto) poi web 02 e i relativi dati e via di seguito. Il parametro check serve per dire ad HAProxy di eseguire il check del server, allo scopo di capire se è “vivo” o fuori uso.
A riguardo notate che se il servizio richiede una password di accesso o se per qualche altra ragione l’opzione check dovesse non funzionare, sarà possibile toglierla dalle istruzioni suesposte; in questo caso HAProxy non metterà più il servizio in verde ma in grigio nella sua pagina di statistiche, però a quel punto il prodotto non saprà più se il server è disponibile o meno per l’utilizzo e quindi questo può creare dei problemi nel caso il server non risponda o abbia problemi che ne impediscano l’utilizzo.

Testare la configurazione di HAProxy prima dell’avvio

Possiamo andare ad avviare servizio, ma prima di avviarlo è cosa buona fare un test della configurazione, soprattutto se l’abbiamo modificata; in questo caso prima di riavviare servizio e applicarla facciamo un test impartendo il comando seguente:

Con questo comando testiamo la configurazione per verificare che sia corretta, a prescindere dal fatto che sia una configurazione nuova o la modifica di una esistente. Il comando verifica che la sintassi del file sia corretta, che non siano state specificate delle opzioni che non vanno bene; se si chiede di fare il bind a un IP che non è il suo o di girare le richieste ad un IP sbagliato, il test non è in grado di verificarlo.

Se dal test non risultano errori, possiamo riavviare il servizio mediante i seguenti comandi, che riavviano HAProxy e ne verificano lo stato:

 

e andiamo a vedere lo status per accertarci che il servizio sia effettivamente attivo (immagine seguente).

Esempio pratico: eseguire un web Load Balancer

Concludiamo con una piccola demo per farvi vedere come funziona HAProxy: partiamo dal presupposto di aver già creato due server di test chiamati WEB01 e WEB02 basati su ubuntu, ciascuno dei quali riaponde su una porta differente. Le due macchine sono Ubuntu con la stessa versione, praticamente uguali, però su due porte diverse perché condividono lo stesso IP pubblico.
Andiamo quindi ad aprire un terminale, che nel caso dell’immagine seguente è PuTTY per collegarci al nostro server HAProxy.

Naturalmente HAProxy è già stato installato e dobbiamo averlo lanciato con il comando:

systemctl start haproxy

Notate che siccome il comando non restituisce alcun a risposta, per vedere se ha sortito l’effetto desiderato dobbiamo impartire:

systemctl status haproxy

per conoscere lo stato e qui avremo una risposta, la quale sarà Active [running] se il servizio sarà partito.
Allorché se il prodotto si avvia correttamente, aprendo la pagina del browser, sulla porta 80 vedremo se risponde: in caso affermativo appare la finestra di autenticazione, oltrepassata la quale accediamo alla schermata delle statistiche di HAProxy (immagine seguente) ovvero la parte di monitoring.

In essa vedete le statistiche di back-end e front-end, poi quelle dei due server web01 e web02, visualizzati come attivi (in verde) le 4.000 connessioni consentite ecc.
Se adesso si va a mettere down uno dei due server (con il comando service apache 2 stop), il riquadro corrispondente diventa rosso, viene visualizzato il messaggio “server down” ed è indicato da quanto tempo il relativo server non risponde.

Più esattamente, in un primo momento la riga diventa gialla, perché il server non risponde, quindi una volta trascorso il time out impostato diviene rossa e nella colonna Status appare DOWN, con il relativo tempo.

Andiamo adesso a vedere come appare l’interfaccia quando HAProxy sta facendo il balancing del traffico: se da un client andiamo a ricaricare la pagina info.php ci risponde web02, poi se la andiamo a ricaricare risponde web01 e via di seguito.

Nella riga di ciascun server, la schermata di monitoring ci fa vedere le connessioni che abbiamo eseguito e quanto traffico abbiamo fatto per ciascun servere: in Sessions, la colonna Lbtot indica quante connessioni ha servito il rispettivo server. Vediamo anche a quante richieste ha risposto ecc.

Cliccando all’interno delle sezioni delle singole righe corrispondenti ai server potete aprire un riquadro giallo che riepiloga le statistiche corrispondenti al relativo server (immagine seguente) e molti dati utili.
Insomma, vi vedete un po’ di informazioni come lo stato, le risposte HTTP che ha dato, quelle che non sono andate a buon fine, se sono apparsi degli erroti ecc. Accanto ad HTTP viene indicato un numero con due X che riepiloga per ciascuna riga (1xx, 2xx, 3xx, 4xx, 5xx) il tipo di evento o di errore corrispondente (per esempio il canonico errore 404). Come vedete è tutto molto semplice.

Purtroppo, essendo HAProxy un prodotto gratuito, con esso non viene fornita un’interfaccia di gestione da web; se cercate in Rete ne trovate alcune a pagamento, comunque eventualmente è disponibile l’appliance specifica di HAProxy, però a pagamento, che dispone di tutta l'interfaccia di gestione eccetera. 

Ripe Ncc Member
vmware
CloudLinux
Plesk
HP
Microsoft