Red Hat Enterprise Linux 6

Amministrazione del Virtual Server

Load Balancer Add-On per Red Hat Enterprise Linux

Edizione 6

Logo

Nota Legale

Copyright © 2010 Red Hat, Inc.
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, MetaMatrix, 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.

Sommario

La creazione di un sistema Load Balancer Add-On offre soluzioni scalabili ad elavata disponibilità per servizi di produzione attraverso l'utilizzo di tecniche specializzate di instradamento e bilanciamento del carico configurate attraverso PIRANHA. Questo manuale affronta il processo di configurazione di sistemi per elevate prestazioni e dei servizi con Red Hat Enterprise Linux e Load Balancer Add-On per Red Hat Enterprise Linux 6.
Introduzione
1. Convenzioni del documento
1.1. Convenzioni tipografiche
1.2. Convenzioni del documento
1.3. Note ed avvertimenti
2. Commenti
1. Panoramica sul Load Balancer Add-On
1.1. Una configurazione Load Balancer Add-On di base
1.1.1. Riproduzione dati e loro condivisione tra real server
1.2. Una configurazione Load Balancer Add-On a tre livelli
1.3. Panoramica sul Load Balancer Add-On scheduling
1.3.1. Algoritmi di scheduling
1.3.2. Peso del server e scheduling
1.4. Metodi d'instradamento
1.4.1. Instradamento NAT
1.4.2. Instradamento diretto
1.5. Persistenza e Firewall mark
1.5.1. Persistenza
1.5.2. Firewall Mark
1.6. Load Balancer Add-On — Un diagramma a blocchi
1.6.1. Componenti di Load Balancer Add-On
2. Configurazione Load Balancer Add-On iniziale
2.1. Configurazione dei servizi sui router LVS
2.2. Impostazione della password per il Piranha Configuration Tool
2.3. Avvio del servizio del Piranha Configuration Tool
2.3.1. Come configurare la Porta del Web Server del Piranha Configuration Tool
2.4. Limitare l'accesso al Piranha Configuration Tool
2.5. Abilitazione del Packet Forwarding
2.6. Configurazione dei servizi sui real server
3. Impostazione del Load Balancer Add-On
3.1. La rete NAT Load Balancer Add-On
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 un 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.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. Com' è possibile interessare l'instradamento Load Balancer Add-On
3.5.3. Creazione delle regole per il filtro dei pacchetti di rete
3.6. Come salvare le impostazioni per il filtro del pacchetto di rete
4. Configurazione del Load Balancer Add-On con il 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. VIRTUAL SERVER
4.6.1. La sottosezione VIRTUAL SERVER
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 di filtraggio dei pacchetti di rete
4.8. Avvio del Load Balancer Add-On
A. Come usare il Load Balancer Add-On con High Availability Add-On
B. Cronologia della revisione
Indice analitico

Introduzione

Questo documento fornisce le informazioni relative all'installazione, configurazione e gestione dei componenti di Load Balancer Add-On. Esso fornisce il 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 clusters, storage, e server computing.
Il documento è organizzato nel modo seguente:
Per maggiori informazioni su Red Hat Enterprise Linux 6 consultare le seguenti risorse:
  • La Red Hat Enterprise Linux Installation Guide — Fornisce le informazioni relative all'installazione di Red Hat Enterprise Linux 6.
  • Il Red Hat Enterprise Linux Deployment Guide — Fornisce le informazioni relative all'impiego, configurazione e amministrazione di Red Hat Enterprise Linux 6.
Per maggiori informazioni su Load Balancer Add-On per Red Hat Enterprise Linux 6 consultare le seguenti risorse:
  • Panoramica di Red Hat Cluster Suite — Fornisce una panoramica dettagliata sull'High Availability Add-On, Resilient Storage Add-On, e Load Balancer Add-On.
  • Configurazione e gestione di un High Availability Add-On — Fornisce le informazioni necessarie per la configurazione e la gestione dell'High Availability Add-On (conosciuto anche come Red Hat Cluster) per Red Hat Enterprise Linux 6.
  • Logical Volume Manager Administration — Fornisce una descrizione del Logical Volume Manager (LVM), incluso le informazioni su come eseguire un LVM in un ambiente clusterizzato.
  • Global File System 2: Configurazione e Amministrazione — Fornisce le informazioni relative all'installazione, configurazione e gestione di Red Hat Resilient Storage Add-On (ǒnosciuto come Red Hat Global File System 2).
  • DM Multipath — Fornisce le informazioni relative all'utilizzo della funzione Device-Mapper Multipath di Red Hat Enterprise Linux 6.
  • Note di rilascio — Fornisce le informazioni necessarie sulla release corrente dei prodotti di Red Hat.
Questo documento ed altri documenti di Red Hat sono disponibili in versioni HTML, PDF, e RPM sul CD di documentazione di Red Hat Enterprise Linux ed online su http://www.redhat.com/docs/.

1. Convenzioni del documento

Questo manuale utilizza numerose convenzioni per evidenziare parole e frasi, ponendo attenzione su informazioni specifiche.
Nelle edizioni PDF e cartacea questo manuale utilizza caratteri presenti nel set Font Liberation. Il set Font Liberation viene anche utilizzato nelle edizioni HTML se il set stesso è stato installato sul vostro sistema. In caso contrario, verranno mostrati caratteri alternativi ma equivalenti. Da notare: Red Hat Enterprise Linux 5 e versioni più recenti, includono per default il set Font Liberation.

1.1. Convenzioni tipografiche

Vengono utilizzate quattro convenzioni tipografiche per richiamare l'attenzione su parole e frasi specifiche. Queste convenzioni, e le circostanze alle quali vengono applicate, sono le seguenti.
Neretto monospazio
Usato per evidenziare l'input del sistema, incluso i comandi della shell, i nomi dei file ed i percorsi. Utilizzato anche per evidenziare tasti e combinazione di tasti. Per esempio:
Per visualizzare i contenuti del file my_next_bestselling_novel nella vostra directory di lavoro corrente, inserire il comando cat my_next_bestselling_novel al prompt della shell e premere Invio per eseguire il comando.
Quanto sopra riportato include il nome del file, un comando della shell ed un tasto, il tutto riportato in neretto monospazio e distinguibile grazie al contesto.
Le combinazioni si distinguono dai tasti singoli tramite l'uso del segno più, il quale viene usato per creare una combinazione di tasti. Per esempio:
Premere Invio per eseguire il comando.
Premere Ctrl+Alt+F2 per usare un terminale virtuale.
Il primo esempio evidenzia il tasto specifico singolo da premere. Il secondo riporta una combinazione di tasti: un insieme di tre tasti premuti contemporaneamente.
Se si discute del codice sorgente, i nomi della classe, i metodi, le funzioni i nomi della variabile ed i valori ritornati indicati all'interno di un paragrafo, essi verranno indicati come sopra, e cioè in neretto monospazio. Per esempio:
Le classi relative ad un file includono filesystem per file system, file per file, e dir per directory. Ogni classe possiede il proprio set associato di permessi.
Proportional Bold
Ciò denota le parole e le frasi incontrate su di un sistema, incluso i nomi delle applicazioni; il testo delle caselle di dialogo; i pulsanti etichettati; le caselle e le etichette per pulsanti di selezione, titoli del menu e dei sottomenu. Per esempio:
Selezionare SistemaPreferenzeMouse dalla barra del menu principale per lanciare Preferenze del Mouse. Nella scheda Pulsanti, fate clic sulla casella di dialogo mouse per mancini, e successivamente fate clic su Chiudi per cambiare il pulsante primario del mouse da sinistra a destra (rendendo così il mouse idoneo per un utilizzo con la mano sinistra).
Per inserire un carattere speciale in un file gedit selezionare ApplicazioniAccessoriMappa del carattere dalla barra del menu principale. Selezionare successivamente CercaTrova… dal menu Mappa del carattere, digitare il nome desiderato nel campo Cerca e selezionare Successivo. Il carattere desiderato sarà evidenziato nella Tabella dei caratteri. Eseguire un doppio clic sul carattere per poterlo posizionare nel campo Testo da copiare e successivamente fare clic sul pulsante Copia. Ritornare sul documento e selezionare ModificaIncolla dalla barra del menu di gedit.
Il testo sopra riportato include i nomi delle applicazioni; nomi ed oggetti del menu per l'intero sistema; nomi del menu specifici alle applicazioni; e pulsanti e testo trovati all'interno di una interfaccia GUI, tutti presentati in neretto proporzionale e distinguibili dal contesto.
Corsivo neretto monospazio o Corsivo neretto proporzionale
Sia se si tratta di neretto monospazio o neretto proporzionale, l'aggiunta del carattere corsivo indica un testo variabile o sostituibile . Il carattere corsivo denota un testo che non viene inserito letteralmente, o visualizzato che varia a seconda delle circostanze. Per esempio:
Per collegarsi ad una macchina remota utilizzando ssh, digitare ssh username@domain.name al prompt della shell. Se la macchina remota è example.com ed il nome utente sulla macchina interessata è john, digitare ssh john@example.com.
Il comando mount -o remount file-system rimonta il file system indicato. Per esempio, per rimontare il file system /home, il comando è mount -o remount /home.
Per visualizzare la versione di un pacchetto attualmente installato, utilizzare il comando rpm -q package. Esso ritornerà il seguente risultato: package-version-release.
Da notare le parole in corsivo grassetto - username, domain.name, file-system, package, version e release. Ogni parola funge da segnaposto, sia esso un testo inserito per emettere un comando o mostrato dal sistema.
Oltre all'utilizzo normale per la presentazione di un titolo, il carattere Corsivo denota il primo utilizzo di un termine nuovo ed importante. Per esempio:
Publican è un sistema di pubblicazione per DocBook.

