Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

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.
  1. Su di un nodo del cluster create /etc/cluster/cluster.conf utilizzando il template dell'esempio in Esempio 7.1, «cluster.conf Esempio: Configurazione di base».
  2. (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'opzione two_node dal file cluster.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'opzione two_node consultare Esempio 7.2, «cluster.conf Esempio: Configurazione di base con due nodi».
  3. Specificare la versione della configurazione ed il nome del cluster usando gli attributi cluster: name e config_version (consultare Esempio 7.1, «cluster.conf Esempio: Configurazione di base» o Esempio 7.2, «cluster.conf Esempio: Configurazione di base con due nodi»).
  4. Nella sezione clusternodes specificare il nome e l'ID di ogni nodo usando gli attributi clusternode: name e nodeid.
  5. Salvare /etc/cluster/cluster.conf.
  6. Convalidare il file con lo schema del cluster (cluster.rng) eseguendo il comando ccs_config_validate. Per esempio:
    [root@example-01 ~]# ccs_config_validate 
    Configuration validates
    
  7. 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 comando scp.

    Nota

    Ciò è necessario durante la creazione del cluster. Dopo l'installazione e l'esecuzione del cluster sarà possibile diffondere il file di configurazione usando cman_tool version -r. Per la diffusione di un file di configurazione aggiornato sarà possibile usare il comando scp; tuttavia il software del cluster dovrà essere arrestato su tutti i nodi durante l'utilizzo del comando scp. In aggiunta eseguire ccs_config_validate se diffondete un file di configurazione tramite scp.

    Nota

    Anche se sono presenti elementi ed attributi aggiuntivi in un file di configurazione d'esempio (per esempio fence e fencedevices) non vi è alcuna necessità di popolarli ora. Le procedure di seguito riportate in questo capitolo forniscono le informazioni relative ad altri elementi ed attributi.
  8. Avviare il cluster. Su ogni nodo del cluster eseguire il seguente comando:
    service cman start
    Per esempio:
    [root@example-01 ~]# service cman start
    Starting 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  ]
    
  9. Su ogni nodo del cluster eseguire cman_tools nodes per verificare che i nodi siano membri attivi del cluster (contrassegnati con "M" nella colonna dello stato, "Sts"). Per esempio:
    [root@example-01 ~]# cman_tool nodes
    Node  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
    
  10. 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 consensus risulterà 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 consensus risulterà 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.