Language:
Format:

Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Amministrazione di Load Balancer

Red Hat Enterprise Linux 6

Load Balancer Add-on per Red Hat Enterprise Linux

Edizione 6

Sommario

La creazione di un sistema Load Balancer Add-On offre soluzioni scalabili ad elavata disponibilità per servizi di produzione attraverso l'utilizzo di Linux Virtual Server (LVS) per tecniche di instradamento e bilanciamento del carico specializzate. Questo manuale affronta il processo di configurazione di sistemi ad elevate prestazioni e dei servizi con Red Hat Enterprise Linux e Load Balancer Add-On per Red Hat Enterprise Linux 6.

Introduzione

Questo documento fornisce le informazioni relative all'installazione, configurazione e gestione dei componenti di Load Balancer Add-On, il quale, quando utilizzato, rende possibile un bilanciamento del carico attraverso tecniche di instradamento specializzate in grado di distribuire il traffico ad un gruppo di server.

È rivolto a coloro che possiedono una conoscenza avanzata di Red Hat Enterprise Linux e dei concetti di cluster, storage, e server computing.

Questo documento è organizzato nel modo seguente:

Capitolo 1, Panoramica Load Balancer Add-On
Capitolo 2, Configurazione iniziale di Load Balancer Add-On
Capitolo 3, Impostazione Load Balancer Add-On
Capitolo 4, Configurazione di Load Balancer Add-On con Piranha Configuration Tool
Appendice A, Come usare il Load Balancer Add-On con High Availability Add-On

Per maggiori informazioni su Red Hat Enterprise Linux 6 consultate le seguenti risorse:

Red Hat Enterprise Linux Installation Guide — Fornisce le informazioni relative all'installazione di Red Hat Enterprise Linux 6.
Red Hat Enterprise Linux Deployment Guide — Fornisce le informazioni relative all'impiego, configurazione ed amministrazione di Red Hat Enterprise Linux 6.

Per maggiori informazioni su Load Balancer Add-On e sui prodotti relativi per Red Hat Enterprise Linux 6 consultate le seguenti risorse:

Panoramica su Red Hat Cluster Suite — Fornisce una panoramica più dettagliata su High Availability Add-On, Resilient Storage Add-On, e Load Balancer Add-On.
Configurazione e gestione di High Availability Add-On Questa guida descrive la configurazione e la gestione di High Availability Add-On (conosciuto anche come Red Hat Cluster) per Red Hat Enterprise Linux 6.
Amministrazione del Logical Volume Manager — Fornisce una descrizione del Logical Volume Manager (LVM), ed include le informazioni su come eseguire LVM in un ambiente clusterizzato.
Global File System 2: Configurazione e amministrazione — Fornisce le informazioni sull'installazione, configurazione ed amministrazione di Red Hat Resilient Storage Add-On (conosciuto anche come Red Hat Global File System 2).
DM Multipath — Fornisce le informazioni relative all'utilizzo del Device-Mapper Multipath di Red Hat Enterprise Linux 6.
Note di rilascio — Fornisce le informazioni sulla release corrente dei prodotti di Red Hat.

Questo documento ed altre documentazioni di Red Hat sono disponibili in versione HTML, PDF, e EPUB online su http://access.redhat.com/documentation/docs.

1. Commenti