1.2. Convenzioni del documento

Gli elenchi originati dal codice sorgente e l'output del terminale vengono evidenziati rispetto al testo circostante.
L'output inviato ad un terminale è impostato su tondo monospazio e così presentato:
books        Desktop   documentation  drafts  mss    photos   stuff  svn
books_tests  Desktop1  downloads      images  notes  scripts  svgs
Gli elenchi del codice sorgente sono impostati in tondo monospazio ma vengono presentati ed evidenziati nel modo seguente:
static int kvm_vm_ioctl_deassign_device(struct kvm *kvm,
                 struct kvm_assigned_pci_dev *assigned_dev)
{
         int r = 0;
         struct kvm_assigned_dev_kernel *match;

         mutex_lock(&kvm->lock);

         match = kvm_find_assigned_dev(&kvm->arch.assigned_dev_head,
                                       assigned_dev->assigned_dev_id);
         if (!match) {
                 printk(KERN_INFO "%s: device hasn't been assigned before, "
                   "so cannot be deassigned\n", __func__);
                 r = -EINVAL;
                 goto out;
         }

         kvm_deassign_device(kvm, match);

         kvm_free_assigned_device(kvm, match);

out:
         mutex_unlock(&kvm->lock);
         return r;
}

1.3. Note ed avvertimenti

E per finire, tre stili vengono usati per richiamare l'attenzione su informazioni che in caso contrario potrebbero essere ignorate.

Nota

Una nota è un suggerimento o un approccio alternativo per il compito da svolgere. Non dovrebbe verificarsi alcuna conseguenza negativa se la nota viene ignorata, ma al tempo stesso potreste non usufruire di qualche trucco in grado di facilitarvi il compito.

Importante

Le caselle 'importante' riportano informazioni che potrebbero passare facilmente inosservate: modifiche alla configurazione applicabili solo alla sessione corrente, o servizi i quali necessitano di un riavvio prima di applicare un aggiornamento. Ignorare queste caselle non causa alcuna perdita di dati ma potrebbe causare irritazione e frustrazione da parte dell'utente.

Avvertimento

Un Avvertimento non dovrebbe essere ignorato. Se ignorato, potrebbe verificarsi una perdita di dati.

2. 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 componente Documentazione-cluster.
Assicuratevi di indicare l'identificatore del manuale;
Virtual_Server_Administration(EN)-6 (2010-10-14T16:28)
Indicando l'identificatore del manuale noi sapremo esattamente di quale versione siete in possesso.
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 sul Load Balancer Add-On

Il Load Balancer Add-On è composto da un set di componenti software integrati che forniscono il Linux Virtual Servers (LVS) per il bilanciamento del carico IP attraverso un insieme di real server. Viene eseguito su di una coppia di computer configurati in modo identico: uno come router LVS attivo, e l'altro come router LVS di backup. Il router LVS attivo serve per:
  • Bilanciare il carico attraverso i real server.
  • Per controllare l'integrità dei servizi su ogni real server.
Il router LVS di backup controlla il router LVS attivo, e ne assume il controllo in caso di un suo fallimento.
Questo capitolo fornisce una panoramica dei componenti del Load Balancer Add-On e delle loro funzioni, e consiste nelle seguenti sezioni:

1.1. Una configurazione Load Balancer Add-On di base

Figura 1.1, «Una configurazione Load Balancer Add-On di base» mostra una configurazione Load Balancer Add-On semplice di due livelli. Sul primo sono presenti due router LVS — uno attivo e l'altro di backup. Ogni router LVS presenta due interfacce di rete, una su internet e l'altra sulla rete privata, in grado così di regolare il traffico presente tra le due reti. Per questo esempio il router attivo utilizza il Network Address Translation o NAT per direzionare il traffico da internet ad un numero variabile di real server sul secondo livello, il quale a sua volta fornisce i servizi necessari. Per questo motivo i real server in questo esempio sono collegati ad un apposito segmento di rete privata, e passano tutto il traffico pubblico attraverso il router LVS attivo. Al mondo esterno, i server appaiono come una sola entità.
Una configurazione Load Balancer Add-On di base

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


Le richieste del servizio in arrivo ai router LVS vengono indirizzate ad un indirizzo virtual IP, o VIP. Esso è un indirizzo pubblicamente-instradabile che l'amministratore del sito associa con un fully-qualified domain name, come ad esempio www.example.com, assegnandolo ad uno o più virtual server. Un virtual server è un servizio configurato per essere in ascolto su di un virtual IP specifico. Consultate la Sezione 4.6, «VIRTUAL SERVER» per maggiori informazioni su come configurare un virtual server utilizzando Piranha Configuration Tool. Un indirizzo VIP migra da un router LVS ad un altro durante il processo di failover, mantenendo una presenza sull'indirizzo IP in questione (conosciuto anche come indirizzi IP floating).
È possibile eseguire l'alias degli indirizzi VIP sullo stesso dispositivo che collega il router LVS ad internet. Per esempio, se eth0 è collegato ad internet, allora sarà possibile eseguire l'alias dei server virtuali multipli su eth0:1. Alternativamente ogni virtual server 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 solo router LVS per volta è attivo. Il ruolo del router attivo è quello di ridirezionare le richieste del servizio da indirizzi virtual IP ai real server. Tale processo si basa su uno degli otto algoritmi di bilanciamento del carico supportati descritti in Sezione 1.3, «Panoramica sul Load Balancer Add-On scheduling».
Il router dinamico controlla dinamicamente anche lo stato generale dei servizi specifici sui real server, attraverso script send/expect semplici. Per un ausilio al rilevamento dello stato dei servizi che necessitano di dati dinamici, come ad esempio HTTP o SSL, l'amministratore potrà chiamare anche eseguibili esterni. Se un servizio su di un real server funziona incorrettamente, il router attivo sospende l'invio dei lavori al server in questione, fino a quando non verrà ripristinato un funzionamento normale.
Il router di backup esegue il ruolo di un sistema in standby. Periodicamente i router LVS scambiano messaggi heartbeat attraverso l'interfaccia pubblica esterna primaria e, in condizioni di failover, attraverso l'interfaccia privata. Se il nodo di backup non riceve un messaggio heartbeat entro un intervallo di tempo previsto, esso inizierà un processo di failover, assumendo il ruolo del router attivo. Durante il processo di failover, il router di backup assume il controllo degli indirizzi VIP serviti dal router fallito, utilizzando una tecnica conosciuta come ARP spoofing — dove il router LVS di backup si presenta come destinazione per i pacchetti IP inviati al nodo fallito. Quando il suddetto nodo ripristina il proprio servizio attivo, il nodo di backup assume il suo ruolo di hot-backup.
La configurazione a due livelli usata in Figura 1.1, «Una configurazione Load Balancer Add-On di base» risulta essere l'ideale per servire dati che non variano molto frequentemente — come ad esempio le pagine web statiche — poichè i real server individuali non sincronizzano automaticamente i dati tra ogni nodo.

1.1.1. Riproduzione dati e loro condivisione tra real server

Poichè non è presente alcun componente interno al Load Balancer Add-On per poter condividere gli stessi dati tra i real server, l'amministratore è in possesso di due opzioni:
  • Sincronizzare i dati attraverso il gruppo di real server
  • Aggiungere un terzo livello alla tipologia per un accesso dei dati condivisi
È preferibile la prima opzione per quei server che non permettono ad un gran numero di utenti di caricare o modificare i dati sui real server. Se la configurazione permette invece ad un gran numero di utenti di modificare i dati, come ad esempio un sito web e-commerce, allora sarà preferibile aggiungere un terzo livello.

