Archivi tag: haproxy

MaxScale – un proxy per i Database MariaDB e MySQL

Maxscale - Proxy per MariaDB & Mysql

Maxscale – Proxy per MariaDB & Mysql

MaxScale è il nuovo database proxy server open source sviluppato da MariaDB Corporation Ab.

MaxScale nasce con un concetto di proxy alla base, ma con una filosofia ed un approccio “database centrico” ed una architettura a plugin estremamente configurabile.

Per chi si fosse perso i precedenti articoli riguardanti i Proxy Server, ricordiamo che, un proxy, è un server che fa da intermediario in una connessione, ossia esso riceve le richieste da un client e le reindirizza verso altri server che sono i destinatari delle richieste. In altre parole un proxy funziona come un centralinista: riceve la chiamata del cliente  e la gira al primo operatore libero.
Per capire meglio cosa e’ in grado fare elenchiamo alcune delle sue funzionalità principali quali:

  • controllo della disponibilità del Database (monitoring)
  • load balancing
  • analisi della query in ingresso per capire se indirizzarla su una specifica tipologia di server

tutto questo, e molto altro ancora.

MaxScale si può inserire in modo trasparente tra l’applicativo e il server MySQL, esattamente come fa un proxy web tra il nostro browser e il sito che stiamo cercando di visitare.
Grazie ad un proxy è possibile avere:

  • Ridondanza: usando più di un database dietro al proxy, poiche’ un solo server non fornisce l’affidabilità e l’alta disponibilità in caso di down di una macchina.
  • Diminuizione dei costi di infrastruttura: perché generalmente due server piccoli sono meno costosi che un unico server molto performante.

Per migliorare la spiegazione ora vedremo due tipi di database proxy server:

I proxy di livello trasporto come HAProxy (di cui abbiamo piu’ volte parlato in altri articoli).
I proxy di livello applicativo come MaxScale
HAProxy: un proxy efficiente, rapido e funzionale

Fino ad oggi tra i proxy più usati in ambito MySQL Cluster è l’HAProxy che lavora ad un livello più basso (livello 4: trasporto). HAproxy pero’ non conosce nulla di MySQL e si occupa quindi soltanto di bilanciare le connessioni tra i server. Haproxy e’ molto veloce, leggero ed efficente, tuttavia questo tipo di bilanciamento è fatto senza che il proxy sia a conoscenza di cosa sta smistando. Questo rende il sistema meno efficente poiché un server può ricevere molte richieste pesanti, mentre altri server possono essere scarichi. Quindi l’HAProxy non è la scelta vincente in tutti i casi.

MaxScale: e’ un proxy che in configurazioni di questo tipo può fare cose incredibili

MaxScale lavora a livello più alto (livello 7: applicativo) e, monitorando i server riesce a capire cosa sta succedendo all’interno dell’infrastruttura. Conoscendo il protocollo MySQL può intervenire manipolando il traffico tra client e server. Ecco alcune delle sue principali funzionalità:

  • Filtro delle query al database
  • Gestione del routing: instradamento delle richieste a uno o più database server
  • Modifica delle query al volo prima che raggiungano il database
  • Possibilità di nascondere la struttura interna dell’infrastruttura lasciando un singolo punto d’accesso.
  • Alta affidabilità e scalabilità del sistema
  • Possibilità di spostare un database dal server locale ad un server esterno senza modificare la configurazione delle applicazioni
  • Divide automaticamente le scritture sul server MASTER e le letture su uno o più database SLAVE.
  • MaxScale può fornire un Load Balacing delle connessioni senza bisogno di utilizzare applicazioni o CMS che prevedano questa funzionalità. Questo significa che CMS come Joomla! o WordPress possono trarre i benefici usando una replicazione Master/Slave per rendere scalabile il proprio sito.

Caratteristiche di MaxScale

Il punto di forza di MaxScale è sicuramente la sua modularità che permette una notevole libertà adattandosi a molti casi d’uso. MaxScale è :

  • Modulare: un sistema di moduli ne definisce le funzionalità
  • Estendibile: è possibile applicare più filtri anche in cascata
  • Flessibile: i moduli e i filtri possono essere aggiunti dinamicamente

