Load Balancer. Cos’è? A cosa serve?

In questo nuovo articolo del nostro blog parleremo di load balancer, o bilanciatori di carico. Ma cos’è un load balancer ? L’idea di pubblicare questo articolo mi è venuta qualche giorno fa, quando mio figlio, inaspettatamente, mi ha chiesto: “Papà, ma quant’è grande il computer che fa funzionare Amazon?”. Sono andato in loop; cervello in cortocircuito per dieci secondi. “E ora come glielo spiego?”, mi sono chiesto. Ho preso una boccata d’ossigeno, cercando le parole adatte a spiegare a un ragazzo di 13 anni come funziona una web application (lo so, è super riduttivo definire Amazon così).

Ovviamente ho omesso tutte le tarantelle su cloud, paas, autoscaling etc etc, e gli ho ingenuamente risposto: “In realtà non c’è un solo computer, ce ne sono tantissimi”. Da piccolo nerd curioso qual è, cosa che avrei dovuto aspettarmi, mi ha incalzato: “Ce ne sono 1000? Io vado sempre sullo stesso o ogni volta su uno diverso?”. Mi sono armato di carta e penna (cosa che lui odia) e gli ho spiegato a grandi linee, facendo un schizzo a matita molto simile all’immagine a inizio pagina (ma senza i punti interrogativi; quelli cercavo di eliminarli dalla sua testa), cosa succede quando si visita un sito web di grandi dimensioni. Dopo una decina di minuti abbiamo finito. Lui si alza e mi dice: “Ok grazie, ho capito. Funziona tutto grazie alla bilancina (n.d.r bilanciatore) li davanti”. Cos’è quindi un load balancer ?

“Funziona tutto grazie alla bilancina li davanti”

In realtà tutti i torti non ce li ha. Quella che lui chiama bilancina, e che noi chiameremo con il suo nome corretto ovvero bilanciatore di carico (o di traffico), o più semplicemente bilanciatore, è una delle componenti principali di un’architettura web.

Indice dei contenuti

• Cos’è un load balancer?
• A cosa serve?
• Perché è utile per un sito web?
• Come funziona un Load Balancer?
• Funzionalità avanzate di un Load Balancer

Cos’è un load balancer?

Se provare a risolvere sul DNS www.amazon.it, noterete che viene risolto con un indirizzo IP (104.94.236.221 nel momento in cui sto scrivendo). Anche il vostro computer per navigare su internet utilizza un indirizzo IP. Provate a visitare il sito https://www.myip.come troverete l’IP del computer che state utilizzando. Ciò significa che ogni computer, smartphone, o server ha bisogno di un IP address per navigare e per essere raggiunto e riconosciuto su internet.

Qui torniamo alla domanda di mio mio figlio. Quindi Amazon ha un solo “computer”? Ovviamente NO. 

Come si fa ad avere tanti computer che rispondono con un solo indirizzo?

E’ proprio qui che entrano in gioco le funziona di un load balancer. Cosa dice Wikipedia a riguardo?

In informatica il bilanciamento del carico, in inglese load balancing, è una tecnica informatica utilizzata nell’ambito dei sistemi informatici che consiste nel distribuire il carico di elaborazione di uno specifico servizio, ad esempio la fornitura di un sito web (in questo caso prende il nome più specifico bilanciamento carico di rete), tra più server, aumentando in questo modo scalabilità e affidabilità dell’architettura nel suo complesso.

A cosa serve?

In pratica se arrivano 10 richieste per una pagina web su un cluster di 3 server, alle prime 3 risponderà il “primo” server, a 3 il “secondo” ed alle ultime 4 il “terzo”.

La scalabilità deriva dal fatto che, nel caso sia necessario, si possono aggiungere nuovi server al cluster, mentre la maggiore affidabilità deriva dal fatto che la rottura di uno dei server non compromette la fornitura del servizio (fault tolerance) agli utenti;

Il load balancer quindi si preoccupa di prendere in carico le richieste dei clienti e di inoltrarli ai server che erogano il servizio richiesto. Proviamo a schematizzare il concetto:

Il servizio vero e proprio quindi, non è erogato dal load balancer, che altro non fa che ruotare il traffico, bensì dai server bilanciati presenti nell’area viola sulla destra.

Il bilanciatore permette di inserire una batteria di server (2, 5, 10, 100, X+n a piacimento) che erogano il servizio esposto su internet. Tendenzialmente, maggiore è il traffico, maggiore è il numero di server configurati dietro un bilanciatore. Amazon e Google probabilmente avranno centinaia di server bilanciati. Il sito della gazzetta della vostra città probabilmente solo qualcuno. Il vostro blog personale, “hostato” su un server su Aruba, non ha un bilanciatore :). Questo perché, affinché un bilanciatore abbia motivo di esistere, devono esserci almeno 2 server bilanciati.

Perché è utile per un sito web?

Da Wikipedia abbiamo scoperto nuovi concetti associabili a un load balancer:

1. Scalabilità
2. Affidabilità
3. Performance (questo l’ho aggiunto io)
4. Sicurezza (questo pure)

Prendiamo in esame il sito della Gazzetta della nostra città che oggi ha un bilanciatore di carico che smista il traffico su 2 server (Server 1 e 2 in Figura 2) che erogano il servizio web. E’ ormai un mese che viene pubblicizzata la notizia secondo la quale, nella giornata di domani, la nostra Gazzetta lancerà un concorso a partire dalle ore 11:00. Tra tutti i visitatori che si registreranno al sito tra le 11:00 e le 12:00 verrà estratto un fortunato vincitore di una Tesla Model X. E’ molto probabile che questa iniziativa porti un elevatissimo volume di traffico al sito (sicuramente molto più alto del solito). E’ anche altrettanto probabile che i due server non basteranno a reggere il carico causato della massa di visitatori.

Scalabilità: Sarà sufficiente aggiungere un paio di server alla lista dei server bilanciati (server 3 e 4 in Figura 2) per riuscire a reggere il doppio dei visitatori.

Affidabilità: Cosa accadrebbe nella malaugurata ipotesi che uno dei 4 server dovesse rompersi? Nulla. Gli altri 3 continuerebbero ad erogare servizio; con meno potenza elaborativa certo, ma di sicuro il sito non sarebbe irraggiungibile. Questo perché il bilanciatore si accorge che il server non sta più rispondendo, e lo esclude dal bilanciamento. In sostanza non gli gira più il traffico degli utenti. Questo ci viene in aiuto anche nel caso ci sia la necessità di fare un aggiornamento di sistema operativo (o applicativo) dei server. Lavorando su un server alla volta sarà possibile non andare in disservizio.

Sicurezza: Senza un bilanciatore davanti ai nostri server potremmo essere costretti a esporre i nostri server direttamente su internet tramite un IP pubblico, come mostrato nell’immagine seguente.

Questo è quello che fanno molti ISP quando si noleggia un server. In realtà ci sono delle alternative per evitare di esporre un server su internet con il proprio IP pubblico. Per esempio si potrebbe usare il NAT (Network Address Translation). Ma questo è un altro argomento.

Se la lettura vi ha fin qui appassionato, allora sarete stati senz’altro attenti e vi sarete accorti che abbiamo saltato uno dei quattro concetti associabili ai load balancer: le performance (si, ok, pronunciatelo come quando Virginia Raffaele imita Marina Abramović). Di questo parleremo più avanti (delle Performance, non di Marina Abramović), perché man mano che leggerete, capirete che il mondo in cui ci stiamo avventurando è molto più complesso di quello che forse pensavate all’inizio e che tre righe non bastano per parlare di Miglioramento delle Prestazioni.

Come funziona un Load Balancer?

Entriamo ora nel dettaglio e vediamo come funziona un load balancer.

Prendiamo come esempio l’architettura rappresentata in Figura 2. 

Abbiamo il sito della Gazzetta della città che risponde con il suo indirizzo pubblico sulla porta 443 (https) e bilancia il traffico su 4 server.