1.1.1.1. Configurazione dei real server per sincronizzare i dati

Per un amministratore sono diponibili diversi metodi per poter sincronizzare i dati in un gruppo di real server. Per esempio, è possibile implementare gli script della shell in modo tale che se un Web engineer aggiorna una pagina, la pagina stessa viene inviata simultaneamente su tutti i server. Altresì, l'amministratore del sistema può utilizzare programmi come rsync, per riprodurre i dati modificati attraverso tutti i nodi ad un intervallo di tempo prestabilito.
Tuttavia questo tipo di sincronizzazione dei dati non funziona in maniera ottimale se la configurazione è sovraccarica con utenti che a loro volta caricano costantemente file o che eseguono transazioni database. Per una configurazione con un carico molto elevato, una tipologia a tre livelli risulta essere la soluzione ideale.

1.2. Una configurazione Load Balancer Add-On a tre livelli

Figura 1.2, «Una configurazione Load Balancer Add-On a tre livelli» mostra una tipologia di Load Balancer Add-On tipica a tre livelli. In questo esempio il router LVS attivo indirizza le richieste da internet al gruppo di real server. Ogni real server accede a sua volta un sorgente di dati condivisi attraverso la rete.
Una configurazione Load Balancer Add-On a tre livelli

Figura 1.2. Una 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 centrale ad elevata disponibilità, e disponibili ad ogni real server tramite una directory NFS esportata o condivisione Samba. Questa tipologia è consigliata per siti web che accedono ad un database ad elevata disponibilità centrale per le loro transazioni. Altresì, utilizzando una configurazione active-active con Red Hat Cluster Manager, gli amministratori possono configurare un cluster high-availability, per servire entrambi i ruoli simultaneamente.
Il terzo livello negli esempi sopra riportati, non è obbligato ad utilizzare Red Hat Cluster Manager, ma se non utilizza una soluzione ad elevata disponibilità, causerà un single point of failure critico.

1.3. Panoramica sul Load Balancer Add-On scheduling

Uno dei vantaggi nell'utilizzo del Load Balancer Add-On è rappresentato dalla sua capacità di eseguire un bilanciamento del carico a livello-IP flessibile nel gruppo dei real server. Questa flessibilità è dovuta alla varietà di algoritmi di scheduling che un amministratore può scegliere quando configura Load Balancer Add-On. Il bilanciamento del carico LVS risulta essere superiore rispetto a metodi meno flessibili, come ad esempio Round-Robin DNS, dove la natura gerarchica di DNS ed il caching da parte di macchine client, può portare ad uno squilibrio del carico. In aggiunta, un livello basso di filtraggio implementato dal router LVS produce dei vantaggi nei confronti dell'inoltro delle richieste di livello-applicazione, poichè il bilanciamento dei carichi a livello di pacchetto di rete causa un overhead minimo e permette una maggiore scalabilità.
Utilizzando lo scheduling durante l'instradamento delle richieste, il router attivo può prendere in considerazione l'attività dei real server e, facoltativamente, un fattore peso assegnato dall'amministratore. Utilizzando pesi già assegnati verrà conferita una priorità arbitraria alle macchine individuali. Usando questa forma di scheduling, è possibile creare un gruppo di real server utilizzando una varietà di combinazioni hardware e software, dando la possibilità al router attivo di conferire un carico uniforme ad ogni real server.
Il meccanismo di scheduling per il Load Balancer Add-On è fornito da una raccolta di patch del kernel chiamata moduli IP Virtual Server o IPVS. I suddetti moduli abilitano il cambiamento del livello di trasporto (transport layer) Livello 4 (L4), ideato per funzionare bene con server multipli su di un indirizzo IP singolo.
Per controllare e direzionare i pacchetti ai real server in modo efficiente, IPVS crea una tabella IPVS nel kernel. Questa tabella viene utilizzata dal router LVS attivo per instradare le richieste da un indirizzo del virtual server per, e in ritorno, dai real server nel gruppo. La tabella IPVS viene costantemente aggiornata da una utilità chiamata ipvsadm — aggiungendo e rimuovendo i membri del cluster a seconda della loro disponiblità.

1.3.1. Algoritmi di scheduling

La struttura assunta dalla tabella IPVS dipende dall'algoritmo di scheduling scelto dall'amministratore per ogni virtual server. Per avere una flessibilità massima nei tipi di servizi che potrete raggruppare, e su come programmare i suddetti servizi, Red Hat Enterprise Linux fornisce i seguenti algoritmi di scheduling. Per informazioni su come assegnare gli algoritmi di scheduling consultate la Sezione 4.6.1, «La sottosezione VIRTUAL SERVER».
Scheduling Round-Robin
Distribuisce ogni richiesta in modo sequenziale attraverso il gruppo di real server. Utilizzando questo algoritmo, tutti i real server vengono trattati nello stesso modo, senza considerare la capacità o il carico. Questo modello di scheduling richiama il round-robin DNS, ma risulta essere più granulare poichè si basa sul collegamento alla rete e non sull'host. Lo scheduling round-robin del Load Balancer Add-On non soffre dello squilibrio creato dalle richieste DNS della cache.
Scheduling Weighted Round-Robin
Distribuisce ogni richiesta in modo sequenziale al gruppo di real server, dando però più lavoro ai server con maggiore capacità. La capacità viene indicata da un fattore di peso assegnato dall'utente, il quale viene modificato in base alle informazioni sul carico dinamico. Consultate la Sezione 1.3.2, «Peso del server e scheduling» per il peso dei real server.
Lo scheduling Weighted round-robin è la scelta preferita se sono presenti differenze significative di capacità nei server di un gruppo. Tuttavia, se il carico richiesto varia in modo drammatico, il server con più peso potrebbe assumere un carico maggiore alle sue capacità.
Least-Connection
Distribuisce un numero maggiore di richieste ai real server con un numero minore di collegamenti attivi. Poichè mantiene un controllo sui collegamenti attivi per i real server attraverso la tabella IPVS, least-connection è un tipo di algoritmo di scheduling dinamico ideale se è presente una variazione molto ampia del carico. È la scelta migliore per un gruppo di real server dove ogni nodo del membro possiede più o meno la stessa capacità. Se un gruppo di server presenta una capacità diversa, allora lo scheduling weighted least-connection è quello migliore.
Weighted Least-Connections (predefinito)
Distribuisce un numero maggiore di richieste ai server con un numero di collegamenti attivi minori in base alle loro capacità. La capacità viene indicata da un peso assegnato dall'utente, il quale viene modificato dalle informazioni del carico dinamico. L'aggiunta di peso rende questo algoritmo ideale quando il gruppo dei real server contiene hardware di varia capacità. Consultate la Sezione 1.3.2, «Peso del server e scheduling» per maggiori informazioni.
Scheduling Least-Connection in base al locale
Distribuisce un numero maggiore di richieste ai server con meno collegamenti attivi in base ai loro IP di destinazione. Questo algoritmo è stato ideato per un uso all'interno di un proxy-cache server cluster. Esso instrada i pacchetti di un indirizzo IP al server per l'indirizzo in questione se il server non ha superato le proprie capacità, ed un secondo server presenta un carico pari alla metà delle proprie capacità. In tal caso verrà assegnato l'indirizzo IP al real server con un carico minore.
Scheduling Least-Connection in base al locale con Scheduling di riproduzione
Distribuisce un numero maggiore di richieste ai server con un numero di collegamenti attivi minori in base ai propri IP di destinazione. Questo algoritmo è stato creato anche per un suo utilizzo in un proxy-cache server cluster. Differisce dallo scheduling Least-Connection in base al locale, a causa di una mappatura dell'indirizzo IP target su di un sottoinsieme di nodi del real server. Le richieste vengono instradate al server all'interno del sottoinsieme, con il numero più basso di collegamenti. Se tutti i nodi per l'IP di destinazione sono oltre la loro capacità, esso replicherà un nuovo server per l'indirizzo IP di destinazione, aggiungendo il real server con un numero minore di collegamenti dal gruppo di real server al sottoinsieme di real server per l'IP di destinazione interessato. Il nodo con un carico maggiore viene rilasciato dal sottoinsieme di real server in modo da evitare una eccessiva presenza di nodi.
Scheduling Hash di destinazione
Distribuisce le richieste al gruppo di real server andando alla ricerca dell'IP di destinazione in una tabella Hash statica. Questo algoritmo è stato creato per un suo utilizzo in un proxy-cache server cluster.
Scheduling Hash sorgente
Distribuisce le richieste al gruppo di real server andando alla ricerca dell'IP sorgente in una tabella Hash statica. Questo algoritmo è stato creato per i router LVS con firewall multipli.

1.3.2. Peso del server e scheduling