I moduli base di MaxScale

Ecco i 5 moduli che costituiscono il cuore di MaxScale:

  • Protocol: da la possibilità di utilizzare più protocolli es. MySQL client, http, telnet;
    I client si connettono a MaxScale anziché al database MySQL senza accorgersi della differenza. Possono usare le stesse librerie di connessione utilizzate fino ad ora: es. MySQL client o MariaDB client
  • Authentication: il sistema di autenticazione permette ai client di accedere a MaxScale usando le credenziali presenti sui server di Backend;
    MaxScale non ha un sistema di autenticazione o un database di utenti. Vengono utilizzati gli stessi utenti presenti sui database di backend, caricati all’avvio dell’applicazione
  • Monitor: legge la configurazione dello stato del sistema direttamente dai server di backend;
    Viene utilizzato per capire in ogni momento lo stato di tutti i database di backend collegati a MaxScale. In questo modo è possibile sapere qual’è il server Master e quanti Slave stanno replicando correttamentei dati. Il monitor può essere utilizzato per controllare un Galera Cluster.
  • Router: smista le connessioni a uno o più database di backend;
    Dirige il traffico dal client ai server utilizzando una regola specifica denominata connection routing
  • Filter e logging: i filtri permettono di modificare le query oppure di scrivere un file di log con tutte le richieste e le risposte ricevute;
    Tra i più potenti strumenti messi a disposizione di MaxScale ci sono sicuramente i filtri che permettono di effettuare operazioni avanzate sulle query senza modificare il comportamento dell’applicazione, 1) processando query SQL e risultati, 2) utilizzando una semplice regex, 3)  analizzando, modificando o rifiutando le query, 4) mettendo più filtri in cascata

Non resta che testare di persona, magari con un ambiente ad hoc con Docker e Vagrant.

 

Load Balancing Systems

Load Balancing Systems

Load Balancing Systems

Ormai Internet e’ parte della vita di milioni di persone e’ lo sara’ sempre di piu’. Sono lontanissimi i tempi dei siti statici con qualche migliaio di accessi al mese o poco piu’, oggi quasi ogni tipologia di servizio offerto dalle aziende o dalla pubblica amministrazione, ha la gestione su di un portale Internet, dunque la gestione degli accessi, al secondo, e’ diventata la discriminante per valutare un ottimo servizio da uno scadente; si pensi alla fantastica operabilita’ di portali come Facebook, Twitter o Gmail, solo per citarne alcuni, che permettono e gesticono l’accesso di milioni di utenti 24h senza praticamente disservizi o rallentamenti .

Ora dietro c’e’ una mole di lavoro ingegneristico del software, dell’hardware, dell’architettura migliore, del DB piu’ performante etc ma, prima che tutto cio’ inizi ad operare l’utente dev’essere, per prima cosa, agganciato ed instradato verso il server (fisico o virtuale che sia) che accogliera’ le sue operazioni (acquisti , home banking, pagamento bollette…), tutto cio verra’ fatto dall’infrastruttura di Load Balancing, che puo’ essere un fiore all’occhiello dell’azienda oppure trasformarsi in un Mega Point of Failure, quindi vediamo di spiegare meglio che cosa sono i Load Balancer e come operano.

Letteralmente “Load Balancing” significa bilanciare il carico di lavoro su più nodi dell’architettura.Viene spesso confuso come tecnica per ottenere l’ High Availability (HA), ma pur condividendone alcuni mezzi, ha dei fini totalmente diversi.

In pratica il “bilanciatore di carico”, per chi non lo sapesse, è quel componente (di frontend) che prende in carico le connessioni in ingresso (quelle degli utenti per gli accessi POP/IMAP ad esempio) e le smista verso i server (backend) veri e propri che erogano i servizi (webserver, application server..). E’ sempre il bilanciatore che interviene quando un server di backend viene rimosso dal cluster, per manutenzione o interruzione, a dirottare il traffico verso i server rimasti attivi.