Vediamo quali dati servono per configurare un bilanciatore, ed entriamo nel dettaglio di queste informazioni.

• VIP
• VIP Port
• REAL IPs
• REAL Ports
• Policy di bilanciamento
• Persistence

Ce ne sono anche altri ma per ora limitiamoci a questi.

VIP è l’indirizzo pubblico con il quale viene risolto, tramite DNS, il nome del nostro sito. Facciamo conto che il sito risponda con l’ip 169.1.1.1 (impossibile, ma come esempio va bene). L’IP pubblico è attestato sul nostro LB.

VIP Port è la porta (o le porte) su cui il VIP deve ascoltare. Nel nostro esempio abbiamo scelto di farlo ascoltare sulla porta 443. Con questo dato abbiamo quindi già la coppia VIP:PORT ovvero 169.1.1.1:443

REAL IPs sono gli indirizzi IP privati dei server contenuti nell’area viola della Figura 2. Prendiamo come esempio: 10.0.0.1, 10.0.0.2, 10.0.0.3 e 10.0.0.4

REAL Ports sono le porte TCP in ascolto sui REAL IP. Facciamo conto che i real server ascoltino in https sulle porte 38443.

Policy si riferisce alla politica di bilanciamento ovvero alla logica con cui il traffico viene smistato tra i 4 server bilanciati. Le policy maggiormente utilizzate sono 2:

1. Round Robin (RR): il balancer invia la prima richiesta al primo server, la seconda richiesta al secondo server, la terza al terzo, e così via per ricominciare di nuovo il giro dalla quinta richiesta in poi. Un po’ ciascuno non fa male a nessuno 🙂
2. Least Connection: il balancer tiene traccia di ciascuna connessione attiva sui 4 server bilanciati e invia la prossima chiamata al server più scarico, ovvero con meno connessioni attive. Questa policy occupa più memoria rispetto alla modalità Round Robin.

Persistence: si riferisce alla persistenza di sessione ovvero all’eventuale necessità di mantenere la connessione tra il client e lo stesso server bilanciato per un determinato arco temporale prestabilito. Questa può essere basata su diversi fattori:

1. Ip sorgente
2. Sessione
3. SSL Session ID
4. Cookie
5. Nessuna persistenza
6. Modalità avanzate di persistenza, come per esempio persistenza su header XFF (X-Forwarded-For). Questa modalità viene solitamente utilizzata nel caso in cui davanti al nostro bilanciatore si trova un altro apparato, come per esempio un WAF (Web Application Firewall). Il WAF, in particolari configurazioni, fa un NAT di tutte le connessioni provenienti da Internet; ciò significa che se mille visitatori stanno visitando il nostro sito, tutte le connessioni arriveranno sul LB sempre con lo stesso IP, ovvero quello del WAF. In questa configurazione non avrebbe senso utilizzare una persistenza di tipo Source IP in quanto il traffico andrebbe sempre su un solo server bilanciato. 

Nel nostro esempio scegliamo l’opzione 1 ovvero persistenza su IP Sorgente, con durata di 30 minuti. Poniamo il caso che al mio primo accesso al sito, il bilanciatore mi invii al server bilanciato n.2. Dopo questa prima chiamata, fin quando continuerò a navigare con lo stesso IP, il balancer continuerà a inviarmi sul server 2 fino a 30 minuti dopo la mia ultima visita. La persistenza di sessione si rende particolarmente utile nel caso di processi di autenticazione (es. oauth) in cui è necessario recuperare dei dati in sessione dallo stesso server che ha servito la prima richiesta. E’ invece poco utile nelle aree pubbliche dei siti. Potrebbe risultare addirittura controproducente davanti a una CDN.

Vediamo in un grafico cosa succede.

La linea tratteggiata rossa rappresenta la mia richiesta.

