novembre | 2014 | Appunti e note tecniche

LVS —- Linux Virtual Server

Un Load Balancer, per brevità anche indicato come LB, è un sistema singolo od articolato su più elementi che normalmente viene anteposto ad una batteria di server, con il compito di bilanciare il carico in ingresso bilanciando in modo opportuno le richieste da parte dei client.

E’ in sostanza un sistema che dispone di regole ed algoritmi differenti per la distribuzione del carico. Tipicamente utilizzato in ambito Wan ossia come, bilanciatore di carico in ingresso per servizi Internet, la sua adozione è utile anche in ambito lan dove può efficacemente essere utilizzato oltre che come armonizzatore di carico anche come sistema di fault tolerance.

Essendo in grado di indirizzare le richieste solo verso gli host a valle realmente attivi garantisce anche una gestione della Fault Tolerance.

Questa modalità operativa permette di scalare in modo rapido nel caso il carico aumenti, semplicemente inserendo nuovi application server e inserendoli nella disponibilità dei bilanciatori.

Chiaramente al fine di non risultare esso stesso un Single Point Of Failure il LB deve essere ridondato.

Sono molte le tipologie di prodotti che svolgono questa funzione, e molti di questi a pagamento e disponibili come veri e propri appliances HW, tuttavia in ambito Open Source, esiste il progetto Linux LVS che permette la realizzazione di un di Balancing software rilasciato su licenza Open Source.

Diverse Distribuzioni Linux implementano questa funzionalità, in questa beve guida vengono prese in considerazione le distribuzioni Redhat, Oracle Linux e Centos, in cui i metodi di installazione e configurazione sono pressoché identici.

Descrizione del Servizio

LVS può essere configurato in diverse modalità di connessione a seconda dello scenario in cui viene ad essere collocato:

NAT
Direct Routing
Tunneling

La modalità NAT è tipica di ambienti dove i Balancer agiscono da veri e propri router con due schede di rete, una connessa sulla rete dei client e un’altra sulla rete dei Server Reali, in questo caso LVS esegue un NAT del traffico, dall’esterno verso l’interno.

Tutto il traffico da per i Server Reali passa attraverso LVS stesso.

NAT Direct Routing

Direct Routing, invece è indicata quando LVS è utilizzato soltanto come bilanciatore per le richieste in entrata, e successivamente le risposte dai Server Reali verso i client avvengono direttamente (senza più interessare LVS).

Questa configurazione è utile in ambiente Lan dove i Load Balancer hanno funzione principalmente di distribuzione delle chiamate in arrivo, in questo modo LVS è sgravato di parte del lavoro, in quanto si occupa esclusivamente di indirizzare il traffico in una direzione.

Direct Routing richiede che i Server Reali e LVS siano fisicamente connessi allo stesso segmento di rete.

Per contro esiste un problema legato al protocollo ARP, in quanto entrambe i server, LVS e Reali, avranno impostato il medesimo ip (virtuale), in questo caso, non sarebbe possibile una comunicazione corretta sulla LAN.

Il funzionamento corretto, prevede che LVS risponda ad un indirizzo ip, ossia l’indirizzo virtuale del servizio (VIP) ruotando poi le richieste verso i Server Reali ma la risposta dovrà poi avvenire dal Server Reale che ha impostato lo stesso ip ma chiaramente con un MAC ADDRESS differente.

A tal fine è necessario installare il servizio arptables_jf (sul server reale) ed attivare un secondo ip identico a quello comune del Balancer.

Tramite le regole di arptables, si istruisce il server reale in modo da ignorare le richieste ARP per l’ip del Balancer e rispondere con il proprio MAC ADDRESS.

La modalità Tunneling è molto simile alla precedente, la differenza principale è nel fatto che I pacchetti sono ridiretti al Server Reale tramite un incapsulamento IP anziché per mezzo di un nuovo Frame.

Questa differenza fa sì che LVS e Server Reali possano essere posizionati su reti differenti.

Installazione:

Analizziamo ora i passi da seguire per portare a termine una installazione in modalità Direct Routing su Distribuzione Oracle Linux Enterprise, la stessa procedura può essere seguita per REDHAT piuttosto che per CENTOS.

Lo scenario che verrà implementato è quello di un sistema composto da due Bilanciatori LVS (uno è installato come backup nel caso di guasto) e due server Web application entrambi con la medesima configurazione.

Servizi di sistema:

L’intero ambiente LVS sui Bilanciatori è installabile tramite YUM, per mezzo del comando

yum groupinstall “Load Balancer”,

In questo modo verranno installati tutti i pacchetti necessari e le relative dipendenze.

Il gruppo “Load Balancer” contiene i pacchetti IPVSADM e PIRANA, nel sistema, sono aggiunti i servizi necessari al funzionamento di LVS.