Uno degli errori più comuni per effettuare il Load Balancing è quello di prendere come riferimento il Load dei server, scrivendo sulle console delle nostre macchine il comando “uptime”, riceveremo come risposta un dato come questo

16:49 up 453 days, 12:17, 56 users, load averages: 0,59 0,46 0,47

dove gli ultimi tre numeri identificano il carico del server negli ultimi 1, 5 e 15 minuti rispettivamente.

Immaginiamo ora di aggiungere ulteriori nodi quando il carico di un server negli ultimi 5 minuti superera’ il valore di 1,5. La nuova macchina aggiunta partirà con un carico pressoché a 0 e verrà invasa da centinaia di richieste fino a rischiarne la saturazione, e dovremo inoltre attendere altri 5 minuti prima che un nuovo bilanciamento possa intervenire.

Peccato che prima di quei 5 minuti il nostro nuovo server farà parecchia fatica a rispondere a tutte queste richieste, perdendo cosi di fatto parecchi utenti a causa di errori di pagina non trovata oppure di time out per la troppa attesa etc….facendo perdere parecchi soldi all’azienda. Questo tipo di problema è chiamato “staleness”, e può essere aggirato con altre tecniche che non si basano su una metrica numerica.

Come implementare il load balancing:

Come scegliere quindi su quale server dirigere una richiesta?

La tecnica di Load Balaincing più semplice è detta Round Robin, il suo principio e’ che ogni richiesta che viene effettuata viene smistata su un server differente, a rotazione.

In un cluster di 100 macchine, 100 richieste verranno distribuite su tutti 100 i servers a rotazione dal primo all’ultimo. Questa è una tecnica molto semplice da usare, e inclusa ad esempio già in Apache, ma si porta il limite che se un server è sovraccarico non avrà mail il tempo rientrare in una situazione di normalità che subito dopo dovra’ gestire un’ennesima richiesta e cosi via.

La tecnica “Random” ci offre un modo elegante per distribuire le richieste; in pratica non si basa su nessuna metrica, ma per i puristi resta comunque fuori controllo poiche’ offre comunque la possibilià (anche se randomica) di continuare a girare richieste verso server già sovraccarichi.

Una variante della tecnica “Random” è la “Weighted Random“, dove viene introdotta la variabile “potenza del server”, ossia i server più potenti avranno una possibilià più alta di ricevere richieste, rispetto ad hardware meno performante.

La tecnica “Predictive” invece è una variante del “Round Robin”, in questa metodologia vengono introdotte alcune variabili al normale ciclo per permettere di avere una ripartizione più accurata saltando ad esempio i server già troppo carichi. E’ una tecnica implementata a livello di Load Balancers hardware, e i produttori sono di solito restii a documentare gli algoritmi “Predictive”.

Resta scontato che, una volta scelta la tecnica preferita, dovremo prendere in considerazione anche altri problemi. Ora, ad esempio, proviamo ad uscire dal ragionamento di un singolo Load Balancer, e proviamo ad aumentare la posta ed a pensare in modalita’ High Availability con almeno due bilanciatori dove il lavoro del primo verrà supportato o, in caso di problemi, preso in carico dal secondo, che redistribuirà il traffico secondo una sua logica.

Per l’utente finale (colui che naviga dal suo browser) non cambierà nulla, infatti il browser si connetterà ad un IP dove non ci sarà un webserver ad attenderlo, ma il Load Balancer. Il Load Balancer girerà quindi, seguendo il nostro metodo di allocazione scelto, la richiesta ad un webserver scarico pronto a risponderci.

Cosa fondamentale e’ che i due, o più load balancer, devono essere in grado di parlarsi e condividere informazioni, così che entrambi sapranno che un dato server è da considerare sovraccarico o che un altro server sta per uscire dal pool.

Come scegliere il giusto load balancing

Scegliere il metodo di load balancing, e lo strumento col quale applicarlo, necessitano quindi di studi specifici sul tipo di traffico, e sull’architettura dell’applicazione che si vuole bilanciare, soprattutto quando entrano in gioco variabili come SSL.