L'amministratore del Load Balancer Add-On è in grado di assegnare un peso ad ogni nodo presente nel gruppo di real server. Il suddetto peso è composto da un valore intero presente in qualsiasi algoritmo di scheduling weight-aware (come ad esempio weighted least-connections), e viene utilizzato dal router LVS per indirizzare il carico in modo più uniforme su hardware con diverse capacità.
I pesi sono in relazione tra loro. Per esempio, se un real server possiede un peso uguale a 1, e l'altro server possiede un peso pari a 5, il server con peso 5 otterrà 5 collegamenti per ogni 1 collegamento ricevuto dall'altro server. Il valore di default per un real server è 1.
Anche se l'aggiunta di peso alle diverse configurazioni hardware in un gruppo di real server può comportare un bilanciamento del carico più efficiente, questa operazione può causare squilibri temporanei quando un real server viene introdotto in un gruppo, e lo stesso è stato schedulato per usare un weighted least-connection. Per esempio, supponiamo ci siano tre server in un gruppo di real server. Server A e B hanno un peso pari a 1 ed il terzo, server C, ha un peso pari a 2. Se il server C viene per qualche ragione interrotto, i server A e B distribuiranno uniformemente il carico appena abbandonato. Tuttavia, quando il server C è nuovamente attivo, il router LVS lo considera come se avesse zero collegamenti e quindi inizia il trasferimento al server di un numero elevato di richieste in entrata fino a raggiungere una parità con i server A e B.
Per prevenire questo fenomeno gli amministratori possono trasformare il virtual server in un server quiesce — ogni qualvolta un nuovo nodo del real server risulta essere online, la tabella delle least-connection viene azzerata e il router LVS instrada le richieste come se tutti i real server fossero stati appena aggiunti al cluester.

1.4. Metodi d'instradamento

Red Hat Enterprise Linux utilizza il Network Address Translation o instradamento NAT per il Load Balancer Add-On, il quale conferisce all'amministratore un elevatissimo grado di flessibilità durante l'utilizzo dell'hardware disponibile, e permette l'integrazione di LVS in una rete esistente.

1.4.1. Instradamento NAT

Figura 1.3, «Load Balancer Add-On implementato con instradamento NAT», mostra il Load Balancer Add-On durante l'utilizzo di un instradamento NAT per spostare le richieste tra internet ed una rete privata.
Load Balancer Add-On implementato con instradamento NAT

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


Nell'esempio sono presenti due NIC nel router LVS attivo. Il NIC per internet presenta un indirizzo IP reale su eth0 ed un alias dell'indirizzo IP floating su eth0:1. Il NIC per l'interfaccia di rete privata presenta un indirizzo IP reale su eth1 ed un alias dell'indirizzo IP floating su eth1:1. Se si verifica un failover, l'interfaccia virtuale a contatto con internet e quella privata rivolta verso l'interfaccia virtuale, vengono controllate simultaneamente dal router LVS di backup. Tutti i real server posizionati sulla rete privata, utilizzano l'IP floating per il router NAT come propria rotta predefinita per comunicare con il router LVS attivo, così da non compromettere la loro abilità a rispondere alle richieste provenienti da internet.
In questo esempio viene eseguito l'alias dell'indirizzo IP floating pubblico del router LVS e dell'indirizzo IP floating NAT privato su due NIC fisici. Anche se è possibile associare ogni indirizzo IP floating con il proprio dispositivo fisico sui nodi del router LVS, non è necessario avere più di due NIC.
Utilizzando questa topografia il router LVS attivo riceve la richiesta e la direziona verso il server appropriato. Successivamente, il real server la processa e ritorna i pacchetti al router LVS, il quale utilizza il network address translation per sostituire l'indirizzo del real server nei pacchetti, con l'indirizzo VIP pubblico dei router LVS. Questo processo è chiamato IP masquerading poichè gli indirizzi IP dei real server sono nascosti ai client richiedenti.
Se si utilizza l'instradamento NAT i real server potranno essere qualsiasi macchina in grado di eseguire diversi sistemi operativi. Lo svantaggio principale è rappresentato dal fatto che il router LVS potrebbe diventare il punto più debole, se utilizzato in implementazioni cluster più grandi poichè sarà necessario processare sia richieste in uscita che richieste in entrata.

1.4.2. Instradamento diretto

La creazione di una impostazione Load Balancer Add-On che utilizzi un instradamento diretto, fornisce maggiori benefici sulle prestazioni rispetto ad altri tipi di networking Load Balancer Add-On. L'instradamento diretto permette ai real server di processare e direzionare i pacchetti direttamente ad un utente richiedente, invece di passare tutti i pacchetti in uscita attraverso il router LVS. L'instradamento diretto riduce le problematiche relative alla prestazione di rete, relegando le funzioni del router LVS alla sola processazione dei pacchetti in ingresso.
Load Balancer Add-On implementato con un instradamento diretto

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


In una impostazione Load Balancer Add-On con instradamento diretto tipica il router LVS riceve le richieste del server in arrivo attraverso il virtual IP (VIP), ed utilizza un algoritmo di scheduling per instradare ed inviare le risposte direttamente al client bypassando i router LVS. Questo metodo d'instradamento permette di avere una certa scalabilità, poichè i real server possono essere aggiunti, senza la necessità di avere un router LVS apposito per instradare i pacchetti in uscita dal real server al client, eliminando un potenziale problema in presenza di carichi di rete molto pesanti.

1.4.2.1. Instradamento diretto e limitazioni ARP

Insieme ai numerosi vantaggi offerti dall'utilizzo dell'instradamento diretto in un Load Balancer Add-On sono presenti anche alcune limitazioni. Il problema più comune con il Load Balancer Add-On e l'instradamento diretto si verifica con l'Address Resolution Protocol (ARP).
In situazioni tipiche un client presente su internet invia una richiesta ad un indirizzo IP. I router di rete generalmente inviano le richieste alle rispettive destinazioni, mettendo in relazione gli indirizzi IP per un 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 corretta indirizzo IP/MAC riceverà il pacchetto. Le associazioni IP/MAC vengono conservate in una cache ARP, la quale viene svuotata periodicamente (ogni 15 minuti) e riempita con associazioni IP/MAC.
Il problema presente con le richieste ARP in una impostazione Load Balancer Add-On con istradamento diretto, è causato da una richiesta del client ad un indirizzo IP la quale deve essere associata con un indirizzo MAC per poter essere gestita. Da notare che l'indirizzo IP virtuale del sistema Load Balancer Add-On deve anch'esso essere associato ad un MAC. Tuttavia, poichè il router LVS ed i real server hanno lo stesso VIP, la richiesta ARP verrà trasmessa a tutte le macchine associate con il VIP. Ciò potrebbe causare diversi problemi come ad esempio l'associazione del VIP direttamente ad uno dei real server, e quindi la processazione diretta delle richieste, bypassando completamente il router LVS e annullando lo scopo dell'impostazione del Load Balancer Add-On.
Per risolvere questo problema fate in modo che le richieste in ingresso siano sempre inviate al router LVS, invece di essere inviate ad uno dei real server. Per fare questo utilizzate il tool di filtraggio del pacchetto iptables o arptables_jf nelle seguenti situazioni:
  • arptables_jf impedisce l'associazione dei VIP con i real server da parte di ARP.
  • Il metodo iptables evita completamente la problematica ARP, non configurando i VIP sui real server.
Per maggiori informazioni su come utilizzare arptables o iptables in un ambiente Load Balancer Add-On con instradamento diretto, consultate la 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 determinate situazioni potrebbe essere conveniente per un client ricollegarsi ripetutamente allo stesso real server invece di avere un algoritmo di bilanciamento del carico Load Balancer Add-On in grado di inviare la richiesta al miglior server disponibile. Esempi di queste situazioni includono forme web multi-screen, cookies, SSL, e collegamenti FTP. In questi casi un client potrebbe non operare correttamente a meno che le transazioni non siano gestite dallo stesso server per garantire una certa continuità. A tale scopo Load Balancer Add-On fornisce due diverse funzioni: la persistenza ed i firewall mark.

1.5.1. Persistenza