Pulse: E’ i controllore di LVS e si occupa di avviare tutti i processi dipendenti (utilizzato anche per il controllo della presenza del nodo di backup del bilanciatore)
Lvs: E’ richiamato da Pulse ed è caricato nel nodo attivo, ha il compito di leggere le configurazioni nel file /etc/sysconfig/ha/lvs.cf, richiama ipvsadm ed assegna il processo nanny per ogni servizio definito in LVS, se il nanny rileva che un Server Reale è irraggiungibile, LVS istruisce ipvsadm al fine di rimuovere il server in fault dalla propria Routing table.
Ipvsadm: mantiene aggiornate la tabelle di Routing nel kernel
Nanny: Ha il compito di monitorare la raggiungibilità di ogni Server Reale e, se richiesto dalla configurazione, il suo carico.
Pirana-Gui: è il servizio che permette la gestione dell’intero sistema tramite interfaccia WEB

Sui Server reali, nel caso si utilizzi la modalità Direct Routing è necessario installare Arptables sempre tramite Yum. yum install arptables_jf

Configurazione:

Bilanciatori: (LVS server)

La configurazione può essere effettuata mediante la modifica manuale dei vari file di configurazione, ma è disponibile, come indicato sopra una consolle Web di gestione e configurazione dell’intero sistema LVS.
Pirana è il servizio Web-Based per la gestione di LVS, tramite la sua interfaccia WEB permette la gestione e configurazione del file /etc/sysconfig/ha/lvs.cf

Terminata la fase di installazione del software sia sui server Bilanciatori che sui Server Reali, è necessario fare sì che Pirana ed i servizi necessari al funzionamento di LVS vengano avviati a boot time.

chkconfig pirana-gui on
chkconfig pulse on

Successivamente è consigliabile impostare un password di accesso per l’utente del servizio piranha.

/usr/sbin/piranha-passwd

Al fine di consentire in modo corretto il Routing dei pacchetti ai Server Reali, è necessario che ogni bilanciatore abbia la funzione di Routing IP attiva a livello di Kernel. Questa funzione si ottiene modificando il file /etc/sysctl.conf ed alla riga net.ipv4.ip_forward = 0 impostare il valore ad 1

net.ipv4.ip_forward = 1

Server Reali

Come per i bilanciatori è necessario impostare in avvio automatico il servizio arptables_jf

chkconfig arptables_jf on

Successivamente impostare le regole del servizio (in modo da consentire di ignorare le richieste ARP per il loro indirizzo virtuale definito sui bilanciatori) e salvare le regole impostate in modo permanente

arptables -A IN -d <virtual_ip> -j DROP
arptables -A OUT -s <virtual_ip> -j mangle –mangle-ip-s <real_ip>
service arptables_jf save

Virtual_ip è l’indirizzo ip virtuale del(i) bilanciatori, real_ip è l’indirizzo del Server Reale

L’ultimo passo della configurazione dei Server Reali è l’impostazione dell’indirizzo ip virtuale definito sui bilanciatori.

ip addr add <virtual_ip> dev eth0

lo stesso risultato si può ottenere mediante il comando ifconfig secondo la sintassi propria del comando stesso

Nota Bene: E’ importante non assegnare direttamente l’indirizzo ip virtuale tramite i tool classici di gestione dell’ip, in quanto questo farebbe sì che l’indirizzo impostato diventi disponibile già a boot-time. Mentre è necessario che questo venga attivato al termine dell’avvio completo del sistema, quindi il comando dovrà essere definito nel file /etc/rc.d/rc.local

Configurazione dei servizi e della modalità operativa di LVS:

Terminate le fasi di installazione e configurazione di base dei sistemi, è necessario procedere con la configurazione vera e propria di LVS tramite il servizio WEB Pirana.

Per poter accedere è necessario tramite borwser aprire l’url http:// <virtual_ip>:3636

accesso al portale di configurazione, l’user name di default è pirana mentre la password è stata impostata in precedenza con il comando:/usr/sbin/piranha-passwd

definizione, in GLOBAL SETTINGS dell’ip principale di LVS, ossia l’indirizzo reale del Balancer che stiamo configurando.

in REDUNDANCY impostare l’ip del secondo balancer di backup al precedente

nella parte relativa ai VIRTUAL SERVERS, si definiscono le impostazioni del sevizio che verrà poi bilanciato verso i Server Reali. L’indirizzo ip “virtuale” ossia quello del servizio vero e proprio, viene aggiunto automaticamente a quello del bilanciatore attivo.

La configurazione richiede i seguenti parametri:

NAME:

Nome del servizio (puramente descrittivo) NON è il nome del server né del servizio

APPLICATION PORT:

La porta su cui il servizio è attivo

PROTOCOL:

Il relativo protocollo (TCP o UDP)

VIRTUAL IP E VIRTUAL IP NETWORK MASK:

Indirizzo IP e subnet relative all’IP in balancing

