Capitolo 1. Panoramica Load Balancer Add-On
Nota
Con Red Hat Enterprise Linux 6.6 oltre al supporto al software per il bilanciamento del carico Piranha, Red Hat rende disponibile il supporto per HAProxy e keepalived. Per informazioni su come configurare un sistema Red Hat Enterprise Linux con HAProxy e keepalived, consultare la documentazione per l'Amministrazione di Load Balancer di Red Hat Enterprise Linux 7.
Il Load Balancer Add-On è un insieme di componenti software integrati per il bilanciamento del carico IP attraverso un set di real server. Load Balancer Add-On viene eseguito su di un router LVS attivo e su un router LVS di backup. Il router LVS attivo viene utilizzato per:
- Bilanciare il carico attraverso i real server.
- Controllare l'integrità dei servizi su ogni real server.
Il router LVS di backup monitorizza il router LVS attivo, sostituendolo nel caso in cui il router LVS attivo fallisce.
Questo capitolo fornisce un sommario dei componenti e delle funzioni del Load Balancer Add-On e consiste nelle seguenti sezioni:
1.1. Una configurazione di base di Load Balancer Add-On
Figura 1.1, «Una configurazione di base di Load Balancer Add-On» mostra una configurazione semplice di Load Balancer Add-On a due livelli. Sul primo livello sono presenti un router LVS attivo e uno di backup. Ogni router LVS presenta due interfacce di rete una su Internet e una sulla rete privata, questa disposizione permette loro di regolare il traffico tra le due reti. Per questo esempio il router attivo usa un Network Address Translation o NAT per instradare il traffico da Internet ai real server del secondo livello, i quali a loro volta forniscono i servizi necessari. Per questo motivo i real server sono collegati ad un segmento di una rete privata specifica, e passano tutto il traffico pubblico da e per il router LVS attivo. Visto dall'esterno, il server può sembrare una entità unica.
Figura 1.1. Una configurazione di base di Load Balancer Add-On
Le richieste del servizio che arrivano ad un router LVS vengono indirizzate ad un indirizzo IP virtuale o VIP. Esso rappresenta un indirizzo instradabile pubblicamente che l'amministratore del sito associa con un fully-qualified domain name, come ad esempio www.example.com, e assegnato ad uno o più server virtuali. Un server virtuale è un servizio configurato per l'ascolto su un IP virtuale specifico. Consultare Sezione 4.6, «SERVER VIRTUALI» per maggiori informazioni sulla configurazione di un server virtuale usando Piranha Configuration Tool. Nota bene che un indirizzo IP migra da un router LVS ad un altro durante un failover, mantenendo così una presenza nell'indirizzo IP, conosciuto anche come Indirizzi IP floating.
È possibile eseguire l'alias degli indirizzi VIP sullo stesso dispositivo che esegue il collegamento del router LVS con internet. Per esempio, se eth0 è collegato ad internet, allora sarà possibile eseguire l'alias dei server virtuali multipli su
eth0:1. Alternativamente ogni server virtuale può essere associato con un dispositivo separato per servizio. Per esempio, il traffico HTTP può essere gestito su eth0:1, ed il traffico FTP gestito su eth0:2.
Solo un router LVS alla volta può essere attivo. Il ruolo del router attivo è quello di ridirezionare le richieste di servizio dagli indirizzi IP virtuali ai real server. Questo processo si basa su uno degli otto algoritmi per il bilanciamento del carico descritto in modo più dettagliato in Sezione 1.3, «Panoramica programmazione di Load Balancer Add-On».
Altresì, il router attivo monitorizza dinamicamente lo stato generale dei servizi specifici sui real server, attraverso semplici script send/expect. Per assistervi nella rilevazione dello stato dei servizi che richiedono dati dinamici, come ad esempio HTTPS o SSL, l'amministratore potrà anche invocare gli eseguibili esterni. Se un servizio non funziona correttamente su di un real server, il router attivo interrompe l'invio di lavori al server interessato, fino a quando non verranno ripristinate le normali funzioni.
Il router di backup esegue il ruolo di un sistema in standby 'attesa'. I router LVS scambiano periodicamente messaggi heartbeat attraverso l'interfaccia pubblica esterna primaria e, in una situazione di failover, attraverso l'interfaccia privata. Se il nodo di backup non riceve un messaggio heartbeat entro un intervallo di tempo determinato, esso inizierà un processo di failover assumendo così il ruolo di router attivo. Durante il processo di failover, il router di backup prende a carico gli indirizzi VIP serviti dal router fallito utilizzando una tecnica conosciuta come ARP spoofing — con questa tecnica il router LVS di backup si presenta come destinazione per i pacchetti IP indirizzati al nodo fallito. Quando il nodo in questione ritorna in uno stato di servizio attivo, il router di backup assume il proprio ruolo di backup.
La configurazione semplice a due livelli usata in Figura 1.1, «Una configurazione di base di Load Balancer Add-On» è la migliore per i dati non frequentemente modificati — come ad esempio le pagine web statiche — poichè un real server non esegue la sincronizzazione dei dati tra i nodi.
1.1.1. Condivisione e replica dei dati tra real server
Poichè non è presente alcun componente interno in Load Balancer Add-On per condividere i dati tra i real server, l'amministratore avrà a disposizione due opzioni di base:
- Sincronizzare i dati nel pool di real server.
- Aggiungere un terzo livello alla tipologia per l'accesso dei dati condivisi.
Verrà utilizzata la prima opzione per i server che non permettono un numero di utenti molto grande per caricare o modificare i dati sui real server. Se la configurazione permette di avere un numero esteso di utenti per la modifica dei dati, come ad esempio un sito web e-commerce, allora sarà preferita l'aggiunta di un terzo livello.
1.1.1.1. Configurazione dei Real server per la sincronizzazione dei dati
Per un amministratore può sincronizzare i dati tra i real server in diversi modi. Per esempio è possibile utilizzare gli script della shell, così facendo se un Web engineer aggiorna una pagina, la pagina stessa verrà postata simultaneamente sui real server. Altresì, l'amministratore del sistema può utilizzare programmi come
rsync per replicare i dati modificati su tutti i nodi, ad un intervallo specifico.
Tuttavia in ambienti dove gli utenti caricano spesso i file o emettono transazioni del database, questo tipo di sincronizzazione dei dati non sarà ottimale. Per una configurazione con un numero di upload molto elevato, una tipologia a tre livelli risulta essere più appropriata.
