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:[root@example-01 ~]#
ccs_config_validateConfiguration validates - 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:[root@example-01 ~]#
service cman startStarting cluster: Checking Network Manager... [ OK ] Global setup... [ OK ] Loading kernel modules... [ OK ] Mounting configfs... [ OK ] Starting cman... [ OK ] Waiting for quorum... [ OK ] Starting fenced... [ OK ] Starting dlm_controld... [ OK ] Starting gfs_controld... [ OK ] Unfencing self... [ OK ] Joining fence domain... [ OK ] - 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:[root@example-01 ~]#
cman_tool nodesNode Sts Inc Joined Name 1 M 548 2010-09-28 10:52:21 node-01.example.com 2 M 548 2010-09-28 10:52:21 node-02.example.com 3 M 544 2010-09-28 10:52:21 node-03.example.com - Se il cluester è in esecuzione procedere alla Sezione 7.3, «Configurazione del fencing».
Esempi di configurazione di base
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
<cluster name="mycluster" config_version="2">
<clusternodes>
<clusternode name="node-01.example.com" nodeid="1">
<fence>
</fence>
</clusternode>
<clusternode name="node-02.example.com" nodeid="2">
<fence>
</fence>
</clusternode>
<clusternode name="node-03.example.com" nodeid="3">
<fence>
</fence>
</clusternode>
</clusternodes>
<fencedevices>
</fencedevices>
<rm>
</rm>
</cluster>
Esempio 7.2. cluster.conf Esempio: Configurazione di base con due nodi
<cluster name="mycluster" config_version="2">
<cman two_node="1" expected_votes="1"/>
<clusternodes>
<clusternode name="node-01.example.com" nodeid="1">
<fence>
</fence>
</clusternode>
<clusternode name="node-02.example.com" nodeid="2">
<fence>
</fence>
</clusternode>
</clusternodes>
<fencedevices>
</fencedevices>
<rm>
</rm>
</cluster>
Valore consensus per totem in un cluster a due nodi
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" />
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.
