7.2. Creazione di un file di configurazione del cluster di base
Previa installazione hardware del cluster, Red Hat Enterprise Linux, e del software High Availability Add-On, sarà possibile creare un file di configurazione del cluster (
/etc/cluster/cluster.conf) ed iniziare l'esecuzione dell'High Availability Add-On. Come punto di partenza questa sezione descrive il metodo attraverso il quale creare la struttura di un file di configurazione del cluster senza fencing, domini di failover e servizi HA. Le sezioni seguenti descrivono il metodo per la configurazione delle varie parti del file di configurazione.
Importante
Questa è solo una fase provvisoria per la creazione del file di configurazione del cluster; il file risultante non presenta alcun fencing e non viene considerato come configurazione supportata.
Le fasi di seguito riportate descrivono il metodo attraverso il quale creare e configurare una struttura del file di configurazione del cluster. Il file di configurazione del cluster varia in base al numero dei nodi, tipo di fencing, tipo e numero di servizi HA ed altri requisiti specifici.
- Su di un nodo del cluster create
/etc/cluster/cluster.confutilizzando il template dell'esempio in Esempio 7.1, «cluster.confEsempio: Configurazione di base». - (Opzionale) Se configurate un cluster con due nodi sarà possibile aggiungere la seguente riga sul file di configurazione, così facendo un singolo nodo sarà in grado di mantenere il quorum (per esempio in caso di fallimento di un nodo):
<cman two_node="1" expected_votes="1"/>Quando aggiungete o rimuovete l'opzionetwo_nodedal filecluster.conf, sarà necessario riavviare il cluster per poter implementare le modifiche al momento dell'aggiornamento della configurazione. Per informazioni su come aggiornare la configurazione del cluster consultare Sezione 8.4, «Aggiornamento di una configurazione». Per un esempio su come specificare l'opzionetwo_nodeconsultare Esempio 7.2, «cluster.confEsempio: Configurazione di base con due nodi». - Specificare la versione della configurazione ed il nome del cluster usando gli attributi
cluster:nameeconfig_version(consultare Esempio 7.1, «cluster.confEsempio: Configurazione di base» o Esempio 7.2, «cluster.confEsempio: Configurazione di base con due nodi»). - Nella sezione
clusternodesspecificare il nome e l'ID di ogni nodo usando gli attributiclusternode:nameenodeid. - Salvare
/etc/cluster/cluster.conf. - Convalidare il file con lo schema del cluster (
cluster.rng) eseguendo il comandoccs_config_validate. Per esempio:ccs_config_validate
[root@example-01 ~]# ccs_config_validate Configuration validatesCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Diffondere il file di configurazione su
/etc/cluster/in ogni nodo del cluster. Per esempio è possibile diffondere il file su altri nodi del cluster usando il comandoscp.Nota
Ciò è necessario durante la creazione del cluster. Dopo l'installazione e l'esecuzione del cluster sarà possibile diffondere il file di configurazione usandocman_tool version -r. Per la diffusione di un file di configurazione aggiornato sarà possibile usare il comandoscp; tuttavia il software del cluster dovrà essere arrestato su tutti i nodi durante l'utilizzo del comandoscp. In aggiunta eseguireccs_config_validatese diffondete un file di configurazione tramitescp.Nota
Anche se sono presenti elementi ed attributi aggiuntivi in un file di configurazione d'esempio (per esempiofenceefencedevices) non vi è alcuna necessità di popolarli ora. Le procedure di seguito riportate in questo capitolo forniscono le informazioni relative ad altri elementi ed attributi. - Avviare il cluster. Su ogni nodo del cluster eseguire il seguente comando:
service cman startPer esempio:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Su ogni nodo del cluster eseguire
cman_tools nodesper verificare che i nodi siano membri attivi del cluster (contrassegnati con "M" nella colonna dello stato, "Sts"). Per esempio:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Se il cluester è in esecuzione procedere alla Sezione 7.3, «Configurazione del fencing».
Esempi di configurazione di base Copia collegamentoCollegamento copiato negli appunti!
Copia collegamentoCollegamento copiato negli appunti!
Esempio 7.1, «
cluster.conf Esempio: Configurazione di base» e Esempio 7.2, «cluster.conf Esempio: Configurazione di base con due nodi» (per un cluster a due nodi) ognuno fornisce un esempio di file di configurazione del cluster di base come punto d'inizio. Le procedure di seguito riportate in questo capitolo forniscono le informazioni sulla configurazione dei servizi HA e di fencing.
Esempio 7.1. cluster.conf Esempio: Configurazione di base
Esempio 7.2. cluster.conf Esempio: Configurazione di base con due nodi
Valore consensus per totem in un cluster a due nodi Copia collegamentoCollegamento copiato negli appunti!
Copia collegamentoCollegamento copiato negli appunti!
Durante la creazione di un cluster a due nodi se non desiderate aggiungere nodi supplementari al cluster omettere il valore
consensus nel tag totem in cluster.conf, così facendo il valore consensus sarà calcolato automaticamente. Dopo aver calcolato automaticamente il suddetto valore saranno implementate le seguenti regole:
- Se in presenza di un numero minore o uguale a due nodi, il valore
consensusrisulterà essere (token * 0.2), con un tetto di 2000 msec ed una base di 200 msec. - Se in presenza di tre o più nodi il valore
consensusrisulterà essere (token + 2000 msec)
Se per la configurazione del timeout di consensus utilizzate l'utilità
cman in questo modo, e se passate da due a tre nodi, (o più nodi) allora sarà necessario riavviare il cluster poichè il timeout di consensus dovrà essere modificato implementando un valore più grande in base al timeout del token.
Se state configurando un cluster a due nodi e desiderate aggiornare la configurazione in futuro passandola ad un numero maggiore di nodi, allora sarà possibile sovrascrivere il timeout di consensus in modo da non riavviare il cluster all'aumentare dei nodi. Per eseguire questa operazione nel file
cluster.conf seguite quanto di seguito riportato:
<totem token="X" consensus="X + 2000" />
<totem token="X" consensus="X + 2000" />
Da notare che l'analizzatore della configurazione non calcola automaticamente X + 2000. Usare un valore intero e non una equazione.
Il vantaggio dell'utilizzo di un timeout ottimizzato per cluster a due nodi è che il periodo di tempo generale per il failover viene ridotto poichè consensus non risulta essere una funzione del timeout del token.
Da notare che in
cman per un autorilevamento in presenza di due nodi, il numero dei nodi fisici è l'elemento più importante rispetto alla presenza della direttiva two_node=1 nel file cluster.conf.