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.