L’SSL è basato sulla generazione di un certificato legato ad un IP, e in uno scenario dove abbiamo diversi IP virtuali che rigirano il traffico verso altri “nattati” diventa quantomeno improbabile poter gestire in modo corretto il certificato. Questo proprio perche’ il certificato è usato per validare la reale identità del server web, quindi mettendoci in mezzo un load balancer otterremmo un “man in the middle” che invalidera’ la connessione SSL.

L’unico modo diventa spostare la connessione SSL solo tra browser e Load balancer, inserendo il certificato sul VIP del sistema di Load Balancing e lasciando il traffico dopo il Load balancer in chiaro (anche se è sempre possibile attraverso una VPN ottenere maggiore sicurezza sui canali di comunicazione).

In sostanza, il Load balancing è un argomento semplice da capire, e probabilmente ancora più semplice da ottenere anche con hardware non dedicato, grazie alle diverse opportunità che il mondo Open Source ci regala.

Come sempre, il grosso del problema è strutturare l’applicazione nel suo complesso, incastrando i vari elementi affinché tutto il flusso dei dati sia ottimale.

La scelta del bilanciatore non e’ facile, ce ne sono di diversi tipi, sia hardware che software e, molte volte, la loro bonta’ non dipende dal prezzo che lo pagate ma dalla giusta scelta che farete a monte, di ottimizzazione del servizio che dovete erogare. Possiamo dire che molto spesso, in ambito Opensource la scelta ricade su LVS, HAProxy, Pound…, mentre in ambiti piu’ istituzionali (Banche, Assicurazioni etc) la scelta spesso ricade su F5, Citrix, Radware….

Personalmente sono un sostenitore di LVS, che ho usato spesso in grossi progetti, ma vediamo quali sono i suoi punti di forza confrontandolo con l’altro ottimo prodotto Open HAProxy.

LVS lavora in kernel-space (disponibile quindi solo per Linux) il che lo rende estremamente leggero e veloce, anche se limitato in termini di funzionalità. Haproxy è invece un software che gira in user-space, sicuramente più portabile (gira praticamente su qualsiasi Linux/Unix) ma anche più costoso in termini di risorse.

Per darvi un idea di quante poche risorse usa LVS, considerate che ogni connessione attiva occupa solo 128 bytes di memoria (nella tabella dove queste vengono memorizzate). Con circa 4GB di RAM sarete in grado di smistare qualcosa tipo 500.000 connessioni simultanee.

LVS lavora al layer 4 (vedi Open Systems Interconnection), mentre HAProxy lavora al layer 7 della pila OSI. Se questo da una parte è un vantaggio per haproxy, che può ispezionare anche il contenuto del pacchetto, di fatto si traduce in un maggiore carico a livello di CPU e quindi minore scalabilità.  In un bilanciatore di carico con LVS il carico del server sarà quasi sempre pari a 0.00, mentre con haproxy si manterrà intorno allo 0.50.

Sempre con LVS è possibile ottimizzare il consumo di banda dei singoli server che compongono il cluster. Se configurato in modalità “Direct Routing” (o LVS-TUN) il bilanciatore si farà carico solo del traffico in ingresso mentre saranno i singoli server di backend ad inviare il traffico di risposta ai client remoti. Con haproxy (o LVS configurato come NAT) tutto il traffico IN/OUT passa dal bilanciatore il che lo tiene maggiormente sotto stress e vi constringe a dimensionarlo in modo da poter sostenere un traffico di rete pari alla somma totale del traffico diretta verso l’intero cluster.

Non ultimo LVS puo’ vantare il tool ipvsadm, questo ottimo tool aggiorna la tabella d’instradamento IPVS nel kernel. Ipvsadm consente di modificare la configurazione di LVS aggiungendo e rimuovendo servizi, modificando la modalita’ di forwarding, paradigmi di bilanciamento, ecc. Il pacchetto ipvsadm non ha interfacce grafiche e segue il principio unix, fare una cosa sola e farla bene, quindi risponde al solo compito di avere uno strumento per il bilanciamento a livello 4.

Con ipvsadm è possibile selezionare un metodo per passare i pacchetti dal server LVS ai real server dove gira il servizio, i metodi principali sono:

LVS-DR (direct routing) dove il MAC addresses nel pacchetto è cambiato ed il pacchetto indirizzatto verso il real server
LVS-NAT basato sul network address translation (NAT)
LVS-TUN (tunneling) where the packet is IPIP encapsulated and forwarded to the realserver.

Praticamente un bilanciatore di carico con LVS lo potete accendere, configurare e dimenticarvelo per anni.

MaxScale DB Proxy scalabile

 

MaxScale DB Proxy Server

MaxScale DB Proxy Server

Il suo nome per esteso e’ “MariaDB MaxScale” ed è il nuovo database proxy server open source sviluppato da MariaDB Corporation Ab.

In pratica  MaxScale ci permetta di avere database ad alte prestazioni, in grado di consentire la costruzione di architetture flessibili. Ecco nel dettaglio le sue caratteristiche e funzionalità principali.

 

Innanzitutto ricordiamo a tutti che, un proxy è un server che fa da intermediario in una connessione: riceve le richieste da un client e le reindirizza verso altri server che sono i destinatari delle richieste. In altre parole un proxy è un mezzo per deviare una connessione tra due computer in modo da non collegarli direttamente. Un proxy funziona, nella sua pratica, come un centralinista: riceve la chiamata da chi vuole telefonare e la gira all’interno desiderato.

MaxScale si può inserire in modo trasparente tra l’applicativo e il server MySQL, esattamente come fa un proxy web tra il nostro browser (es. Chrome) e il sito che stiamo cercando di visitare.

Grazie ad un proxy è possibile avere:

  • Ridondanza: usando più di un database dietro al proxy. Un solo server non fornisce l’affidabilità e l’alta disponibilità in caso di down di una macchina.
  • Diminuizione dei costi di infrastruttura: perché generalmente due server piccoli sono meno costosi che un unico server molto performante.

Vedremo ora due tipologie di database proxy server:

I proxy di livello trasporto come HAProxy
I proxy di livello applicativo come MaxScale

HAProxy: un proxy efficiente, rapido e funzionale

Fino ad oggi il proxy più usato in ambito MySQL è l’HAProxy che lavora ad un livello più basso (livello 4: trasporto). HAproxy non conosce nulla di MySQL e si occupa solo di bilanciare le connessioni tra più server. E’ molto veloce, leggero ed efficente, tuttavia questo bilanciamento è fatto senza conoscere cosa sta smistando. Questo rende il sistema meno efficente poiché un server può ricevere molte richieste pesanti, mentre altri server possono essere scarichi. Quindi l’HAProxy non è la scelta vincente in tutti i casi.

MaxScale: un proxy che può fare cose incredibili

MaxScale lavora a livello più alto (livello 7: applicativo), monitorando i server riesce a capire cosa sta succedendo all’interno dell’infrastruttura. Conoscendo il protocollo MySQL può intervenire manipolando il traffico tra client e server. Ecco alcune delle sue principali funzionalità:

  • Filtro delle query al database
  • Gestione del routing: instradamento delle richieste a uno o più database server
  • Modifica delle query al volo prima che raggiungano il database
  • Possibilità di nascondere la struttura interna dell’infrastruttura lasciando un singolo punto d’accesso.
  • Alta affidabilità e scalabilità del sistema
  • Possibilità di spostare un database dal server locale ad un server esterno senza modificare la configurazione delle applicazioni
  • Divide automaticamente le scritture sul server MasterR e le letture su uno o più database Slave.

MaxScale può fornire un Load Balacing delle connessioni senza bisogno di utilizzare applicazioni o CMS che prevedano questa funzionalità. Questo significa che CMS come WordPress o Joomla possono trarne dei benefici, usando una replicazione Master/Slave per rendere scalabile il proprio sito.

Caratteristiche di MaxScale

Il punto di forza di MaxScale è sicuramente la sua modularità che permette una notevole libertà adattandosi a molti casi d’uso, infatti MaxScale è:

  • Modulare: un sistema di moduli ne definisce le funzionalità
  • Estendibile: è possibile applicare più filtri anche in cascata
  • Flessibile: i moduli e i filtri possono essere aggiunti dinamicamente