Quando abilitata, la persistenza funziona come un timer. E cioè quando un client si collega ad un servizio, Load Balancer Add-On si ricorda dell'ultimo collegamento per un periodo di tempo specificato. Se lo stesso indirizzo IP del client si collega entro il suddetto periodo, esso verrà inviato allo stesso server con il quale si è precedentemente collegato — bypassando così i meccanismi di bilanciamento del carico. Se invece il suddetto collegamento si verifica dopo il periodo specificato, esso verrà gestito in base alle regole implementate.
La persistenza permette anche all'amministratore di specificare una maschera di sottorete da applicare al test dell'indirizzo IP del client, come tool per il controllo degli indirizzi con un livello elevato di persistenza, quindi raggruppando i collegamenti a quella sottorete.
Il raggruppamento dei collegamenti destinati a porte diverse può essere un processo importante per i protocolli che utilizzano più di una porta per comunicare, come ad esempio FTP. Tuttavia, la persistenza non rappresenta il modo migliore per affrontare i problemi del raggruppamento dei collegamenti destinati a porte diverse. Per queste situazioni è consigliato usare i firewall mark.

1.5.2. Firewall Mark

I firewall mark rappresentano un modo semplice ed efficiente per raggruppare le porte usate per un protocollo, o gruppo di protocolli, in relazione tra loro. Per esempio, se Load Balancer Add-On viene impiegato per eseguire un sito e-commerce, i firewall mark possono essere utilizzati per raggruppare i collegamenti HTTP sulla porta 80, e rendere i collegamenti HTTP sicuri sulla porta 443. Assegnando lo stesso firewall mark al virtual server per ogni protocollo, è possibile conservare le informazioni sullo stato della transazione, poichè il router LVS inoltra tutte le richieste allo stesso real server dopo aver aperto un collegamento.
Grazie alla sua efficienza e facilità d'uso, gli amministratori del Load Balancer Add-On dovrebbero usare, quando possibile, i firewall mark al posto della persistenza per raggruppare i collegamenti. Tuttavia, gli amministratori dovrebbero aggiungere la persistenza ai server virtuali insieme ai firewall mark, per far si che i client vengano ricollegati allo stesso server per un periodo di tempo adeguato.

1.6. Load Balancer Add-On — Un diagramma a blocchi

I router LVS utilizzano una raccolta di programmi per monitorare i membri del cluster ed i servizi. Figura 1.5, «Componenti di Load Balancer Add-On» illustra come questi programmi sui router LVS di backup e attivo lavorano insieme per gestire il cluster.
Componenti di Load Balancer Add-On

Figura 1.5. Componenti di Load Balancer Add-On


Il demone pulse viene eseguito sul router LVS passivo ed attivo. Sul router di backup pulse invia un heartbeat all'interfaccia pubblica del router attivo, per assicurarsi che il router attivo funzioni correttamente. Sul router attivo pulse avvia il demone lvs, e risponde alle interrogazioni heartbeat dal router LVS di backup.
Una volta avviato, il demone lvs richiama l'utilità ipvsadm per configurare e mantenere la tabella d'instradamento IPVS nel kernel ed avvia un processo nanny per ogni virtual server configurato su ogni real server. Ogni processo nanny controlla lo stato di un servizio configurato su di un real server, ed indica al demone lvs se il servizio sul real server in questione non funziona correttamente. Se viene rilevato tale malfunzionamento il demone lvs indica a ipvsadm di rimuovere il real server dalla tabella d'instradamento IPVS.
Se il router di backup non riceve alcuna risposta dal router attivo, verrà iniziato un processo di failover tramite send_arp il quale riassegna tutti gli indirizzi IP virtuali agli indirizzi hardware NIC (indirizzo MAC) del nodo di backup, invia un comando al router attivo tramite l'interfaccia di rete privata e pubblica per arrestare il demone lvs sul router attivo, ed avvia il demone lvs sul nodo di backup per accettare 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

Questo è il processo di controllo in grado di avviare tutti gli altri demoni relativi ai router LVS. Al momento dell'avvio, il demone viene avviato dallo script /etc/rc.d/init.d/pulse. Successivamente legge 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 attraverso l'esecuzione di un heartbeat semplice in un intervallo configurato dall'utente. Se il router attivo non risponde dopo il suddetto intervallo, verrà iniziato un processo di failover. Durante questo processo, il demone pulse sul router attivo, indica di arrestare tutti i servizi LVS, avvia il programma send_arp per riassegnare gli indirizzi IP floating all'indirizzo MAC del router di backup, ed avvia il demone lvs.

1.6.1.2. lvs

Una volta chiamato da pulse il demone lvs viene eseguito sul router LVS attivo, legge il file di configurazione /etc/sysconfig/ha/lvs.cf, chiama l'utilità ipvsadm per compilare e mantenere la tabella d'instradamento IPVS, e assegna un processo nanny per ogni servizio Load Balancer Add-On configurato. Se nanny riporta che un real server è inattivo, lvs indica alla utilità ipvsadm di rimuovere il real server dalla tabella d'instradamento 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 richiamando ipvsadm per aggiungere, modificare e cancellare le voci all'interno della tabella d'instradamento IPVS.

1.6.1.4. nanny

Il demone di monitoraggio nanny viene eseguito su ogni router LVS attivo. Attrverso questo demone il router attivo determina lo stato di ogni real server e, facoltativamente, monitorizza il carico di lavoro. 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 del 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 del Load Balancer Add-On. Esso è il tool di default per il mantenimento del file di configurazione Load Balancer Add-On /etc/sysconfig/ha/lvs.cf.

1.6.1.7. send_arp

Questo programma invia le trasmissioni ARP quando l'indirizzo IP floating cambia da un nodo ad un altro durante il failover.
Capitolo 2, Configurazione Load Balancer Add-On iniziale ricontrolla le fasi più importanti relative alla configurazione post-installazione da seguire prima della configurazione di Red Hat Enterprise Linux per essere un router LVS.

Capitolo 2. Configurazione Load Balancer Add-On iniziale

Dopo aver installato Red Hat Enterprise Linux, è necessario seguire alcuni processi di base per poter impostare i router LVS ed i real server. Questo capitolo affronta in dettaglio le suddette fasi.

Nota Bene

Il nodo del router LVS che diventa attivo una volta avviato il Load Balancer Add-On, chiamato anche nodo primario. Quando configurate il Load Balancer Add-On, utilizzate il Piranha Configuration Tool sul nodo primario.

2.1. Configurazione dei servizi sui router LVS

Il programma d'installazione di Red Hat Enterprise Linux installa tutti i componenti necessari per l'impostazione del Load Balancer Add-On ma i servizi appropriati dovranno essere attivati prima di eseguire la sua configurazione. Per entrambi i router LVS, impostate i servizi appropriati in modo da avviarli al momento del boot. A tal proposito sono disponibili con Red Hat Enterprise Linux tre tool primari per l'impostazione dei servizi, e quindi per la loro attivazione al momento dell'avvio: il programma della linea di comando chkconfig, il programma basato su ncurses ntsysv, ed il Services Configuration Tool grafico. I suddetti tool richiedono un accesso root.

Nota Bene

Per ottenere un accesso root aprite un prompt della shell ed utilizzate il comando su - seguito dalla password di root. Per esempio:
$ su - root password
Sui router LVS sono presenti tre servizi i quali dovranno essere impostati per una loro attivazione al momento dell'avvio:
  • Il servizio piranha-gui (solo sul nodo primario)
  • Il servizio pulse
  • Il servizio sshd
Se state eseguendo il clustering dei servizi multi-port o se state utilizzando i firewall mark, sarà necessario abilitare anche il servizio iptables.
Vi consigliamo d'impostare questi servizi in modo da attivarli sui runlevel 3 e 5. Per eseguire quanto sopra descritto utilizzando il comando chkconfig, digitate quanto segue per ogni servizio:
/sbin/chkconfig --level 35 daemon on
Nel comando descritto, sostituite daemon con il nome del servizio che state attivando. Per ottenere un elenco dei servizi sul sistema ed il runlevel sul quale verranno attivati, emettete il seguente comando:
/sbin/chkconfig --list

Avvertenza

L'abilitazione di qualsiasi servizio sopra descritto utilizzando chkconfig non avvierà il demone. Per avviarlo usate il comando /sbin/service. Consultate la Sezione 2.3, «Avvio del servizio del Piranha Configuration Tool» per un esempio su come utilizzare il comando /sbin/service.
Per maggiori informazioni sui runlevel e su come configurare i servizi con ntsysv e Services Configuration Tool, consultate il capitolo intitolato "Controllo dell'accesso ai servizi" nella Red Hat Enterprise Linux System Administration Guide.

2.2. Impostazione della password per il 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.

Avvertenza

Per rendere una password più sicura essa non dovrebbe contenere nomi comuni, acronimi usati frequentemente o parole presenti in qualsiasi dizionario. È vivamente sconsigliato lasciare la password non cifrata sul sistema.
Se la password viene modificata durante una sessione attiva del Piranha Configuration Tool, verrà richiesto all'amministratore di fornire la nuova password.

2.3. Avvio del servizio del Piranha Configuration Tool