Se individuate degli errori di battitura in questo manuale, o se pensate di poter contribuire al suo miglioramento, contattateci subito! Inviate i vostri suggerimenti tramite Bugzilla (http://bugzilla.redhat.com/bugzilla/) nei confronti del prodotto Red Hat Enterprise Linux 6, del componente doc-Load_Balancer_Administration e del numero di versione 6.1.

Se inviate un suggerimento per contribuire al miglioramento della guida, cercate di essere il più specifici possibile. Se avete individuato un errore, indicate il numero della sezione e alcune righe di testo in modo da agevolare la ricerca dell'errore.

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:

Sezione 1.1, «Una configurazione di base di Load Balancer Add-On»
Sezione 1.2, «Configurazione Load Balancer Add-On a tre livelli»
Sezione 1.3, «Panoramica programmazione di Load Balancer Add-On»
Sezione 1.4, «Metodi di instradamento»
Sezione 1.5, «Persistenza e Firewall Mark»
Sezione 1.6, «Load Balancer Add-On — Diagramma a blocchi»

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.

1.2. Configurazione Load Balancer Add-On a tre livelli

Figura 1.2, «Configurazione Load Balancer Add-On a tre livelli» mostra una tipologia Load Balancer Add-On a tre livelli. In questo esempio il router LVS attivo instrada le richieste da Internet al pool di real server. Ogni real server accede successivamente un sorgente di dati condivisi attraverso la rete.

Figura 1.2. Configurazione Load Balancer Add-On a tre livelli

Questa configurazione è ideale per server FTP molto occupati, dove i dati accessibili vengono conservati in un server highly available centrale, accessibili da ogni real server tramite una directory NFS esportata o una condivisione Samba. Questa tipologia è anche consigliata per siti web in grado di accedere ad un database ad elevata disponibilità centrale per le loro transazioni. In aggiunta, utilizzando una configurazione attiva-attiva con un Load Balancer Add-on, è possibile configurare un cluster high-availability, in modo da servire simultaneamente entrambi i ruoli.

Il terzo livello presente nell'esempio non deve necessariamente usare il Load Balancer Add-on, in caso di mancato utilizzo di una soluzione altamente disponibile potrebbe introdurre un punto singolo critico d'errore.

1.3. Panoramica programmazione di Load Balancer Add-On

Uno dei vantaggi dell'uso di un Load Balancer Add-On è la sua abilità di eseguire un bilanciamento del carico a livello IP molto flessibile nel pool di real server. Questa flessibilità è resa possibile a causa dell'utilizzo di una varietà di algoritmi di programmazione disponibile per un amministratore, durante la configurazione di un Load Balancer Add-On. Il bilanciamento del carico con un Load Balancer Add-On, risulta superiore rispetto ad altri metodi meno flessibili, come ad esempio Round-Robin DNS dove la natura gerarchica di DNS ed il caching delle macchine client può causare uno squilibrio del carico. Altresì, un livello basso di filtraggio implementato da un router LVS, presenta alcuni vantaggi rispetto all'inoltro delle richieste a livello dell'applicazione, poichè il bilanciamento dei carichi ad un livello del pacchetto di rete può causare livelli minimi di overhead di calcolo, rendendo disponibile una maggiore scalabilità.

Usando una programmazione (scheduling), il router attivo è in grado di considerare l'attività del server, e facoltativamente, il peso assegnato da un amministratore durante l'instradamento delle richieste di servizio. L'uso del peso fornisce una priorità arbitraria alle macchine individuali. Con l'uso di questo tipo di programmazione sarà possibile creare un gruppo di real server usando una varietà di combinazioni hardware e software, e il router attivo è in grado di assegnare in modo omogeneo il carico ad ogni real server.

Il meccanismo di programmazione per il Load Balancer Add-On viene reso disponibile tramite una raccolta di patch del kernel chiamata IP Virtual Server o IPVS. I suddetti moduli abilitano un livello di trasporto layer 4 (L4), ideato per operare con server multipli su un indirizzo IP singolo.

Per controllare e indirizzare i pacchetti sui real server in modo efficiente IPVS compila una tabella IPVS nel kernel. Questa tabella viene utilizzata dal router LVS attivo per instradare le richieste da un indirizzo del server virtuale per, e da, real server presenti nel pool. La tabella IPVS viene costantemente aggiornata dall'utilità ipvsadm — aggiungendo o rimuovendo i membri del cluster in base alla loro disponibilità.

1.3.1. Algoritmi di programmazione

La struttura di una tabella IPVS dipende dall'algoritmo di programmazione scelto dall'amministratore per un dato server virtuale. Per una flessibilità massima nei tipi di servizi desiderati e sul metodo di programmazione, Red Hat Enterprise Linux rende disponibile qui di seguito i seguenti algoritmi. Per informazioni su come assegnare gli algoritmi di programmazione consultare la Sezione 4.6.1, «Sottosezione SERVER VIRTUALE».

Programmazione Round-Robin: Distribuisce ogni richiesta in modo sequenziale a tutti i real server presenti nel pool. Usando questo algoritmo tutti i real server verranno considerati allo stesso livello senza considerare la capacità o il carico. Questo modello di programmazione somiglia molto al round-robin DNS, ma differisce da quest'ultimo perchè risulta essere più granulare in quanto si basa sul collegamento di rete e non sull'host. Questo tipo di programmazione round-robin non soffre di eventuali squilibri causati da richieste DNS in cache.
Programmazione Weighted Round-Robin: Distribuisce ogni richiesta in successione all'interno di un gruppo di real server, dando un carico di lavoro maggiore ai server con maggiore capacità. La capacità viene indicata da un fattore di peso assegnato dall'utente, e viene modificata in base alle informazioni sul carico dinamico. A tal proposito consultare Sezione 1.3.2, «Peso del server e programmazione (scheduling)» per maggiori informazioni.
La programmazione Weighted round-robin rappresenta la scelta preferita se sono presenti differenze sostanziali di capacità dei real server all'interno di un gruppo. Tuttavia se la richiesta di carico varia sensibilmente, un server con un carico di lavoro molto elevato potrebbe operare oltre ai propri limiti.
Least-Connection: Distribuisce un numero maggiore di richieste ai real server con un numero minore di collegamenti attivi. Poichè questo tipo di algoritmo controlla i collegamenti per i real server attraverso la tabella IPVS, esso è un tipo di algoritmo dinamico e rappresenta la scelta migliore se siete in presenza di una elevata variazione nelle richieste di carico. Offre il meglio di se per un gruppo di real server dove ogni nodo presenta una capacità simile. Se in presenza di un gruppo di server con diverse capacità, allora la programmazione di tipo weighted least-connection rappresenta la scelta migliore.
Weighted Least-Connections (default): Distribuisce un numero maggiore di richieste ai server con un numero minore di collegamenti attivi in base alle rispettive capacità. La capacità viene indicata da un peso assegnato dall'utente, e può essere modificata in base alle informazioni relative al carico dinamico. L'aggiunta di peso rende questo algoritmo ideale quando il gruppo di real server contiene un hardware di varia capacità. Per maggiori informazioni consultare Sezione 1.3.2, «Peso del server e programmazione (scheduling)».
Programmazione Locality-Based Least-Connection: Distribuisce un numero maggiore di richieste ai server con un numero minore di collegamenti attivi, in base ai rispettivi IP di destinazione. Questo algoritmo può essere utilizzato in un cluster di server proxy-cache. Usato per indirizzare i pacchetti di un indirizzo IP al server per l'indirizzo stesso, a meno che il server non abbia superato la sua capacità e non sia presente un server che utilizzi metà della propria capacità. In tal caso l'indirizzo IP verrà assegnato al real server con un carico minore.
Programmazione Locality-Based Least-Connection con Programmazione della replica: Distribuisce un numero maggiore di richieste ai server con un numero minore di collegamenti attivi in base ai propri IP di destinazione. Questo algoritmo viene usato anche in un cluster di server proxy-cache. Esso differisce dalla Programmazione di tipo Locality-Based Least-Connection a causa della mappatura dell'indirizzo IP di destinazione su di un sottoinsieme di nodi del real server. Le richieste vengono indirizzate ad un server presente in questo sottoinsieme con il numero più basso di collegamenti. Se tutti i nodi per l'IP di destinazione hanno superato la propria capacità, esso sarà in grado di replicare un nuovo server per l'indirizzo IP in questione, aggiungendo il real server con un numero minore di collegamenti al sottoinsieme di real server dell'IP interessato. Il nodo con più carico carico verrà rilasciato dal sottoinsieme di real server in modo da evitare un processo di riproduzione non corretto.
Programmazione Destination Hash: Distribuisce le richieste al gruppo di real server cercando l'IP sorgente in una tabella hash statica. È possibile usare questo algoritmo in un cluster di server proxy-cache.
Programmazione Source Hash: Distribuisce le richieste al gruppo di real server, cercando l'IP sorgente in una tabella hash statica. È possibile utilizzare questo algoritmo con i router LVS con firewall multipli.

1.3.2. Peso del server e programmazione (scheduling)

L'amministratore di Load Balancer Add-On è in grado di assegnare un peso ad ogni nodo nel pool di real server. Il peso è un valore intero presente in qualsiasi algoritmo di programmazione weight-aware (come ad esempio i weighted least-connections), e viene usato con il router LVS per una assegnazione omogenea delle diverse capacità ad un hardware.

I pesi sono in rapporto tra loro. Per esempio se un real server ha un peso di 1 e un altro server ha un peso di 5, il server con un peso pari a 5 otterrà 5 collegamenti per ogni connessione ricevuta dall'altro server. Il valore predefinito per un real server è 1.

Anche se l'aggiunta di peso alle varie configurazioni hardware in un pool di real server, può assistere ad un bilanciamento più efficiente del carico in un cluster, esso può causare squilibri temporanei quando un real server viene introdotto nel pool e un server virtuale è stato programmato all'uso di un tipo di collegamento weighted least-connections. Per esempio, se in presenza di tre server (A, B e C), server A e B hanno un peso pari a 1, server C invece, ha un peso 2. Se il server C viene interrotto per qualsiasi motivo, i server A e B distribuiscono in modo omogeneo il carico. Tuttavia quando il server C viene riattivato, il router LVS riconosce un numero di collegamenti pari a zero, così facendo tutte le richieste in ingresso verranno indirizzate sul server, inondandolo di richieste, fino a quando lo stesso non raggiunge un livello pari a quello di A e B.

Per impedire il verificarsi di questo fenomeno gli amministratori potranno utilizzare un server virtuale come server quiesce, il quale, quando abilitato, permette al server C nell'esempio sopra riportato di non essere rimosso dalla tabella del server virtuale. Al contrario, il peso verrà impostato su , disabilitandolo. Quando il real server C sarà nuovamente reso disponibile, esso verrà abilitato con il proprio peso originale.

1.4. Metodi di instradamento

Red Hat Enterprise Linux utilizza il Network Address Translation, o NAT routing, per il Load Balancer Add-On, e permette all'amministratore di avere molta flessibilità nell'uso dell'hardware disponibile, e durante l'integrazione di Load Balancer Add-On in una rete esistente.

1.4.1. Instradamento NAT

Figura 1.3, «Load Balancer Add-On implementato con l'instradamento NAT» mostra come Load Balancer Add-On utilizzi un instradamento NAT per spostare le richieste tra Internet e la rete privata.

Figura 1.3. Load Balancer Add-On implementato con l'instradamento NAT

In questo esempio sono presenti due NIC all'interno del router LVS attivo. Il NIC per Internet presenta un indirizzo IP reale su eth0, con un indirizzo IP floating come alias su eth0:1. Il NIC per l'interfaccia di rete privata possiede un indirizzo IP reale su eth1 ed un indirizzo IP floating come alias su eth1:1. Nell'evento di un failover, l'interfaccia virtuale che interessa internet e quella privata che interessa l'interfaccia virtuale, vengono controllate simultaneamente dal router LVS di backup. Tutti i real server presenti sulla rete privata, utilizzano l'IP floating per il router NAT come rotta predefinita per comunicare con il router LVS attivo, in modo tale da non limitare le proprie capacità di rispondere alle richieste provenienti da internet.

In questo esempio viene eseguito l'alias dell'indirizzo IP floating pubblico del router LVS e dell'indirizzo NAT floating IP privato in due NIC fisici. Mentre è possibile associare ogni indirizzo IP floating al proprio dispositivo fisico sui nodi del router LVS, non è necessario avere più di due NIC.

Utilizzando questa topologia il router LVS attivo riceve la richiesta e la direziona al server appropriato. Successivamente, il real server processa la richiesta e ritorna i pacchetti al router LVS il quale utilizza la traduzione dell'indirizzo di rete per sostituire l'indirizzo del real server nei pacchetti, con l'indirizzo VIP pubblico dei router LVS. Questo processo viene chiamato IP masquerading poichè gli indirizzi IP correnti dei real server vengono nascosti ai client richiedenti.

Utilizzando l'instradamento NAT, i real server possono essere rappresentati da ogni tipo di computer sui quali viene eseguito una verietà di sistemi operativi. Un possibile svantaggio dovuto al router LVS con implementazioni molto grandi, è quella della processazione delle richieste sia in entrata che in uscita.

1.4.2. Instradamento diretto

Un Load Balancer Add-On con un instradamento diretto rende disponibili migliori prestazioni rispetto ad altre tipologie di networking Load Balancer Add-On. L'instradamento diretto permette ai real server di processare e inoltrare i pacchetti ad un richiedente, senza passarli prima per il router LVS. Questo processo riduce i problemi di prestazione della rete, relegando il compito del router LVS alla sola processazione dei pacchetti in entrata.

Figura 1.4. Load Balancer Add-On implementato con instradamento diretto

In una configurazione Load Balancer Add-On con instradamento diretto tipica, un router LVS riceve le richieste in entrata del server attraverso un IP virtuale (VIP), ed utilizza un algoritmo di programmazione per direzionare la richiesta al real server. Il real server processa le richieste ed invia le risposte direttamente ai client, bypassando i router LVS. Questo metodo permette di avere una certa scalabilità, e quindi sarà possibile aggiungere un real server senza aver bisogno che il router LVS direzioni i pacchetti in uscita dal real server al client. Questo processo elimina potenziali vulnerabilità in presenza di carichi di rete maggiori.

1.4.2.1. Instradamento diretto e restrizioni ARP

Anche se l'uso di un instradamento diretto può apportare numerosi vantaggi in un Load Balancer Add-On sono presenti alcune limitazioni. Il problema più comune tra l'instradamento diretto e Load Balancer Add-On è rappresentato dall'Address Resolution Protocol (ARP).

In situazioni tipiche il client presente su internet invia una richiesta ad un indirizzo IP. I router di rete generalmente inviano le richieste alle proprie destinazioni, mettendo in relazione gli indirizzi IP con l'indirizzo MAC della macchina con ARP. Le richieste ARP vengono trasmesse a tutte le macchine collegate su di una rete, e la macchina con la combinazione indirizzo IP/MAC corretta riceve il pacchetto. Le associazioni IP/MAC vengono conservate in una cache ARP, la quale viene ripulita periodicamente (generalmente ogni 15 minuti), e riempita con associazioni IP/MAC.

Il problema esistente con le richieste ARP in una configurazione Load Balancer Add-On con instradamento diretto, è dovuto alla necessità di associare una richiesta del client fatta ad un indirizzo IP, con l'indirizzo MAC per la richiesta da gestire, l'indirizzo IP virtuale del sistema Load Balancer Add-On deve anch'esso essere associato ad un MAC. Tuttavia, poichè sia il router LVS che i real server possiedono lo stesso VIP, la richiesta ARP viene trasmessa a tutti i nodi associati con il VIP. Tale operazione potrebbe causare diversi problemi come ad esempio la possibilità di associare il VIP direttamente ad uno dei real server, e processare la richiesta direttamente bypassando il router LVS, annullando così lo scopo della configurazione Load Balancer Add-On.

Per risolvere questo problema le richieste in entrata dovrebbero essere sempre inviate al router LVS e non ad uno dei real server. È possibile eseguire questo processo utilizzando arptables_jf o iptables per il filtro dei pacchetti quando:

arptables_jf impedisce a ARP di associare i VIP con i real server.
Utilizzando iptables si eviterà completamente il problema dell'ARP poichè i VIP non verranno configurati sui real server.

Per maggiori informazioni sull'uso di arptables o iptables in un ambiente Balancer Add-On con instradamento diretto consultare Sezione 3.2.1, «Instradamento diretto e arptables_jf» o Sezione 3.2.2, «Instradamento diretto e iptables».

1.5. Persistenza e Firewall Mark

In alcune situazioni potrebbe essere più semplice per un client ricollegarsi ripetutamente allo stesso real server, invece di avere un algoritmo di bilanciamento del carico di Load Balancer Add-On per l'invio della richiesta al server migliore disponibile. Esempi di quanto detto includono forme web multi-screen, cookies, SSL, e collegamenti FTP. In questi casi un client potrebbe non funzionare correttamente a meno che le transazioni non vengono gestite dallo stesso server che ne mantiene il contesto. Load Balancer Add-On fornisce due diverse funzioni in grado di gestire quanto detto: persistenza e firewall mark.

1.5.1. Persistenza

Quando abilitata, la persistenza funziona come un timer. Quando un client esegue il collegamento ad un servizio, Load Balancer Add-On ricorda l'ultimo collegamento effettuato dal client stesso per un periodo di tempo specifico. Se lo stesso indirizzo IP del client si collega entro un determinato periodo, esso verrà inviato allo stesso server al quale si è precedentemente collegato — bypassando così i meccanismi di bilanciamento del carico. Se si verifica invece al di fuori del suddetto periodo, tale processo viene gestito in base alle regole in corso.

La persistenza permette all'amministratore di specificare una maschera della sottorete da applicare al test dell'indirizzo IP del client, come tool per il controllo degli indirizzi che possiedono un elevato livello di persistenza, raggruppando così i collegamenti a quella sottorete.

Il raggruppamento dei collegamenti destinati a porte diverse, può essere importante per protocolli che utilizzano più di una porta per le loro comunicazioni, come ad esempio FTP. Tuttavia la persistenza non rappresenta il metodo più efficace per affrontare il problema del raggruppamento dei collegamenti destinati a porte diverse. Per queste situazioni, è consigliato utilizzare firewall mark.

1.5.2. Firewall Mark

I firewall mark rappresentano un modo semplice ed efficiente per le porte di un gruppo, usate per un protocollo o gruppo di protocolli relativi. Per esempio, se Load Balancer Add-On viene implementato su di un sito e-commerce, i firewall mark possono essere usati per raggruppare i collegamenti HTTP sulla porta 80, e rendere i collegamenti HTTPS sicuri sulla porta 443. Assegnando lo stesso firewall mark al server virtuale per ogni protocollo, le informazioni sullo stato per ogni transazione possono essere preservate, poichè il router LVS inoltra tutte le richieste allo stesso real server dopo aver aperto un collegamento.

A causa della sua efficienza e facilità d'uso è consigliato agli amministratori di Load Balancer Add-On l'uso, quando possibile, dei firewall mark al posto della persistenza, per il raggruppamento dei collegamenti. Tuttavia è consigliato agli amministratori di aggiungere la persistenza sui server virtuali insieme ai firewall mark, in modo tale che i client siano in grado di essere ricollegati allo stesso server per un periodo di tempo adeguato.

1.6. Load Balancer Add-On — Diagramma a blocchi

I router LVS utilizzano una raccolta di programmi per il controllo dei membri e dei servizi del cluster. Figura 1.5, «Componenti di Load Balancer Add-On» mostra come questi programmi sui router LVS di backup e attivi, lavorano insieme per la gestione del cluster.

Figura 1.5. Componenti di Load Balancer Add-On

Il demone pulse viene eseguito sia sul router LVS attivo che su quello passivo. Sul router LVS di backup, pulse invia un heartbeat all'interfaccia pubblica del router attivo, in modo da assicurarsi che il router attivo funzioni correttamente. Sul router attivo, pulse avvia il demone lvs e risponde alle interrogazioni heartbeat provenienti dal router LVS di backup.

Una volta avviato, il demone lvs invoca l'utilità ipvsadm per configurare e gestire la tabella d'instradamento IPVS nel kernel, e successivamente avvia un processo nanny per ogni server virtuale configurato su ogni real server. Ogni processo nanny controlla lo stato di un servizio configurato su un real server, e indica al demone lvs se è presente un malfunzionamento del servizio su quel real server. Se tale malfunzionamento viene rilevato, il demone lvs indica a ipvsadm di rimuovere il real server in questione dalla tabella d'instradamento IPVS.

Se il router di backup non riceve alcuna risposta dal router attivo, esso inizia un processo di failover attraverso la chiamata send_arp, riassegnando tutti gli indirizzi IP virtuali agli indirizzi hardware NIC (indirizzo MAC) del nodo di backup, e inviando un comando al router attivo tramite l'interfaccia di rete privata e quella pubblica in modo da interrompere il demone lvs sul router attivo. A questo punto verrà avviato il demone lvs sul nodo di backup ed accettate tutte le richieste per i server virtuali configurati.

1.6.1. Componenti di Load Balancer Add-On

Sezione 1.6.1.1, «pulse» mostra un elenco dettagliato di ogni componente software in un router LVS.

1.6.1.1. `pulse`

Processo di controllo in grado di avviare altri demoni relativi ai router LVS. Al momento dell'avvio il demone viene avviato dallo script /etc/rc.d/init.d/pulse. Successivamente, viene letto il file di configurazione /etc/sysconfig/ha/lvs.cf. Sul router attivo, pulse avvia il demone LVS. Sul router di backup pulse determina lo stato del router attivo eseguendo un heartbeat semplice ad un intervallo configurato dall'utente. Se il router attivo non risponde dopo il suddetto intervallo, verrà inizato un processo di failover. Durante questo processo pulse presente sul router di backup, indica al demone pulse sul router attivo di interrompere tutti i servizi LVS, avviando successivamente il programma send_arp per riassegnare gli indirizzi IP floating all'indirizzo MAC del router di backup, avviando anche il demone lvs.

1.6.1.2. `lvs`

Il demone lvs viene eseguito sul router LVS attivo una volta invocato da pulse. Esso legge il file di configurazione /etc/sysconfig/ha/lvs.cf, chiama l'utilità ipvsadm per compilare e gestire la tabella di instradamento IPVS, e assegna un processo nanny per ogni servizio Load Balancer Add-On configurato. Se nanny riporta la presenza di un real server inattivo, lvs indica alla utilità ipvsadm di rimuovere il real server in questione dalla tabella di routing IPVS.

1.6.1.3. `ipvsadm`

Questo servizio aggiorna la tabella d'instradamento IPVS nel kernel. Il demone lvs imposta e gestisce Load Balancer Add-On, invocando ipvsadm in modo da aggiungere, modificare o cancellare le voci presenti nella tabella d'instradamento IPVS.

1.6.1.4. `nanny`

Il demone di controllo nanny viene eseguito sul router LVS attivo. Attraverso questo demone, il router attivo determina lo stato di ogni real server, e facoltativamente, controlla il carico di lavoro relativo. Viene eseguito un processo separato per ogni servizio definito su ogni real server.

1.6.1.5. `/etc/sysconfig/ha/lvs.cf`

Questo è il file di configurazione di Load Balancer Add-On. Direttamente o indirettamente tutti i demoni ottengono le proprie informazioni sulla configurazione da questo file.

1.6.1.6. Piranha Configuration Tool

Questo è il tool basato sul web per il monitoraggio, configurazione e gestione di Load Balancer Add-On. Esso rappresenta il tool predefinito per gestire il file di configurazione di Load Balancer Add-On /etc/sysconfig/ha/lvs.cf.

1.6.1.7. `send_arp`

Questo programma invia i broadcast ARP quando l'indirizzo IP floating cambia da un nodo ad un altro durante un failover.

Capitolo 2, Configurazione iniziale di Load Balancer Add-On riporta alcune fasi sulla configurazione post-installazione da eseguire prima di configurare Red Hat Enterprise Linux come router LVS.

Capitolo 2. Configurazione iniziale di Load Balancer Add-On

Dopo l'installazione di Red Hat Enterprise Linux sarà necessario intraprendere alcune fasi iniziali per l'impostazione del router LVS e dei real server. Questo capitolo affronta le suddette fasi in modo dettagliato.

Nota

Il nodo del router LVS che diventa attivo dopo l'avvio del Load Balancer Add-On, viene chiamato nodo primario. Durante la configurazione di Load Balancer Add-On, usare Piranha Configuration Tool sul nodo primario.

2.1. Configurazione dei servizi sul router LVS

Il programma d'installazione di Red Hat Enterprise Linux installa tutti i componenti necessari per l'impostazione di Load Balancer Add-On, tuttavia sarà necessario attivare tutti i servizi appropriati prima della sua configurazione. Per il router LVS, impostare i servizi appropriati per un loro avvio durante il processo d'avvio. Per fare questo sono disponibili tre strumenti principali con Red Hat Enterprise Linux: chkconfig, ntsysv un programma basato su ncurses e Services Configuration Tool. Per utilizzare i suddetti strumenti è necessario essere un utente root.

Nota

Per ottenere un accesso root aprire un promt della shell e usare il comando su - seguito dalla password root. Per esempio:

$ su - root password

Sul router LVS sono presenti tre servizi da attivare al momento dell'avvio:

Il servizio piranha-gui (solo nodo primario)
Il servizio pulse
Il servizio sshd

Se state eseguendo il clustering di servizi con porte multiple o se state utilizzando dei firewall mark, sarà necessario abilitare il servizio iptables.

È consigliato impostare i servizi su attiva sui runlevel 3 e 5. Per fare questo usando chkconfig, digitare il seguente comando per ogni servizio:

/sbin/chkconfig --level 35 daemon on

Nel comando sopra riportato sostituire daemon con il nome del servizio che state attivando. Per un elenco dei servizi presenti sul sistema, e dei runlevel sui quali sono stati impostati come attiva, usare il comando:

/sbin/chkconfig --list

Avvertimento

L'attivazione di qualsiasi servizio usando chkconfig, non risulterà in un avvio del demone. Per fare questo usare /sbin/service. Consultare Sezione 2.3, «Avvio servizio Piranha Configuration Tool» per un esempio su come usare /sbin/service.

Per maggiori informazioni sulla configurazione dei servizi e sui runlevel con ntsysv e Services Configuration Tool, consultare il capitolo "Controllo accesso ai servizi" nella Red Hat Enterprise Linux System Administration Guide.

2.2. Impostazione di una password per Piranha Configuration Tool

Prima di utilizzare per la prima volta il Piranha Configuration Tool sul router LVS primario, è necessario limitare il suo accesso attraverso la creazione di una password. Per fare questo eseguite il login come utente root ed emettete il seguente comando:

/usr/sbin/piranha-passwd

Dopo aver inserito il comando create una password amministrativa quando richiesto.

Avvertimento

Per rendere una password più sicura non usare nomi comuni, acronimi usati frequentemente o parole presenti in qualsiasi dizionario. È vivamente sconsigliato lasciare la password non cifrata sul sistema.

Se si modifica la password durante una sessione attiva di Piranha Configuration Tool, l'amministratore dovrà fornire una nuova password.

2.3. Avvio servizio Piranha Configuration Tool

Dopo aver impostato la password per Piranha Configuration Tool, avviare o riavviare il servizio piranha-gui in /etc/rc.d/init.d/piranha-gui. Per fare questo eseguire come utente root il seguente comando:

/sbin/service piranha-gui start

/sbin/service piranha-gui restart

L'uso di questo comando avvierà una sessione privata di Apache HTTP Server utilizzando il link simbolico /usr/sbin/piranha_gui -> /usr/sbin/httpd. Per ragioni di sicurezza la versione del piranha-gui di httpd viene eseguita come utente piranha in un processo separato. Il modo di utilizzo da parte del piranha-gui del servizio httpd implica:

Apache HTTP Server deve essere installato sul sistema.
L'arresto o il riavvio di Apache HTTP Server tramite service arresterà il servizio piranha-gui.

Avvertimento

Se utilizzate il comando /sbin/service httpd stop o /sbin/service httpd restart su un router LVS, sarà necessario avviare il servizio piranha-gui con il seguente comando:

/sbin/service piranha-gui start

Il solo servizio piranha-gui è necessario per poter iniziare la configurazione del Load Balancer Add-On. Tuttavia se state configurando Load Balancer Add-On in modo remoto allora sarà necessario anche il servizio sshd. Così facendo non sarà necessario avviare il servizio pulse fino a quando non completerete la configurazione tramite il Piranha Configuration Tool. Consultate la Sezione 4.8, «Avvio di Load Balancer Add-On» per maggiori informazioni sul servizio pulse.

2.3.1. Configurazione porta del web server Piranha Configuration Tool

Il Piranha Configuration Tool viene eseguito per default sulla porta 3636. Per modificare il numero di questa porta, cambiate la riga Listen 3636 nella Sezione 2 del file di configurazione del piranha-gui web server, /etc/sysconfig/ha/conf/httpd.conf.

Per poter utilizzare il Piranha Configuration Tool avrete bisogno di almeno un web browser di solo testo. Se avviate un web browser sul router LVS primario, aprire http://localhost:3636. È possibile raggiungere il Piranha Configuration Tool da qualsiasi posizione tramite il web browser, semplicemente sostituendo localhost con l'hostname o l'indirizzo IP del router LVS primario.

Quando il browser si collega al Piranha Configuration Tool sarà necessario registrarsi per poter accedere ai servizi di configurazione. Inserite piranha nel campo Nome utente insieme alla password, usando piranha-passwd, nel campo Password.

Ora che il Piranha Configuration Tool è in esecuzione sarà possibile limitare l'accesso al tool attraverso la rete. La sezione seguente affronta i diversi modi attraverso i quali è possibile eseguire questo compito.

2.4. Limitare l'accesso a Piranha Configuration Tool

Il Piranha Configuration Tool ha bisogno di una combinazione valida di nome utente e password. Tuttavia, tutti i dati inviati al Piranha Configuration Tool sono in testo semplice, e per questo motivo è consigliato limitare l'accesso solo alle reti fidate o alla macchina locale.

Il modo più semplice per limitare l'accesso è quello di utilizzare i meccanismi interni di controllo dell'accesso di Apache HTTP Server, attraverso la modifica di /etc/sysconfig/ha/web/secure/.htaccess. Dopo aver alterato il file non sarà necessario riavviare il servizio piranha-gui, poichè il server controlla il file .htaccess ogni qualvolta accede alla directory.

Per impostazione predefinita i controlli per l'accesso a questa directory permettono a qualsiasi utente di visualizzare i contenuti presenti. Di seguito viene riportato l'accesso predefinito:

Order deny,allow
Allow from all

Per limitare l'accesso al Piranha Configuration Tool al solo localhost, modificate il file .htaccess in modo da permettere l'accesso solo dal dispositivo loopback (127.0.0.1). Per maggiori informazioni sul dispositivo loopback consultate il capitolo Script di rete nella Red Hat Enterprise Linux Reference Guide.

Order deny,allow
Deny from all
Allow from 127.0.0.1

Come riportato in questo esempio è possibile abilitare anche host specifici o sottoreti:

Order deny,allow
Deny from all
Allow from 192.168.1.100
Allow from 172.16.57

In questo esempio solo i web browser della macchina con un indirizzo IP 192.168.1.100, e macchine presenti sulla rete 172.16.57/24, saranno in grado di accedere al Piranha Configuration Tool.

Avvertimento

La modifica del file di Piranha Configuration Tool, .htaccess, limiterà l'accesso alle pagine di configurazione nella directory /etc/sysconfig/ha/web/secure/, ma non alle pagine di login e d'aiuto in /etc/sysconfig/ha/web/. Per limitare l'accesso alla suddetta directory, create un file .htaccess nella directory /etc/sysconfig/ha/web/ con le righe order, allow, e deny in modo identico a /etc/sysconfig/ha/web/secure/.htaccess.

2.5. Abilitare l'inoltro dei pacchetti

Per permettere al router LVS di inoltrare i pacchetti di rete in modo corretto ai real server, sarà necessario aver abilitato sul nodo del router LVS nel kernel l'IP forwarding. Registratevi come utente root e modificate la riga net.ipv4.ip_forward = 0 in /etc/sysctl.conf nel modo seguente:

net.ipv4.ip_forward = 1

Le modifiche verranno implementate durante il successivo riavvio del sistema.

Per controllare se l'IP forwarding è stato abilitato, emettete il seguente comando come utente root:

/sbin/sysctl net.ipv4.ip_forward

Se il comando ritorna 1, l'IP forwarding è stato abilitato. Se invece il valore è 0, allora sarà possibile abilitarlo usando il seguente comando:

/sbin/sysctl -w net.ipv4.ip_forward=1

2.6. Configurazione dei servizi sui Real Server

Se i real server sono sistemi Red Hat Enterprise Linux, impostate i demoni del server appropriati in modo da attivarsi al momento dell'avvio. I suddetti demoni possono includere httpd per servizi web o xinetd per servizi Telnet o FTP.

Potrebbe essere necessario accedere i real server in modo remoto, e per questo motivo è consigliato installare ed eseguire il demone sshd.

Capitolo 3. Impostazione Load Balancer Add-On

Load Balancer Add-On consiste in due gruppi di base: i router LVS ed i real server. Per evitare il verificarsi di un single point of failure, ogni gruppo dove avere un minimo di due membri.

Il gruppo del router LVS deve essere composto di due sistemi identici o molto simili sui quali viene eseguito Red Hat Enterprise Linux. Uno come router LVS attivo e l'altro in modalità di hot standby, quindi entrambi dovranno avere una capacità quanto più simile possibile.

Prima di selezionare e configurare l'hardware per il gruppo di real server è necessario determinare quale tipologia di Load Balancer Add-On usare.

3.1. Il NAT Load Balancer Add-On Network

La tipologia NAT permette di utilizzare l'hardware esistente in diversi modi, ma è limitata nella propria abilità di gestire carichi molto grandi a causa del passaggio di tutti i pacchetti, sia in entrata che in uscita, attraverso il router Load Balancer Add-On.

Disposizione di rete: Da una prospettiva della struttura di rete, la tipologia per il Load Balancer Add-On che utilizza un instradamento NAT risulta essere quella più semplice da configurare, poichè è necessario solo un punto d'accesso alla rete pubblica. I real server ritornano tutte le richieste attraverso il router LVS in modo che le stesse risultano essere nella propria rete privata.
Hardware: La tipologia NAT è la più flessibile in relazione all'hardware, poichè i real server non devono essere macchine Linux per poter funzionare correttamente. In una tipologia NAT ogni real server avrà bisogno di un solo NIC poichè esso risponderà solo al router LVS. I router LVS invece, avranno bisogno ciascuno di due NIC per instradare il traffico tra le due reti. Poichè questa tipologia crea una limitazione nei confronti del router LVS, è possibile impiegare i NIC gigabit Ethernet su ogni router LVS per migliorare la larghezza di banda che un router LVS è in grado di gestire. Se il gigabit Ethernet viene implementato sui router LVS, qualsiasi interruttore che collega i real server ai router LVS deve avere un minimo di due porte gigabit Ethernet per gestire in modo efficiente il carico.
Software: Poichè la tipologia NAT richiede l'utilizzo di iptables per alcune configurazioni, potrebbe esser necessario eseguire una ulteriore configurazione esterna al Piranha Configuration Tool. In particolare, i servizi FTP e l'utilizzo dei firewall mark richiedono una configurazione manuale supplementare dei router LVS, per instradare in modo correto tutte le richieste.

3.1.1. Configurazione delle interfacce di rete per il Load Balancer Add-On con NAT

Per impostare il Load Balancer Add-On con il NAT è necessario configurare sui router LVS le interfacce di rete per la rete pubblica e per la rete privata. In questo esempio le interfacce pubbliche del router LVS (eth0) saranno sulla rete 192.168.26/24 (questo non è un IP instradabile, ma pretendiamo che ci sia un firewall di fronte al router LVS), e le interfacce private che collegano ai real server (eth1) saranno sulla rete 10.11.12/24.

Importante

Da notare che la modifica dei seguenti file relativi al servizio network ed il Load Balancer Add-on, non è compatibile con il servizio NetworkManager.

Quindi sul nodo del router LVS primario o attivo, lo script di rete dell'interfaccia pubblica, /etc/sysconfig/network-scripts/ifcfg-eth0, potrebbe somigliare al seguente:

DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.26.9
NETMASK=255.255.255.0
GATEWAY=192.168.26.254

/etc/sysconfig/network-scripts/ifcfg-eth1 per l'interfaccia NAT privata sul router LVS potrebbe somigliare al seguente:

DEVICE=eth1
BOOTPROTO=static
ONBOOT=yes
IPADDR=10.11.12.9
NETMASK=255.255.255.0

In questo esempio il VIP per l'interfaccia pubblica del router LVS sarà 192.168.26.10, ed il VIP per NAT o interfaccia privata sarà 10.11.12.10. Sarà quindi necessario che i real server inoltrino le richieste al VIP per l'interfaccia NAT.

Importante

Gli esempi delle impostazioni per la configurazione dell'interfaccia Ethernet in questa sezione, si riferiscono agli indirizzi IP reali di un router LVS e non agli indirizzi IP floating. Per configurare gli indirizzi IP floating privato e pubblico, l'amministratore dovrà utilizzare Piranha Configuration Tool come mostrato in Sezione 4.4, «IMPOSTAZIONI GLOBALI» e Sezione 4.6.1, «Sottosezione SERVER VIRTUALE».

Dopo aver configurato le interfacce di rete per il nodo del router LVS primario, configurate le interfacce della rete reale del router LVS di backup — facendo particolare attenzione che nessun indirizzo IP sia in conflitto con gli indirizzi IP presenti sulla rete.

Importante

Assicuratevi che ogni interfaccia sul nodo di backup serva la stessa rete dell'interfaccia presente sul nodo primario. Per esempio se eth0 si collega alla rete pubblica sul nodo primario, la stessa deve collegarsi anche alla rete pubblica sul nodo di backup.

3.1.2. Instradamento sui real server

La cosa più importante da ricordare durante la configurazione delle interfacce di rete dei real server in una tipologia NAT, è quella d'impostare il gateway per l'indirizzo IP floating NAT del router LVS. In questo esempio, l'indirizzo in questione sarà 10.11.12.10.

Nota

Una volta impostate le interfacce di rete sui real server le macchine non saranno in grado di eseguire il ping, o di stabilire un collegamento con la rete pubblica. Ciò è normale. Tuttavia sarete in grado di eseguire il ping dell'IP reale per l'interfaccia privata del router LVS, in questo caso 10.11.12.9.

Quindi il file /etc/sysconfig/network-scripts/ifcfg-eth0 del real server somiglierà al seguente:

DEVICE=eth0
ONBOOT=yes
BOOTPROTO=static
IPADDR=10.11.12.1
NETMASK=255.255.255.0
GATEWAY=10.11.12.10

Avvertimento

Se un real server possiede più di una interfaccia di rete configurata con la riga GATEWAY=, la prima interfaccia usata otterrà il gateway. Per questo motivo se eth0 e eth1 sono configurate, e eth1 viene utilizzata per il Load Balancer Add-On, i real server potrebbero non indirizzare le richieste in modo corretto.

È fortemente consigliato disabilitare le interfacce di rete estranee tramite l'impostazione di ONBOOT=no, negli script di rete interessati all'interno della directory /etc/sysconfig/network-scripts/, oppure assicuratevi che il gateway sia stato impostato correttamente nella prima interfaccia usata.

3.1.3. Come abilitare l'instradamento NAT sui router LVS

In una configurazione NAT Load Balancer Add-On semplice dove ogni servizio clusterizzato utilizza solo una porta, come ad esempio HTTP sulla porta 80, l'amministratore può abilitare solo il packet forwarding sui router LVS per instradare correttamente le richieste tra il mondo esterno ed i real server. Consultate la Sezione 2.5, «Abilitare l'inoltro dei pacchetti» per informazioni su come abilitare il packet forwarding. Tuttavia sarà necessario una ulteriore configurazione quando i servizi clusterizzati richiedono più di una porta per andare dallo stesso real server durante una sessione dell'utente. Per informazioni sulla creazione di servizi multi-port utlizzando i firewall mark, consultate la Sezione 3.4, «Servizi multi-port e Load Balancer Add-On».

Una volta abilitato il forwarding sui router LVS ed impostato i real server sui quali vengono eseguiti i servizi clusterizzati, utilizzate Piranha Configuration Tool per configurare Load Balancer Add-On come mostrato nel Capitolo 4, Configurazione di Load Balancer Add-On con Piranha Configuration Tool.

Avvertimento

Non configurate l'IP floating per eth0:1 o eth1:1 modificando manualmente gli script di rete, o utilizzando un tool di configurazione di rete. Al contrario utilizzate Piranha Configuration Tool come mostrato in Sezione 4.4, «IMPOSTAZIONI GLOBALI» e Sezione 4.6.1, «Sottosezione SERVER VIRTUALE».

Una volta terminato avviate il servizio pulse come riportato in Sezione 4.8, «Avvio di Load Balancer Add-On». Quando pulse è in esecuzione il router LVS attivo inizierà ad instradare le richieste al gruppo di real server.

3.2. Load Balancer Add-On tramite instradamento diretto

Come mostrato in Sezione 1.4.2, «Instradamento diretto», l'instradamento diretto permette ai real server di processare e direzionare i pacchetti direttamente all'utente richiedente invece di passare i pacchetti in uscita attraverso il router LVS. L'instradamento diretto ha bisogno di una connessione fisica dei real server ad un segmento di rete con il router LVS, i quali a loro volta sono in grado di processare e direzionare i pacchetti in uscita.

Disposizione di rete: In una impostazione Load Balancer Add-On dell'instradamento diretto, il router LVS avrà bisogno di ricevere le richieste in entrata e direzionarle al real server corretto per una loro processazione. I real server a loro volta dovranno instradare direttamente le risposte al client. Ciò significa che se il client è su internet ed invia il pacchetto ad un real server attraverso il router LVS, il real server dovrà essere in grado di contattare direttamente il client attraverso internet. È possibile eseguire tale processo attraverso la configurazione del gateway per il real server, in modo da passare i pacchetti ad internet. Ogni real server nel pool dei server, può avere un proprio gateway separato (e ogni gateway può avere un proprio collegamento ad internet), permettendo di avere una portata e scalabilità massima. Tuttavia per impostazioni Load Balancer Add-On tipiche i real server possono comunicare attraverso un gateway (e quindi un collegamento di rete).
Importante
Non è consigliato utilizzare il router LVS come gateway per i real server, poichè sarà possibile creare una impostazione più complessa e non necessaria insieme ad un carico di rete sul router LVS, questa impostazione causerà alcune limitazioni nell'instradamento NAT.
Hardware: I requisiti hardware di un sistema Load Balancer Add-On che utilizza un instradamento diretto sono simili ad altre tipologie Load Balancer Add-On. Mentre il router LVS ha bisogno di eseguire Red Hat Enterprise Linux per processare le richieste in entrata ed eseguire il bilanciamento del carico per i real server, i real server non hanno bisogno di essere machine Linux per funzionare correttamente. I router LVS necessitano ciascuno di uno o due NIC (se è presente un router di backup). Potrete utilizzare due NIC per facilitare la configurazione e per separare in modo netto il traffico — le richieste in ingresso vengono gestite da un solo NIC, ed i pacchetti indirizzati ai real server gestiti dal secondo.
Poichè i real server bypassano il router LVS ed inviano i pacchetti in uscita direttamente ad un client, sarà necessario implementare un gateway per Internet. Per una disponibilità e prestazione massima, ogni real server può essere collegato alla rete portante alla quale il client è collegato (come ad esempio Internet o intranet).
Software: Da eseguire una ulteriore configurazione esterna al Piranha Configuration Tool in modo paricolare per amministratori che affrontano problematiche ARP durante l'utilizzo del Load Balancer Add-On tramite un instradamento diretto. Consultate la Sezione 3.2.1, «Instradamento diretto e arptables_jf» o Sezione 3.2.2, «Instradamento diretto e iptables» per maggiori informazioni.

3.2.1. Instradamento diretto e `arptables_jf`

Per poter configurare l'instradamento diretto utilizzando arptables_jf è necessario aver configurato su ogni real server un indirizzo IP virtuale in modo da instradare direttamete i pacchetti. Le richieste ARP per il VIP vengono ignorate dai real server, e qualsiasi pacchetto ARP che potrebbe essere inviato con al suo interno un VIP, viene modificato in modo da contenere l'IP del real server.

Utilizzando il metodo arptables_jf le applicazioni potrebbero associarsi ad ogni VIP o porta individuali serviti dal real server. Per esempio, il metodo arptables_jf permette a istanze multiple di Apache HTTP Server di essere eseguite esplicitamente su VIP diversi del sistema. L'utilizzo di arptables_jf comporta vantaggi significativi in termini di prestazione rispetto all'opzione iptables.

Tuttavia utilizzando il metodo arptables_jf i VIP non potranno essere configurati per avviarsi al boot utilizzando gli strumenti di configurazione del sistema di Red Hat Enterprise Linux.

Per configurare ogni real server in modo da ignorare le richieste ARP per ogni indirizzo IP virtuale, seguite le fasi di seguito riportate:

Create le voci della tabella ARP per ogni indirizzo IP virtuale su ogni real server (il real_ip è l'IP usato dal director per comunicare con il real server; spesso è l'IP assegnato all'eth0):
```
arptables -A IN -d <virtual_ip> -j DROP
arptables -A OUT -s <virtual_ip> -j mangle --mangle-ip-s <real_ip>
```
Ciò permetterà ai real server di ignorare tutte le richieste ARP per gli indirizzi IP virtuali, modificando qualsiasi risposta ARP in uscita che potrebbe contenere l'IP virtuale se non modificata, contenendo invece l'IP reale del server. L'unico nodo che dovrebbe rispondere alle richieste ARP per qualsiasi VIP, risulta essere il nodo LVS attivo.
Una volta completato questo processo su ogni real server, salvate le voci per la tabella ARP digitando i seguenti comandi su ogni real server:
service arptables_jf save
chkconfig --level 2345 arptables_jf on
Il comando chkconfig causerà il ricaricamento della configurazione di arptables al momento dell'avvio da parte del sistema — prima dell'avvio della rete.
Configurate l'indirizzo IP virtuale su tutti i real server utilizzando ifconfig per creare un alias IP. Per esempio:
```
# ifconfig eth0:1 192.168.76.24 netmask 255.255.252.0 broadcast 192.168.79.255 up
```
Oppure utilizzando l'utilità iproute2, ip, per esempio:
```
# ip addr add 192.168.76.24 dev eth0
```
Come precedentemente riportato, gli indirizzi IP virtuali non possono essere configurati in modo da aviarsi al boot utilizzando i tool di configurazione del sistema di Red Hat. Una soluzione a questo problema potrebbe essere quella di posizionare i suddetti comandi in /etc/rc.d/rc.local.
Configurate Piranha per l'instradamento diretto. Per maggiori informazioni consultate il Capitolo 4, Configurazione di Load Balancer Add-On con Piranha Configuration Tool.

3.2.2. Instradamento diretto e `iptables`

È possibile risolvere il problema riguardante ARP durante l'utilizzo del metodo d'instradamento diretto tramite la creazione di regole del firewall iptables. Per configurare l'instradamento diretto utilizzando iptables è necessario utilizzare regole in grado di creare un proxy trasparente, e che permettono quindi ad un real server di servire i pacchetti inviati all'indirizzo VIP, anche se l'indirizzo VIP non è presente sul sistema.

Il metodo iptables è più semplice da configurare rispetto al metodo arptables_jf. Questo metodo è in grado di evitare interamente il verificarsi delle problematiche LVS ARP poichè gli indirizzi IP virtuali esistono solo sul director LVS attivo.

Tuttavia sono presenti alcune problematiche relative alla prestazione se si utilizza il metodo iptables rispetto a arptables_jf. Tali problematiche sono dovute ad un overhead durante l'inoltro/mascheramento di ogni pacchetto.

Non sarà possibile altresì riutilizzare le porte con il metodo arptables_jf. Per esempio, non è possibile eseguire due servizi Apache HTTP Server separati ma assegnati alla porta 80, poichè entrambi devono essere associati a INADDR_ANY e non agli indirizzi IP virtuali.

Per configurare l'instradamento diretto utilizzando il metodo iptables seguite le fasi di seguito riportate:

Su ogni real server eseguite il seguente comando per ogni combinazione di protocollo (TCP o UDP), VIP, e porta da servire:
iptables -t nat -A PREROUTING -p <tcp|udp> -d <vip> --dport <port> -j REDIRECT
Questo comando causerà la processazione, da parte dei real server, dei pacchetti destinati al VIP e alla porta a loro conferiti.
Salvate la configurazione su ogni real server:
```
# service iptables save
# chkconfig --level 2345 iptables on
```
I comandi sopra riportati causano il ricaricamento della configurazione di iptables al momento dell'avvio — prima dell'avvio della rete.

3.3. Come eseguire la configurazione

Dopo aver determinato quale metodo implementare, sarà necessario collegare l'hardware sulla rete.

Importante

I dispositivi dell'adattatore sui router LVS devono essere configurati in modo da accedere alle stesse reti. Per esempio se eth0 si collega alla rete pubblica, e eth1 si collega a quella privata, allora gli stessi dispositivi sul router LVS di backup dovranno collegarsi alle stesse reti.

Il gateway presente nella prima interfaccia visualizzata al momento dell'avvio viene aggiunto alla tabella d'instradamento, mentre i gateway seguenti presenti su altre interfacce vengono ignorati. Considerate tale comportamento durante la configurazione dei real server.

Dopo aver collegato fisicamente l'hardware configurate le interfacce di rete sui router LVS di backup e primari. È possibile eseguire questa operazione usando un'applicazione grafica come system-config-network, oppure modificando manualmente gli script di rete. Per maggiori informazioni su come aggiungere i dispositivi utilizzando system-config-network, consultare il capitolo Configurazione di rete nella Red Hat Enterprise Linux Deployment Guide. Per il rimando di questo capitolo, gli esempi di alterazioni delle interfacce di rete vengono eseguiti manualmente o attraverso il Piranha Configuration Tool.

3.3.1. Suggerimenti generali per il Networking del Load Balancer Add-On

Configurate gli indirizzi IP reali per la rete pubblica e privata sui router LVS prima di configurare Load Balancer Add-On utilizzando Piranha Configuration Tool. Le sezioni su ogni tipologia presentano degli esempi di indirizzi di rete, utilizzate indirizzi di rete validi. Di seguito sono riportati alcuni comandi molto utili per l'attivazione delle interfacce di rete o per il controllo dello stato.

Attivazione delle interfacce di rete reali: Per attivare una interfaccia di rete reale utilizzate il seguente comando come utente root, sostituendo N con il numero corrispondente dell'interfaccia (eth0 e eth1).
/sbin/ifup ethN
Avvertimento
Non usate gli script ifup per attivare gli indirizzi IP floating configurati con Piranha Configuration Tool (eth0:1 o eth1:1). Utilizzate il comando service per avviare pulse (consultare Sezione 4.8, «Avvio di Load Balancer Add-On» per maggiori informazioni).
Disattivazione delle interfacce di rete reali: Per disattivare una interfaccia di rete reale utilizzate il seguente comando come utente root, sostituendo N con il numero corrispondente all'interfaccia (eth0 and eth1).
/sbin/ifdown ethN
Controllo dello stato delle interfacce di rete: Se desiderate controllare quale interfaccia è attiva in un determinato momento, digitate quanto segue:
/sbin/ifconfig
Per visualizzare la tabella d'instradamento per una macchina usare il seguente comando:
/sbin/route

3.3.1.1. Risoluzione problematiche dell'indirizzo IP virtuale

Un amministratore può incontrare alcuni scenari nei quali si verifica un failover automatico da un host LVS attivo ad un host standby. Tutti gli indirizzi IP virtuali potrebbero non attivarsi sull'host standby previo failover. Questo comportamento si può verificare anche durante l'arresto dell'host standby e all'avvio di quello primario. Tutti gli indirizzi IP virtuali verranno attivati solo al riavvio manuale del servizio pulse.

Per risolvere momentaneamente questo problema eseguire il comando nel prompt della shell root:


echo 1 > /proc/sys/net/ipv4/conf/all/promote_secondaries

Ricordate che questa soluzione è provvisoria e non verrà implementata dopo il riavvio del sistema.

Per una risoluzione permanente aprite il file /etc/sysctl.conf e aggiungere la seguente riga:

net.ipv4.conf.all.promote_secondaries = 1

3.4. Servizi multi-port e Load Balancer Add-On

Durante la creazione dei servizi Load Balancer Add-On multi-port i router LVS avranno bisogno, con qualsiasi tipologia, di una configurazione aggiuntiva. I servizi multi-port possono essere creati artificialmente tramite i firewall mark per unire tra loro protocolli diversi ma correlati, come ad esempio HTTP (porta 80) e HTTPS (porta 443), o quando si utilizza Load Balancer Add-On con protocolli multi-port veri e propri, come ad esempio FTP. In entrambi i casi il router LVS utilizza i firewall mark per sapere che i pacchetti destinati a porte diverse, mantenendo lo stesso firewall mark, devono essere gestiti in modo identico. Altresì, quando combinati con la persistenza, i firewall mark assicurano l'instradamento dei collegamenti della macchina client allo stesso host, fino a quando i collegamenti si verificano all'interno di un periodo specificato dal parametro della persistenza. Per maggiori informazioni su come assegnare persistenza ad un virtual server, consultate la Sezione 4.6.1, «Sottosezione SERVER VIRTUALE».

Sfortunatamente il meccanismo usato per bilanciare il carico sui real server — IPVS — è in grado di riconoscere i firewall mark assegnati ad un pacchetto, ma non di assegnarli. Il compito di assegnare i firewall mark deve essere espletato dal filtro del pacchetto di rete, iptables, esternamente al Piranha Configuration Tool.

3.4.1. Assegnazione dei firewall mark

Per assegnare i firewall mark ad un pacchetto destinato ad una porta particolare l'amministratore dovrà utilizzare iptables.

Questa sezione mostra come unire HTTP e HTTPS, tuttavia FTP rappresenta un altro protocollo multi-port clusterizzato molto comune. Se un Load Balancer Add-On viene utilizzato per i servizi FTP, consultate la Sezione 3.5, «Configurazione di FTP» per informazioni su come eseguire la configurazione.

La regola di base da ricordare quando si utilizzano i firewall mark è quella che per ogni protocollo che utilizza un firewall mark con il Piranha Configuration Tool, è necessaria la presenza di una regola iptables equivalente per assegnare i firewall mark ai pacchetti di rete.

Prima di creare le regole per il filtro dei pacchetti di rete, assicuratevi che non siano presenti altre regole. Per fare questo aprite un prompt della shell, registratevi come utente root e digitate:

/sbin/service iptables status

Se iptables non è in esecuzione, il prompt apparirà istantaneamente.

Se iptables è attivo, esso visualizzerà un set di regole. Se sono presenti alcune regole, digitate il seguente comando:

/sbin/service iptables stop

Se le regole già presenti sono regole importanti, controllate il contenuto di /etc/sysconfig/iptables e copiate qualsiasi regola importante in un luogo sicuro prima di procedere.

Di seguito vengono riportate le regole che assegnano lo stesso firewall mark, 80, al traffico in ingresso destinato all'indirizzo IP floating, n.n.n.n, su porte 80 e 443.

/sbin/iptables -t mangle -A PREROUTING -p tcp -d n.n.n.n/32 -m multiport --dports 80,443 -j MARK --set-mark 80

Per istruzioni su come assegnare il VIP all'interfaccia di rete pubblica, consultate la Sezione 4.6.1, «Sottosezione SERVER VIRTUALE». Sarà necessario eseguire una registrazione come utenti root e caricare il modulo per iptables prima di assegnare le regole per la prima volta.

Nei comandi iptables sopra riportati, n.n.n.n deve essere sostituito con l'IP floating per i vostri server virtuali HTTP e HTTPS. Questi comandi avranno l'effetto di assegnare a qualsiasi traffico indirizzato al VIP sulle porte appropriate, un firewall mark di 80, il quale a sua volta viene riconosciuto da IPVS e inoltrato in modo appropriato.

Avvertimento

I suddetti comandi avranno un effetto immediato, ma non persisteranno dopo aver riavviato il sistema. Per assicurarsi che le impostazioni del filtro dei pacchetti di rete siano ripristinati dopo il riavvio, consulate la Sezione 3.6, «Come salvare le impostazioni per il filtro del pacchetto di rete»

3.5. Configurazione di FTP

Il File Transport Protocol (FTP) è un protocollo multi-port vecchio e complesso il quale presenta un certo numero di problematiche per un ambiente Load Balancer Add-On. Per capirne la natura è necessario comprendere il funzionamento di FTP.

3.5.1. Come funziona FTP

Con la maggior parte dei rapporti intrapresi con altri client server, la macchina client apre un collegamento per il server attraverso una determinata porta, la quale verrà utilizzata dal server per rispondere al client. Quando un client FTP si collega ad un server FTP, esso aprirà un collegamento con la porta 21 di controllo FTP. Subito dopo il client indicherà al server FTP se stabilire un collegamento attivo o passivo. Il tipo di collegamento scelto dal client determina il tipo di risposta del server, e la porta attraverso la quale avverrà tale transazione.

I due tipi di collegamento dei dati sono:

Collegamenti attivi: Quando si stabilisce un collegamento attivo il server aprirà un collegamento dei dati per il client dalla porta 20 ad una porta con un valore più alto sulla macchina client. Successivamente tutti i dati del server verranno passati attraverso questo collegamento.
Collegamenti passivi: Quando stabilite un collegamento passivo il client chiederà al server FTP di stabilire una porta per il collegamento passivo, la quale può essere superiore a 10,000. Per questa sessione il server si unisce alla suddetta porta e trasmette al client il numero della porta stessa. A questo punto il client aprirà la nuova porta per il collegamento dei dati. Ogni richiesta fatta dal client risulterà in un collegamento dei dati separato. La maggior parte dei client FTP moderni cercano di stabilire un collegamento passivo al momento della richiesta dei dati dal server.

Nota

Il client determina il tipo di collegamento e non il server. Ciò significa che per eseguire in modo effettivo il cluster FTP, è necessario configurare i router LVS in modo da gestire sia i collegamenti attivi che quelli passivi.

Il rapporto client/server FTP è in grado di aprire un numero molto grande di porte, le quali sono sconosciute a IPVS ed al Piranha Configuration Tool.

3.5.2. Come interessare l'instradamento di Load Balancer Add-On

L'inoltro del pacchetto da parte di IPVS abilita solo i collegamenti in ingresso e in uscita dal cluster in base al riconoscimento del proprio numero di porta o del firewall mark. Se un client esterno al cluster cerca di aprire una porta che IPVS non è configurato a gestire, esso interrompe il collegamento. In modo simile, se il real server cerca di aprire un collegamento su internet attraverso una porta che IPVS non conosce, esso interromperà il collegamento. Ciò significa che tutti i collegamenti provenienti dai client FTP su internet, devono avere lo stesso firewall mark, e tutti i collegamenti provenienti dal server FTP devono essere inoltrati correttamente su internet, utilizzando le regole di filtraggio dei pacchetti di rete.

Nota

Per abilitare i collegamenti FTP passivi assicuratevi di aver caricato il modulo del kernel ip_vs_ftp, per fare questo eseguire modprobe ip_vs_ftp come utente amministrativo al prompt della shell.

3.5.3. Creazione delle regole per il filtro dei pacchetti di rete

Prima di assegnare qualsiasi regola iptables per il servizio FTP, ricontrollate le informazioni in Sezione 3.4.1, «Assegnazione dei firewall mark» relative ai servizi multi-port e alle tecniche per il controllo di regole esistenti per il filtraggio dei pacchetti di rete.

Di seguito vengono elencate le regole che assegnano lo stesso firewall mark, 21, al traffico FTP. Per il funzionamento corretto delle suddette regole è necessario utilizzare anche la sottosezione VIRTUAL SERVER di Piranha Configuration Tool per configurare un virtual server per la porta 21 con un valore 21 nel campo Firewall Mark. Consultate la Sezione 4.6.1, «Sottosezione SERVER VIRTUALE» per maggiori informazioni.

3.5.3.1. Regole per collegamenti attivi

Le regole per i collegamenti attivi indicano al kernel di accettare e inoltrare i collegamenti in arrivo nell'indirizzo IP floating interno sulla porta 20 — la porta dei dati FTP.

Il seguente comando iptables permette al router LVS di accettare i collegamenti in uscita dai real server non conosciuti da IPVS:

/sbin/iptables -t nat -A POSTROUTING -p tcp -s n.n.n.0/24 --sport 20 -j MASQUERADE

Nel comando iptables, n.n.n deve essere sostituito con i primi tre valori dell'IP floating per l'interfaccia di rete interna dell'interfaccia NAT, definita nel pannello IMPOSTAZIONI GLOBALI del Piranha Configuration Tool.

3.5.3.2. Regole per i collegamenti passivi

Le regole per i collegamenti passivi assegnano il firewall mark appropriato ai collegamenti in entrata provenienti da internet per l'IP floating del servizio su di una determinata gamma di porte — da 10,000 a 20,000.

Avvertimento

Se limitate la gamma di porte per i collegamenti passivi sarà necessario configurare il server VSFTP in modo da utilizzare una gamma di porte corrispondente. È possibile eseguire tale operazione aggiungendo le seguenti righe su /etc/vsftpd.conf:

pasv_min_port=10000

pasv_max_port=20000

È consigliato non impostare pasv_address per sovrascrivere l'indirizzo del real server FTP poichè esso viene aggiornato sull'indirizzo IP virtuale da LVS.

Per la configurazione di altri server FTP, consultate le rispettive documentazioni.

Questa gamma dovrebbe essere sufficientemente grande per la maggior parte degli scenari; tuttavia è possibile aumentare questo numero in modo da includere tutte le porte non sicure tramite la modifica di 10000:20000 nei comandi sotto riportati in 1024:65535.

I seguenti comandi iptables avranno l'effetto di assegnare un firewall mark di 21 a qualsiasi traffico indirizzato all'IP floating delle porte appropriate, il quale a sua volta viene riconosciuto da IPVS e inoltrato in modo appropriato:

/sbin/iptables -t mangle -A PREROUTING -p tcp -d n.n.n.n/32 --dport 21 -j MARK --set-mark 21

/sbin/iptables -t mangle -A PREROUTING -p tcp -d n.n.n.n/32 --dport 10000:20000 -j MARK --set-mark 21

Nei comandi iptables, n.n.n.n dovrebbe essere sostituito con l'IP floating per il virtual server FTP, definito nella sottosezione VIRTUAL SERVER di Piranha Configuration Tool.

Avvertimento

I suddetti comandi avranno un effetto immediato ma non persisteranno dopo aver riavviato il sistema. Per assicurarsi che le impostazioni del filtro dei pacchetti di rete siano ripristinati dopo il riavvio, consulate la Sezione 3.6, «Come salvare le impostazioni per il filtro del pacchetto di rete»

Per finire, sarà necessario assicurarsi che il servizio appropriato venga impostato in modo da attivarsi sul runlevel corretto. Per maggiori informazioni consultate la Sezione 2.1, «Configurazione dei servizi sul router LVS».

3.6. Come salvare le impostazioni per il filtro del pacchetto di rete

Dopo aver configurato i filtri del pacchetto di rete appropriato salvate le impostazioni in modo da ripristinarle dopo il riavvio. Per iptables, digitate il seguente comando:

/sbin/service iptables save

Così facendo verranno salvate le impostazioni in /etc/sysconfig/iptables, e potranno essere richiamate al momento dell'avvio.

Una volta modificato il file sarete in grado di utilizzare il comando /sbin/service per poter avviare, arrestare e controllare lo stato (utilizzando lo status switch) di iptables. /sbin/service caricherà automaticamente il modulo appropriato per voi. Per un esempio su come utilizzare il comando /sbin/service, consultate la Sezione 2.3, «Avvio servizio Piranha Configuration Tool».

Per finire, assicuratevi che il servizio appropriato sia stato impostato in modo da avviarsi sul runlevel corretto. Per maggiori informazioni consultate la Sezione 2.1, «Configurazione dei servizi sul router LVS».

Il capitolo successivo spiega come utilizzare Piranha Configuration Tool per configurare il router LVS, e descrive le fasi necessarie per un Load Balancer Add-On attivo.

Capitolo 4. Configurazione di Load Balancer Add-On con Piranha Configuration Tool

Piranha Configuration Tool fornisce un approccio strutturato alla creazione del file di configurazione necessario per il Load Balancer Add-On — /etc/sysconfig/ha/lvs.cf. Questo capitolo descrive l'operazione di base del Piranha Configuration Tool, ed il processo di attivazione del Load Balancer Add-On una volta completata la configurazione.

Importante

Il file di configurazione per il Load Balancer Add-On segue regole molto precise di formattazione. L'utilizzo del Piranha Configuration Tool è il modo migliore per prevenire errori di sintassi in lvs.cf e quindi prevenire errori software.

4.1. Software necessario

Il servizio piranha-gui deve essere in esecuzione sul router LVS primario per poter usare Piranha Configuration Tool. Per poter configurare Load Balancer Add-On è necessario avere almeno un Web browser di solo testo, ad esempio links. Se desiderate accedere al router LVS da un'altra macchina, allora sarà necessario un collegamento ssh al router LVS primario come utente root.

Durante la configurazione del router LVS primario è consigliato mantenere un collegamento ssh corrente in una finestra del terminale. Questo collegamento fornisce un modo sicuro per riavviare pulse e altri servizi, configurare i filtri del pacchetto di rete, e monitorare /var/log/messages durante la risoluzione dei problemi.

Le quattro sezioni successive vi guideranno attraverso le pagine di configurazione del Piranha Configuration Tool, fornendo le istruzioni sul suo utilizzo per l'impostazione del Load Balancer Add-On.

4.2. Accesso al Piranha Configuration Tool

Durante la configurazione di un Load Balancer Add-On è necessario iniziare sempre configurando il router primario con Piranha Configuration Tool. Per fare questo verificate che il servizio piranha-gui sia in esecuzione, e che la password amministrativa sia stata impostata, come riportato in Sezione 2.2, «Impostazione di una password per Piranha Configuration Tool».

Se desiderate accedere alla macchina in modo locale sarà possibile aprire http://localhost:3636 in un web browser per accedere al Piranha Configuration Tool. In caso contrario digitate l'hostname o l'indirizzo IP reale per il server, seguito da :3636. Una volta stabilito il collegamento da parte del browser, sarete in grado di visualizzare la schermata mostrata in Figura 4.1, «Pannello di benvenuto».

Selezionare Login ed inserire piranha per il Nome utente e la password amministrativa creata nel campo Password.

Piranha Configuration Tool è composto di quattro schermate principali o pannelli. Altresì, il pannello dei Server virtuali presenta quattro sottosezioni. La prima è CONTROLLO/MONITORAGGIO subito dopo la schermata di login.

4.3. CONTROLLO/MONITORAGGIO

Il pannello CONTROLLO/MONITORAGGIO presenta lo stato del runtime limitato di Load Balancer Add-On. Inoltre è in grado di visualizzare lo stato del demone di pulse, la tabella d'instradamento LVS, ed i processi nanny generati da LVS.

Nota

I campi TABELLA D'INSTRADAMENTO LVS CORRENTE e PROCESSI LVS CORRENTI resteranno vuotI fino a quando non avvierete il Load Balancer Add-On, come riportato in Sezione 4.8, «Avvio di Load Balancer Add-On».

Figura 4.2. Pannello CONTROLLO/MONITORAGGIO

Auto update: È possibile aggiornare automaticamente il display dello stato ad un intervallo configurato dall'utente. Per abilitare questa funzione selezionare Auto update e impostare la frequenza di aggiornamento desiderata nella casella Frequenza di aggiornamento in secondi (il valore predefinito è 10 secondi).
Non è consigliato impostare l'aggiornamento automatico ad un intervallo di tempo inferiore a 10 secondi, poichè così facendo sarà difficile riconfigurare l'intervallo di Aggiornamento automatico poichè la pagina verrà aggiornata troppo frequentemente. Se incontrate questo problema fate clic su di un altro pannello e successivamente su CONTROLLO/MONITORAGGIO.
La funzione di Auto update non è operativa con tutti i browser, come ad esempio Mozilla.
Aggiorna informazioni ora: È possibile aggiornare manualmente le informazioni sullo stato selezionando questo pulsante.
MODIFICA PASSWORD: Facendo clic su questo pulsante verrete direzionati su di una schermata d'aiuto, contenente le informazioni su come modificare la password amministrativa per il Piranha Configuration Tool.

4.4. IMPOSTAZIONI GLOBALI

Il pannello IMPOSTAZIONI GLOBALI è il luogo dove è possibile definire le informazioni sul networking per le interfacce di rete privata e pubblica del router LVS primario.

Figura 4.3. Pannello IMPOSTAZIONI GLOBALI

La metà superiore di questo pannello imposta l'interfaccia pubblica e privata del router LVS primario. Queste sono le interfacce configurate in Sezione 3.1.1, «Configurazione delle interfacce di rete per il Load Balancer Add-On con NAT».

IP pubblico del server primario: In questo campo inserire l'indirizzo IP reale pubblicamente instradabile per il nodo LVS primario.
IP privato del server primario: Inserite l'indirizzo IP reale per una interfaccia di rete alternativa sul nodo LVS primario. Questo indirizzo verrà utilizzato solo come canale heartbeat alternativo per il router di backup, e non sarà correlato all'indirizzo IP privato reale assegnato in Sezione 3.1.1, «Configurazione delle interfacce di rete per il Load Balancer Add-On con NAT». È possibile lasciare vuoto questo campo, ma così facendo non avrete a disposizione alcun canale heartbeat alternativo per il router LVS di backup da utilizzare, creando così un single point of failure.
Nota
L'indirizzo IP privato non è necessario per le configurazioni dell'Instradamento diretto, poichè tutti i real server e le directory LVS condividono gli stessi indirizzi IP virtuali, e dovrebbero avere la stessa configurazione IP route.
Nota
L'IP privato del router LVS primario può essere configurato su qualsiasi interfaccia che accetti TCP/IP, incluso un adattatore Ethernet oppure una porta seriale.
TCP Timeout: Inserire il periodo (in secondi) prima della scadenza della sezione TCP. Il valore di timeout predefinito è 0.
TCP Fin Timeout: Inserire il periodo (in secondi) prima della scadenza della sezione TCP dopo aver ricevuto il pacchetto FIN. Il valore di timeout predefinito è 0.
UDP Timeout: Inserire il periodo (in secondi) prima della scadenza della sezione UDP. Il valore di timeout predefinito è 0.
Tipo di rete da usare: Selezionare NAT per l'instradamento NAT.
Selezionare Instradamento diretto per l'instradamento diretto.

I tre campi successivi sono specifici all'interfaccia di rete virtuale del router NAT, collegata alla rete privata con i server reali. Questi campi non si riferiscono al tipo di rete instradamento diretto.

IP del router NAT: Inserite in questo campo l'IP floating privato. Il suddetto IP dovrebbe essere usato come gateway per i real server.
Maschera di rete del router NAT: Se l'indirizzo IP floating del router NAT ha bisogno di una maschera di rete particolare, selezionatela dall'elenco a tendina.
Dispositivo del router NAT: Usate questo campo per deifinire il nome del dispositivo dell'interfaccia di rete per l'indirizzo IP floating, come ad esempio eth1:1.
Nota
Eseguite l'alias dell'indirizzo IP floating del NAT sull'interfaccia Ethernet collegata alla rete privata. In questo esempio la rete privata si trova sull'interfaccia eth1 e quindi eth1:1 risulta essere l'indirizzo IP floating.

Avvertimento

Dopo aver completato questa pagina fate clic sul pulsante ACCETTA in modo da non perdere le modifiche durante la selezione di un nuovo pannello.

4.5. RIDONDANZA

Il pannello RIDONDANZA permette di configurare il nodo del router LVS di backup, e d'impostare diverse opzioni per il monitoraggio dell'heartbeat.

Nota

Quando visiterete questa schermata per la prima volta sarete in grado di visualizzare uno stato di Backup "inattivo" insieme ad un pulsante ABILITA. Per configurare il router LVS di backup selezionare ABILITA in modo che la schermata corrisponda alla Figura 4.4, «Il pannello RIDONDANZA».

Figura 4.4. Il pannello RIDONDANZA

IP pubblico del server ridondante: Inserire l'indirizzo IP reale pubblico per il nodo del router LVS di backup.
IP privato del server ridondante: Inserire in questo campo l'indirizzo IP reale privato del nodo di backup.
Se non siete in grado di visualizzare il campo IP privato del server ridondante, tornate sul pannello IMPOSTAZIONI GLOBALI e inserite un indirizzo IP privato del server primario e successivamente fate clic su ACCETTA.

È possibile utilizzare il resto del pannello per configurare il canale heartbeat, il quale viene usato dal nodo di backup per controllare la presenza di errori nel nodo primario.

Intervallo heartbeat (secondi): Questo campo imposta il numero di secondi che intercorrono tra gli heartbeat — l'intervallo entro il quale il nodo di backup controllerà lo stato di funzionalità del nodo LVS primario.
Supponi inattivo dopo (secondi): Se il nodo LVS primario non risponde dopo il suddetto numero di secondi, allora il nodo del router LVS di backup inizierà un processo di failover.
Heartbeat è in esecuzione sulla porta: Questo campo imposta la porta sulla quale l'heartbeat comunica con il nodo LVS primario. Il default è impostato su 539 se questo campo viene lasciato vuoto.

La sezione finale del pannello può essere utilizzata per abilitare e configurare il Demone di sincronizzazione opzionale, e le relative opzioni. Il demone permette al LVS director attivo e di backup di mantenere sincronizzato lo stato del TCP. Quando abilitato, il director attivo invierà un messaggio multicast sulla rete con un ID di sincronizzazione (o syncid) configurabile, per un director di backup destinatario.

Avvertimento

Red Hat Enterprise Linux 6.5 introduce un nuovo formato per il protocollo del messaggio di sinc, ideato per impedire le interruzioni ai servizi causati da una scadenza prematura delle connessioni persistenti sui nodi di basckup, causando uno stato non consistente in presenza di un failover.

Il nuovo formato non è compatibile con Red Hat Enterprise Linux 6.4 o versioni precedenti, o con le versioni del kernel precedenti a kernel-2.6.32-406.el6. È consigliato aggiornare i nodi di backup prima di aggiornare il nodo master al Red Hat Enterprise Linux 6.5.

Per continuare a utilizzare il vecchio formato per i messaggi di sinc (per un aggiornamento al nodo master prima dei nodi di backup), impostare il valore di sync_version usando il comando echo come utente root nel prompt della shell:

echo 0 > /proc/sys/net/ipv4/vs/sync_version

Come selezionare il demone di sincronizzazione: Selezionare la casella corrispondente se desiderate abilitare il Demone di sincronizzazione.
Interfaccia del demone di sincronizzazione: L'interfaccia di rete attraverso la quale il demone di sincronizzazione invia/riceve i propri messaggi multicast. L'interfaccia predefinita in questo campo è eth0.
id demone di sinc: Questo campo imposta un identificatore (ID) per i messaggi di sinc multicast. I valori supportati vanno da 0 a 255, con il valore predefinito 0 se il campo viene lasciato vuoto.

Avvertimento

Dopo aver completato questa pagina fate clic sul pulsante ACCETTA, in modo da non perdere le modifiche durante la selezione di un nuovo pannello.

4.6. SERVER VIRTUALI

Il pannello SERVER VIRTUALI visualizza le informazioni relative ad ogni server virtuale corrente definito. Ogni voce presente nella tabella mostra lo stato del server virtuale, il nome del server, l'IP virtuale assegnato al server, la maschera di rete dell'IP virtuale, il numero della porta usata dal servizio per comunicare, il protocollo usato e l'interfaccia del dispositivo virtuale.

Figura 4.5. Pannello SERVER VIRTUALI

Ogni server presente nel pannello SERVER VIRTUALI può essere configurato sulle schermate successive o sulle sottosezioni.

Per aggiungere un dispositivo fate clic sul pulsante AGGIUNGI. Per rimuovere un servizio, selezionatelo tramite il pulsante situato accanto al server virtuale, e successivamente sul pulsante CANCELLA.

Per abilitare o disabilitare un server virtuale nella tabella, fate clic sul pulsante corrispondente e successivamente sul pulsante (DIS.)ABILITA.

Dopo aver aggiunto un server virtuale, sarà possibile configurarlo facendo clic sul pulsante corrispondente sulla sinistra, e successivamente il pulsante MODIFICA per visualizzare la sottosezione SERVER VIRTUALE.

4.6.1. Sottosezione SERVER VIRTUALE

La sottosezione SERVER VIRTUALE mostrata in Figura 4.6, «La sottosezione SERVER VIRTUALI» permette di configurare un server virtuale individuale. Lungo la parte alta della pagina sono situati i link per le sottosezioni specifiche del server virtuale. Prima di configurare le suddette sottosezioni completate questa pagina e fate clic sul pulsante ACCETTA.

Figura 4.6. La sottosezione SERVER VIRTUALI

Nome: Inserite un nome descrittivo per identificare il server virtuale. Questo nome non è l'hostname per la macchina, quindi rendetelo descrittivo e facilmente identificabile. È possibile far riferimento al protocollo usato dal virtual server, come ad esempio HTTP.
Porta per l'applicazione: Inserite il numero della porta attraverso la quale l'applicazione del servizio sarà in ascolto. Poichè questo esempio si riferisce ai servizi HTTP, la porta usata è 80.
Protocollo: Scegliere tra UDP e TCP nel menù a tendina. I web server generalmente comunicano tramite il protocollo TCP, per questo motivo esso viene selezionato nell'esempio sopra riportato.
Indirizzo IP virtuale: Inserite in questo campo l'indirizzo IP floating del server virtuale.
Maschera di rete dell'IP virtuale: Impostate la maschera di rete per questo server virtuale attraverso il menù a tendina.
Firewall Mark: Non inserite alcun valore intero per il firewall mark in questo campo, a meno che non raggruppate protocolli multi-port o create un virtual server multi-port per protocolli separati ma correlati. In questo esempio il server virtuale presenta un Firewall Mark di 80, poichè stiamo raggruppando i collegamenti per HTTP sulla porta 80 e per HTTPS sulla porta 443 utilizzando il valore 80 del firewall mark. Combinata con la persistenza questa tecnica è in grado di assicurare agli utenti che accedono pagine web sicure e non sicure, un instradamento allo stesso real server conservandone così lo stato.
Avvertimento
Inserendo un firewall mark in questo campo permetterete a IPVS di riconoscere che i pacchetti con questo firewall mark verranno trattati allo stesso modo, ricordate che sarà comunque necessario eseguire una ulteriore configurazione esterna al Piranha Configuration Tool per assegnare i firewall mark. Consultate la Sezione 3.4, «Servizi multi-port e Load Balancer Add-On» per informazioni sulla creazione di servizi multi-port, e la Sezione 3.5, «Configurazione di FTP» per la creazione di un server virtuale FTP ad elevata disponibilità.
Dispositivo: Inserire il nome del dispositivo di rete al quale desiderate unire l'indirizzo IP floating definito nel campo Indirizzo IP virtuale.
Eseguite l'alias dell'indirizzo IP floating pubblico sull'interfaccia Ethernet collegata alla rete pubblica. In questo esempio la rete pubblica si trova sull'interfaccia eth0, e quindi eth0:1 deve essere inserito come nome del dispositivo.

Periodo nuovo tentativo: Inserite un valore intero il quale definisce la durata del periodo, in secondi, prima che il router LVS attivo cerchi di ripristinare un real server nel gruppo dopo il verificarsi di un errore.
Timeout del servizio: Inserite un valore intero il quale definisce la durata del periodo, in secondi, prima che un real server venga considerato inattivo e quindi rimosso dal gruppo.
Server Quiesce: Dopo aver selezionato il pulsante del server Quiesce il peso di un real server verrà impostato su 0 quando non disponibile. Così facendo il real server verrà disabilitato e, se in un secondo momento, risulterà essere nuovamente disponibile, i real server verranno riabilitati implementando il peso originale. Se il server Quiesce è disabilitato, il real server fallito verrà rimosso dalla tabella dei server, ma verrà nuovamente aggiunto quando riporterà uno stato disponibile.
Tool di monitoraggio del carico: Il router LVS è in grado di monitorare il carico sui vari real server tramite l'utilizzo sia di rup che di ruptime. Se selezionate rup dal menu a tendina, ogni real server deve eseguire il servizio rstatd. Se invece selezionate ruptime, ogni real server deve eseguire il servizio rwhod.
Avvertimento
Il controllo del carico non è sinonimo di bilanciamento del carico, e può risultare in un comportamento di programmazione difficile da prevedere, quando combinato con algoritmi di schedulazione 'pesati'. Altresì se utilizzate il monitoraggio del carico, i real server devono essere macchine Linux.
Programmazione: Selezionate l'algoritmo di programmazione preferito dal menù a tendina. Il valore di default è Weighted least-connection. Per maggiori informazioni sugli algoritmi di scheduling consultate la Sezione 1.3.1, «Algoritmi di programmazione».
Persistenza: Se un amministratore ha bisogno di collegamenti persistenti per il server virtuale durante le transazioni del client, inserite in questo campo il numero di secondi di inattività permessi prima dell'interruzione del collegamento.
Importante
Se avete inserito un valore nel campo Firewall Mark, allora dovreste inserire anche un valore per la persistenza. Se utilizzate insieme i firewall mark e la persistenza, assicuratevi che la quantità di persistenza sia uguale per ogni server virtuale con il firewall mark. Per maggiori informazioni sulla persistenza e firewall mark, consultate la Sezione 1.5, «Persistenza e Firewall Mark».
Maschera di rete per la persistenza: Per poter limitare la persistenza di una particolare sottorete, selezionate la maschera di rete appropriata dal menu a tendina.
Nota
Prima dell'avvento dei firewall mark la persistenza, limitata in base alle sottoreti, rappresentava un metodo artigianale per unificare i collegamenti. Ora per ottenere lo stesso risultato è consigliato utilizzare la persistenza in relazione ai firewall mark.

Avvertimento

Ricordate di selezionare il pulsante ACCETTA dopo aver eseguito qualsiasi cambiamento, per non perdere alcuna modifica durante la selezione di un nuovo pannello.

4.6.2. Sottosezione REAL SERVER

Facendo clic sul link della sottosezione REAL SERVER nella parte alta del pannello, sarete in grado di visualizzare la sottosezione MODIFICA REAL SERVER. Essa mostra lo stato degli host del server fisico per un servizio virtuale specifico.

Figura 4.7. Sottosezione REAL SERVER

Fate clic sul pulsante AGGIUNGI per aggiungere un nuovo server. Per cancellare un server esistente selezionate il pulsante situato accanto ad esso e successivamente CANCELLA. Fate clic sul pulsante MODIFICA per caricare il pannello MODIFICA REAL SERVER, come riportato in Figura 4.8, «Pannello di configurazione del REAL SERVER».

Figura 4.8. Pannello di configurazione del REAL SERVER

Questo pannello consiste in tre campi:

Nome: Un nome descrittivo per il real server.
Nota
Questo nome non è l'hostname per la macchina, quindi rendetelo descrittivo e facilmente identificabile.
Indirizzo: L'indirizzo IP del real server. Poichè la porta in ascolto è stata già specificata per il server virtuale associato, non aggiungete alcun numero.
Peso: Un valore intero il quale indica la capacità di questo host in relazione alla capacità di altri host presenti nel gruppo. Il valore può essere arbitrario, ma consideratelo come un rapporto in relazione agli altri real server. Per maggiori informazioni consultare Sezione 1.3.2, «Peso del server e programmazione (scheduling)».

Avvertimento

Dopo aver completato questa pagina fate clic sul pulsante ACCETTA, in modo da non perdere le modifiche durante la selezione di un nuovo pannello.

4.6.3. Sottosezione MODIFICA SCRIPT DI MONITORAGGIO

Fate clic sul link SCRIPT DI MONITORAGGIO nella parte alta della pagina. La sottosezione MODIFICA SCRIPT DI MONITORAGGIO permette all'amministratore di specificare una sequenza della stringa del tipo send/expect, per verificare che il servizio per il server virtuale funzioni correttamente su ogni real server. Esso rappresenta anche il luogo dove l'amministratore può specificare script personalizzati per il controllo dei servizi che richiedono una modifica dinamica dei dati.

Figura 4.9. Sottosezione MODIFICA SCRIPT DI MONITORAGGIO

Programma mittente

Per una verifica dei servizi molto più avanzata è possibile utilizzare questo campo per specificare il percorso per uno script di controllo del servizio. Questa funzione è particolarmente utile per servizi che richiedono una modifica dinamica dei dati, come ad esempio HTTPS o SSL.

Per utilizzare questa funzione è necessario scrivere uno script il quale ritorna una risposta testuale, impostatela in modo da essere eseguibile e digitate il percorso relativo nel campo Programma mittente.

Nota

Per assicurarsi che ogni server all'interno del pool dei real server venga controllato, utilizzate il token speciale %h dopo il percorso per lo script nel campo Programma mittente. Il suddetto token viene sostituito con l'indirizzo IP del real server durante la chiamata dello script da parte del demone nanny.

Il seguente è un esempio di scirpt da utilizzare come guida durante la composizione di uno script esterno per il controllo del servizio:

#!/bin/sh

TEST=`dig -t soa example.com @$1 | grep -c dns.example.com

if [ $TEST != "1" ]; then
	echo "OK
else
	echo "FAIL"
fi

Nota

Se inserite nel campo Programma mittente un programma esterno, allora il campo Invio viene ignorato.

Invio

Inserire una stringa per il demone nanny da inviare ad ogni real server in questo campo. Per default il campo relativo a HTTP è stato completato. È possibile alterare questo valore a seconda delle vostre esigenze. Se lasciate questo campo vuoto, il demone nanny cerca di aprire la porta, e se ha successo assume che il servizio è in esecuzione.

In questo campo è permesso solo una sola sequenza d'invio, e può contenere solo caratteri ASCII stampabili insieme ai seguenti caratteri:

\n per una nuova riga.
\r per il ritorno a capo del cursore.
\t per tab.
\ escape del carattere successivo che lo segue.

In attesa

Inserire la risposta testuale che il server dovrebbe ritornare se funziona correttamente. Se avete scritto il vostro programma mittente, inserite la risposta da inviare in caso di successo.

Nota

Per determinare cosa inviare per un determinato servizio, aprite un collegamento telnet per la porta su di un real server, e controllate cosa viene ritornato. Per esempio FTP riporta 220 previo collegamento, è possibile quindi inserire quit nel campo Invia e 220 nel campo In attesa.

Avvertimento

Dopo aver completato questa pagina fate clic sul pulsante ACCETTA, in modo da non perdere le modifiche durante la selezione di un nuovo pannello.

Una volta completata la configurazione dei server virtuali utilizzando Piranha Configuration Tool, sarà necessario copiare i file di configurazione specifici sul router LVS di backup. Consultate la Sezione 4.7, «Sincronizzazione dei file di configurazione» per informazioni.

4.7. Sincronizzazione dei file di configurazione

Dopo aver configurato il router LVS primario è necessario copiare diversi file di configurazione sul router LVS di backup prima di avviare il Load Balancer Add-On.

Questi file includono:

/etc/sysconfig/ha/lvs.cf — i file di configurazione per i router LVS.
/etc/sysctl — il file di configurazione che, oltre ad altre funzioni, abilita l'inoltro dei pacchetti nel kernel.
/etc/sysconfig/iptables — Se state utilizzando i firewall mark dovreste sincronizzare uno di questi file in base al filtro del pacchetto di rete usato.

Importante

I file /etc/sysctl.conf e /etc/sysconfig/iptables non vengono modificati quando si configura Load Balancer Add-On con Piranha Configuration Tool.

4.7.1. Sincronizzazione di `lvs.cf`

Ogni qualvolta il file di configurazione LVS, /etc/sysconfig/ha/lvs.cf, viene aggiornato o creato, sarà necessario copiarlo sul nodo del router LVS di backup.

Avvertimento

Sia il nodo del router LVS attivo che quello passivo devono avere file lvs.cf identici. Se i file di configurazione LVS dei nodi del router LVS non corrispondono, il processo di failover non si potrà verificare.

Il modo migliore per fare questo è di utilizzare il comando scp .

Importante

Per usare scp è necessario eseguire sshd nel router di backup. Consultare Sezione 2.1, «Configurazione dei servizi sul router LVS» per informazioni su come configurare correttamente i servizi necessari sui router LVS.

Emettere il seguente comando come utente root dal router LVS primario per sincronizzare i file lvs.cf tra i nodi del router:

scp /etc/sysconfig/ha/lvs.cf n.n.n.n:/etc/sysconfig/ha/lvs.cf

Nel comando sostituite n.n.n.n con l'indirizzo IP del real server del router LVS di backup.

4.7.2. Sincronizzazione di `sysctl`

Nella maggior parte dei casi il file sysctl viene modificato solo una volta. Questo file viene letto al momento dell'avvio e indica al kernel di abilitare il packet forwarding.

Importante

Se non siete sicuri di aver abilitato il packet forwarding consultate la Sezione 2.5, «Abilitare l'inoltro dei pacchetti» per maggiori informazioni su come controllare e, se necessario, abilitare questa funzione molto importante.

4.7.3. Sincronizzazione delle regole per il filtro dei pacchetti di rete

Se state utilizzando iptables sarà necessario sincronizzare il file di configurazione appropriato sul router LVS di backup.

Se modificate qualsiasi regola di filtraggio dei pacchetti di rete, inserite il seguente comando come utente root dal router LVS primario:

scp /etc/sysconfig/iptables n.n.n.n:/etc/sysconfig/

Nel comando sostituite n.n.n.n con l'indirizzo IP del real server del router LVS di backup.

Successivamente aprite una sessione ssh per il router di backup, oppure eseguite la registrazione sulla macchina come utente root e digitate il seguente comando:

/sbin/service iptables restart

Una volta copiati i file sul router di backup e avviato i servizi appropriati (consultate la Sezione 2.1, «Configurazione dei servizi sul router LVS» per maggiori informazioni su questo argomento), potrete avviare il Load Balancer Add-On.

4.8. Avvio di Load Balancer Add-On

Per avviare il Load Balancer Add-On è consigliato avere due terminali root aperti simultaneamente, oppure due sessioni ssh root per il router LVS primario.

In un terminale controllate i messaggi di log del kernel con il comando:

tail -f /var/log/messages

Successivamente avviate Load Balancer Add-On digitando il seguente comando all'interno dell'altro terminale:

/sbin/service pulse start

Seguite l'avvio del servizio pulse nel terminale con i messaggi di log del kernel. Quando visualizzerete il seguente output, il demone di pulse sarà stato avviato correttamente:

gratuitous lvs arps finished

Per non controllare più /var/log/messages, digitare Ctrl+c.

Da qui in avanti il router LVS primario è anche il router LVS attivo. A questo punto anche se sarà possibile effettuare richieste al Load Balancer Add-On, è consigliato avviare il router LVS di backup prima d'innescare il Load Balancer Add-On. Per fare questo ripetete il processo sopra descritto sul nodo del router LVS di backup.

Dopo aver completato la fase finale, Load Balancer Add-On sarà in esecuzione.

Appendice A. Come usare il Load Balancer Add-On con High Availability Add-On

È possibile utilizzare il Load Balancer Add-On con High Availability Add-On per implementare un sito a elevata disponibilità e-commerce, in grado di fornire un bilanciamento del carico, una integrità dei dati ed una disponibilità delle applicazioni.

La configurazione presente in Figura A.1, «Load Balancer Add-On con un High Availability Add-On» rappresenta un sito e-commerce usato per l'ordinazione online di materiale attraverso un URL. Le richieste del client fatte attraverso l'URL passano il firewall fino ad arrivare al router di bilanciamento del carico LVS, il quale a sua volta inoltra le richieste ad uno dei web server. I nodi High Availability Add-On servono dati dinamici ai web server, i quali inoltrano i dati al client richiedente.

Figura A.1. Load Balancer Add-On con un High Availability Add-On

Per fornire un contenuto web dinamico con Load Balancer Add-On è necessario avere una configurazione a tre livelli (come mostrato in Figura A.1, «Load Balancer Add-On con un High Availability Add-On»). Questa combinazione di Load Balancer Add-On e High Availability Add-On permette una configurazione di un sito e-commerce con una elevata integrità e senza alcun single-point-of-failure. High Availability Add-On è in grado di eseguire una istanza ad elevata disponibilità di un database o di un set di database accessibili tramite la rete ai web server.

Per fornire un contenuto dinamico è necessario avere una configurazione a tre livelli. Anche se la configurazione di Load Balancer Add-On a due livelli è idonea se i web server servono solo contenuti web statici (i quali consistono in una quantità piccola di dati non frequentemente modificati), essa non è idonea se i web server servono un contenuto dinamico. Tale contenuto include un inventario dei prodotti, ordinazioni, o database dei clienti, i quali devono essere aggiornati e conformi su tutti i web server, in modo da assicurare ai clienti stessi un accesso a informazioni accurate e costantemente aggiornate.

Ogni livello fornisce le seguenti funzioni:

Primo livello — i router LVS eseguono un bilanciamento del carico per distribuire le richieste web.
Secondo livello — Un set di web server per servire le richieste.
Terzo livello — Un High Availability Add-On per servire i dati ai Web server.

In una configurazione Load Balancer Add-On simile a quella riportata in Figura A.1, «Load Balancer Add-On con un High Availability Add-On», i sistemi client emettono le richieste sul World Wide Web. Per ragioni di sicurezza, queste richieste entrano in un sito web attraverso un firewall, il quale può essere un sistema Linux o un dispositivo firewall apposito. Per motivi di ridondanza è possibile configurare i dispositivi firewall in una configurazione di failover. Dietro il firewall sono presenti i router LVS di bilanciamento del carico, i quali possono essere configurati in modalità active-standby. Il router attivo per il bilanciamento del carico inoltra le richieste al set di web server.

Ogni web server è in grado di processare indipendentemente una richiesta HTTP proveniente da un client e inviare la risposta al client stesso. Load Balancer Add-On permette di aumentare la capacità di un sito web, aggiungendo alcuni web server dietro i router LVS; i suddetti router eseguono un bilanciamento del carico attraverso un set più vasto di web server. In aggiunta, se un web server fallisce, esso potrà essere rimosso; Load Balancer Add-On continua ad eseguire il bilanciamento del carico attraverso un set più piccolo di web server.

Appendice B. Diario delle Revisioni

Diario delle Revisioni

Revisione 1-15.1

Thu Apr 30 2015

Francesco Valente

Translation files synchronised with XML sources 1-15

Revisione 1-15

Tue Dec 16 2014

Steven Levine

Aggiornato per l'implementazione di sort_order nella pagina di apertura di RHEL 6.

Revisione 1-13

Thu Oct 9 2014

Steven Levine

Release per il GA di Red Hat Enterprise Linux 6.6

Revisione 1-10

Tue Nov 19 2013

John Ha

Release per il GA di Red Hat Enterprise Linux 6.5.

Revisione 1-8

Fri Sep 27 2013

John Ha

Release per il Beta di Red Hat Enterprise Linux 6.5.

Revisione 1-4

Wed Nov 28 2012

John Ha

Release per il Beta di Red Hat Enterprise Linux 6.4.

Revisione 1-3

Mon Jun 18 2012

John Ha

Release per il GA di Red Hat Enterprise Linux 6.3.

Revisione 1-2

Fri Dec 2 2011

John Ha

Release per il GA di Red Hat Enterprise Linux 6.2

Revisione 1-1

Wed Nov 10 2010

Paul Kennedy

Release iniziale per il Red Hat Enterprise Linux 6

Indice analitico

Simboli

/etc/sysconfig/ha/lvs.cf file, /etc/sysconfig/ha/lvs.cf

A

arptables_jf, Instradamento diretto e arptables_jf

C

chkconfig, Configurazione dei servizi sul router LVS

cluster

come usare il Load Balancer Add-On con High Availability Add-On, Come usare il Load Balancer Add-On con High Availability Add-On

commenti, Commenti

componenti

Load Balancer Add-On, Componenti di Load Balancer Add-On

F

FTP, Configurazione di FTP

(vedi anche Load Balancer Add-On)

H

High Availability Add-On

come usare Load Balancer Add-On con, Come usare il Load Balancer Add-On con High Availability Add-On
e Load Balancer Add-On , Come usare il Load Balancer Add-On con High Availability Add-On

I

inoltro dei pacchetti, Abilitare l'inoltro dei pacchetti

(vedi anche Load Balancer Add-On)

instradamento

prerequisiti per il Load Balancer Add-On, Configurazione delle interfacce di rete per il Load Balancer Add-On con NAT

instradamento diretto

e arptables_jf, Instradamento diretto e arptables_jf

introduzione, Introduzione

altri documenti Red Hat Enterprise Linux, Introduzione

iptables , Configurazione dei servizi sul router LVS

ipvsadm programma, ipvsadm

L

least connections (vedi programmazione processi, Load Balancer Add-On)

Load Balancer Add-On

/etc/sysconfig/ha/lvs.cf file, /etc/sysconfig/ha/lvs.cf

avvio di Load Balancer Add-On, Avvio di Load Balancer Add-On

come usare il Load Balancer Add-On con High Availability Add-On, Come usare il Load Balancer Add-On con High Availability Add-On

componenti, Componenti di Load Balancer Add-On

configurazione iniziale, Configurazione iniziale di Load Balancer Add-On

dati condivisi, Condivisione e replica dei dati tra real server

inoltro dei pacchetti, Abilitare l'inoltro dei pacchetti

instradamento diretto

e arptables_jf, Instradamento diretto e arptables_jf
requisiti di rete, Load Balancer Add-On tramite instradamento diretto
requisiti, di rete, Instradamento diretto
requisiti, hardware, Instradamento diretto, Load Balancer Add-On tramite instradamento diretto
requisiti, software, Instradamento diretto, Load Balancer Add-On tramite instradamento diretto

instradamento NAT

requisiti, di rete, Il NAT Load Balancer Add-On Network
requisiti, hardware, Il NAT Load Balancer Add-On Network
requisiti, software, Il NAT Load Balancer Add-On Network

ipvsadm programma, ipvsadm

metodi di instradamento

NAT, Metodi di instradamento

nanny demone, nanny

Piranha Configuration Tool , Piranha Configuration Tool

prerequisiti per l'instradamento, Configurazione delle interfacce di rete per il Load Balancer Add-On con NAT

programmazione processi, Panoramica programmazione di Load Balancer Add-On

programmazione, processi, Panoramica programmazione di Load Balancer Add-On

pulse demone, pulse

replica dei dati, real server, Condivisione e replica dei dati tra real server

router LVS

configurazione servizi, Configurazione iniziale di Load Balancer Add-On
nodo primario, Configurazione iniziale di Load Balancer Add-On
servizi necessari, Configurazione dei servizi sul router LVS

send_arp programma, send_arp

servizi multi-port, Servizi multi-port e Load Balancer Add-On

FTP, Configurazione di FTP

sincronizzazione dei file di configurazione, Sincronizzazione dei file di configurazione

tre livelli

Load Balancer Add-on, Configurazione Load Balancer Add-On a tre livelli

LVS

instradamento NAT

abilitazione, Come abilitare l'instradamento NAT sui router LVS

lvs demone, lvs

panoramica, Panoramica Load Balancer Add-On

real server, Panoramica Load Balancer Add-On

lvs demone, lvs

N

nanny demone, nanny

NAT

abilitazione, Come abilitare l'instradamento NAT sui router LVS
metodi di instradamento, Load Balancer Add-On, Metodi di instradamento

network address translation (vedi NAT)

P

Piranha Configuration Tool , Piranha Configuration Tool

CONTROLLO/MONITORAGGIO , CONTROLLO/MONITORAGGIO

impostazione di una password, Impostazione di una password per Piranha Configuration Tool

IMPOSTAZIONI GLOBALI , IMPOSTAZIONI GLOBALI

limitare l'accesso a, Limitare l'accesso a Piranha Configuration Tool

MODIFICA SCRIPT DI MONITORAGGIO Sottosezione, Sottosezione MODIFICA SCRIPT DI MONITORAGGIO

pannello di login, Accesso al Piranha Configuration Tool

panoramica, Configurazione di Load Balancer Add-On con Piranha Configuration Tool

REAL SERVER sottosezione, Sottosezione REAL SERVER

RIDONDANZA , RIDONDANZA

SERVER VIRTUALE sottosezione, Sottosezione SERVER VIRTUALE

Firewall Mark , Sottosezione SERVER VIRTUALE
Indirizzo IP virtuale , Sottosezione SERVER VIRTUALE
Persistence , Sottosezione SERVER VIRTUALE
Scheduling , Sottosezione SERVER VIRTUALE

SERVER VIRTUALI , SERVER VIRTUALI

software necessario, Software necessario

piranha-passwd , Impostazione di una password per Piranha Configuration Tool

programmazione processi, Load Balancer Add-On, Panoramica programmazione di Load Balancer Add-On

programmazione, processi (Load Balancer Add-On), Panoramica programmazione di Load Balancer Add-On

pulse demone, pulse

R

real server

configurazione dei servizi, Configurazione dei servizi sui Real Server

round robin (vedi programmazione processi, Load Balancer Add-On)

S

Samba

demone, lvs

security

Piranha Configuration Tool , Limitare l'accesso a Piranha Configuration Tool

send_arp programma, send_arp

servizi multi-port, Servizi multi-port e Load Balancer Add-On

(vedi anche Load Balancer Add-On)

servizio piranha-gui , Configurazione dei servizi sul router LVS

servizio pulse , Configurazione dei servizi sul router LVS

servizio sshd , Configurazione dei servizi sul router LVS

sincronizzazione dei file di configurazione, Sincronizzazione dei file di configurazione

W

weighted least connections (vedi programmazione processi, Load Balancer Add-On)
weighted round robin (vedi programmazione processi, Load Balancer Add-On)

Nota Legale

This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

Language and Page Formatting Options

Red Hat Training

Amministrazione di Load Balancer

Load Balancer Add-on per Red Hat Enterprise Linux

Introduzione

1. Commenti

Capitolo 1. Panoramica Load Balancer Add-On

1.1. Una configurazione di base di Load Balancer Add-On

1.1.1. Condivisione e replica dei dati tra real server

1.1.1.1. Configurazione dei Real server per la sincronizzazione dei dati

1.2. Configurazione Load Balancer Add-On a tre livelli

1.3. Panoramica programmazione di Load Balancer Add-On

1.3.1. Algoritmi di programmazione

1.3.2. Peso del server e programmazione (scheduling)

1.4. Metodi di instradamento

1.4.1. Instradamento NAT

1.4.2. Instradamento diretto

1.4.2.1. Instradamento diretto e restrizioni ARP

1.5. Persistenza e Firewall Mark

1.5.1. Persistenza

1.5.2. Firewall Mark

1.6. Load Balancer Add-On — Diagramma a blocchi

1.6.1. Componenti di Load Balancer Add-On

1.6.1.1. pulse

1.6.1.2. lvs

1.6.1.3. ipvsadm

1.6.1.4. nanny

1.6.1.5. /etc/sysconfig/ha/lvs.cf

1.6.1.6. Piranha Configuration Tool

1.6.1.7. send_arp

Capitolo 2. Configurazione iniziale di Load Balancer Add-On

2.1. Configurazione dei servizi sul router LVS

2.2. Impostazione di una password per Piranha Configuration Tool

2.3. Avvio servizio Piranha Configuration Tool

2.3.1. Configurazione porta del web server Piranha Configuration Tool

2.4. Limitare l'accesso a Piranha Configuration Tool

2.5. Abilitare l'inoltro dei pacchetti

2.6. Configurazione dei servizi sui Real Server

Capitolo 3. Impostazione Load Balancer Add-On

3.1. Il NAT Load Balancer Add-On Network

3.1.1. Configurazione delle interfacce di rete per il Load Balancer Add-On con NAT

3.1.2. Instradamento sui real server

3.1.3. Come abilitare l'instradamento NAT sui router LVS

3.2. Load Balancer Add-On tramite instradamento diretto

3.2.1. Instradamento diretto e arptables_jf

3.2.2. Instradamento diretto e iptables

3.3. Come eseguire la configurazione

3.3.1. Suggerimenti generali per il Networking del Load Balancer Add-On

3.3.1.1. Risoluzione problematiche dell'indirizzo IP virtuale

3.4. Servizi multi-port e Load Balancer Add-On

3.4.1. Assegnazione dei firewall mark

3.5. Configurazione di FTP

3.5.1. Come funziona FTP

3.5.2. Come interessare l'instradamento di Load Balancer Add-On

3.5.3. Creazione delle regole per il filtro dei pacchetti di rete

3.5.3.1. Regole per collegamenti attivi

3.5.3.2. Regole per i collegamenti passivi

3.6. Come salvare le impostazioni per il filtro del pacchetto di rete

Capitolo 4. Configurazione di Load Balancer Add-On con Piranha Configuration Tool

4.1. Software necessario

4.2. Accesso al Piranha Configuration Tool

4.3. CONTROLLO/MONITORAGGIO

4.4. IMPOSTAZIONI GLOBALI

4.5. RIDONDANZA

4.6. SERVER VIRTUALI

4.6.1. Sottosezione SERVER VIRTUALE

4.6.2. Sottosezione REAL SERVER

4.6.3. Sottosezione MODIFICA SCRIPT DI MONITORAGGIO

4.7. Sincronizzazione dei file di configurazione

4.7.1. Sincronizzazione di lvs.cf

4.7.2. Sincronizzazione di sysctl

4.7.3. Sincronizzazione delle regole per il filtro dei pacchetti di rete

4.8. Avvio di Load Balancer Add-On

Appendice A. Come usare il Load Balancer Add-On con High Availability Add-On

Appendice B. Diario delle Revisioni

Indice analitico

Simboli

A

C

F

1.6.1.1. `pulse`

1.6.1.2. `lvs`

1.6.1.3. `ipvsadm`

1.6.1.4. `nanny`

1.6.1.5. `/etc/sysconfig/ha/lvs.cf`

1.6.1.7. `send_arp`

3.2.1. Instradamento diretto e `arptables_jf`

3.2.2. Instradamento diretto e `iptables`

4.7.1. Sincronizzazione di `lvs.cf`

4.7.2. Sincronizzazione di `sysctl`