9.3. Panoramica del programma LVS

Uno dei vantaggi nell'uso di un cluster LVS, é rappresentato dalla propria abilitá di effettuare, in modo flessibile, un bilanciamento del carico dell'IP-level su di un gruppo di server reali. Questa flessibilitá é dovuta ad una varietá di algoritmi presenti, da dove un amministratore puó effettuare la sua scelta durante la configurazione di un cluster. Il bilanciamento del carico LVS é superiore ai metodi meno flessibili come ad esempio un Round-Robin DNS, dove la natura gerarchica del DNS e il caching delle macchine client, possono portare a degli sbilanciamentidel carico. Il basso livello di filtro usato dal router LVS, ha dei vantaggi rispetto all'inoltro della richiesta del livello di applicazione, questo perché bilanciando i carichi sul livello del pacchetto di rete, ne consegue uno sforzo minimo nel calcolo permettendo cosí una maggiore scalabilitá.

Usando scheduling, il router attivo prende in considerazione l'attivitá dei server reali e, in modo facoltativo, il fattore weight assegnato da un amministratore quando effettua un routing delle richieste del servizio. L'uso di weight assegnati conferisce delle priorità arbitrarie a macchine individuali, èpossibile cosí creare un gruppo di server reali, usando diverse combinazioni hardware e software e il router attivo sará in grado cosí di effettuare un caricamento di ogni server reale in modo uniforme.

Il meccanismo di scheduling per un cluster LVS, é fornito di una collezione di patch del kernel chiamati moduli del Server IP Virtuale o IPVS. Questi moduli abilitano lo smistamento del livello di trasporto livello 4 (L4), il quale é stato creato per funzionare in modo efficiente con server multipli su di un indirizzo IP singolo.

Per seguire e direzionare in modo efficace i pacchetti ai server reali, l'IPVS crea una tabella IPVS nel kernel. Questa tabella é usata dal router LVS attivo, per dirigere le richieste da un indirizzo del server virtuale ad un gruppo di server reali per poi ritornarle dallo stesso gruppo, al server virtuale. La tabella IPVS viene costantemente aggiornata da una utility chiamata ipvsadm — aggiungendo e rimuovendo i membri del cluster in base alla loro disponibilitá.

9.3.1. Programmazione degli Algoritmi

La forma che puó assumere una tabella IPVS, dipende dell'algoritmo di scheduling che un amministratore sceglie per ogni server virtuale. Per permettere una massima flessibilitá in entrambi i tipi di servizi nei confronti dei quali l'utente puó eseguire una clasterizzazione e su come questi servizi sono programmati, Red Hat Enterprise Linux fornisce gli otto algoritmi scheduling di seguito riportati. Per istruzioni su come assegnare tali algoritmi, controllare la Sezione 12.6.1.

Programmazione Round-Robin

Tale programmazione distribuisce ogni richiesta in modo sequenziale nel gruppo dei server reali. Usando questo algoritmo, tutti i server reali sono trattati allo stesso modo senza distinzione di capacitá o di carico. Questo modello di programmazione, somiglia ad un round-robin DNS, esso peró é piú granulare, ció dipende del fatto che é basato su di un collegamento di rete e non su di un host. É da segnalare altresí che la programmazione LVS round-robin, non soffre lo squilibrio causato dalle interrogazioni DNS.

Programmazione Weighted Round-Robin

Tale programmazione distribuisce ogni richiesta in modo sequenziale nel gruppo dei server reali dando piú lavoro peró, ai server con maggiore capacitá. La capacitá é indicata da un fattore weight assegnato dall'utente, il quale fattore viene regolato da informazioni di carico dinamici. Per maggiori informazioni sull'assegnazione del weight ai server reali, controllare la Sezione 9.3.2.

Lo scheduling weighted round-robin, rappresenta la migliore scelta se ci sono differenze sostanziali in capacità nel gruppo di server reali. Comunque, se la richiesta del carico varia in modo drammatico, il server con un carico piú elevato, puó rispondere in modo maggiore a quello a lui richiesto.

Least-Connection

Distribuisce piú richieste ai server con pochi collegamenti attivi. Ció é reso possibile perché esso mantiene un controllo dei collegamenti ai server reali attraverso una tabella IPVS, il least-connection é un tipo di algoritmo dinamico di programmazione, che lo rende la scelta migliore nel caso in cui si verifica un alto grado di variazione nel carico della richiesta. É la migliore scelta per un gruppo di server reali, dove ogni nodo ha quasi la stessa capacitá. Se un gruppo di server ha capacitá diverse, la programmazione del weighted least-connection rappresenta la scelta migliore.