Dopo aver impostato la password per il Piranha Configuration Tool, avviate o riavviate il servizio piranha-gui situato in /etc/rc.d/init.d/piranha-gui. Per fare questo digitate il seguente comando come utente root:
/sbin/service piranha-gui start
o
/sbin/service piranha-gui restart
L'utilizzo di questo comando avvierà una sessione privata di Apache HTTP Server attraverso il link simbolico /usr/sbin/piranha_gui -> /usr/sbin/httpd. Per ragioni di sicurezza la versione piranha-gui di httpd viene eseguita come utente piranha in un processo separato. Il fatto stesso che piranha-gui fà leva sul servizio httpd stà a significare che:
  1. Apache HTTP Server deve essere installato sul sistema.
  2. L'arresto o il riavvio di Apache HTTP Server tramite il comando service, arresterà il servizio piranha-gui.

Avvertenza

Se il comando /sbin/service httpd stop o /sbin/service httpd restart viene emesso su di un router LVS, sarà necessario avviare il servizio piranha-gui tramite 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 il Load Balancer Add-On in modo remoto sarà necessario anche il servizio sshd. Non sarà necessario avviare il servizio pulse fino a quando non completerete la configurazione tramite il Piranha Configuration Tool. Per maggiori informazioni sul servizio pulse consultate la Sezione 4.8, «Avvio del Load Balancer Add-On».

2.3.1. Come configurare la Porta del Web Server del 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, aprite 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 vostro browser si collega al Piranha Configuration Tool sarà necessario registrarsi per poter accedere ai servizi di configurazione. Inserite piranha nel campo Nome utente insieme al set di password con 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 al Piranha Configuration Tool

Il Piranha Configuration Tool ha bisogno di una combinazione valida di nome utente e password. Tuttavia, tutti i dati passati 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 default 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/2 saranno in grado di accedere al Piranha Configuration Tool.

Avvertenza

La modifica del file .htaccess del Piranha Configuration Tool 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. Abilitazione del Packet Forwarding

Per permettere al router LVS di inoltrare i pacchetti di rete in modo corretto ai real server, è 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 del 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 dovrebbe avere almeno due sistemi membri.
Il gruppo del router LVS dovrebbe consistere in 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 del real server è necessario determinare quale tipologia di Load Balancer Add-On usare.

3.1. La rete NAT Load Balancer Add-On

La tipologia NAT vi 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 in entrata e in uscita attraverso il router Load Balancer Add-On.
Struttura della 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 almeno 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 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.
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, risultano essere per gli indirizzi IP reali di un router LVS e non gli indirizzi IP floating. Per configurare gli indirizzi IP floating privato e pubblico, l'amministratore deve utilizzare Piranha Configuration Tool, come mostrato in Sezione 4.4, «IMPOSTAZIONI GLOBALI» e Sezione 4.6.1, «La sottosezione VIRTUAL SERVER».
Dopo aver configurato le interfacce di rete per il nodo del router LVS primario, configurate le interfacce della rete reale — 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 Bene

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.8.
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

Avvertenza

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, «Abilitazione del Packet Forwarding» 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 del Load Balancer Add-On con il Piranha Configuration Tool.

Avvertenza

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, «La sottosezione VIRTUAL SERVER».
Una volta terminato avviate il servizio pulse come riportato in Sezione 4.8, «Avvio del 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 un 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.
Struttura della 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 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 necessita 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 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 server.
Utilizzando il metodo arptables_jf le applicazioni potrebbero legarsi ad ogni VIP o porta, 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 i tool 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:
  1. 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 bound per 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.
  2. 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.
  3. 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 la 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.
  4. Configurate Piranha per l'instradamento diretto. Per maggiori informazioni consultate il Capitolo 4, Configurazione del Load Balancer Add-On con il 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 usando il metodo iptables. Per esempio, non è possibile eseguire due servizi Apache HTTP Server separati ma uniti alla porta 80, poichè entrambi devono essere uniti a INADDR_ANY invece degli indirizzi IP virtuali.
Per configurare l'instradamento diretto utilizzando il metodo iptables, seguite le fasi di seguito riportate:
  1. 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.
  2. 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 tale operazione usando un'applicazione grafica come ad esempio system-config-network, oppure modificando manualmente gli script di rete. Per maggiori informazioni su come aggiungere i dispositivi utilizzando system-config-network, consultate 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 del loro 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

Avvertenza