SORRY SERVER:

Un server a cui verranno ridirette le chiamate in caso di irraggiungibilità dei Server Reali

FIREWALL MARK:

Da utilizzare nel caso in cui venga definito un server con diversi servizi bilanciati, ad esempio nel caso si abbia un Server Reale con HTTP ed HTTPS il Firewall Mark combinato con Persistence fa sì che l’accesso alle varie pagine da parte di un client venga ruotato allo stesso server con il mantenimento dello stato

DEVICE:

Il nome della scheda di rete su cui viene attivato l’Ip virtuale, in questo caso ETH0:1, è utile qualora esistano diverse schede lan per definire quale scheda è quella da usare per questo servizio.4

RE-ENTRY TIME:

Imposta il tempo, in secondi, prima che il nodo LVS tenta di riportare un Server Reale nel pool di bilanciamento dopo un malfunzionamento

SERVICE TIMEOUT:

Definisce il tempo, in secondi, trascorso il quale un Server Reale viene considerato non funzionante e quindi rimosso dal pool di bilanciamento

QUIESCE SERVER:

Questa impostazione resetta la Least-Connection table ogni volta che un nuovo Server Reale viene aggiunto o torna operativo dopo un malfunzionamento. Questo previene il fatto che un nuovo server sia oggetto di un numero elevato di connessioni simultanee.

LOAD MONITORING TOOL:

LVS può monitorare il carico di vari Server Reali componenti il pool, tramite Rup o Ruptime, rispettivamente richiedono i servizi rstatd o rwhod attivi sui Server Reali.

SCHEDULING:

Permette di definire l’algoritmo di bilanciamento, ossia di distribuzione del carico ai Server Reali; di default è impostato Weighted least-connection, le scelte possibili sono le seguenti.

Round-Robin: le richieste son distribuite sequenzialmente senza tenere conto di capacità o carico
Weighted Round-Robin: come il precedente, ma è possibile assegnare un “peso” ad ogni server del pool. (è l’algoritmo da preferire in caso di server reali con capacità computazionali molto differenti) Viene mantenuta traccia delle connessioni attive e le nuove connessioni sono distribuite verso i server reali meno carichi. Weighted Least-Connection: associa il precedente con la possibilità di assegnare un “peso” nella configurazione dei vari server reali
Locally-Based Least-Connection: Sono distribuite più richieste ai server con meno connessioni attive relativamente alla loro destinazione IP.
Locally-Based Least-Connection With Replication Scheduling: differisce dal precedente in quanto esegue un raggruppamento di Server Reali secondo la loro destinazione IP, per ogni gruppo, poi le richeste sono inviate al server con il minor numero di connessioni. E’ un algoritmo utilizzato per gestire il bilanciamento tra cluster di cache-proxy.
Destination Hash Scheduling: simile al precendente differisce per la tipologia (statica) di tabella di destinazione
Source Hash Scheduling: basato sull’Ip di provenienza della richiesta di connessione

PERSISTENCE:

Nel caso in cui sia richiesta una connessione persistente durante le transazioni dei client è necessario impostare il periodo di secondi di inattività tale da fare si che LVS non interpreti la connessione scaduta.

PERSISTENCE NETWORK MASK:

E’ possibile impostare una subnet per un particolare tipo di connessioni con un valore di persistence differente

Il passo successivo, per il completamento della configurazione dei Virtual Server richiede di definire i Real Server, per ognuno di quali dovremo definire, NOME, IP, PORTA del Protocollo, (se identica a quella del Virtual Server creato in precedenza possiamo lasciare il valore non definito) ed il peso, da impostare in accordo con l’algoritmo scelto ed analizzato sopra.

impostazione dei singoli Real Server

la configurazione è terminata sono presenti tutti i Real Server impostati ed il loro stato operativo

Al termine è necessario, per poter effettivamente rendere il sistema ridondato, copiare i file /etc/sysconfig/ha/lvs.cf dal server LVS su cui si fatta la configurazione con Piranha, sul server di “REDUNDANCY” specificato in precedenza.

Nel caso di future modifiche alla configurazione è necessario ri-copiare il file manualmente.

Per controllare l’avvenuto avvio corretto del servizio è sufficiente verificare all’interno del file /var/log/messages, che sia presente l’output: gratuitous lvs arps finished.

Comandi utili per la verifica del funzionamento:

Ipvsadm (–help) fornisce un controllo al linea di comando preciso per l’intero sistema LVS

Output del comando ipvsadm che informa sullo stato di raggiungibilità dei due Server Reali e delle connessioni attive, inattive e del peso assegnato all’host

Service arptables_jf status riporta lo stato del servizio sui server reali

Riferimenti:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/pdf/Virtual_Server_Administration/Red_Hat_Enterprise_Linux-5-Virtual_Server_Administration-en-US.pdf
http://www.linuxvirtualserver.org/software/index.html