I moduli base di MaxScale

Quelli elencati qui sotto sono i 5 moduli che costituiscono il cuore di MaxScale:

  • Protocol: da la possibilità di utilizzare più protocolli es. MySQL client, http, telnet
  • Authentication: il sistema di autenticazione permette ai client di accedere a MaxScale usando le credenziali presenti sui server di Backend
  • Monitor: legge la configurazione dello stato del sistema direttamente dai server di backend
  • Router: smista le connessioni a uno o più database di backend
  • Filter e logging: i filtri permettono di modificare le query oppure di scrivere un file di log con tutte le richieste e le risposte ricevute.

1. Protocollo di connessione
I client si connettono a MaxScale anziché al database MySQL senza accorgersi della differenza. Possono usare le stesse librerie di connessione utilizzate fino ad ora: es. MySQL client o MariaDB client.

2. Autenticazione
MaxScale non ha un sistema di autenticazione o un database di utenti. Vengono utilizzati gli stessi utenti presenti sui database di backend, caricati all’avvio dell’applicazione.

3. Monitor
Viene utilizzato per capire in ogni momento lo stato di tutti i database di backend collegati a MaxScale. In questo modo è possibile sapere qual’è il server Master e quanti Slave stanno replicando correttamentei dati.

4. Router
Dirige il traffico dal client ai server utilizzando una regola specifica:

  • Connection routing: normale router di connessione ad un database
  • Read/Write Split router: smista le richieste di scrittura sul Master e le richieste di lettura su uno degli Slave collegati

5. Filtri e log delle query
Tra i più potenti strumenti messi a disposizione di MaxScale ci sono sicuramente i filtri che permettono di effettuare operazioni avanzate sulle query senza modificare il comportamento dell’applicazione:

  • Processando query SQL e risultati
  • Utilizzando una semplice regex
  • Analizzando, modificando o rifiutando le query
  • Mettendo più filtri in cascata

Insomma, da questo primo articolo, si deduce che le potenzialita’ sono tutte a favore di MaxScale

 

#MaxscaledbproxyserverMysql

HAPROXY – ed il bilanciamento di carico e’ servito

HAProxy Load Balancing

HAProxy Load Balancing

Bilanciamento, chi è costui?
Quando pensiamo a come implementare un servizio web, solitamente lo immaginiamo erogato da potenti server che, all’occorenza, sono in grado di scalare in automatico in modo da garantirne la continuità.
Ma con i nuovi servizi cloud ad alta frequentazione, la mole di accessi che deve essere trattata sara’ talmente elevata da mettere in crisi qualunque configurazione.

Come evitare una situazione del genere? Utilizzare ulteriore hardware, più potente, potrebbe non essere sufficiente, inoltre gestire una configurazione composta da sempre più server richiede l’introduzione di un “oggetto” capace di distribuire le connessioni su tutte le macchine installate.

L’oggetto a cui facciamo riferimento è un Load Balancer (bilanciatore di carico), capace di distribuire tutte le connessioni entranti tra i vari server assegnati alla funzionalita’ del nostro servizio.
Così facendo sara’ possibile:

  • migliorare l’alta affidabilità del servizio, perchè le richieste verranno sempre e solo, indirizzate ai server “attivi”;
  • migliorare la disponibilità del servizio, perchè le richieste verranno inviate ai server meno “carichi” in quel momento.