1. Io sono un cliente su internet e richiamo il sito https://gazzettadellamiacitta.org, che viene risolto con l’IP 169.0.0.1.
2. La mia chiamata arriva al load balancer su cui è attestato l’IP pubblico.
3. Le regole di bilanciamento dicono che il traffico per quella chiamata deve essere inoltrato ai server nel riquadro viola, sulla porta 38443. Facciamo conto che mi invii al real server 2. Per i prossimi 30 minuti tutto il traffico diretto alla gazzetta dal mio pc, sarà gestito dal server 2 (persistenza di sessione). Se per 30 minuti non faccio traffico (inattività), la chiamata successiva potrebbe finire su un server diverso.

That’s all … più o meno.

Abbiamo detto tutto? No. Finora abbiamo parlato delle funzionalità base di un LB. Proviamo a passare al livello successivo.

Funzionalità avanzate di un Load Balancer

Quanto descritto finora è il comportamento base di un bilanciatore di carico, ovvero le funzionalità di livello 4 (transport layer) della pila OSI.

Con il passare del tempo i produttori di LB si sono adeguati alle esigenze applicative più disparate, aggiungendo sempre nuove funzionalità che si spingono fino al livello 7 (application layer) della pila ISO OSI.

Qual è esattamente la differenza tra L4 e L7?

I LB che lavorano a livello 4 operano al livello di transport, ovvero si occupano della consegna dei messaggi indipendentemente dal loro contenuto. I sistemi di bilanciamento del carico di livello 4 inoltrano semplicemente i pacchetti di rete da e verso i server bilanciati senza ispezionare e senza entrare nel merito del contenuto dei pacchetti stessi. Possono prendere decisioni di routing limitate ispezionando i primi pacchetti nel flusso TCP.

I LB che lavorano a livello 7 operano a livello di applicazione di alto livello, che si occupa del contenuto effettivo di ciascun messaggio. HTTP è il protocollo di livello 7 predominante per il traffico Web. I sistemi di bilanciamento di livello 7 instradano il traffico di rete in un modo molto più sofisticato rispetto ai sistemi di livello 4. Un sistema di bilanciamento del carico di livello 7 termina il traffico di rete (SSL HANDSHAKE) e legge il messaggio contenuto al suo interno. Può prendere una decisione di bilanciamento del carico in base al contenuto del messaggio (l’URL o il cookie, ad esempio). Quindi effettua una nuova connessione TCP al server upstream selezionato (o ne riutilizza uno esistente, tramite keepalive HTTP) e scrive la richiesta sul server.

Vediamo alcune delle funzionalità di livello 7 messe a disposizione da alcuni LB, partendo dal presupposto che ormai il 99,x% del traffico diretto ai siti web è in HTTPS.