Weighted Least-Connection (default)

Distribuisce piú richieste ai server che presentano pochi collegamenti attivi in relazione alle loro capacitá. La capacitá viene indicata da un weight assegnato da un utente, il quale viene regolato da informazioni di carico dinamiche. L'aggiunta del weight, rende questo algoritmo ideale quando il gruppo di server reali contiene un hardware di diversa capacitá. Per maggiori informazioni sul weighting dei server reali, controllare la Sezione 9.3.2.

Programmazione della Least-Connection Locale

Distribuisce piú richieste ai server che presentano pochi collegamenti attivi in relazione alle loro destinazioni IP. Questo algoritmo é designato per un uso in un cluster di server proxy-cache. Esso dirige i pacchetti per un indirizzo IP, al server di quell'indirizzo specifico, almeno che lo stesso server, é al di sopra delle proprie capacitá e se lo stesso cluster ha un server nella propria metá del carico, in tal caso assegnerá l'indirizzo IP al server reale che avrá meno carico.

Scheduling di un Least-Connection basato sulla posizione con uno scheduling di replica

Distribuisce piú richieste ai server che presentano pochi collegamenti attivi in relazione alle loro destinazioni IP. Questo algoritmo é designato per un uso in un server del cluster proxy-cache. Esso si differisce dalla programmazione Least-Connection Locale, effettuando una corrispondenza tra l'indirizzo IP ed una sottorete di nodi del server reale. Le richieste vengono indirizzate al server della suddetta sottorete, con il numero piú basso di collegamenti. Se tutti i nodi sono al di sopra delle proprie capacitá, esso effettua una replica di un nuovo server per l'indirizzo IP specifico aggiungendo il server reale, quello che presenta il minor numero di collegamenti rispetto al gruppo di server, ad una sottorete di server reali di destinazione dell'IP. Il nodo con piú carico, viene disabilitato dal sottoinsieme del server reale, per prevenire una replica troppo elevata "over-replication".

Programmazione di una Destinazione Hash

Distribuisce le richieste al gruppo di server reali, bloccando la destinazione dell'IP in una tabella hash statica. Questo algoritmo é designato per un uso in un server del cluster proxy-cache.

Programmazione di un Hash Source

Distribuisce le richieste al gruppo di server reali, bloccando la source IP in una tabella hash statica. Questo algoritmo é designato per dei router LVS con firewall multipli.

9.3.2. Programmazione e Server Weight

L'amministratore di un cluster LVS, puó assegnare un weight ad ogni nodo nel gruppo dei server reali. Il weight, é un valore intero insito negli algoritmi di scheduling weight-aware(come ad esempio le weighted least-connection) e aiutano l'hardware di carico del router LVS con diverse capacitá, in modo piú uniforme.

I weight sono in stretto rapporto tra loro. Per esempio, se un server reale ha un weight di 1 ad un altro server ha un weight pari a 5, il server con il weight 5 avrá 5 collegamenti per ogni collegamento che l'altro server riceve. Il valore di default del weight di un server reale é di 1.

Aggiungendo il weight per variare le configurazioni dell'hardware in un gruppo di server reali, si puó agevolare il bilanciamento del carico del cluster in modo piú efficiente. Esso peró, puó causare uno squilibrio momentaneo quando un server reale viene introdotto in un gruppo di server reali ed il server virtuale é programmato per un uso del weighted least-connection. Per esempio, supponiamo che ci siano tre server in un gruppo di server reali. I server A e B sono 'pesati' a1 ed il terzo, il server C, é 'pesato' a 2. Se il server C viene interrotto per qualche ragione, i server A e B prenderanno il suo carico. Tuttavia, quando il serverC tornerà in funzione, il router LVS si accorgerá che esso non avrá alcun collegamento, direzionando cosí tutte le richieste in arrivo sul suddetto server fino a quando lo stesso non raggiungerá il livello degli altri server.

Per prevenire questo fenomeno, l'amministratore puó fare di un server virtuale un server quiesce — ogni qualvolta che un nuovo nodo del server reale torna online, la tabella least-connection viene azzerata, cosí facendo il router LVS direziona le richieste come se tutti i server reali fossero stati aggiunti al cluster.