La soluzione: HAPROXY
Esistono molte soluzioni commerciali in tema di Load Balancing, ma può essere più interessante, sfruttabile, performante e conveniente, ricorrere a prodotti Open Source e, tra questi, c’è HAPROXY.
HAPROXY (http://www.haproxy.org/) è un bilanciatore in grado di gestire sia connessioni HTTP/HTTPS che connessioni di tipo TCP.

Utilizzo
Per prendere coscienza di quali siano le potenzialità di HAPROXY, proviamo a fare due esempi d’impiego delle funzionalità di bilanciamento, una dedicata ad un servizio di puro HTTP, e l’altra dedicata a bilanciare un servizio esclusivamente TCP.
Per provare le funzionalità di HAPROXY ho realizzato un ambiente virtuale con vagrant costituito da tre macchine virtuali:

  • 1 macchina Gentoo (molto leggera e performante) utilizzata come bilanciatore (loadbalancer)
  • 2 macchine Ubuntu utilizzate come server da bilanciare (web1 e web2)

Installiamo HAPROXY  sulla macchina Gentoo, attraverso il comando:

emerge haproxy

Mentre sulle macchine Ubuntu procediamo con l’installazione di Apache utilizzando il comando:

apt-get install apache2

Tutte le macchine sono state collegate alla stessa rete: 192.168.0.0/24:

  • loadbalancer: configurato con l’indirizzo fisico 192.168.0.254, e con due alias, per i servizi bilanciati, 192.168.0.253 e 192.168.0.252.
  • web1: indirizzo 192.168.0.31.
  • web2: indirizzo 192.168.0.32.

Si ricorre all’uso degli alias di rete per poter pubblicare i due servizi di bilanciamento su indirizzi distinti; in alternativa sarebbe stato possibile pubblicare tutti i servizi di bilanciamento sullo stesso indirizzo fisico del server loadbalancer, perché, nel nostro caso, le porte di ascolto dei due servizi sono comunque differenti; ovviamente, se si vogliono bilanciare più servizi che ascoltano sulla stessa porta l’impiego degli alias è inevitabile.

La configurazione di un servizio di bilanciamento in HAPROXY, può essere realizzata definendo una sezione di “frontend” ed una di “backend”; la prima serve per definire il punto di accesso dei client (internet), mentre la seconda viene utilizzata per definire l’insieme dei server a cui inviare le connessioni da bilanciare.
In alternativa, è possibile configurare un’unica sezione, “listen”, in cui vengono racchiuse sia le direttive che verrebbero utilizzate per configurare le sezioni di “frontend” e di “backend”.

Esempi di impiego di HAPROXY
Il file di configurazione del servizio si trova in /etc/haproxy/haproxy.cfg.

La configurazione di Haproxy è stata impostata per includere una sezione in cui inserire i parametri che agiscono a livello globale (“global”), nel nostro caso viene configurato il log degli eventi.
Viene poi configurata una sezione in cui riportare tutte quelle impostazioni che costituiranno la base di ciascun servizio bilanciato (sezione “defaults”).

global
log /dev/log local0
log /dev/log local1 notice


defaults
timeout client 5000
timeout connect 5000
timeout server 5000

Nella sezione “defaults” sono quindi impostati i valori dei timeout:

  • i timeout di inattività lato client mentre si attende una risposta dal server (timeout client);
  • i timeout di attesa di attivazione di una connessione al server (timeout connect);
  • il timeout di inattività lato server (timeout server).

Tutti i valori di timeout sono stati impostati a 5000 millisecondi (5 secondi); ma possono essere adeguati in base alle proprie necessità.

Esempio 1: bilanciare il web
In questo primo esempio, HAPROXY viene utilizzato per bilanciare le richieste indirizzate a due server web, configurati per pubblicare una semplice pagina HTML (index2.html) che visualizza una serie di immagini (differenti tra i due server web, così da rendere evidente all’utente su quale server si è stati bilanciati).

frontend webfront
bind 192.168.0.253:80
default_backend webback
backend webback
balance roundrobin
server web1 192.168.0.31:80 check inter 5000 rise 2 fall 3 weight 10
server web2 192.168.0.32:80 check inter 5000 rise 2 fall 3 weight 10
mode http
log global
option httplog
option httpchk GET /index.html

All’interno della sezione “frontend” viene specificato l’indirizzo su cui si pone in ascolto il bilanciatore per il servizio specifico, e viene poi incluso il riferimento alla configurazione di “backend”, contenente informazioni sui server da bilanciare.

Nella parte “backend”, si può specificare quale metodologia di bilanciamento da utilizzare, quindi con quale criterio distribuire le richieste dei client, in questo caso il bilanciamento è di tipo “round robin”, cioè le richieste vengono inviate alternativamente ai due server bilanciati 50 & 50 % .
Con la direttiva “server” vengono specificati tutti i server che si vogliono bilanciare, identificando ciascuno con un nome (non necessariamente corrispondente all’hostname del server), l’indirizzo IP e la porta su cui ascolta il servizio (in questo esempio, la porta TCP/80 per il web server).
Per ogni server, vengono poi specificati i criteri da seguire per controllare se questo è attivo (a livello di servizio web) o meno, in modo da poterlo escludere a fronte di un problema.
Con l’opzione “check” viene specificata la frequenza con cui controllare il server (“inter”, impostata a 5000 millisecondi), dopo quanti check falliti il server deve essere escluso dal bilanciamento (“fall”), oppure dopo quanti check andati a buon fine (“rise”), invece, deve essere reinserito nel bilanciamento, ed il peso (“weight”) di ciascun server, in modo da poter distribuire il carico in maniera proporzionale tra le varie macchine, cosi da poter meglio bilanciare lo sforzo dei server nel caso che questi avessero hadrware con prestazioni differenti, infatti impostando un server con un peso maggiore rispetto alle altre macchine, questo riceverà un numero di richieste maggiore.

Se non si specificheranno particolari direttive, Haproxy verificera’ solo la disponibilità del servizio su ciascun server, controllando se la porta TCP specificata è in ascolto o meno.
Nel caso di web server bilanciati, è possibile definire dei controlli specifici sul protocollo HTTP interrogando direttamente la parte web, cosi che, a fronte di una risposta HTTP diversa dal codice 200 (OK) , il server verra’ escluso (“option httpchk”).

Con l’opzione httplog si attiva anche un livello di log per tutte le richieste HTTP che arrivano al bilanciatore per quel determinato servizio.
Particolare attenzione va riservata alle impostazioni di “rise” e “fall”, per cercare il giusto equilibrio che consenta di evitare che un server venga escluso, o reinserito troppo velocemente dal bilanciamento.

Esempio 2: bilanciare un servizio TCP
Oltre a bilanciare servizi HTTP, Haproxy può bilanciare praticamente qualsiasi tipo di connessione TCP; nel nostro test, sui due server attivati e’ stato configurato in ascolto, un servizio sulla porta TCP/2222.
In queso caso, HAPROXY è configurato per restare in ascolto su un indirizzo IP diverso da quello del servizio web dell’esempio precedente, e diverso dall’indirizzo fisico del bilanciatore.

frontend sshfront
bind 192.168.0.252:2222
default_backend sshbe
backend sshback
balance roundrobin
server ssh1 192.168.0.31:2222 check inter 5000 rise 2 fall 3 weight 10
server ssh2 192.168.0.32:2222 check inter 5000 rise 2 fall 3 weight 10

Troubleshooting
All’interno dei log generati da haproxy è possibile rilevare gli eventi in cui un server viene escluso, oppure incluso, nel bilanciamento.
Nel caso in cui il server (o il servizio) bilanciato non sia disponibile verrà registrato il seguente evento:

Feb 22 10:30:50 localhost haproxy[23679]: Server webbe/web2 is DOWN, reason: Layer4 connection problem, info: "Connection refused", check duration: 0ms. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.

Nel momento in cui il server/servizio torna disponibile nei log di Haproxy si troverà, invece, questo evento:

Feb 22 10:32:10 localhost haproxy[23679]: Server webbe/web2 is UP, reason: Layer7 check passed, code: 200, info: "OK", check duration: 0ms. 2 active and 0 backup servers online. 0 sessions requeued, 0 total in queue.

Conclusioni
Haproxy offre la possibilità di risolvere problemi di eccessivo carico, ma anche di realizzare un meccanismo di alta affidabilità per diverse architetture di server, con questo approccio si semplifichera’ quindi la gestione dei sistemi e dei servizi.
Le funzionalità di Haproxy non si fermano solo agli esempi trattati precedentemente, ma permettono di creare servizi di bilanciamento capaci di lavorare dal livello 3 al livello 7 della pila ISO/OSI.
Vedremo in un secondo tempo di approfondire le varie funzionalità avanzate che Haproxy mette a disposizione.

 

#Haproxy#Bilanciatoredicarico