Non usate gli script ifup per attivare gli indirizzi IP floating configurati con Piranha Configuration Tool (eth0:1 o eth1:1). Utilizzate invece il comando service per avviare pulse (consultate la Sezione 4.8, «Avvio del Load Balancer Add-On» per 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 e 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 emettete il seguente comando:
/sbin/route

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, «La sottosezione VIRTUAL SERVER».
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 assegnare i firewall mark. 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/modprobe ip_tables
/sbin/iptables -t mangle -A PREROUTING -p tcp -d n.n.n.n/32 --dport 80 -j MARK --set-mark 80
/sbin/iptables -t mangle-A PREROUTING -p tcp -d n.n.n.n/32 --dport 443 -j MARK --set-mark 80
Per istruzioni su come assegnare il VIP all'interfaccia di rete pubblica, consultate la Sezione 4.6.1, «La sottosezione VIRTUAL SERVER». 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 ed inoltrato in modo appropriato.

Avvertenza

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 un collegamento attivo viene stabilito 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 vengono poi 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 Bene

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. Com' è possibile interessare l'instradamento Load Balancer Add-On

L'inoltro del pacchetto da parte di IPVS abilita solo i collegamenti in ingresso ed 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 ad internet utilizzando le regole di filtraggio dei pacchetti di rete.

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 ed 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, «La sottosezione VIRTUAL SERVER» per maggiori informazioni.

3.5.3.1. Regole per collegamenti attivi

Le regole per i collegamenti attivi indicano al kernel di accettare ed 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.

Avvertenza

Se state limitando 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
Altresì è necessario controllare l'indirizzo mostrato dal server al client per i collegamenti FTP passivi. In un sistema Load Balancer Add-On con un instradamento NAT, aggiungete la seguente riga su /etc/vsftpd.conf, per sovrascrivere l'indirizzo IP del real server sul VIP, il quale viene visualizzato dal client al momento del collegamento. Per esempio:
pasv_address=n.n.n.n
Sostituite n.n.n.n con l'indirizzo VIP del sistema LVS.
Per la configurazione di altri server FTP, consultate le rispettive documentazioni.
Questa gamma dovrebbe essere sufficientemente grande per la maggior parte delle situazioni; 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 ed 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 esser sostituito con l'IP floating per il virtual server FTP, definito nella sottosezione VIRTUAL SERVER di Piranha Configuration Tool.

Avvertenza

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 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 sui 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
Esso salverà le impostazioni in /etc/sysconfig/iptables, e potranno essere richiamate al momento dell'avvio.
Una volta scritto 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 Sezione 2.3, «Avvio del servizio del 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 sui 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 del Load Balancer Add-On con il 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

Per poter utilizzare il Piranha Configuration Tool il servizio piranha-gui deve essere in esecuzione sul router LVS primario. Per configurare Load Balancer Add-On sarà necessario almeno un web browser di solo testo, come ad esempio links. Se desiderate accedere al router LVS da un'altra machcina, allora avrete bisogno anche di un collegamento ssh per il 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 ed 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 della password per il 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, «Il pannello di benvenuto».
Il pannello di benvenuto

Figura 4.1. Il pannello di benvenuto


Fate clic sul pannello Login ed inserite piranha per il Nome utente, e la password amministrativa da voi creata nel campo Password.
Il Piranha Configuration Tool è costituito da quattro schermate principali o pannelli. In aggiunta, il pannello Virtual Server contiene quattro sottosezioni. Il pannello CONTROLLO/MONITORAGGIO è il primo pannello dopo la schermata di registrazione.

4.3. CONTROLLO/MONITORAGGIO

Il pannello CONTROLLO/MONITORAGGIO presenta all'amministratore uno stato di runtime limitato del Load Balancer Add-On. Esso contiene lo stato del demone pulse, la tabella per il routing LVS, ed i processi nanny generati da LVS.

Nota Bene

I campi TABELLA PER L'INSTRADAMENTO LVS CORRENTE e PROCESSI LVS CORRENTI resteranno vuoti fino a quando non avvierete il Load Balancer Add-On, come mostrato in Sezione 4.8, «Avvio del Load Balancer Add-On».
Il pannello CONTROLLO/MONITORAGGIO

Figura 4.2. Il pannello CONTROLLO/MONITORAGGIO


Aggiornamento automatico
Lo stato riportato in questa pagina può essere aggiornato automaticamente ad un intervallo configurato dall'utente. Per abilitare questa funzione fate clic sulla casella Aggiornamento automatico, ed impostate la frequenza di aggiornamento desiderata nella casella di testo Frequenza di aggiornamento in secondi (il valore di default è 10 secondi).
Non è consigliato impostare l'aggiornamento automatico ad un intervallo inferiore a 10 secondi. Se l'intervallo è inferiore a dieci secondi, sarà molto difficile riconfigurare l'intervallo per l'Aggiornamento automatico poichè la pagina verrà aggiornata troppo frequentemente. Se incontrate questo problema, fate clic su di un pannello diverso per poi riselezionare CONTROLLO/MONITORAGGIO.
La funzione Aggiornamento automatico non funziona con tutti i browser, come ad esempio Mozilla.
Aggiorna ora le informazioni
È possibile aggiornare manualmente le informazioni sullo stato facendo clic su questo pulsante.
MODIFICA PASSWORD
Facendo clic su questo pulsante verrete direzionati sulla schermata d'aiuto, la quale contiene le informazioni utili per modificare la password amministrativa per il Piranha Configuration Tool.

4.4. IMPOSTAZIONI GLOBALI

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

Figura 4.3. Il pannello IMPOSTAZIONI GLOBALI


La metà superiore di questo pannello imposta le interfacce di rete privata e pubblica del router LVS primario. Esse sono le interfacce già configurate in Sezione 4.8, «Avvio del Load Balancer Add-On».
IP pubblico del server primario
In questo campo inserite l'indirizzo IP reale instradabile pubblicamente 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 Bene

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 Bene

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.
Usa tipo di rete
Fate clic su NAT per selezionare un instradamento NAT.
Fate clic su Instradamento diretto per selezionare l'instradamento diretto.
I tre campi successivi affrontano in modo specifico l'interfaccia di rete virtuale del router NAT, che collega la rete privata con i real server. I suddetti campi non riguardano il tipo di rete per l'instradamento diretto.
IP router NAT
Inserite in questo campo l'IP floating privato. Il suddetto IP floating dovrebbe essere usato come gateway per i real server.
Maschera di rete del router NAT
Se l'IP floating del router NAT necessita di una maschera di rete particolare, selezionatela dall'elenco a tendina.
Dispositivo 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 Bene

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.

Avvertenza

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 vi permette di configurare il nodo del router LVS di backup, e d'impostare diverse opzioni per il monitoraggio dell'heartbeat.

Nota Bene

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 a Figura 4.4, «Il pannello RIDONDANZA».
Il pannello RIDONDANZA

Figura 4.4. Il pannello RIDONDANZA


IP pubblico del server ridondante
Inserite l'indirizzo IP reale pubblico per il nodo del router LVS di backup.
IP privato del server ridondante
Inserite in questo campo l'indirizzo IP reale privato del nodo di backup.
Se non siete in grado di visualizzare il campo chiamato IP privato del server ridondante, tornate sul pannello IMPOSTAZIONI GLOBALI ed 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 morto dopo (secondi)
Se il nodo LVS primario non risponde dopo questo intervallo in 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.

Avvertenza

Ricordate di selezionare il pulsante ACCETTA dopo aver eseguito qualsiasi modifica in questo pannello in modo da non perdere le modifiche fatte durante la selezione di un nuovo pannello.

4.6. VIRTUAL SERVER

Il pannello VIRTUAL SERVER visualizza le informazioni per ogni virtual server attualmente definito. Ogni voce della tabella mostra lo stato del virtual server, il nome del server, l'indirizzo IP assegnato al server, la maschera di rete dell'IP virtuale, il numero della porta attraverso la quale il servizio comunica, il protocollo usato e l'interfaccia del dispositivo virtuale.
Il pannello VIRTUAL SERVER

Figura 4.5. Il pannello VIRTUAL SERVER


Ogni server presente nel pannello VIRTUAL SERVER può essere configurato sulle sottoschermate seguenti o sottosezioni.
Per aggiungere un servizio fate clic su AGGIUNGI. Per rimuovere un servizio, selezionatelo attraverso il pulsante di selezione situato accanto al virtual server, e successivamente fate clic su CANCELLA.
Per abilitare o disabilitare un virtual server nella tabella, fate clic sul pulsante di selezione e successivamente su (DIS)ATTIVA.
Dopo aver aggiunto un virtual server sarà possibile configurarlo tramite il pulsante di selezione situato sulla sinistra, e successivamente tramite la selezione del pulsante MODIFICA per visualizzare la sottosezione VIRTUAL SERVER.

4.6.1. La sottosezione VIRTUAL SERVER

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

Figura 4.6. La sottosezione VIRTUAL SERVER


Nome
Inserite un nome descrittivo per identificare il virtual server. 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
Scegliete 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 virtual server.
Maschera di rete dell'IP virtuale
Impostate la maschera di rete per questo virtual server 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 virtual server 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.

Avvertenza

Inserendo un firewall mark in questo campo permetterete a IPVS di riconoscere che i pacchetti relativi a questo firewall mark vengono trattati allo stesso modo, sarà comunque necessario eseguire una ulteriore configurazione esterna al Piranha Configuration Tool per assegnare i firewall mark. Cosnultate 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 virtual server FTP ad elevata disponibilità.
Dispositivo
Inserite il nome del dispositivo di rete al quale desiderate legare 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 morto e quindi rimosso dal gruppo.
Server Quiesce
Quando il pulsante di selezione del server Quiesce viene selezionato, ogni qualvolta un nodo del real server risulta online la tabella delle least-connection viene azzerata. In questo modo il router LVS attivo instrada le richieste come se tutti i real server sono stati appena aggiunti al cluster. Questa opzione impedisce ad un nuovo server di bloccarsi a causa di un elevato numero di collegamenti subito dopo l'ingresso in un gruppo.
Tool di monitoraggio del carico
Il router LVS è in grado di monitorare il carico sui diversi real server attraverso l'utilizzo di rup o ruptime. Se rup viene selezionato dal menù a tendina, ogni real server deve eseguire il servizio rstatd. Se invece selezionate ruptime, ogni real server deve eseguire il servizio rwhod.

Avvertenza

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.
Scheduling
Selezionate il vostro algoritmo di scheduling 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 scheduling».
Persistenza
Se un amministratore ha bisogno di collegamenti persistenti per il virtual server 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 virtual server con il firewall mark. Per maggiori informazioni sulla persistenza e firewall mark, consultate la Sezione 1.5, «Persistenza e Firewall mark».
Maschera di rete della persistenza
Per limitare la persistenza su sottoreti particolari, selezionate la maschera di rete appropriata dal menù a tendina.

Nota Bene

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.

Avvertenza

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

4.6.2. Sottosezione REAL SERVER

Facendo clic sul link REAL SERVER nella parte alta del pannello, verrà visualizzata la sottosezione MODIFICA REAL SERVER. Essa mostra lo stato degli host del server fisico per un servizio virtuale particolare.
Sottosezione REAL SERVER

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 su CANCELLA. Fate clic sul pulsante MODIFICA per caricare il pannello MODIFICA REAL SERVER, come riportato in Figura 4.8, «Il pannello di configurazione del REAL SERVER».
Il pannello di configurazione del REAL SERVER

Figura 4.8. Il pannello di configurazione del REAL SERVER


Questo pannello consiste in tre campi:
Nome
Un nome descrittivo per il real server.

Nota Bene

Questo nome non è l'hostname per la macchina, quindi rendetelo descrittivo e facilmente identificabile.
Indirizzo
L'indirizzo IP del real server. Poichè la porta d'ascolto è stata già specificata per il virtual server associato, non aggiungete alcun numero per la porta.
Weight
Un valore intero il quale indica la capacità di questo host in relazione a quella di altri host presenti nel gruppo. Il valore può essere arbitrario ma consideratelo come un rapporto in relazione ad altri real server presenti nel gruppo. Per maggiori informazioni sul peso del server consultate la Sezione 1.3.2, «Peso del server e scheduling».

Avvertenza

Ricordate di selezionare il pulsante ACCETTA dopo aver eseguito qualsiasi modifica in questo pannello, in modo da non perdere le modifiche fatte 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 send/expect, per verificare che il servizio per il virtual server sia in funzione su ogni real server. Qui l'amministratore può anche specificare script personalizzati per controllare i servizi che richiedono una modifica dinamica dei dati.
La sottosezione MODIFICA SCRIPT DI MONITORAGGIO

Figura 4.9. La sottosezione MODIFICA SCRIPT DI MONITORAGGIO


Programma mittente
Per una verifica del servizio più avanzata è possibile utilizzare questo campo per specificare il percorso per uno script verifica-servizio. Questa funzionalità è molto utile per i servizi che richiedono la modifica dinamica dei dati, come ad esempio HTTPS o SSL.
Per utilizzare questa funzione è necessario scrivere uno script in grado di ritornare una risposta testuale, impostatelo per essere eseguibile e digitate il percorso nel campo Programma mittente.

Nota Bene

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-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 Bene

Se viene inserito all'interno del campo Programma mittente un programma esterno, allora il campo Invio viene ignorato.
Invio
Inserite in questo campo una stringa per il demone nanny da inviare ad ogni real server. Per default il campo invio viene completato per HTTP. Potrete alterare questo valore a seconda delle vostre necessità. Se lasciate questo campo vuoto, il demone nanny cercherà di aprire la porta, e se avrà successo, assumerà che il servizio sia in esecuzione.
In questo campo è permesso solo una sequenza di invio, e può contenere solo caratteri stampabili, ASCII, insieme ai seguenti caratteri di escape:
  • \n per nuove righe.
  • \r per il ritorno a capo del cursore.
  • \t per tab.
  • \ per eseguire l'escape del carattere successivo.
Eccetto
Inserite una risposta testuale che il server deve ritornare se funziona correttamente. Se avete compilato il vostro programma mittente, inserite la risposta da inviare in caso di successo.

Nota Bene

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.

Avvertenza

Ricordate di selezionare il pulsante ACCETTA dopo aver eseguito qualsiasi modifica in questo pannello, in modo da non perdere le modifiche fatte durante la selezione di un nuovo pannello.
Una volta completata la configurazione dei virtual server 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.
I file includono:
  • /etc/sysconfig/ha/lvs.cf — il file di configurazione per i router LVS.
  • /etc/sysctl — il file di configurazione oltre ad altre funzioni abilita il packet forwarding 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 da voi utilizzato.

Importante

I file /etc/sysctl.conf e /etc/sysconfig/iptables non cambiano quando configurate il Load Balancer Add-On utilizzando 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.

Avvertenza

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 ciò è quello di utilizzare il comando scp.

Importante

Per poter usare scp, sshd deve essere in esecuzione sul router di backup, a tal proposito consultate la Sezione 2.1, «Configurazione dei servizi sui router LVS» per informazioni su come configurare i servizi necessari sui router LVS.
Emettete 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 delle situazioni il file sysctl viene modificato solo una volta. Questo file viene letto al momento dell'avvio ed indica al kernel di abilitare il packet forwarding.

Importante

Se non siete sicuri di aver abilitato il packet forwarding consultate la Sezione 2.5, «Abilitazione del Packet Forwarding» per maggiori informazioni su come controllare e, se necessario, abilitare questa funzione molto importante.

4.7.3. Sincronizzazione delle regole di filtraggio dei pacchetti di rete

Se state utilizzando iptables avrete bisogno di 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 ed avviato i servizi appropriati (consultate la Sezione 2.1, «Configurazione dei servizi sui router LVS» per maggiori informazioni su questo argomento), potrete avviare il Load Balancer Add-On.

4.8. Avvio del 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, digitate 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 risulterà in esecuzione.

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 high-availability 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.
Load Balancer Add-On con un High Availability Add-On

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 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 del 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, ed 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 può essere rimosso; Load Balancer Add-On continua ad eseguire il bilanciamento del carico attraverso un set più piccolo di web server.

Cronologia della revisione

Diario delle Revisioni
Revisione 6-3.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
Revisione 6-32012-07-18Anthony Towns
Rebuild for Publican 3.0
Revisione 1.0-0 Wed Nov 10 2010Paul Kennedy
Release iniziale del libro per Red Hat Enterprise Linux 6

Indice analitico

Simboli

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

C

chkconfig, Configurazione dei servizi sui router LVS
cluster
utilizzo del Load Balancer Add-On con High Availability Add-On, Come usare il Load Balancer Add-On con High Availability Add-On
commento, Commenti
componenti
del 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
ed il Load Balancer Add-On, Come usare il Load Balancer Add-On con High Availability Add-On
utilizzo del Load Balancer Add-On con, Come usare il Load Balancer Add-On con High Availability Add-On

I

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 di Red Hat Enterprise Linux, Introduzione
iptables , Configurazione dei servizi sui router LVS
ipvsadm programma, ipvsadm

L

least connections (vedi programmazione lavori, Load Balancer Add-On)
Load Balancer Add-On
avvio del Load Balancer Add-On, Avvio del Load Balancer Add-On
componenti del, Componenti di Load Balancer Add-On
configurazione iniziale, Configurazione Load Balancer Add-On iniziale
dati condivisi, Riproduzione dati e loro condivisione tra real server
demone nanny , nanny
demone pulse , pulse
file /etc/sysconfig/ha/lvs.cf , /etc/sysconfig/ha/lvs.cf
instradamento diretto
e arptables_jf, Instradamento diretto e arptables_jf
requisiti, hardware, Instradamento diretto, Load Balancer Add-On tramite un instradamento diretto
requisiti, rete, Instradamento diretto, Load Balancer Add-On tramite un instradamento diretto
requisiti, software, Instradamento diretto, Load Balancer Add-On tramite un instradamento diretto
instradamento NAT
requisiti, hardware, La rete NAT Load Balancer Add-On
requisiti, rete, La rete NAT Load Balancer Add-On
requisiti, software, La rete NAT Load Balancer Add-On
metodi di instradamento
NAT, Metodi d'instradamento
packet forwarding, Abilitazione del Packet Forwarding
Piranha Configuration Tool , Piranha Configuration Tool
presequisiti per l'instradamento, Configurazione delle interfacce di rete per il Load Balancer Add-On con NAT
programma ipvsadm, ipvsadm
programma send_arp , send_arp
programmazione lavori, Panoramica sul Load Balancer Add-On scheduling
programmazione, lavori, Panoramica sul Load Balancer Add-On scheduling
riproduzione dati, real server, Riproduzione dati e loro condivisione tra real server
router LVS
configurazione dei servizi, Configurazione Load Balancer Add-On iniziale
nodo primario, Configurazione Load Balancer Add-On iniziale
servizi necessari, Configurazione dei servizi sui router LVS
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
Red Hat Cluster Manager, Una configurazione Load Balancer Add-On a tre livelli
utilizzo di un Load Balancer Add-On con High Availability Add-On, Come usare il Load Balancer Add-On con High Availability Add-On
LVS
demone, lvs
instradamento NAT
abilitazione, Come abilitare l'instradamento NAT sui router LVS
lvs demone, lvs
panoramica di, Panoramica sul Load Balancer Add-On
real server, Panoramica sul 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 d'instradamento
network address translation (vedi NAT)

P

packet forwarding, Abilitazione del Packet Forwarding
(vedi anche Load Balancer Add-On)
Piranha Configuration Tool , Piranha Configuration Tool
CONTROLLO/MONITORAGGIO , CONTROLLO/MONITORAGGIO
impostazione di una password, Impostazione della password per il Piranha Configuration Tool
IMPOSTAZIONI GLOBALI , IMPOSTAZIONI GLOBALI
Limitare l'accesso al, Limitare l'accesso al Piranha Configuration Tool
pannello di login, Accesso al Piranha Configuration Tool
panoramica di , Configurazione del Load Balancer Add-On con il Piranha Configuration Tool
RIDONDANZA , RIDONDANZA
software necessario, Software necessario
sottosezione MODIFICA SCRIPT DI MONITORAGGIO , Sottosezione MODIFICA SCRIPT DI MONITORAGGIO
sottosezione REAL SERVER , Sottosezione REAL SERVER
sottosezione VIRTUAL SERVER , La sottosezione VIRTUAL SERVER
Firewall Mark , La sottosezione VIRTUAL SERVER
Indirizzo IP virtuale , La sottosezione VIRTUAL SERVER
Persistenza , La sottosezione VIRTUAL SERVER
Scheduling , La sottosezione VIRTUAL SERVER
VIRTUAL SERVER , VIRTUAL SERVER
piranha-passwd , Impostazione della password per il Piranha Configuration Tool
programmazione lavoro, Load Balancer Add-On, Panoramica sul Load Balancer Add-On scheduling
programmazione, lavoro (Load Balancer Add-On), Panoramica sul Load Balancer Add-On scheduling
pulse demone, pulse

R

real servers
configurazione dei servizi, Configurazione dei servizi sui real server
round robin (vedi programmazione lavori, Load Balancer Add-On)

S

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 sui router LVS
servizio pulse , Configurazione dei servizi sui router LVS
servizio sshd , Configurazione dei servizi sui router LVS
sicurezza
Piranha Configuration Tool , Limitare l'accesso al Piranha Configuration Tool
sincronizzazione dei file di configurazione, Sincronizzazione dei file di configurazione

W

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