1. SSL Handshake ovvero la possibilità, previo caricamento di un certificato digitale sul balancer, di gestire l’handshake SSL direttamente sul bilanciatore, anziché farlo fare ai server. Questo permette di scaricare i server bilanciati in quanto non devono più farsi carico di processare l’handshake SSL. Affinché questo sia possibile, si rende necessario il caricamento del certificatto SSL e della relativa key sul LB. E’ doveroso aggiungere, dal punto di vista della sicurezza, che anche il traffico tra il LB e i server bilanciati dovrebbe essere in HTTPS (rif. Figura 6). Ciò significa che i server dovranno comunque farsi carico di gestire il traffico SSL. Non è buona prassi (cosa invece accettata qualche anno fa) utilizzare traffico HTTP in chiaro tra LB e server bilanciati. Alcuni bilanciatori di fascia alta hanno un processore dedicato alla gestione dell’handhake SSL. Questo ovviamente fa salire il prezzo del prodotto ma ne migliora le prestazioni (Performance). 
2. Bilanciamento su base URL. Poniamo il caso, facendo riferimento alla Figura 5 che i primi 2 server eroghino i servizi di area pubblica mentre gli ultimi 2 server erogano i servizi di area privata sul path /private. Il bilanciatore con questa funzionalità, può leggere la richiesta del client e inviare il traffico solo sugli ultimi 2 server nel caso in cui il path richiesto sia https://gazzettadellamiacitta.org/private
3. URL Rewriting. Abbiamo la nostra pagina di login che risponde al path /login. Per necessità applicative la pagina deve cambiare nome e dovrà chiamarsi /accedi. Questa rewrite, che solitamente faremmo fare ai nostri apache con una regola di rewrite, possiamo farla fare al nostro bilanciatore. Questo si traduce in un notevole alleggerimento per i server bilanciati (Performance).
4. Port Rewriting. Abbiamo detto che orami tutto il traffico web è in HTTPS. Ma cosa succede se un cliente richiamasse http://gazzettadellamiacitta.org. Il balancer può leggere il pacchetto e, nel caso ci fosse una chiamata HTTP (Port 80), può fare un port rewriting (Es. HTTP 301, 302 o 307) riscrivendo la URL in https://gazzettadellamiacitta.org. Per fare ciò ovviamente il VIP del balancer deve essere in ascolto anche sulla porta 80; non è invece necessaria questa configurazione sui server bilanciati, che potranno limitarsi ad ascoltare soltanto su TCP/HTTPS/443. Altro alleggerimento per il server (Performance).
5. Caching. Così come esiste un processore dedicato per l’SSL, alcuni LB offrono processori dedicati per il caching. Vediamo un esempio pratico. I nostri server bilanciati espongono tutte le immagini nel path /images. Sul balancer si possono applicare delle regole di caching per il path in questione. Si potrebbero applicare regole di caching addirittura per estensione. Per esempio, applica una regola di caching di 180 minuti per tutti i files con estensione .jpg e di 1 anno per le estensioni .woff. Una volta cachato l’oggetto, il traffico verrà gestito direttamente dal balancer, senza più arrivare sui server. Abbiamo alleggerito ulteriormente il carico sui nostri server (ancora Performance). Per maggiori dettagli sulla gestione della cache trovate un mio articolo precedente che approfondisce la ottimizzazione cache.

In quattro dei cinque punti appena elencati abbiamo approfondito, come promesso qualche paragrafo più in alto, il concetto di Performance. Questo è il motivo per cui un buon bilanciatore è un concorrente fondamentale nelle prestazioni di un web service. Vi avevo detto che tre righe non sarebbero bastate a parlare di prestazioni e la lunga lista appena scorsa ne è il motivo.

Conclusioni

I bilanciatori sono apparati molto potenti e mettono a nostra disposizione molte altre funzionalità rispetto a quelle elencate. In questo articolo abbiamo affrontato quelle più comuni e usate, che potranno sicuramente risultarvi utili in futuro.

Per darvi un’idea di quante funzionalità di load balancing siano disponibili, vi riporto il Load Balancing Decision Tree di Google (fonti dettagliate sotto l’immagine seguente) che aiuta i clienti di Google, su GCP, a scegliere il miglior Load Balancer in base alle specifiche esigenze:

Fonti: https://cloud.google.com/load-balancing/docs/choosing-load-balancer, https://cloud.google.com/static/load-balancing/images/choose-lb.svg

Abbiamo anche capito che questi apparati ci fanno risparmiare risorse computazionali, quindi denaro, e ci aiutano nella gestione della sicurezza.

Si ma, com’è fatto un LB?

Se vi state chiedendo in che modo si palesi un LB ….. Qualora il vostro LB sia posizionato ON-PREM, molto probabilmente sarà un comune “pezzo di ferro”, simile a un PC. Se invece parliamo di bilanciatori in cloud (simili a quelli messi a disposizione da GCP ed elencati nell’immagine precedente) parleremo di un apparato virtuale, simile a una virtual machine. La sua gestione è solitamente delegata a un’interfaccia web.

Qualora vogliate approfondire, tra i principali produttori di load balancer ci sono F5 e Fortinet.

Vi lascio il link della mia newsletter qualora vogliate iscrivervi: https://www.linkedin.com/newsletters/web-in-cloud-6945274376917274624/

Cosa ne pensate dell’articolo? Mi piacerebbe avere la vostra opinione nei commenti. 

Il confronto è sempre costruttivo. 

I wish you a fun job

Fabio Iegri