Red Hat Enterprise Linux 5 Panoramica sul Cluster Suite

Transcript

Red Hat Enterprise Linux 5
Panoramica sul Cluster Suite
Red Hat Cluster Suite per Red Hat Enterprise Linux 5
Edizione 3
Landmann
Red Hat Cluster Suite per Red Hat Enterprise Linux 5
Edizione 3
Landmann
[email protected] m
Nota Legale
Copyright © 2009 Red Hat, Inc.
T his 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 T orvalds 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.
T he 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 Panoramica su Red Hat Cluster Suite fornisce una panoramica del Red Hat Cluster Suite per Red Hat
Enterprise Linux 5.
Indice
Indice
.Introduzione
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4. . . . . . . . . .
1. Convenzioni del documento
4
1.1. Convenzioni tipografiche
5
1.2. Convenzioni del documento
6
1.3. Note ed avvertimenti
7
2. Commenti
8
.Capitolo
. . . . . . . . .1.
. . Panoramica
. . . . . . . . . . . . .su
. . .Red
. . . . Hat
. . . . .Cluster
. . . . . . . .Suite
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9. . . . . . . . . .
1.1. Concetti di base del cluster
9
1.2. Red Hat Cluster Suite Introduction
10
1.3. Cluster Infrastructure
11
1.3.1. Cluster Management
11
1.3.2. Lock Management
12
1.3.3. Fencing
13
1.3.4. Il Cluster Configuration System
16
1.4. Gestione dei servizi High-availability
17
1.5. Red Hat GFS
20
1.5.1. Prestazione e scalabilità superiori
21
1.5.2. Prestazione, scalabilità e prezzo moderato
22
1.5.3. Risparmio e prestazione
22
1.6. Cluster Logical Volume Manager
23
1.7. Global Network Block Device
25
1.8. Linux Virtual Server
26
1.8.1. T wo-T ier LVS T opology
28
1.8.2. T hree-T ier LVS T opology
30
1.8.3. Metodi di instradamento
31
1.8.3.1. NAT Routing
31
1.8.3.2. Instradamento diretto
32
1.8.4. Persistenza e Firewall Mark
34
1.8.4.1. Persistence
34
1.8.4.2. Firewall Mark
34
1.9. T ool di amministrazione del cluster
34
1.9.1. Conga
35
1.9.2. GUI di amministrazione del cluster
37
1.9.2.1. Cluster Configuration T ool
37
1.9.2.2. Cluster Status T ool
39
1.9.3. T ool di amministrazione della linea di comando
40
1.10. GUI di amministrazione del server virtuale di Linux
41
1.10.1. CONT ROL/MONIT ORING
42
1.10.2. GLOBAL SET T INGS
43
1.10.3. REDUNDANCY
44
1.10.4. VIRT UAL SERVERS
45
1.10.4.1. Sottosezione SERVER VIRT UALE
46
1.10.4.2. Sottosezione REAL SERVER
48
1.10.4.3. EDIT MONIT ORING SCRIPT S Subsection
50
.Capitolo
. . . . . . . . .2.
. . Sommario
. . . . . . . . . . .dei
. . . .componenti
. . . . . . . . . . . . di
. . .Red
. . . . Hat
. . . . Cluster
. . . . . . . . Suite
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
............
2.1. Componenti del cluster
52
2.2. Pagine man
57
2.3. Hardware compatibile
59
. . . . . . . . . . . . della
Cronologia
. . . . . .revisione
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
............
1
.Indice
. . . . . . analitico
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
............
C
60
F
60
I
60
L
61
M
61
N
61
O
61
P
61
R
62
T
62
2
Indice
3
Introduzione
Questo documento fornisce una buona panoramica sul Red Hat Cluster Suite per Red Hat Enterprise
Linux 5, ed è organizzato nel modo seguente:
Capitolo 1, Panoramica su Red Hat Cluster Suite
Capitolo 2, Sommario dei componenti di Red Hat Cluster Suite
Anche se le informazioni presenti in questo documento sono generali, l'utente dovrebbe essere in
possesso di una conoscenza pratica avanzata con Red Hat Enterprise Linux, e capire i concetti di
computazione del server, in modo da comprendere correttamente le informazioni presenti.
Per maggiori informazioni su come utilizzare Red Hat Enterprise Linux, consultate le seguenti risorse:
Red Hat Enterprise Linux Installation Guide — Fornisce tutte le informazioni necessarie per
l'installazione di Red Hat Enterprise Linux 5.
Red Hat Enterprise Linux Deployment Guide — Fornisce tutte le informazioni necessarie per
l'impiego, la configurazione e l'amministrazione di Red Hat Enterprise Linux 5.
Per maggiori informazioni su Red Hat Cluster Suite per Red Hat Enterprise Linux 5, consultate le
seguenti risorse:
Configurazione e gestione di un Red Hat Cluster — Contiene informazioni sull'installazione,
configurazione e gestione dei componenti del Red Hat Cluster.
LVM Administrator's Guide: Configuration and Administration — Provides a description of the Logical
Volume Manager (LVM), including information on running LVM in a clustered environment.
Global File System: Configurazione e Amministrazione — Contiene informazioni su come installare,
configurare e gestire il Red Hat GFS (Red Hat Global File System).
Global File System 2: Configurazione e Amministrazione — Contiene informazioni su come installare,
configurare e gestire il Red Hat GFS (Red Hat Global File System 2).
Utilizzo del Device-Mapper Multipath — Fornisce tutte le informazioni necessarie per l'impiego del
Device-Mapper Multipath di Red Hat Enterprise Linux 5.
Utilizzo di GNBD con il Global File System — Fornisce una panoramica su come usare il Global
Network Block Device (GNBD) con Red Hat GFS.
Amministrazione del server virtuale di Linux — Fornisce le informazioni su come configurare i servizi
ed i sistemi ad alte prestazioni con il Linux Virtual Server (LVS).
Note di rilascio di Red Hat Cluster Suite — Fornisce informazioni sulla release corrente del Red Hat
Cluster Suite.
La documentazione di Red Hat Cluster Suite ed altri documenti di Red Hat sono disponibili nelle versioni
HT ML, PDF, e RPM sul CD di documentazione di Red Hat Enterprise Linux, e 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 HT ML 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.
4
Introduzione
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 m onospazio
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 m y_next_bestselling_novel nella vostra directory
di lavoro corrente, inserire il comando cat m y_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
m onospazio. 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 Sistema → Preferenze → Mouse dalla barra del menu principale per
lanciare Preferenze del Mouse. Nella scheda Pulsanti, fate clic sulla casella di dialogo
m ouse per m ancini, 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 Applicazioni → Accessori
→ Mappa del carattere dalla barra del menu principale. Selezionare successivamente
Cerca → T rova… dal menu Mappa del carattere, digitare il nome desiderato nel campo
Cerca e selezionare Successivo. Il carattere desiderato sarà evidenziato nella T abella
dei caratteri. Eseguire un doppio clic sul carattere per poterlo posizionare nel campo
T esto da copiare e successivamente fare clic sul pulsante Copia. Ritornare sul
documento e selezionare Modifica → Incolla 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.
5
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 è exam ple.com ed
il nome utente sulla macchina interessata è john, digitare ssh john@ exam ple.com .
Il comando m ount -o rem ount file-system rimonta il file system indicato. Per esempio,
per rimontare il file system /hom e, il comando è m ount -o rem ount /hom e.
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 m onospazio e così presentato:
books
books_tests
Desktop
Desktop1
documentation
downloads
drafts
images
mss
notes
photos
scripts
stuff
svgs
svn
Gli elenchi del codice sorgente sono impostati in tondo m onospazio ma vengono presentati ed
evidenziati nel modo seguente:
6
Introduzione
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.
7
2. Commenti
Se individuate degli errori, o pensate di poter contribuire al miglioramento di questa guida, contattateci
subito! Vi preghiamo di inviare un report in Bugzilla (http://bugzilla.redhat.com/bugzilla/) contro il
componente Documentazione-cluster.
Be sure to mention the document's identifier:
Cluster_Suite_Overview(EN)-5 (2008-12-11T15:49)
By mentioning this document's identifier, we know exactly which version of the guide you have.
Se avete dei suggerimenti per migliorare la documentazione, cercate di essere il più specifici possibile.
Se avete trovato un errore, vi preghiamo di includere il numero della sezione, e alcune righe di testo, in
modo da agevolare le ricerca dell'errore stesso.
8
Capitolo 1. Panoramica su Red Hat Cluster Suite
I sistemi clusterizzati forniscono affidabilità, scalabilità e disponibilità ai i servizi critici di produzione.
Utilizzando Red Hat Cluster Suite, è possibile creare un cluster in grado di far fronte alle vostre
esigenze di prestazione, high availability, di bilanciamento del carico, scalabilità, file sharing e di
risparmio. Questo capitolo fornisce una panoramica sui componenti di Red Hat Cluster Suite e le sue
funzioni, e consiste nelle seguenti sezioni:
Sezione 1.1, «Concetti di base del cluster»
Sezione 1.2, «Red Hat Cluster Suite Introduction»
Sezione 1.3, «Cluster Infrastructure»
Sezione 1.4, «Gestione dei servizi High-availability»
Sezione 1.5, «Red Hat GFS»
Sezione 1.6, «Cluster Logical Volume Manager»
Sezione 1.7, «Global Network Block Device»
Sezione 1.8, «Linux Virtual Server»
Sezione 1.9, «T ool di amministrazione del cluster»
Sezione 1.10, «GUI di amministrazione del server virtuale di Linux»
1.1. Concetti di base del cluster
Un cluster è costituito da due i più computer (chiamati nodi o membri), che operano insieme per
eseguire un compito. Sono presenti quattro tipi principali di cluster:
Storage
High availability
Bilanciamento del carico
Elevate prestazioni
I cluster storage forniscono una immagine coerente del file system sui server presenti in un cluster,
permettendo ai server stessi di leggere e scrivere simultaneamente su di un file system condiviso
singolo. Un cluster storage semplifica l'amministrazione dello storage, limitando l'installazione ed il
patching di applicazioni su di un file system. Altresì, con un file system cluster-wide, un cluster storage
elimina la necessità di copie ridondanti di dati dell'applicazione, semplificando il processo di backup e di
disaster recovery. Red Hat Cluster Suite fornisce uno storage clustering attraverso Red Hat GFS.
I cluster High-availability forniscono una disponibilità continua dei servizi tramite l'eliminazione dei così
detti single points of failure, e tramite l'esecuzione del failover dei servizi da un nodo del cluster ad un
altro nel caso in cui il nodo diventi non operativo. Generalmente i servizi presenti in un cluster highavailability leggono e scrivono i dati (tramite un file system montato in modalità di lettura-scrittura). Per
questo motivo un cluster high-availability deve essere in grado di garantire l'integrità dei dati, poichè un
nodo del cluster può assumere il controllo di un servizio da un altro nodo. La presenza di errori in un
cluster high-availability non risulta essere visibile da parte di client esterni al cluster. (I cluster highavailability sono talvolta indicati come cluster di failover.) Red Hat Cluster Suite fornisce un clustering
high-availability attraverso il proprio componente High-availability Service Management.
I cluster a bilanciamento del carico 'cluster load-balancing' inviano le richieste del servizio di rete a nodi
multipli del cluster, in modo da bilanciare il carico richiesto tra i nodi del cluster. Il bilanciamento del carico
fornisce una scalabilità molto economica, poichè è possibile corrispondere il numero di nodi in base ai
requisiti del carico. Se un nodo all'interno del cluster risulta essere non operativo, il software per il
bilanciamento del carico rileva l'errore e ridireziona le richieste ad altri nodi del cluster. Il fallimento di un
nodo nel cluster load-balancing non risulta essere visibile da parte dei client esterni al cluster. Red Hat
9
Cluster Suite fornisce un bilanciamento del carico attraverso LVS (Linux Virtual Server).
I cluster High-performance utilizzano i nodi del cluster per eseguire processi di calcolo simultanei. Un
cluster high-performance permette alle applicazioni di lavorare in parallelo aumentando così la
prestazione delle applicazioni. (I cluster High performance vengono anche identificati come cluster
computational o grid computing.)
Nota Bene
I cluster sopra citati rappresentano le configurazioni di base; in base alle vostre esigenze
potreste aver bisogno di una combinazione dei tipi di cluster appena descritti.
1.2. Red Hat Cluster Suite Introduction
Il Red Hat Cluster Suite (RHCS) è un set integrato di componenti software il quale può essere impiegato
in una varietà di configurazioni idonee per far fronte alle vostre esigenze di prestazione, high-availability,
di bilanciamento del carico, scalabilità, file sharing e di risparmio.
RHCS consists of the following major components (refer to Figura 1.1, «Red Hat Cluster Suite
Introduction»):
Infrastruttura del cluster — Fornisce le funzioni fondamentali per i nodi in modo che gli stessi
possano operare insieme come un cluster: gestione della configurazione-file, gestione
appartenenza, lock management, e fencing.
High-availability Service Management — Fornisce il failover dei servizi da un nodo del cluster ad un
altro, in caso in cui il nodo non è più operativo.
T ool di amministrazione del cluster — T ool di gestione e configurazione per l'impostazione, la
configurazione e la gestione di un cluster di Red Hat. È possibile utilizzare i suddetti tool con i
componenti dell'infrastruttura del cluster, e con componenti per la Gestione del servizio, High
availability e storage.
Linux Virtual Server (LVS) — Software di instradamento che fornisce l'IP-Load-balancing. LVM viene
eseguito su di una coppia di server ridondanti, che distribuisce le richieste del client in modo
omogeneo ai real server dietro i server LVS.
È possibile integrare con Red Hat Cluster Suite i seguenti componenti facenti parte di un pacchetto
opzionale (e non parte di Red Hat Cluster Suite):
Red Hat GFS (Global File System) — Fornisce il file system del cluster per un utilizzo con Red Hat
Cluster Suite. GFS permette ai nodi multipli di condividere lo storage ad un livello del blocco, come se
lo storage fosse collegato localmente ad ogni nodo del cluster.
Cluster Logical Volume Manager (CLVM) — Fornisce la gestione del volume del cluster storage.
Nota
When you create or modify a CLVM volume for a clustered environment, you must ensure that
you are running the clvm d daemon. For further information, refer to Sezione 1.6, «Cluster
Logical Volume Manager».
Global Network Block Device (GNBD) — Un componente ausiliario di GFS in grado di esportare uno
storage del livello del blocco su Ethernet. Esso rappresenta un modo molto economico per rendere
disponibile il suddetto storage a Red Hat GFS.
10
For a lower level summary of Red Hat Cluster Suite components and optional software, refer to
Capitolo 2, Sommario dei componenti di Red Hat Cluster Suite.
Figura 1.1. Red Hat Cluster Suite Introduction
Nota Bene
Figura 1.1, «Red Hat Cluster Suite Introduction» includes GFS, CLVM, and GNBD, which are
components that are part of an optional package and not part of Red Hat Cluster Suite.
1.3. Cluster Infrastructure
L'infrastruttura del cluster di Red Hat Cluster Suite fornisce le funzioni di base per un gruppo di
computer (chiamati nodi o membri), in modo da poter operare insieme come un cluster. Una volta
formato il cluster utilizzando l'infrastruttura del cluster stesso, è possibile utilizzare altri componenti del
Red Hat Cluster Suite, in modo da far fronte alle esigenze del proprio cluster (per esempio per
l'impostazione di un cluster per la condivisione dei file su di un file system GFS, oppure per
l'impostazione del servizio di failover). L'infrastruttura del cluster esegue le seguenti funzioni:
Cluster management
Lock management
Fencing
Gestione configurazione del cluster
1.3.1. Cluster Management
Cluster management manages cluster quorum and cluster membership. CMAN (an abbreviation for
cluster manager) performs cluster management in Red Hat Cluster Suite for Red Hat Enterprise Linux 5.
CMAN is a distributed cluster manager and runs in each cluster node; cluster management is distributed
across all nodes in the cluster (refer to Figura 1.2, «CMAN/DLM Overview»).
CMAN keeps track of cluster quorum by monitoring the count of cluster nodes. If more than half the
11
nodes are active, the cluster has quorum. If half the nodes (or fewer) are active, the cluster does not
have quorum, and all cluster activity is stopped. Cluster quorum prevents the occurrence of a "splitbrain" condition — a condition where two instances of the same cluster are running. A split-brain
condition would allow each cluster instance to access cluster resources without knowledge of the other
cluster instance, resulting in corrupted cluster integrity.
Il quorum viene determinato tramite la presenza di messaggi inviati tra i nodi del cluster via Ethernet.
Facoltativamente il quorum può essere anche determinato da una combinazione di messaggi via
Ethernet e attraverso un quorum disk. Per il quorum via Ethernet, esso consiste nel 50 per cento dei voti
del nodo più 1. Invece per un quorum tramite il quorum disk, esso consiste nelle condizioni specificate
dall'utente.
Nota Bene
Per default ogni nodo possiede un voto. Facoltativamente è possibile configurare ogni nodo in
modo da avere più di un voto.
CMAN controlla l'appartenenza tramite il monitoraggio dei messaggi provenienti da altri nodi del cluster.
Quando l'appartenenza del cluster cambia, il cluster manager invia una notifica agli altri componenti
dell'infrastruttura, i quali a loro volta intraprendono l'azione appropriata. Per esempio, se il nodo A si
unisce al cluster e monta un file system GFS già montato sui nodi B e C, allora sarà necessario per il
nodo A un journal ed un lock management aggiuntivi per poter utilizzare il file system GFS in questione.
Se il nodo non trasmette alcun messaggio entro un ammontare di tempo prestabilito il cluster manager
rimuove il nodo dal cluster, e comunica agli altri componenti dell'infrastruttura del cluster che il nodo in
questione non risulta più essere un membro. Ancora, altri componenti dell'infrastruttura del cluster
determinano le azioni da intraprendere, previa notifica, poichè il nodo non è più un membro del cluster.
Per esempio, il fencing potrebbe isolare il nodo non più membro.
Figura 1.2. CMAN/DLM Overview
1.3.2. Lock Management
Lock management is a common cluster-infrastructure service that provides a mechanism for other
cluster infrastructure components to synchronize their access to shared resources. In a Red Hat cluster,
DLM (Distributed Lock Manager) is the lock manager. As implied in its name, DLM is a distributed lock
manager and runs in each cluster node; lock management is distributed across all nodes in the cluster
(refer to Figura 1.2, «CMAN/DLM Overview»). GFS and CLVM use locks from the lock manager. GFS
uses locks from the lock manager to synchronize access to file system metadata (on shared storage).
12
CLVM uses locks from the lock manager to synchronize updates to LVM volumes and volume groups
(also on shared storage).
1.3.3. Fencing
Fencing is the disconnection of a node from the cluster's shared storage. Fencing cuts off I/O from
shared storage, thus ensuring data integrity. T he cluster infrastructure performs fencing through the
fence daemon, fenced.
Quando CMAN determina la presenza di un nodo fallito, esso lo comunica agli altri componenti
dell'infrastruttura del cluster. fenced, una volta notificata la presenza di un errore, isola il nodo in
questione. Successivamente gli altri componenti dell'infrastruttura del cluster determinano le azioni da
intraprendere — essi eseguiranno qualsiasi processo necessario per il ripristino. Per esempio, subito
dopo la notificata di un errore a DLM e GFS, essi sospendono l'attività fino a quando non accerteranno il
completamento del processo di fencing da parte di fenced. Previa conferma del completamento di tale
operazione, DLM e GFS eseguono l'azione di ripristino. A questo punto DLM rilascia i blocchi del nodo
fallito e GFS ripristina il jounal del suddetto nodo.
Fencing determina dal file di configurazione del cluster il metodo da utilizzare. Per la definizione del
suddetto metodo è necessario prendere in considerazione due elementi principali: il dispositivo fencing
ed il fencing agent. Questo programma esegue una chiamata nei confronti di un fencing agent
specificato nel file di configurazione del cluster. Il fencing agent a sua volta, isola il nodo tramite un
dispositivo di fencing. Una volta completato, il programma esegue la notifica al cluster manager.
Red Hat Cluster Suite fornisce una varietà di metodi usati per il fencing:
Power fencing — Esso è il metodo utilizzato da un controllore di alimentazione per disalimentare il
nodo non utilizzabile.
Fibre Channel switch fencing — Rappresenta il metodo attraverso il quale viene disabilitata la porta
del Fibre Channel la quale collega lo storage ad un nodo non utilizzabile.
GNBD fencing — A fencing method that disables an inoperable node's access to a GNBD server.
Altri tipi di fencing — Diversi metodi per il fencing che disabilitano l'I/O o l'alimentazione di un nodo
non utilizzabile, incluso gli IBM Bladecenters, PAP, DRAC/MC, HP ILO, IPMI, IBM RSA II, ed altro
ancora.
Figura 1.3, «Power Fencing Example» shows an example of power fencing. In the example, the fencing
program in node A causes the power controller to power off node D. Figura 1.4, «Fibre Channel Switch
Fencing Example» shows an example of Fibre Channel switch fencing. In the example, the fencing
program in node A causes the Fibre Channel switch to disable the port for node D, disconnecting node D
from storage.
13
Figura 1.3. Power Fencing Example
Figura 1.4 . Fibre Channel Switch Fencing Example
Specificare un metodo significa modificare il file di configurazione del cluster in modo da assegnare un
nome per il metodo di fencing desiderato, il fencing agent, ed il dispositivo di fencing per ogni nodo nel
cluster.
T he way in which a fencing method is specified depends on if a node has either dual power supplies or
multiple paths to storage. If a node has dual power supplies, then the fencing method for the node must
specify at least two fencing devices — one fencing device for each power supply (refer to Figura 1.5,
14
«Fencing a Node with Dual Power Supplies»). Similarly, if a node has multiple paths to Fibre Channel
storage, then the fencing method for the node must specify one fencing device for each path to Fibre
Channel storage. For example, if a node has two paths to Fibre Channel storage, the fencing method
should specify two fencing devices — one for each path to Fibre Channel storage (refer to Figura 1.6,
«Fencing a Node with Dual Fibre Channel Connections»).
Figura 1.5. Fencing a Node with Dual Power Supplies
Figura 1.6. Fencing a Node with Dual Fibre Channel Connections
15
È possibile configurare un nodo con uno o più metodi di fencing. Quando configurate un nodo per un
determinato metodo di fencing, tale metodo risulterà l'unico perseguibile per eseguire il fencing del nodo
in questione. Se configurate invece un nodo con metodi di fencing multipli, i suddetti metodi seguiranno
una determinata sequenza, da un metodo ad un altro seguendo l'ordine riportato nel file di
configurazione del cluster. Se un nodo fallisce, esso viene isolato utilizzando il primo metodo specificato
nel file di configurazione del cluster. Se il primo metodo fallisce, verrà utilizzato il metodo successivo per
quel nodo. Se nessun metodo è riuscito ad isolare il nodo, allora il processo di fencing inizierà
nuovamente seguendo l'ordine appena descritto e specificato nel file di configurazione del cluster, fino a
quando il nodo non verrà isolato con successo.
1.3.4. Il Cluster Configuration System
T he Cluster Configuration System (CCS) manages the cluster configuration and provides configuration
information to other cluster components in a Red Hat cluster. CCS runs in each cluster node and makes
sure that the cluster configuration file in each cluster node is up to date. For example, if a cluster system
administrator updates the configuration file in Node A, CCS propagates the update from Node A to the
other nodes in the cluster (refer to Figura 1.7, «CCS Overview»).
Figura 1.7. CCS Overview
Other cluster components (for example, CMAN) access configuration information from the configuration
file through CCS (refer to Figura 1.7, «CCS Overview»).
16
Figura 1.8. Accessing Configuration Information
Il file di configurazione del cluster (/etc/cluster/cluster.conf) è un file XML che descrive le
seguenti caratteristiche:
Nome del cluster — Mostra il nome del cluster, il livello della revisione del file di configurazione, e le
proprietà di base sul tempo necessario per l'esecuzione del fencing, usate quando un nodo si
unisce al cluster o viene isolato.
Cluster — Mostra ogni nodo del cluster, specificandone il nome, l'ID ed il numero di voti del quorum
del cluster insieme al metodo per il fencing corrispondente.
Fence Device — Mostra i dispositivi per il fencing nel cluster. I parametri variano a seconda del tipo di
dispositivo. Per esempio, per un controllore dell'alimentazione usato come un dispositivo per il
fencing, la configurazione del cluster definisce il nome del controllore dell'alimentazione, l'indirizzo IP
relativo, il login e la password.
Risorse gestite — Mostrano le risorse necessarie per creare i servizi del cluster. Le risorse gestite
includono la definizione dei domini di failover, delle risorse (per esempio un indirizzo IP), e dei servizi.
Insieme, le risorse gestite definiscono i servizi del cluster ed il comportamento del failover dei servizi
del cluster.
1.4. Gestione dei servizi High-availability
La gestione del servizio High-availability fornisce la possibilità di creare e gestire servizi cluster highavailability in un cluster Red Hat. Il componente principale per la gestione di un servizio high-availability
in un cluster Red Hat, rgm anager, implementa un cold failover per applicazioni commerciali. In un
cluster di Red Hat un'applicazione viene configurata con altre risorse del cluster in modo da formare un
servizio high-availability. È possibile eseguire un failover nei confronti di tale servizio da un nodo del
cluster ad un altro, senza interruzione apparente per i client. Il failover del servizio può verificarsi se un
nodo fallisce o se un amministratore di sistema del cluster muove il servizio da un nodo ad un altro (per
esempio, per una interruzione pianificata di un nodo).
Per creare un servizio high-availability, è necessario prima configurarlo all'interno del file di
configurazione del cluster. Un servizio è composto da svariate risorse. Le suddette risorse sono
costituite da blocchi di costruzione da voi creati e gestiti nel file di configurazione del cluster — per
17
esempio, un indirizzo IP, uno script di inizializzazione dell'applicazione, o una partizione condivisa di
Red Hat GFS.
You can associate a cluster service with a failover domain. A failover domain is a subset of cluster
nodes that are eligible to run a particular cluster service (refer to Figura 1.9, «Domini di failover»).
Nota Bene
I domini di failover non sono necessari per questa operazione.
Il servizio può essere eseguito su di un nodo per volta in modo da garantire l'integrità dei dati. È
possibile specificare la priorità di failover in un dominio di failover. T ale priorità consiste in una
assegnazione di un livello di priorità ad ogni nodo in un dominio di failover. Il suddetto livello determina
l'ordine di failover — determinando così il nodo sul quale un servizio del cluster deve essere eseguito in
presenza di un failover. Se non specificate alcuna priorità, allora sarà possibile eseguire il failover del
servizio su qualsiasi nodo presente nel proprio dominio di failover. Altresì, è possibile specificare se un
servizio sia limitato durante la sua esecuzione, e quindi eseguibile solo su nodi presenti nel dominio di
failover associato. (Quando associato con un dominio di failover non limitato, il servizio del cluster può
essere eseguito su qualsiasi nodo, nel caso in cui nessun membro del dominio di failover risulti
disponibile.)
In Figura 1.9, «Domini di failover», Failover Domain 1 is configured to restrict failover within that domain;
therefore, Cluster Service X can only fail over between Node A and Node B. Failover Domain 2 is also
configured to restrict failover with its domain; additionally, it is configured for failover priority. Failover
Domain 2 priority is configured with Node C as priority 1, Node B as priority 2, and Node D as priority 3. If
Node C fails, Cluster Service Y fails over to Node B next. If it cannot fail over to Node B, it tries failing
over to Node D. Failover Domain 3 is configured with no priority and no restrictions. If the node that
Cluster Service Z is running on fails, Cluster Service Z tries failing over to one of the nodes in Failover
Domain 3. However, if none of those nodes is available, Cluster Service Z can fail over to any node in
the cluster.
18
Figura 1.9. Domini di failover
Figura 1.10, «Web Server Cluster Service Example» shows an example of a high-availability cluster
service that is a web server named "content-webserver". It is running in cluster node B and is in a
failover domain that consists of nodes A, B, and D. In addition, the failover domain is configured with a
failover priority to fail over to node D before node A and to restrict failover to nodes only in that failover
domain. T he cluster service comprises these cluster resources:
Risorsa indirizzo IP — Indirizzo IP 10.10.10.201.
An application resource named "httpd-content" — a web server application init script
/etc/init.d/httpd (specifying httpd).
A file system resource — Red Hat GFS named "gfs-content-webserver".
19
Figura 1.10. Web Server Cluster Service Example
I client sono in grado di accedere al servizio del cluster tramite l'indirizzo IP 10.10.10.201, permettendo
una interazione con l'applicazione del web server, httpd-content. L'applicazione httpd-content utilizza il
file system gfs-content-webserver. Se il nodo B fallisce, il servizio del cluster content-webserver
eseguirà il failover sul nodo D. Se il nodo D non risulta disponibile o se fallito, è possibile eseguire il
failover sul nodo A. Il processo di failover si verificherà con nesuna interruzione apparente al client del
cluster. Il servizio del cluster sarà accessibile da un altro nodo tramite lo stesso indirizzo IP prima del
verificarsi del processo di failover.
1.5. Red Hat GFS
Red Hat GFS è un file system del cluster che permette ad un cluster di nodi di accedere
simultaneamente ad un dispositivo a blocchi condiviso tra i nodi. GFS è un file system nativo che
interfaccia con il livello VFS dell'interfaccia del file system del kernel di Linux. GFS impiega i metadata
distribuiti e journal multipli, per operare in maniera ottimale all'interno di un cluster. Per mantenere
l'integrità del file system, GFS utilizza un lock manager per coordinare l'I/O. Quando un nodo modifica i
dati su di un file system GFS, tale modifica sarà visibile immediatamente da parte di altri nodi del cluster
che utilizzano quel file system.
Utilizzando Red Hat GFS, è possibile ottenere l'uptime massimo dell'applicazione attraverso i seguenti
benefici:
Semplificazione della vostra infrastruttura dei dati
Installazione e aggiornamenti eseguiti una sola volta per l'intero cluster.
Elimina la necessità di copie ridondanti dei dati (duplicazione).
Abilita un accesso lettura /scrittura simultaneo dei dati da parte di numerosi client.
Semplifica il backup ed il disaster recovery (backup o ripristino di un solo file system)
20
Massimizza l'utilizzo delle risorse dello storage, e minimizza i costi di amministrazione.
Gestisce lo storage nella sua totalità invece di gestirlo tramite ogni singola partizione.
Diminuisce le necessità di spazio, eliminando la necessita di replicare i dati.
Varia la dimensione del cluster aggiungendo server o storage, durante il suo normale funzionamento.
Non è più necessario il partizionamento dello storage con tecniche complicate.
Aggiunge il server al cluster semplicemente montandoli al file system comune
I nodi che eseguono il Red Hat GFS sono configurati e gestiti tramite i tool di configurazione e gestione
del Red Hat Cluster Suite. Il Volume management viene gestito attraverso il CLVM (Cluster Logical
Volume Manager). Red Hat GFS permette una condivisione dei dati tra i nodi del GFS all'interno di un
cluster di Red Hat. GFS fornisce una panoramica singola ed uniforme sullo spazio del nome del file
system, attraverso i nodi del GFS in un cluster di Red Hat. GFS permette l'installazione e l'esecuzione
delle applicazioni senza avere una conoscenza dettagliata dell'infrastruttura dello storage. Altresì, GFS
fornisce alcune caratteristiche spesso necessarie in ambienti enterprise, come ad esempio i quota,
journal multipli ed il supporto multipath.
GFS fornisce un metodo versatile per lo storage networking basato sulle prestazioni, sulla scalabilità e
sulle esigenze economiche del vostro ambiente storage. Questo capitolo fornisce alcune informazioni di
base abbreviate come background, per aiutarvi a comprendere il GFS.
You can deploy GFS in a variety of configurations to suit your needs for performance, scalability, and
economy. For superior performance and scalability, you can deploy GFS in a cluster that is connected
directly to a SAN. For more economical needs, you can deploy GFS in a cluster that is connected to a
LAN with servers that use GNBD (Global Network Block Device) or to iSCSI (Internet Small Computer
System Interface) devices. (For more information about GNBD, refer to Sezione 1.7, «Global Network
Block Device».)
Le seguenti sezioni forniscono alcuni esempi su come implementare GFS in modo da soddisfare le
vostre esigenze di prestazione, scalabilità e di risparmio:
Sezione 1.5.1, «Prestazione e scalabilità superiori»
Sezione 1.5.2, «Prestazione, scalabilità e prezzo moderato»
Sezione 1.5.3, «Risparmio e prestazione»
Nota Bene
Gli esempi relativi all'implementazione del GFS riflettono le configurazioni di base; nel vostro caso
potreste richiedere una combinazione di configurazioni riportate con i seguenti esempi.
1.5.1. Prestazione e scalabilità superiori
You can obtain the highest shared-file performance when applications access storage directly. T he GFS
SAN configuration in Figura 1.11, «GFS with a SAN» provides superior file performance for shared files
and file systems. Linux applications run directly on cluster nodes using GFS. Without file protocols or
storage servers to slow data access, performance is similar to individual Linux servers with directly
connected storage; yet, each GFS application node has equal access to all data files. GFS supports over
300 GFS nodes.
21
Figura 1.11. GFS with a SAN
1.5.2. Prestazione, scalabilità e prezzo moderato
Multiple Linux client applications on a LAN can share the same SAN-based data as shown in Figura 1.12,
«GFS and GNBD with a SAN». SAN block storage is presented to network clients as block storage
devices by GNBD servers. From the perspective of a client application, storage is accessed as if it were
directly attached to the server in which the application is running. Stored data is actually on the SAN.
Storage devices and data can be equally shared by network client applications. File locking and sharing
functions are handled by GFS for each network client.
Figura 1.12. GFS and GNBD with a SAN
1.5.3. Risparmio e prestazione
Figura 1.13, «GFS e GNBD con uno storage collegato direttamente» shows how Linux client applications
can take advantage of an existing Ethernet topology to gain shared access to all block storage devices.
Client data files and file systems can be shared with GFS on each client. Application failover can be fully
22
automated with Red Hat Cluster Suite.
Figura 1.13. GFS e GNBD con uno storage collegato direttamente
1.6. Cluster Logical Volume Manager
Il Cluster Logical Volume Manager (CLVM) fornisce una versione cluster-wide di LVM2. CLVM fornisce le
stesse caratteristiche di LVM2 su di un nodo singolo, rendendo i volumi disponibili su tutti i nodi in un
cluster di Red Hat. I volumi logici creati con CLVM, rende gli stessi disponibili a tutti i nodi presenti in un
cluster.
T he key component in CLVM is clvm d. clvm d is a daemon that provides clustering extensions to the
standard LVM2 tool set and allows LVM2 commands to manage shared storage. clvm d runs in each
cluster node and distributes LVM metadata updates in a cluster, thereby presenting each cluster node
with the same view of the logical volumes (refer to Figura 1.14, «CLVM Overview»). Logical volumes
created with CLVM on shared storage are visible to all nodes that have access to the shared storage.
CLVM allows a user to configure logical volumes on shared storage by locking access to physical
storage while a logical volume is being configured. CLVM uses the lock-management service provided by
the cluster infrastructure (refer to Sezione 1.3, «Cluster Infrastructure»).
Nota Bene
Lo storage condiviso con Red Hat Cluster Suite necessita di una esecuzione del cluster logical
volume manager daemon (clvm d) o degli High Availability Logical Volume Management agent
(HA-LVM). Se non siete in grado di utilizzare il demone clvm d o HA-LVM per ragioni operative, o
perchè non siete in possesso degli entitlement corretti, è consigliato non usare il single-instance
LVM sul disco condiviso, poichè tale utilizzo potrebbe risultare in una corruzione dei dati. Per
qualsiasi problema si prega di consultare un rappresentante per la gestione dei servizi di Red
Hat.
23
Nota Bene
L'utilizzo di CLVM richiede piccole modifiche di /etc/lvm /lvm .conf per il cluster-wide locking.
Figura 1.14 . CLVM Overview
You can configure CLVM using the same commands as LVM2, using the LVM graphical user interface
(refer to Figura 1.15, «LVM Graphical User Interface»), or using the storage configuration function of the
Conga cluster configuration graphical user interface (refer to Figura 1.16, «Conga LVM Graphical User
Interface») . Figura 1.17, «Creating Logical Volumes» shows the basic concept of creating logical
volumes from Linux partitions and shows the commands used to create logical volumes.
Figura 1.15. LVM Graphical User Interface
24
Figura 1.16. Conga LVM Graphical User Interface
Figura 1.17. Creating Logical Volumes
1.7. Global Network Block Device
25
Il Global Network Block Device (GNBD) fornisce un accesso ai dispositivi a blocchi per Red Hat GFS
attraverso T CP/IP. GNBD è simile nel concetto a NBD; tuttavia GNBD è specifico al GFS, e viene regolato
solo per un suo utilizzo con il GFS. GNBD è utile se è necessario utilizzare tecnologie più robuste, il
Fibre Channel o lo SCSI single-initiator non sono necessari o presentano costi proibitivi.
GNBD consists of two major components: a GNBD client and a GNBD server. A GNBD client runs in a
node with GFS and imports a block device exported by a GNBD server. A GNBD server runs in another
node and exports block-level storage from its local storage (either directly attached storage or SAN
storage). Refer to Figura 1.18, «Panoramica di GNBD». Multiple GNBD clients can access a device
exported by a GNBD server, thus making a GNBD suitable for use by a group of nodes running GFS.
Figura 1.18. Panoramica di GNBD
1.8. Linux Virtual Server
Il Linux Virtual Server (LVS) è un insieme di componenti software integrati per il bilanciamento del carico
IP attraverso un set di real server. LVS viene eseguito su di una coppia di computer configurati in modo
simile: un router LVS attivo ed un router LVS di backup. Il router LVS attivo viene utilizzato per:
Bilanciare il carico attraverso i real server.
Controllare l'integrità dei servizi su ogni real server.
Il router LVS di backup monitorizza il router LVS attivo, sostituendolo nel caso in cui il router LVS attivo
fallisce.
Figura 1.19, «Components of a Running LVS Cluster» provides an overview of the LVS components and
their interrelationship.
26
Figura 1.19. Components of a Running LVS Cluster
Il demone pulse viene eseguito sia sul router LVS attivo che su quello passivo. Sul router LVS di
backup, pulse invia un heartbeat all'interfaccia pubblica del router attivo, in modo da assicurarsi che il
router LVS attivo funzioni correttamente. Sul router LVS attivo, pulse avvia il demone lvs, e risponde
alle interrogazioni heartbeat provenienti dal router LVS di backup.
Una volta avviato, il demone lvs chiama l'utilità ipvsadm per configurare e gestire la tabella
d'instradamento IPVS (IP Virtual Server) nel kernel, e successivamente avvia un processo nanny per
ogni server virtuale configurato su ogni real server. Ogni processo nanny controlla lo stato di un
servizio configurato su di un real server, ed indica al demone lvs se è presente un malfunzionamento
del servizio su quel real server. Se tale malfunzionamento viene rilevato, il demone lvs indica a
ipvsadm di rimuovere il real server in questione dalla tabella d'instradamento di IPVS.
Se il router LVS di backup non riceve alcuna risposta dal router LVS attivo, esso inizia un processo di
failover attraverso la chiamata send_arp, riassegnando tutti gli indirizzi IP virtuali agli indirizzi hardware
NIC (indirizzo MAC) del router LVS di backup, ed inviando un comando al router LVS attivo tramite
l'interfaccia di rete privata e quella pubblica in modo da interrompere il demone lvs sul router LVS attivo.
A questo punto verrà avviato il demone lvs sul router LVS di backup ed accettate tutte le richieste per i
server virtuali configurati.
Per un utente esterno che accede ad un servizio hosted (come ad esempio le applicazioni databese o
website), LVS può apparire come un unico server. T uttavia l'utente accede ai real server situati oltre i
router LVS.
Poichè non è presente alcun componente interno a LVS per condividere i dati tra i server reali, sono
disponibili due opzioni di base:
La sincronizzazione dei dati attraverso i real server.
L'aggiunta di un terzo livello alla topologia per l'accesso dei dati condivisi.
Verrà utilizzata la prima opzione per i server che non permettono un numero di utenti molto grande per
27
caricare o modificare i dati sui real server. Se i real server permettono un numero esteso di utenti per la
modifica dei dati, come ad esempio un sito web e-commerce, allora sarà preferita l'aggiunta di un terzo
livello.
Sono disponibili diverse modalità per la sincronizzazione dei dati tra i real server. Per esempio è
possibile utilizzare gli script della shell per postare simultaneamente le pagine web aggiornate sui real
server. Altresì è possibile utilizzare programmi come rsync, per replicare i dati modificati attraverso tutti
i nodi in un intervallo di tempo determinato. T uttavia in ambienti dove gli utenti caricano spesso file o
emettono transazioni del database, l'utilizzo di script o del comando rsync per la sincronizzazione dei
dati, non funzionerà in maniera ottimale. Per questo motivo per real server con un numero di upload
molto elevato, e per transazioni del database o di traffico simile, una topologia three-tiered risulta essere
più appropriata se desiderate sincronizzare i dati.
1.8.1. Two-Tier LVS Topology
Figura 1.20, «T wo-T ier LVS T opology» shows a simple LVS configuration consisting of two tiers: LVS
routers and real servers. T he LVS-router tier consists of one active LVS router and one backup LVS
router. T he real-server tier consists of real servers connected to the private network. Each LVS router
has two network interfaces: one connected to a public network (Internet) and one connected to a private
network. A network interface connected to each network allows the LVS routers to regulate traffic
between clients on the public network and the real servers on the private network. In Figura 1.20, «T woT ier LVS T opology», the active LVS router uses Network Address Translation (NAT) to direct traffic from
the public network to real servers on the private network, which in turn provide services as requested.
T he real servers pass all public traffic through the active LVS router. From the perspective of clients on
the public network, the LVS router appears as one entity.
Figura 1.20. T wo-T ier LVS T opology
Le richieste del servizio che arrivano ad un router LVS vengono indirizzate ad un indirizzo IP virtuale o
VIP. Esso rappresenta un indirizzo instradabile pubblicamente che l'amministratore del sito associa con
un fully-qualified domain name, come ad esempio www.example.com, e assegnato ad uno o più server
virtuali [1] . Nota bene che un indirizzo IP migra da un router LVS ad un altro durante un failover,
28
mantenendo così una presenza in quel indirizzo IP, conosciuto anche come Indirizzi IP floating.
È possibile eseguire l'alias degli indirizzi VIP, sullo stesso dispositivo che esegue il collegamento del
router LVS con la rete pubblica. Per esempio, se eth0 è collegato ad internet, allora sarà possibile
eseguire l'alias dei server virtuali multipli su eth0:1. Alternativamente ogni server virtuale può essere
associato con un dispositivo separato per servizio. Per esempio, il traffico HT T P può essere gestito su
eth0:1, ed il traffico FT P gestito su eth0:2.
Solo un router LVS alla volta può essere attivo. Il ruolo del router LVS attivo è quello di ridirezionare le
richieste di servizio dagli indirizzi IP virtuali ai real server. Questo processo si basa su uno degli otto
algoritmi per il bilanciamento del carico:
Round-Robin Scheduling — Distribuisce ogni richiesta in successione all'interno di un gruppo di real
server. Utilizzando questo algoritmo, tutti i real server vengono trattati allo stesso modo, senza
considerare la loro capacità o il loro carico.
Weighted Round-Robin Scheduling — Distribuisce ogni richiesta in successione all'interno di un
gruppo di real server, dando un carico di lavoro maggiore ai server con maggiore capacità. La
capacità viene indicata da un fattore di peso assegnato dall'utente, e viene modificata in base alle
informazioni sul carico dinamico. Essa rappresenta la scelta preferita se sono presenti differenze
sostanziali di capacità dei real server all'interno di un gruppo di server. T uttavia se la richiesta di
carico varia sensibilmente, un server con un carico di lavoro molto elevato potrebbe operare oltre ai
propri limiti.
Least-Connection — Distribuisce un numero maggiore di richieste ai real server con un numero
minore di collegamenti attivi. Questo è un tipo di algoritmo di programmazione dinamico, il quale
rappresenta la scelta migliore se siete in presenza di una elevata variazione nelle richieste di carico.
Offre il meglio di se per un gruppo di real server dove ogni nodo del server presenta una capacità
simile. Se i real server in questione hanno una gamma varia di capacità, allora il weighted leastconnection scheduling rappresenta la scelta migliore.
Weighted Least-Connections (default) — Distribuisce un numero maggiore di richieste ai server con
un numero minore di collegamenti attivi, in base alle proprie capacità. La capacità viene indicata da un
peso assegnato dall'utente, e viene modificata in base alle informazioni relative al carico dinamico.
L'aggiunta di peso rende questo algoritmo ideale quando il gruppo del real server contiene un
hardware di varia capacità.
Locality-Based Least-Connection Scheduling — Distribuisce un numero maggiore di richieste ai
server con un numero minore di collegamenti attivi, in base ai propri IP di destinazione. Questo
algoritmo viene utilizzato in un cluster di server proxy-cache. Esso indirizza i pacchetti per un
indirizzo IP al server per quel indirizzo, a meno che il server in questione non abbia superato la sua
capacità e sia presente al tempo stesso un server che utilizzi metà della propria capacità. In questo
caso l'indirizzo IP verrà assegnato al real server con un carico minore.
Locality-Based Least-Connection Scheduling con Replication Scheduling — Distribuisce un numero
maggiore di richieste ai server con un numero minore di collegamenti attivi, in base ai propri IP di
destinazione. Questo algoritmo viene usato anche in un cluster di server proxy-cache. Esso
differisce da Locality-Based Least-Connection Scheduling a causa della mappatura dell'indirizzo IP
target su di un sottoinsieme di nodi del real server. Le richieste vengono indirizzate ad un server
presente in questo sottoinsieme con il numero più basso di collegamenti. Se tutti i nodi per l'IP di
destinazione sono al di sopra della propria capacità, esso sarà in grado di replicare un nuovo server
per quel indirizzo IP di destinazione, aggiungendo il real server con un numero minore di
collegamenti del gruppo di real server, al sottoinsieme di real server per quel IP di destinazione. Il
nodo maggiormente carico verrà rilasciato dal sottoinsieme di real server in modo da evitare un
processo di riproduzione non corretto.
Source Hash Scheduling — Distribuisce le richieste al gruppo di real server, cercando l'IP sorgente
in una tabella hash statica. Questo algoritmo viene usato per i router LVS con firewall multipli.
29
Altresì, il router LVS attivo monitorizza dinamicamente lo stato generale dei servizi specifici sui real
server, attraverso semplici script send/expect. Per assistervi nella rilevazione dello stato dei servizi che
richiedono dati dinamici, come ad esempio HT T PS o SSL, è possibile richiamare gli eseguibili esterni. Se
un servizio non funziona correttamente su di un real server, il router LVS attivo interrompe l'invio di lavori
al server interessato, fino a quando non vengono ripristinate le normali funzioni.
Il router LVS di backup esegue il ruolo di un sistema in standby 'attesa'. I router LVS scambiano
periodicamente messaggi heartbeat attraverso l'interfaccia pubblica esterna primaria e, in una
situazione di failover, attraverso l'interfaccia privata. Se il router LVS di backup non riceve un messaggio
heartbeat entro un intervallo di tempo determinato, esso inizierà un processo di failover assumendo così
il ruolo di router LVS attivo. Durante il processo di failover, il router LVS di backup prende a carico gli
indirizzi VIP serviti dal router fallito utilizzando una tecnica conosciuta come ARP spoofing — con questa
tecnica il router LVS di backup si presenta come destinazione per i pacchetti IP indirizzati al nodo fallito.
Quando il nodo in questione ritorna in uno stato di servizio attivo, il router LVS di backup assume il
proprio ruolo di backup.
T he simple, two-tier configuration in Figura 1.20, «T wo-T ier LVS T opology» is suited best for clusters
serving data that does not change very frequently — such as static web pages — because the
individual real servers do not automatically synchronize data among themselves.
1.8.2. Three-Tier LVS Topology
Figura 1.21, «T hree-T ier LVS T opology» shows a typical three-tier LVS configuration. In the example, the
active LVS router routes the requests from the public network (Internet) to the second tier — real
servers. Each real server then accesses a shared data source of a Red Hat cluster in the third tier over
the private network.
30
Figura 1.21. T hree-T ier LVS T opology
Questa topologia è ideale per server FT P molto occupati, dove i dati accessibili vengono conservati in
un server highly available centrale, accessibili da ogni real server tramite una directory NFS esportata o
una condivisione Samba. Questa topologia è anche consigliata per siti web in grado di accedere ad un
database high-availability centrale per le loro transazioni. In aggiunta, utilizzando una configurazione
attiva-attiva con un cluster Red Hat, è possibile configurare un cluster high-availability, in modo da
servire simultaneamente entrambi i ruoli.
1.8.3. Metodi di instradamento
È possibile utilizzare con LVS il Network Address T ranslation (NAT ) routing oppure l'instradamento
diretto. Le seguenti sezioni descrivono brevemente il NAT routing e quello diretto con LVS.
1.8.3.1. NAT Routing
Figura 1.22, «LVS Implemented with NAT Routing», illustrates LVS using NAT routing to move requests
between the Internet and a private network.
31
Figura 1.22. LVS Implemented with NAT Routing
In questo esempio sono presenti due NIC all'interno del router LVS attivo. Il NIC per Internet presenta un
indirizzo IP reale su eth0, con un indirizzo IP floating come alias su eth0:1. Il NIC per l'interfaccia di rete
privata possiede un indirizzo IP reale su eth1 ed un indirizzo IP floating come alias su eth1:1. Nell'evento
di un failover, l'interfaccia virtuale che interessa internet e quella privata che interessa l'interfaccia
virtuale, vengono controllate simultaneamente dal router LVS di backup. T utti i real server presenti sulla
rete privata, utilizzano l'IP floating per il router NAT come rotta predefinita per comunicare con il router
LVS attivo, in modo tale da non limitare le proprie capacità di rispondere alle richieste provenienti da
internet.
In the example, the LVS router's public LVS floating IP address and private NAT floating IP address are
aliased to two physical NICs. While it is possible to associate each floating IP address to its physical
device on the LVS router nodes, having more than two NICs is not a requirement.
Utilizzando questa topologia il router LVS attivo riceve la richiesta e la direziona al server appropriato.
Successivamente, il real server processa la richiesta e ritorna i pacchetti al router LVS. Il router LVS
utilizza la traduzione dell'indirizzo di rete per sostituire l'indirizzo del real server nei pacchetti, con
l'indirizzo VIP pubblico dei router LVS. Questo processo viene chiamato IP masquerading poichè gli
indirizzi IP correnti dei real server vengono nascosti ai client richiedenti.
Utilizzando il NAT routing i real server possono essere rappresentati da ogni tipo di computer sui quali
viene eseguito una verietà di sistemi operativi. Il router LVS può rappresentare lo svantaggio del NAT
routing, infatti con implementazioni molto grandi esso deve processare richieste sia in entrata che in
uscita.
1.8.3.2. Instradamento diretto
L'instradamento diretto fornisce maggiori benefici per quanto riguarda le prestazioni rispetto al NAT
routing. Esso permette ai real server di processare e direzionare i pacchetti direttamente ad un
richiedente, invece di passare i pacchetti in uscita attraverso il router LVS. L'instradamento diretto riduce
i problemi di prestazione della rete, relegando il compito del router LVS alla sola processazione dei
32
pacchetti in entrata.
Figura 1.23. LVS Implemented with Direct Routing
In una configurazione LVS direct-routing tipica, un router LVS riceve le richieste in entrata del server
attraverso un IP virtuale (VIP), ed utilizza un algoritmo di programmazione per direzionare la richiesta al
real server. Ogni real server processa le richieste ed invia le risposte direttamente ai client, bypassando
i router LVS. L'instradamento diretto permette di avere una certa scalabilità, e quindi aggiungere real
server senza aver bisogno che il router LVS direzioni i pacchetti in uscita dal real server al client,
evitando un potenziale problema in presenza di carichi di rete maggiori.
Anche se sono presenti numerosi vantaggi nell'utilizzo dell'instradamento diretto in LVS, sono presenti
alcune limitazioni. Il problema più comune tra l'instradamento diretto e LVS è rappresentato dall'Address
Resolution Protocol (ARP).
In typical situations, a client on the Internet sends a request to an IP address. Network routers typically
send requests to their destination by relating IP addresses to a machine's MAC address with ARP. ARP
requests are broadcast to all connected machines on a network, and the machine with the correct
IP/MAC address combination receives the packet. T he IP/MAC associations are stored in an ARP cache,
which is cleared periodically (usually every 15 minutes) and refilled with IP/MAC associations.
Il problema esistente con le richieste ARP in una configurazione LVS con instradamento diretto, è dovuto
alla necessità di associare una richiesta del client fatta ad un indirizzo IP, con l'indirizzo MAC per la
richiesta da gestire, l'indirizzo IP virtuale del router LVS deve anch'esso essere associato ad un MAC.
T uttavia, poichè sia il router LVS che i real server possiedono lo stesso VIP, la richiesta ARP viene
trasmessa a tutti i nodi associati con il VIP. T ale operazione potrebbe causare diversi problemi come ad
esempio la possibilità di associare il VIP direttamente ad uno dei real server, e processare la richiesta
33
direttamente bypassando completamente il router LVS, ed annullando lo scopo della configurazione LVS.
L'utilizzo di un router LVS con una CPU molto potente in grado di rispondere rapidamente alle richieste
del client, porebbe non risolvere questo problema. Se il router LVS presenta un carico molto elevato,
esso potrebbe rispondere alle richieste ARP molto più lentamente di un real server con un carico di
lavoro normale, il quale sarà in grado di rispondere più velocemente e al quale verrà assegnato il VIP
nella cache ARP del client richiedente.
Per risolvere questo problema le richieste in entrata dovrebbero solo associare il VIP al router LVS, il
quale processerà correttamente le richieste, inviandole al gruppo di real server. È possibile eseguire
questo processo utilizzando il tool arptables di filtraggio del pacchetto.
1.8.4. Persistenza e Firewall Mark
In alcune situazioni potrebbe essere più semplice per un client ricollegarsi ripetutamente allo stesso real
server, invece di avere un algoritmo di bilanciamento del carico di LVS per l'invio della richiesta al server
migliore disponibile. Esempi di quanto detto includono forme web multi-screen, cookies, SSL, e
collegamenti FT P. In questi casi un client potrebbe non funzionare correttamente a meno che le
transazioni non vengono gestite dallo stesso server che ne mantiene il contesto. LVS fornisce due
diverse funzioni in grado di gestire quanto detto: persistenza e firewall mark.
1.8.4 .1. Persistence
Quando abilitata, la persistenza funziona come un timer. Quando un client esegue il collegamento ad un
servizio, LVS ricorda l'ultimo collegamento effettuato dal client stesso per un periodo di tempo
specificato. Se lo stesso indirizzo IP del client si collega entro un determinato periodo, esso verrà inviato
allo stesso server al quale si è precedentemente collegato — bypassando così i meccanismi di
bilanciamento del carico. Se si verifica invece al di fuori del suddetto periodo, tale processo viene gestito
in base alle regole in corso.
La persistenza vi permette altresì di specificare una maschera di sottorete da applicare al test
dell'indirizzo IP del client, come tool per il controllo degli indirizzi che possiedono un elevato livello di
persistenza, e quindi raggruppando i collegamenti a quella sottorete.
Il raggruppamento dei collegamenti destinati a porte diverse, può essere importante per protocolli che
utilizzano più di una porta per le loro comunicazioni, come ad esempio FT P. T uttavia la persistenza non
rappresenta il metodo più efficace per affrontare il problema del raggruppamento dei collegamenti
destinati a porte diverse. Per queste situazioni, è consigliato utilizzare firewall mark.
1.8.4 .2. Firewall Mark
I firewall mark rappresentano un modo semplice ed efficiente per le porte di un gruppo, usate per un
protocollo o gruppo di protocolli relativi. Per esempio, se LVS viene implementato su di un sito ecommerce, i firewall mark possono essere usati per raggruppare i collegamenti HT T P sulla porta 80, e
rendere i collegamenti HT T PS sicuri sulla porta 443. Assegnando lo stesso firewall mark al server
virtuale per ogni protocollo, le informazioni sullo stato per ogni transazione possono essere preservate,
poichè il router LVS inoltra tutte le richieste allo stesso real server dopo aver aperto un collegamento.
A causa della sua efficienza e facilità d'uso, è consigliato agli amministratori di LVS l'utilizzo, quando
possibile, dei firewall mark invece della persistenza per raggruppare i collegamenti. T uttavia è
consigliato aggiungere la persistenza sui server virtuali insieme ai firewall mark, in modo da assicurarsi
che i client possono essere ricollegati allo stesso server per un periodo di tempo adeguato.
1.9. Tool di amministrazione del cluster
Red Hat Cluster Suite fornisce una varietà di tool per configurare e gestire il vostro cluster di Red Hat.
Qusta sezione fornisce una panoramica dei tool di amministrazione disponibili con Red Hat Cluster
34
Suite:
Sezione 1.9.1, «Conga»
Sezione 1.9.2, «GUI di amministrazione del cluster»
Sezione 1.9.3, «T ool di amministrazione della linea di comando»
1.9.1. Conga
Conga è un set di componenti software in grado di fornire una gestione ed una configurazione
centralizzata dello storage e dei cluster di Red Hat. Conga fornisce le seguenti funzioni:
Una interfaccia web per la gestione dello storage e del cluster
Implementazione automatizzata dei dati del cluster e pacchetti di supporto
Integrazione semplice con i cluster esistenti
Nessuna necessità di eseguire la riautenticazione
Integrazione dello stato del cluster e dei log
Controllo più meticoloso sui permessi dell'utente
I componenti primari di Conga sono luci e ricci, i quali non possono essere installati separatamente.
luci è un server eseguito su di un computer in grado di comunicare con cluster multipli e computer
tramite ricci. ricci è un agent eseguito su ogni computer (un membro del cluster o un computer
standalone) gestito da Conga.
luci è accessibile tramite un web browser e fornisce le tre funzioni più importanti accessibili attraverso
le seguenti schede:
homebase — Fornisce i tool usati per aggiungere e cancellare i computer, gli utenti e per la
configurazione dei privilegi dell'utente. Solo un amministratore di sistema è in grado di accedere a
questa scheda.
cluster — Fornisce i tool usati per la creazione e la configurazione dei cluster. Ogni istanza di luci
elenca i cluster impostati con quel luci. Un amministratore del sistema può gestire tutti i cluster
presenti su questa scheda. Altri utenti potranno amministrare solo i cluster verso i quali l'utente avrà
i permessi per la gestione (conferiti da un amministratore).
storage — Fornisce i tool per l'amministrazione remota dello storage. Con i tool presenti su questa
scheda, sarete in grado di gestire lo storage sui computer, senza considerare se essi appartengono
o meno ad un cluster.
Per amministrare un cluster o uno storage, un amministratore deve aggiungere (o registrare) un cluster
o un computer su di un server luci. Quando un cluster o un computer risultano registrati con luci,
l'hostname FQDN o indirizzo IP di ogni computer, viene conservato in un database luci.
Potete popolare il database di una istanza luci tramite un'altra istanza luci. Questa capacità fornisce un
mezzo per la replica di una istanza del server luci, e fornisce un aggiornamento efficiente insieme ad un
percorso di prova. Quando installate una istanza di luci, il suo database risulta vuoto. T uttavia è
possibile importare parte o tutto il database luci da un server luci esistente, quando implementate un
nuovo server luci.
Ogni istanza di luci presenta un utente al momento dell'installazione iniziale — admin. Solo l'utente
admin è in grado di aggiungere i sistemi ad un server luci. Altresì il suddetto utente può creare account
aggiuntivi e determinare quali utenti sono in grado di accedere ai cluster ed ai computer registrati nel
database di luci. È possibile importare gli utenti a gruppi in un nuovo server di luci, in modo simile al
processo d'importazione dei cluster e dei computer.
Quando un computer viene aggiunto ad un server luci per essere amministrato, l'autenticazione viene
35
eseguita solo una volta. Per questo motivo non è necessario alcun processo di autenticazione
supplementare (a meno che il certificato usato non venga annullato da un CA). Successivamente è
possibile configurare e gestire in modo remoto i cluster e lo storage attraverso l'interfaccia utente di luci.
luci e ricci comunicano tra loro attraverso XML.
Le seguenti figure mostrano esempi delle tre schede più importanti di luci: homebase, cluster, e
storage.
Per maggiori informazioni su Conga, consultate la Configurazione e gestione di un Red Hat Cluster, e
l'aiuto disponibile online con il server di luci.
Figura 1.24 . Scheda homebase di luci
Figura 1.25. Scheda cluster di luci
36
Figura 1.26. Scheda storage di luci
1.9.2. GUI di amministrazione del cluster
T his section provides an overview of the system -config-cluster cluster administration graphical
user interface (GUI) available with Red Hat Cluster Suite. T he GUI is for use with the cluster
infrastructure and the high-availability service management components (refer to Sezione 1.3, «Cluster
Infrastructure» and Sezione 1.4, «Gestione dei servizi High-availability»). T he GUI consists of two major
functions: the Cluster Configuration T ool and the Cluster Status T ool. T he Cluster
Configuration T ool provides the capability to create, edit, and propagate the cluster configuration file
(/etc/cluster/cluster.conf). T he Cluster Status T ool provides the capability to manage highavailability services. T he following sections summarize those functions.
Sezione 1.9.2.1, «Cluster Configuration T ool»
Sezione 1.9.2.2, «Cluster Status T ool»
1.9.2.1. Cluster Configuration T ool
You can access the Cluster Configuration T ool (Figura 1.27, «Cluster Configuration T ool») through
the Cluster Configuration tab in the Cluster Administration GUI.
37
Figura 1.27. Cluster Configuration T ool
Il Cluster Configuration T ool rappresenta i componenti di configurazione del cluster nel file di
configurazione (/etc/cluster/cluster.conf), con un display grafico gerarchico nel pannello di
sinistra. Una icona triangolare a sinistra del nome del componente, indica che il componente stesso
possiede uno o due componenti subordinati assegnati. Facendo clic sull'icona triangolare sarete in
grado di espandere o comprimere la porzione d'albero situata sotto un componente. I componenti
visualizzati nella GUI vengono riassunti nel seguente modo:
Nodi del Cluster — Visualizza i nodi del cluster. I nodi vengono rappresentati per nome come
elementi subordinati sotto Nodi del Cluster. Utilizzando i pulsanti per la configurazione della
struttura (sotto Proprietà), sarà possibile aggiungere, cancellare i nodi e modificare le loro
proprietà, configurando anche i metodi di fencing per ogni nodo.
Dispositivi Fence — Mostra i dispositivi Fence. I suddetti dispositivi vengono rappresentati
come elementi subordinati sotto Dispositivi Fence. Utilizzando i pulsanti di configurazione nella
parte inferiore della struttura (sotto Proprietà), sarà possibile aggiungere e cancellare i dispositivi
Fence, e modificarne le loro proprietà. È necessario definire questi dispositivi prima di configurare il
processo di fencing (tramite il pulsante Gestisci il fencing per questo nodo) per ogni
nodo.
Risorse gestite — Visualizza i domini di failover, le risorse ed i servizi.
Dom ini di Failover — Per la configurazione di uno o più sottoinsiemi dei nodi del cluster
usati per eseguire un servizio high-availability nell'evento del fallimento di un nodo. I domini di
failover sono rappresentati come elementi subordinati sotto i Dom ini di Failover.
Utilizzando i pulsanti per la configurazione nella parte bassa della struttura (sotto Proprietà),
38
è possibile creare i domini di failover (quando viene selezionato Dom ini di Failover, oppure
modificare le proprietà del dominio di failover (quando è stato selezionato un dominio di failover).
Risorse — Per la configurazione delle risorse condivise utilizzate dai servizi high-availability. Le
risorse condivise consistono in file system, indirizzi IP, esportazioni e montaggi NFS e script
creati dall'utente disponibili per qualsiasi servizio high-availability nel cluster. Le risorse vengono
rappresentate come elementi subordinati sotto Risorse. Utilizzando i pulsanti di configurazione
nella parte bassa della struttura (sotto Proprietà), è possibile creare le risorse (se Risorse è
stato selezionato), oppure modificare la proprietà di una risorsa (se avete selezionato una
risorsa).
Nota Bene
Il Cluster Configuration T ool fornisce la capacità di configurare le risorse private. Una
risorsa privata è una risorsa configurata per l'utilizzo con un solo servizio. È possibile
configurare una risorsa privata all'interno di un componente di Service tramite la GUI.
Servizi — Per la creazione e la configurazione di servizi high-availability. Un servizio viene
configurato attraverso l'assegnazione delle risorse (condivise o private), assegnando un dominio
di failover, e definendo una policy di ripristino per il servizio. I servizi vengono rappresentati come
elementi subordinati sotto Servizi. Utilizzando i pulsanti di configurazione nella parte bassa
della struttura (sotto Proprietà), è possibile creare i servizi (se Servizi è stato selezionato),
oppure modificare le proprietà di un servizio (se avete selezionato un servizio).
1.9.2.2. Cluster Status T ool
You can access the Cluster Status T ool (Figura 1.28, «Cluster Status T ool») through the Cluster
Management tab in Cluster Administration GUI.
39
Figura 1.28. Cluster Status T ool
I nodi ed i servizi visualizzati nel Cluster Status T ool vengono determinati dal file di configurazione del
cluster (/etc/cluster/cluster.conf). È possibile utilizzare il Cluster Status T ool per abilitare,
disabilitare, riavviare o riposizionare un servizio high-availability.
1.9.3. Tool di amministrazione della linea di comando
In addition to Conga and the system -config-cluster Cluster Administration GUI, command line
tools are available for administering the cluster infrastructure and the high-availability service
management components. T he command line tools are used by the Cluster Administration GUI and init
scripts supplied by Red Hat. T abella 1.1, «T ool della linea di comando» summarizes the command line
tools.
40
T abella 1.1. T ool della linea di comando
T ool della linea
di comando
Usato con
Scopo
ccs_tool —
T ool del sistema
di configurazione
del cluster
Cluster
Infrastructure
ccs_tool è un programma usato per creare aggiornamenti
online per il file di configurazione del cluster. Esso
conferisce la capacità di creare e modificare i componenti
dell'infrastruttura del cluster (per esempio creare un cluster,
o aggiungere e rimuovere un nodo). Per maggiori
informazioni su questo tool, consultate la pagina man di
ccs_tool(8).
cm an_tool —
T ool di gestione
del cluster
Cluster
Infrastructure
cm an_tool è un programma che gestisce il CMAN cluster
manager. Esso fornisce la possibilità di unirsi o
abbandonare un cluster, di terminare un nodo, o di
modificare i voti del quorum previsti di un nodo in un cluster.
Per maggiori informazioni su questo tool, consultate la
pagina man di cman_tool(8).
fence_tool —
T ool di Fence
Cluster
Infrastructure
fence_tool è un programma usato per unirsi o
abbandonare il dominio predefinito di fence. In modo
specifico, avviare il demone di fence (fenced), unirsi al
dominio, terminare fenced, e per abbandonare il dominio in
questione. Per maggiori informazioni su questo tool
consultate la pagina man di fence_tool(8).
clustat — Utilità
dello stato del
cluster
Componenti di
gestione del
servizio Highavailability
Il comando clustat visualizza lo status del cluster. Esso
mostra le informazioni sull'appartenenza, la vista sul
quorum e lo stato di tutti i servizi utente configurati. Per
maggiori informazioni su questo tool, consultate la pagina
man di clustat(8).
clusvcadm —
Utilità di
amministrazione
del servizio utente
del cluster
Componenti di
gestione del
servizio Highavailability
Il comando clusvcadm vi permette di abilitare, disabilitare,
riposizionare e riavviare i servizi high-availability in un
cluster. Per maggiori informazioni su questo tool, consultate
la pagina man di clusvcadm(8).
1.10. GUI di amministrazione del server virtuale di Linux
Questa sezione fornisce una panoramica del tool di configurazione LVS disponibile con il Red Hat
Cluster Suite — il Piranha Configuration T ool. Il Piranha Configuration T ool è una interfaccia
utente grafica GUI del web browser, in grado di fornire un approccio strutturato per la creazione del file
di configurazione per LVS — /etc/sysconfig/ha/lvs.cf.
Per poter accedere al Piranha Configuration T ool è necessario eseguire il servizio piranha-gui
sul router LVS attivo. È possibile accedere al Piranha Configuration T ool in modo locale o remoto
tramite un web browser. Per l'accesso locale è possibile utilizzare il seguente URL:
http://localhost:3636. Per un accesso remoto è possibile utilizzare un hostname o l'indirizzo IP
reale seguito da :3636. Se state per accedere al Piranha Configuration T ool in modo remoto, allora
avrete bisogno di un collegamento ssh per il router LVS attivo come utente root.
Starting the Piranha Configuration T ool causes the Piranha Configuration T ool welcome page to
be displayed (refer to Figura 1.29, «T he Welcome Panel»). Logging in to the welcome page provides
41
access to the four main screens or panels: CONT ROL/MONIT ORING, GLOBAL SET T INGS,
REDUNDANCY, and VIRT UAL SERVERS. In addition, the VIRT UAL SERVERS panel contains four
subsections. T he CONT ROL/MONIT ORING panel is the first panel displayed after you log in at the
welcome screen.
Figura 1.29. T he Welcome Panel
Le seguenti sezioni forniscono una breve descrizione sulle pagine di configurazione del Piranha
Configuration T ool.
1.10.1. CONTROL/MONITORING
Il pannello CONT ROLLO/MONIT ORAGGIO visualizza lo stato del runtime. Inoltre, è in grado di
visualizzare lo stato del demone di pulse, la tabella d'instradamento LVS, ed i processi nanny generati
da LVS.
Figura 1.30. T he CONT ROL/MONIT ORING Panel
42
Auto update
Permette l'aggiornamento automatico del display dello stato, ad un intervallo configurato
dall'utente all'interno della casella Frequenza di aggiornam ento in secondi (il valore
predefinito è 10 secondi).
Non è consigliato impostare l'aggiornamento automatico ad un intervallo di tempo inferiore a 10
secondi, poichè così facendo sarà difficile riconfigurare l'intervallo di Aggiornam ento
autom atico poichè la pagina verrà aggiornata troppo frequentemente. Se incontrate questo
problema fate clic su di un altro pannello e successivamente su CONT ROLLO/MONIT ORAGGIO.
Update inform ation now
Fornisce l'aggiornamento manuale delle informazioni sullo stato.
CHANGE PASSWORD
Facendo clic su questo pulsante verrete direzionati su di una schermata d'aiuto, contenente le
informazioni su come modificare la password amministrativa per il Piranha Configuration
T ool.
1.10.2. GLOBAL SETTINGS
T he GLOBAL SET T INGS panel is where the LVS administrator defines the networking details for the
primary LVS router's public and private network interfaces.
Figura 1.31. T he GLOBAL SET T INGS Panel
43
T he top half of this panel sets up the primary LVS router's public and private network interfaces.
Prim ary server public IP
Indirizzo IP reale pubblicamente instradabile per il nodo LVS primario.
Prim ary server private IP
L'indirizzo IP reale per una interfaccia di rete alternativa sul nodo LVS primario. Questo indirizzo
viene utilizzato solo come canale heartbeat alternativo per il router di backup.
Use network type
Seleziona scegli NAT routing.
T he next three fields are specifically for the NAT router's virtual network interface connected the private
network with the real servers.
NAT Router IP
L'IP floating privato in questo campo di testo. Il suddetto IP floating deve essere usato come
gateway per i real server.
NAT Router netm ask
If the NAT router's floating IP needs a particular netmask, select it from drop-down list.
NAT Router device
Definisce il nome del dispositivo dell'interfaccia di rete per l'indirizzo IP floating, come ad
esempio eth1:1.
1.10.3. REDUNDANCY
Il pannello RIDONDANZA vi permette di configurare il nodo del router LVS di backup, ed impostare le
varie opzioni per il monitoraggio dell' heartbeat.
44
Figura 1.32. T he REDUNDANCY Panel
Redundant server public IP
Indirizzo IP reale pubblico per il router LVS di backup.
Redundant server private IP
T he backup router's private real IP address.
Il resto del pannello viene utilizzato per la configurazione del canale heartbeat, il quale a sua volta viene
usato dal nodo di backup per monitorare la presenza di errori nel nodo primario.
Heartbeat Interval (seconds)
Imposta il numero di secondi tra gli heartbeat — l'intervallo entro il quale il nodo di backup
controllerà la funzionalità dello stato del nodo LVS primario.
Assum e dead after (seconds)
Se il nodo LVS primario non risponde dopo il suddetto numero di secondi, allora il nodo del
router LVS di backup inizierà un processo di failover.
Heartbeat runs on port
Imposta la porta sulla quale l'heartbeat comunica con il nodo LVS primario. Il default viene
impostato su 539 se questo campo viene lasciato vuoto.
1.10.4. VIRTUAL SERVERS
45
Il pannello SERVER VIRT UALI visualizza le informazioni relative ad ogni server virtuale corrente
definito. Ogni voce presente nella tabella mostra lo stato del server virtuale, il nome del server, l'IP
virtuale assegnato al server, la maschera di rete dell'IP virtuale, il numero della porta usata dal servizio
per comunicare, il protocollo usato e l'interfaccia del dispositivo virtuale.
Figura 1.33. T he VIRT UAL SERVERS Panel
Ogni server presente nel pannello SERVER VIRT UALI può essere configurato sulle schermate
successive o sulle sottosezioni.
Per aggiungere un dispositivo fate clic sul pulsante AGGIUNGI. Per rimuovere un servizio, selezionatelo
tramite il pulsante situato accanto al server virtuale, e successivamente sul pulsante CANCELLA.
Per abilitare o disabilitare un server virtuale nella tabella, fate clic sul pulsante corrispondente e
successivamente sul pulsante (DIS.)ABILIT A.
Dopo aver aggiunto un server virtuale, sarà possibile configurarlo facendo clic sul pulsante
corrispondente sulla sinistra, e successivamente il pulsante MODIFICA per visualizzare la sottosezione
SERVER VIRT UALE.
1.10.4 .1. Sottosezione SERVER VIRT UALE
T he VIRT UAL SERVER subsection panel shown in Figura 1.34, «T he VIRT UAL SERVERS Subsection»
allows you to configure an individual virtual server. Links to subsections related specifically to this virtual
server are located along the top of the page. But before configuring any of the subsections related to
this virtual server, complete this page and click on the ACCEPT button.
46
Figura 1.34 . T he VIRT UAL SERVERS Subsection
Nam e
Un nome descrittivo per identificare il server virtuale. Questo nome non è l'hostname per la
macchina, quindi rendetelo descrittivo e facilmente identificabile. Potrete altresì riferirvi al
protocollo usato dal server virtuale, come ad esempio HT T P.
Application port
Il numero della porta attraverso la quale il service application sarà in ascolto.
Protocol
Fornisce una scelta di UDP o T CP, in un menu a tendina.
Virtual IP Address
T he virtual server's floating IP address.
Virtual IP Network Mask
La maschera di rete per questo server virtuale nel menu a tendina.
Firewall Mark
Usato per inserire un valore intero di un firewall mark durante l'unione di protocolli multi-port, o
per la creazione di un server virtuale multi-port per protocolli relativi ma separati.
Device
Il nome del dispositivo di rete al quale desiderate unire l'indirizzo IP floating definito nel campo
47
Indirizzo IP virtuale.
È consigliato l'alias dell'indirizzo IP floating pubblico sull'interfaccia Ethernet collegata alla rete
pubblica.
Re-entry T im e
Un valore intero che definisce il numero di secondi prima che il router LVS attivo possa cercare
di utilizzare un real server dopo il suo fallimento.
Service T im eout
Un valore intero che definisce il numero di secondi prima che un real server venga considerato
morto e quindi non disponibile.
Quiesce server
Quando un nodo del real server è online, dopo aver selezionato il pulsante radio server
Quiesce la tabella delle least-connection viene azzerata. Così facendo il router LVS attivo
indirizza le richieste come se i real server fossero stati appena aggiunti al cluster. Questa
opzione impedisce ad un nuovo server di saturarsi a causa di un numero elevato di
collegamenti al momento dell'ingresso nel cluster.
Load m onitoring tool
Il router LVS è in grado di monitorare il carico sui vari real server tramite l'utilizzo sia di rup che
di ruptim e. Se selezionate rup dal menu a tendina, ogni real server deve eseguire il servizio
rstatd. Se invece selezionate ruptim e, ogni real server deve eseguire il servizio rwhod.
Scheduling
L'algoritmo preferito per la programmazione dal menu a tendina. Il default è Weighted leastconnection.
Persistenza
Utilizzato se avete bisogno di collegamenti persistenti per il server virtuale durante le
transazioni del client. Specifica in questo campo il numero di secondi di inattività prima che un
collegamento possa scadere.
Persistence Network Mask
Per poter limitare la persistenza di una particolare sottorete, selezionate la maschera di rete
appropriata dal menu a tendina.
1.10.4 .2. Sottosezione REAL SERVER
Facendo clic sul link della sottosezione REAL SERVER nella parte alta del pannello, sarete in grado di
visualizzare la sottosezione MODIFICA REAL SERVER. Essa mostra lo stato degli host del server
fisico per un servizio virtuale specifico.
48
Figura 1.35. T he REAL SERVER Subsection
Click the ADD button to add a new server. T o delete an existing server, select the radio button beside it
and click the DELET E button. Click the EDIT button to load the EDIT REAL SERVER panel, as seen in
Figura 1.36, «T he REAL SERVER Configuration Panel».
Figura 1.36. T he REAL SERVER Configuration Panel
49
Questo pannello consiste in tre campi:
Nam e
Un nome descrittivo per il real server.
Nota Bene
Questo nome non è l'hostname per la macchina, quindi rendetelo descrittivo e facilmente
identificabile.
Address
T he real server's IP address. Since the listening port is already specified for the associated
virtual server, do not add a port number.
Weight
An integer value indicating this host's capacity relative to that of other hosts in the pool. T he
value can be arbitrary, but treat it as a ratio in relation to other real servers.
1.10.4 .3. EDIT MONIT ORING SCRIPT S Subsection
Fate clic sul link SCRIPT DI MONIT ORAGGIO nella parte alta della pagina. La sottosezione MODIFICA
SCRIPT DI MONIT ORAGGIO permette all'amministratore di specificare una sequenza della stringa del
tipo send/expect, per verificare che il servizio per il server virtuale funzioni correttamente su ogni real
server. Esso rappresenta anche il luogo dove l'amministratore può specificare script personalizzati per il
controllo dei servizi che richiedono una modifica dinamica dei dati.
Figura 1.37. T he EDIT MONIT ORING SCRIPT S Subsection
50
Sending Program
Per una verifica dei servizi molto più avanzata è possibile utilizzare questo campo per
specificare il percorso per uno script di controllo del servizio. Questa funzione è
particolarmente utile per servizi che richiedono una modifica dinamica dei dati, come ad
esempio HT T PS o SSL.
Per utilizzare questa funzione è necessario scrivere uno script il quale ritorna una risposta
testuale, impostatela in modo da essere eseguibile e digitate il percorso relativo nel campo
Program m a m ittente.
Nota Bene
Se viene inserito nel campo Program m a m ittente un programma esterno, allora il
campo Invio viene ignorato.
Send
Una stringa per il demone nanny da inviare ad ogni real server in questo campo. Per default il
campo relativo a HT T P è stato completato. È possibile alterare questo valore a seconda delle
vostre esigenze. Se lasciate questo campo vuoto, il demone nanny cerca di aprire la porta, e
se ha successo assume che il servizio è in esecuzione.
In questo campo è permesso solo una sola sequenza d'invio, e può contenere solo caratteri
ASCII stampabili insieme ai seguenti caratteri:
\n per una nuova riga.
\r per il ritorno a capo del cursore.
\t per tab.
\ escape del carattere successivo che lo segue.
Expect
La risposta testuale che il server dovrebbe ritornare se funziona correttamente. Se avete scritto
il vostro programma mittente, inserite la risposta da inviare in caso di successo.
[1] Un s erver virtuale è un s erviz io c o nfig urato in as c o lto s u d i un IP virtuale s p ec ific o .
51
Capitolo 2. Sommario dei componenti di Red Hat Cluster Suite
Questo capitolo fornisce un sommario dei componenti di Red Hat Cluster Suite e consiste nelle seguenti
sezioni:
Sezione 2.1, «Componenti del cluster»
Sezione 2.2, «Pagine man»
Sezione 2.3, «Hardware compatibile»
2.1. Componenti del cluster
T abella 2.1, «Componenti del sottosistema software di Red Hat Cluster Suite» summarizes Red Hat
Cluster Suite components.
52
T abella 2.1. Componenti del sottosistema software di Red Hat Cluster Suite
Funzione
Componenti
Descrizione
Conga
luci
Sistema di gestione remoto - Stazione di
gestione.
ricci
Sistema di gestione remoto - Stazione
gestita.
Cluster
Configuration T ool
system -config-cluster
Comando usato per gestire la
configurazione del cluster in una
impostazione grafica.
Cluster Logical Volume
Manager (CLVM)
clvm d
Il demone che distribuisce gli
aggiornamenti dei metadata LVM in un
cluster. Esso deve essere in esecuzione
su tutti i nodi nel cluster, ed emetterà un
errore se è presente un nodo in un
cluster il quale non possiederà un
demone in esecuzione.
lvm
T ool LVM2. Fornisce i tool della linea di
comando per LVM2.
system -config-lvm
Fornisce l'interfaccia utente grafica per
LVM2.
lvm .conf
Il file di configurazione LVM. Il percorso
completo è /etc/lvm /lvm .conf.
ccs_tool
ccs_tool fà parte di un Cluster
Configuration System (CCS). Viene
utilizzato per creare aggiornamenti online
dei file di configurazione CCS. È possibile
usarlo anche per aggiornare i file di
configurazione del cluster dagli archivi
CCS creati con GFS 6.0 (e versioni
precedenti) al formato della
configurazione del formato XML usato
con questa release di Red Hat Cluster
Suite.
ccs_test
Comando diagnostico e di prova usato
per ripristinare le informazioni dai file di
configurazione attraverso ccsd.
ccsd
Demone CCS eseguito su tutti i nodi del
cluster, che fornisce i dati del file di
configurazione al software del cluster.
cluster.conf
Questo è il file di configurazione del
cluster. Il percorso completo è
/etc/cluster/cluster.conf.
cm an.ko
Il modulo del kernel per CMAN.
cm an_tool
Rappresenta il front end amministrativo
per CMAN. Esso è in grado di avviare ed
arrestare CMAN e modificare alcuni
parametri interni come ad esempio i voti.
dlm _controld
Demone avviato dallo script init cm an per
Cluster Configuration
System (CCS)
Cluster Manager
(CMAN)
53
gestire dlm nel kernel; non usato
dall'utente.
Resource Group
Manager (rgmanager)
Fence
54
gfs_controld
gestire gfs nel kernel; non usato
dall'utente.
group_tool
Usato per ottenere un elenco di gruppi
relativi al fencing, DLM, GFS, e per
ottenere le informazioni di debug; include
ciò che viene fornito da cm an_tool
services in RHEL 4.
groupd
interfacciare openais/cm an e
dlm _controld/gfs_controld/fenc
ed; non usato dall'utente.
libcm an.so.<version
number>
Librerie per programmi che devono
interagire con cm an.ko.
clusvcadm
Comando usato per abilitare, disabilitare,
riposizionare e riavviare manualmente i
servizi dell'utente in un cluster.
clustat
Comando usato per visualizzare lo stato
del cluster, inclusa l'appartenenza del
nodo ed i servizi in esecuzione.
clurgm grd
Demone usato per gestire le richieste del
servizio dell'utente incluso service start,
service disable, service relocate, e
service restart.
clurm tabd
Demone usato per gestire le tabelle NFS
mount clusterizzate.
fence_apc
Fence agent per l'interrutore di
alimentazione APC.
fence_bladecenter
Fence agent per IBM Bladecenters con
interfacia T elnet.
fence_bullpap
Fence agent per l'interfaccia Bull
Novascale Platform Administration
Processor (PAP).
fence_drac
Fencing agent per la scheda d'accesso
remoto Dell.
fence_ipm ilan
Fence agent per macchine controllate da
IPMI (Intelligent Platform Management
Interface) attraverso la LAN.
fence_wti
Fence agent per l'interruttore di
alimentazione WT I.
fence_brocade
Fence agent per l'interruttore del Brocade
Fibre Channel.
fence_m cdata
Fence agent per l'interruttore del McData
Fibre Channel.
fence_vixel
Fence agent per l'interruttore del Vixel
Fibre Channel.
fence_sanbox2
Fence agent per l'interruttore del
SANBox2 Fibre Channel.
fence_ilo
Fence agent per le interfacce ILO di HP
(chiamate precedentemente fence_rib).
fence_rsa
I/O Fencing agent per IBM RSA II.
fence_gnbd
Fence agent usato con lo storage GNBD.
fence_scsi
I/O fencing agent per le prenotazioni
persistenti di SCSI.
fence_egenera
Fence agent usato con il sistema
Egenera BladeFrame.
fence_m anual
Fence agent per una interazione
manuale. NOTA BENE Questo
componente non è supportato per
ambienti di produzione.
fence_ack_m anual
Interfaccia utente per fence_m anual
agent.
fence_node
Un programma che esegue I/O fencing
su di un nodo singolo.
fence_xvm
I/O Fencing agent per macchine virtuali
Xen.
fence_xvm d
I/O Fencing agent host per macchine
virtuali Xen.
fence_tool
Un programma utilizzato per entrare ed
uscire dal dominio fence.
fenced
Il demone Fencing I/O.
DLM
libdlm .so.<version
number>
Libreria per il supporto del Distributed
Lock Manager (DLM).
GFS
gfs.ko
Modulo del kernel che implementa il file
system GFS caricato sui nodi del cluster
GFS.
gfs_fsck
Comando che ripara un file system GFS
non montato.
gfs_grow
Comando usato per espandere un file
system GFS montato.
gfs_jadd
Comando che aggiunge i journal ad un
file system GFS montato.
gfs_m kfs
Comando che crea un file system GFS su
di un dispositivo di storage.
gfs_quota
Comando che gestisce i quota su di un
file system GFS montato.
gfs_tool
Comando che configura o regola un file
system GFS. Questo comando è in grado
di raccogliere una varietà di informazioni
sul file system.
m ount.gfs
Icona d'aiuto di mount chiamata da
m ount(8); non usato dall'utente.
gnbd.ko
Modulo del kernel che implementa il
driver del dispositivo GNBD sui client.
gnbd_export
Comando usato per creare, esportare e
GNBD
55
gestire GNBD, su di un server GNBD.
LVS
56
gnbd_im port
Comando usato per importare e gestire
GNBD su di un client GNBD.
gnbd_serv
Un demone del server che permette ad
un nodo di esportare lo storage locale
attraverso la rete.
pulse
T his is the controlling process which
starts all other daemons related to LVS
routers. At boot time, the daemon is
started by the
/etc/rc.d/init.d/pulse script. It
then reads the configuration file
/etc/sysconfig/ha/lvs.cf. On the
active LVS router, pulse starts the LVS
daemon. On the backup router, pulse
determines the health of the active router
by executing a simple heartbeat at a
user-configurable interval. If the active
LVS router fails to respond after a userconfigurable interval, it initiates failover.
During failover, pulse on the backup
LVS router instructs the pulse daemon
on the active LVS router to shut down all
LVS services, starts the send_arp
program to reassign the floating IP
addresses to the backup LVS router's
MAC address, and starts the lvs
daemon.
lvsd
Il demone lvs viene eseguito sul router
LVS attivo una volta chiamato da pulse.
Esso legge il file di configurazione
/etc/sysconfig/ha/lvs.cf, chiama
l'utilità ipvsadm per compilare e gestire
la tabella di routing IPVS, e assegna un
processo nanny per ogni servizio LVS
configurato. Se nanny riporta la
presenza di un real server inattivo, lvs
indica alla utilità ipvsadm di rimuovere il
real server in questione dalla tabella di
routing IPVS.
ipvsadm
Questo servizio aggiorna la tabella del
routing IPVS nel kernel. Il demone lvs
imposta e gestisce LVS, chiamando
ipvsadm in modo da aggiungere,
modificare o cancellare le voci presenti
nella tabella del routing IPVS.
nanny
Il demone di controllo nanny viene
eseguito sul router LVS attivo. Attraverso
questo demone, il router LVS attivo
determina lo stato di ogni real server, e
facoltativamente, controlla il carico di
lavoro relativo. Viene eseguito un
processo separato per ogni servizio
definito su ogni real server.
Quorum Disk
lvs.cf
Questo è il file di configurazione di LVS. Il
percorso completo per il file è
/etc/sysconfig/ha/lvs.cf.
Direttamente o indirettamente tutti i
demoni ottengono le proprie informazioni
sulla configurazione da questo file.
Piranha Configuration T ool
Questo è il tool basato sul web per il
monitoraggio, configurazione e gestione
di LVS. Esso rappresenta il tool
predefinito per gestire il file di
configurazione di LVS
/etc/sysconfig/ha/lvs.cf.
send_arp
Questo programma invia i broadcast ARP
quando l'indirizzo IP floating cambia da
un nodo ad un altro durante un failover.
qdisk
Un demone del quorum basato sul disco
per CMAN / Linux-Cluster.
m kqdisk
Utilità disco quorum del cluster.
qdiskd
Demone disco quorum del cluster.
2.2. Pagine man
Questa sezione elenca le pagine man pertinenti al Red Hat Cluster Suite, come risorsa aggiuntiva.
Infrastruttura del cluster
ccs_tool (8) - Il tool usato per creare aggiornamenti online dei file di configurazione CCS
ccs_test (8) - Il tool diagnostico per un Cluster Configuration System
ccsd (8) - Il demone usato per accedere al file di configurazione del cluster di CCS
ccs (7) - Cluster Configuration System
cman_tool (8) - Cluster Management T ool
cluster.conf [cluster] (5) - Il file di configurazione per i prodotti del cluster
qdisk (5) - un demone del quorum basato sul disco per CMAN / Linux-Cluster
mkqdisk (8) - Cluster Quorum Disk Utility
qdiskd (8) - Cluster Quorum Disk Daemon
fence_ack_manual (8) - programma eseguito da un operatore come parte di un I/O Fencing
manuale
fence_apc (8) - I/O Fencing agent per APC MasterSwitch
fence_bladecenter (8) - I/O Fencing agent per IBM Bladecenter
fence_brocade (8) - I/O Fencing agent per interruttori Brocade FC
fence_bullpap (8) - I/O Fencing agent per l'architettura Bull FAME controllata da una console di
gestione PAP
fence_drac (8) - fencing agent per il Dell Remote Access Card
fence_egenera (8) - I/O Fencing agent per Egenera BladeFrame
fence_gnbd (8) - I/O Fencing agent per cluster GFS basati su GNBD
57
fence_ilo (8) - I/O Fencing agent per HP Integrated Lights Out card
fence_ipmilan (8) - I/O Fencing agent per macchine controllate da IPMI tramite LAN
fence_manual (8) - programma eseguita da fenced come parte del manuale I/O Fencing
fence_mcdata (8) - I/O Fencing agent per interruttori McData FC
fence_node (8) - Un programma che esegue I/O fencing su di un nodo singolo
fence_rib (8) - I/O Fencing agent per Compaq Remote Insight Lights Out card
fence_rsa (8) - I/O Fencing agent per IBM RSA II
fence_sanbox2 (8) - I/O Fencing agent per interruttori QLogic SANBox2 FC
fence_scsi (8) - I/O fencing agent per SCSI persistent reservations
fence_tool (8) - Un programma utilizzato per entrare ed uscire dal dominio fence
fence_vixel (8) - I/O Fencing agent per interruttori Vixel FC
fence_wti (8) - I/O Fencing agent per WT I Network Power Switch
fence_xvm (8) - I/O Fencing agent per macchine virtuali Xen
fence_xvmd (8) - I/O Fencing agent host per macchine virtuali Xen
fenced (8) - Il demone I/O Fencing
High-availability Service Management
clusvcadm (8) - Utilità Cluster User Service Administration
clustat (8) - Utilità Cluster Status
Clurgmgrd [clurgmgrd] (8) - Resource Group (Cluster Service) Manager Daemon
clurmtabd (8) - Cluster NFS Remote Mount T able Daemon
GFS
gfs_fsck (8) - Controllore file system GFS Offline
gfs_grow (8) - Espande un file system GFS
gfs_jadd (8) - Aggiunge i journal ad un file system GFS
gfs_mount (8) - opzioni di montaggio GFS
gfs_quota (8) - Manipola i disk quotas del GFS
gfs_tool (8) - interfaccia per le chiamate gfs ioctl
Cluster Logical Volume Manager
clvmd (8) - Demone LVM del cluster
lvm (8) - T ool LVM2
lvm.conf [lvm] (5) - File di configurazione per LVM2
lvmchange (8) - modifica gli attributi del logical volume manager
pvcreate (8) - inizializza un disco o una partizione per un utilizzo da parte di LVM
lvs (8) - riporta informazioni sui volumi logici
Global Network Block Device
gnbd_export (8) - l'interfaccia per esportare GNBD
gnbd_import (8) - manipola i dispositivi a blocchi GNBD su di un client
gnbd_serv (8) - demone del server gnbd
LVS
pulse (8) - demone heartbeating per il monitoraggio della salute dei nodi del cluster
lvs.cf [lvs] (5) - file di configurazione per lvs
lvscan (8) - esegue la scansione (su tutti i dischi) per la presenza di volumi logici
lvsd (8) - demone per controllare i Red Hat clustering service
ipvsadm (8) - Amministrazione del server virtuale di Linux
58
ipvsadm-restore (8) - ripristina la tabella IPVS da stdin
ipvsadm-save (8) - salva la tabella IPVS su stdout
nanny (8) - tool per il monitoraggio dello stato dei servizi in un cluster
send_arp (8) - tool usato per notificare ad una rete la presenza di una nuova mappatura
dell'indirizzo IP / MAC
2.3. Hardware compatibile
Per informazioni sull'hardware compatibile con i componenti Red Hat Cluster Suite (per esempio,
dispositivi di fence supportati, dispositivi storage e switch del Fibre Channel), consultate le linee guida
sulla configurazione hardware su http://www.redhat.com/cluster_suite/hardware/.
59
Cronologia della revisione
Revisione 3-7.4 00
Rebuild with publican 4.0.0
2013-10-31
Rüdiger Landmann
Revisione 3-7
Rebuild for Publican 3.0
2012-07-18
Anthony T owns
Revisione 1.0-0
Consolidamento delle versioni
T ue Jan 20 2008
Paul Kennedy
Indice analitico
C
cluster
- displaying status, Cluster Status T ool
cluster administration
- displaying cluster and service status, Cluster Status T ool
cluster component compatible hardware, Hardware compatibile
cluster component man pages, Pagine man
cluster components table, Componenti del cluster
Cluster Configuration T ool
- accessing, Cluster Configuration T ool
cluster service
- displaying status, Cluster Status T ool
command line tools table, T ool di amministrazione della linea di comando
compatible hardware
- cluster components, Hardware compatibile
Conga
- overview, Conga
Conga overview, Conga
F
feedback, Commenti
I
60
Cronologia della revisione
introduction, Introduzione
- other Red Hat Enterprise Linux documents, Introduzione
L
LVS
- direct routing
- requirements, hardware, Instradamento diretto
- requirements, network, Instradamento diretto
- requirements, software, Instradamento diretto
- routing methods
- NAT , Metodi di instradamento
- three tiered
- high-availability cluster, T hree-T ier LVS T opology
M
man pages
- cluster components, Pagine man
N
NAT
- routing methods, LVS, Metodi di instradamento
network address translation (vedi NAT )
O
overview
- economy, Red Hat GFS
- performance, Red Hat GFS
- scalability, Red Hat GFS
P
Piranha Configuration T ool
- CONT ROL/MONIT ORING, CONT ROL/MONIT ORING
- EDIT MONIT ORING SCRIPT S Subsection, EDIT MONIT ORING SCRIPT S Subsection
- GLOBAL SET T INGS, GLOBAL SET T INGS
- login panel, GUI di amministrazione del server virtuale di Linux
- necessary software, GUI di amministrazione del server virtuale di Linux
- REAL SERVER subsection, Sottosezione REAL SERVER
- REDUNDANCY, REDUNDANCY
61
- VIRT UAL SERVER subsection, VIRT UAL SERVERS
- Firewall Mark , Sottosezione SERVER VIRT UALE
- Persistence , Sottosezione SERVER VIRT UALE
- Scheduling , Sottosezione SERVER VIRT UALE
- Virtual IP Address , Sottosezione SERVER VIRT UALE
- VIRT UAL SERVERS, VIRT UAL SERVERS
R
Red Hat Cluster Suite
- components, Componenti del cluster
T
table
- cluster components, Componenti del cluster
- command line tools, T ool di amministrazione della linea di comando
62

Red Hat Enterprise Linux 5 Panoramica sul Cluster Suite

Transcript

Documenti analoghi

Tecnica operativa in HF e DX Cluster

DX-CLUSTER IQ8BB-6

Intervento dott.ssa Sapio GESP srl - PMI

febbraio 2008

attività - Centro Estero per l`Internazionalizzazione

Visualizza l`ALLEGATO

Client DX FUN Cluster per Arduino - Blog di IU2FRL

Diapositiva 1 - Osservatorio Astronomico di Bassano Bresciano

Mappa - Commissione Divulgazione UAI

Nota MAP per Cluster meningite meningococcica in Europa