Figura 1.22, «LVS Implemented with NAT Routing», illustrates LVS using NAT routing to move requests between the Internet and a private network.

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 the example, the LVS router's public LVS floating IP address and private NAT floating IP address are aliased to two physical NICs. While it is possible to associate each floating IP address to its physical device on the LVS router nodes, having more than two NICs is not a requirement.

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 router LVS 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 il NAT routing i real server possono essere rappresentati da ogni tipo di computer sui quali viene eseguito una verietà di sistemi operativi. Il router LVS può rappresentare lo svantaggio del NAT routing, infatti con implementazioni molto grandi esso deve processare richieste sia in entrata che in uscita.

L'instradamento diretto fornisce maggiori benefici per quanto riguarda le prestazioni rispetto al NAT routing. Esso permette ai real server di processare e direzionare i pacchetti direttamente ad un richiedente, invece di passare i pacchetti in uscita attraverso il router LVS. L'instradamento diretto riduce i problemi di prestazione della rete, relegando il compito del router LVS alla sola processazione dei pacchetti in entrata.

In una configurazione LVS direct-routing 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. Ogni real server processa le richieste ed invia le risposte direttamente ai client, bypassando i router LVS. L'instradamento diretto permette di avere una certa scalabilità, e quindi aggiungere real server senza aver bisogno che il router LVS direzioni i pacchetti in uscita dal real server al client, evitando un potenziale problema in presenza di carichi di rete maggiori.

Anche se sono presenti numerosi vantaggi nell'utilizzo dell'instradamento diretto in LVS, sono presenti alcune limitazioni. Il problema più comune tra l'instradamento diretto e LVS è rappresentato dall'Address Resolution Protocol (ARP).

In typical situations, a client on the Internet sends a request to an IP address. Network routers typically send requests to their destination by relating IP addresses to a machine's MAC address with ARP. ARP requests are broadcast to all connected machines on a network, and the machine with the correct IP/MAC address combination receives the packet. The IP/MAC associations are stored in an ARP cache, which is cleared periodically (usually every 15 minutes) and refilled with IP/MAC associations.

Il problema esistente con le richieste ARP in una configurazione LVS 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 router LVS 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 completamente il router LVS, ed annullando lo scopo della configurazione LVS. L'utilizzo di un router LVS con una CPU molto potente in grado di rispondere rapidamente alle richieste del client, porebbe non risolvere questo problema. Se il router LVS presenta un carico molto elevato, esso potrebbe rispondere alle richieste ARP molto più lentamente di un real server con un carico di lavoro normale, il quale sarà in grado di rispondere più velocemente e al quale verrà assegnato il VIP nella cache ARP del client richiedente.

Per risolvere questo problema le richieste in entrata dovrebbero solo associare il VIP al router LVS, il quale processerà correttamente le richieste, inviandole al gruppo di real server. È possibile eseguire questo processo utilizzando il tool arptables di filtraggio del pacchetto.

Quando abilitata, la persistenza funziona come un timer. Quando un client esegue il collegamento ad un servizio, LVS ricorda l'ultimo collegamento effettuato dal client stesso per un periodo di tempo specificato. 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 vi permette altresì di specificare una maschera di sottorete da applicare al test dell'indirizzo IP del client, come tool per il controllo degli indirizzi che possiedono un elevato livello di persistenza, e quindi raggruppando 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.

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 LVS 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 LVS l'utilizzo, quando possibile, dei firewall mark invece della persistenza per raggruppare i collegamenti. Tuttavia è consigliato aggiungere la persistenza sui server virtuali insieme ai firewall mark, in modo da assicurarsi che i client possono essere ricollegati allo stesso server per un periodo di tempo adeguato.

You can access the Cluster Configuration Tool (Figura 1.27, «Cluster Configuration Tool») through the Cluster Configuration tab in the Cluster Administration GUI.

Il Cluster Configuration Tool rappresenta i componenti di configurazione del cluster nel file di configurazione (/etc/cluster/cluster.conf), con un display grafico gerarchico nel pannello di sinistra. Una icona triangolare a sinistra del nome del componente, indica che il componente stesso possiede uno o due componenti subordinati assegnati. Facendo clic sull'icona triangolare sarete in grado di espandere o comprimere la porzione d'albero situata sotto un componente. I componenti visualizzati nella GUI vengono riassunti nel seguente modo:

You can access the Cluster Status Tool (Figura 1.28, «Cluster Status Tool») through the Cluster Management tab in Cluster Administration GUI.

I nodi ed i servizi visualizzati nel Cluster Status Tool vengono determinati dal file di configurazione del cluster (/etc/cluster/cluster.conf). È possibile utilizzare il Cluster Status Tool per abilitare, disabilitare, riavviare o riposizionare un servizio high-availability.

The VIRTUAL SERVER subsection panel shown in Figura 1.34, «The VIRTUAL SERVERS Subsection» allows you to configure an individual virtual server. Links to subsections related specifically to this virtual server are located along the top of the page. But before configuring any of the subsections related to this virtual server, complete this page and click on the ACCEPT button.

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.

Click the ADD button to add a new server. To delete an existing server, select the radio button beside it and click the DELETE button. Click the EDIT button to load the EDIT REAL SERVER panel, as seen in Figura 1.36, «The REAL SERVER Configuration Panel».

Questo pannello consiste in tre campi:

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.