Red Hat Training

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

7.2. Création d'un fichier de configuration de cluster de base

Pourvu que le matériel du cluster, Red Hat Enterprise Linux, et le logiciel du module complémentaire High Availability soient installés, vous pourrez créer un fichier de configuration de cluster (/etc/cluster/cluster.conf) et commencer à exécuter le module complémentaire High Availability. En tant que point de démarrage seulement, cette section décrit comment créer un squelette de fichier de configuration de cluster sans utiliser le fencing, de domaines de basculement, ou de services HA. Les sections utlérieures décrivent comment configurer ces parties du fichier de configuration.

Important

Ceci n'est qu'une étape intermédiaire pour créer un fichier de configuration de cluster, le fichier en résultant n'est pas clôturé et n'est pas considéré comme une configuration prise en charge.
Les étapes suivantes décrivent comment créer et configurer un squelette de fichier de configuration de cluster. Finalement, le fichier de configuration de votre cluster variera selon le nombre de nœuds, le type de fencing, le type et le nombre de services HA et selon d'autres exigences spécifiques au site.
  1. Sur n'importe quel nœud du cluster, créez /etc/cluster/cluster.conf à l'aide du modèle de l'exemple dans l'Exemple 7.1, « Exemple de cluster.conf : configuration de base ».
  2. (Optional) Si vous configurez un cluster à deux nœuds, vous pouvez ajouter la ligne suivante au fichier de configuration afin de permettre à un nœud unique de maintenir le quorum (si un nœud échoue par exemple) :
    <cman two_node="1" expected_votes="1"/>
    Lorsque vous ajoutez ou supprimez l'option two_node du fichier cluster.conf, vous devez redémarrer le cluster pour que cette modification prenne effet lors de la mise à jour de la configuration. Pour des informations sur la mise à jour d'une configuration de cluster, reportez-vous à la Section 8.4, « Mettre à jour une configuration ». Pour un exemple de spécification de l'option two_node, reportez-vous à l'Exemple 7.2, « Exemple de cluster.conf : configuration à deux nœuds de base ».\n\n\t\n
  3. Spécifiez le nom du cluster ainsi que son numéro de version de configuration à l'aide des attributs cluster : name et config_version (reportez-vous à l'Exemple 7.1, « Exemple de cluster.conf : configuration de base » ou à l'Exemple 7.2, « Exemple de cluster.conf : configuration à deux nœuds de base »).
  4. Dans la section clusternodes, spécifiez le nom du nœud et l'ID du nœud de chaque nœud utilisant les attributs clusternode : name et nodeid.
  5. Enregistrez /etc/cluster/cluster.conf.
  6. Validez le fichier avec le schéma du cluster (cluster.rng) en exécutant la commande ccs_config_validate. Par exemple : 
    [root@example-01 ~]# ccs_config_validate 
Configuration validates
  7. Propagez le fichier de configuration sur /etc/cluster/ dans chaque nœud du cluster. Par exemple, vous pourriez propager le fichier vers d'autres nœuds de cluster à l'aide de la commande scp.

    Note

    La propagation d'un fichier de configuration de cluster de cette manière est nécessaire la première fois qu'un cluster est créé. Une fois que le cluster est installé et en cours d'exécution, le fichier de configuration du cluster peut être propagé à l'aide de cman_tool version -r. Il est possible d'utiliser la commande scp pour propager un fichier de configuration mis à jour. Cependant, le logiciel du cluster doit être arrêté sur tous les nœuds pendant l'utilisation de la commande scp. En outre, vous devriez exécuter ccs_config_validate si vous propagez un fichier de configuration mis à jour via la commande scp.

    Note

    Tandis que d'autres éléments et attributs sont présents dans l'exemple du fichier de configuration (par exemple, fence et fencedevices), il n'est pas nécessaire de les remplir maintenant. Des procédures expliquées ultérieurement dans ce chapitre fournissent des informations sur la spécification d'autres éléments et attributs.
  8. Démarrez le cluster. Exécutez la commande suivante sur chaque nœud de cluster :
    service cman start
    Par exemple : 
    [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. Sur n'importe quel nœud de cluster, exécutez cman_tool nodes pour vérifier que les nœuds fonctionnent en tant que membres dans le cluster (décrit comme « M » dans la colonne du statut « Sts »). Par exemple : 
    [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. Si le cluster est en cours d'exécution, procédez à Section 7.3, « Configurer le fencing ».

Exemples de configurations de base

L'Exemple 7.1, « Exemple de cluster.conf : configuration de base » et l'Exemple 7.2, « Exemple de cluster.conf : configuration à deux nœuds de base » (pour un cluster à deux nœuds) fournissent tous deux un exemple très basique de fichier de configuration de cluster comme point de départ. Les procédures suivantes dans ce chapitre fournissent des informations sur la configuration du fencing et des services HA.

Exemple 7.1. Exemple de cluster.conf : configuration de 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>

Exemple 7.2. Exemple de cluster.conf : configuration à deux nœuds de base


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

La valeur du consensus pour totem dans un cluster à deux nœuds

Lorsque vous créez un cluster à deux nœuds et que vous ne souhaitez pas ajouter de nœud supplémentaire au cluster ultérieurement, vous devriez alors omettre la valeur du consensus dans la balise totem du fichier cluster.conf, ainsi la valeur consensus sera calculée automatiquement. Lorsque la valeur consensus est calculée automatiquement, les règles suivantes sont utilisées :
  • S'il y a deux nœuds ou moins, la valeur consensus sera (token * 0.2), avec un plafond de 2000 msec et un plancher de 200 msec.
  • S'il y a trois nœuds ou plus, la valeur consensus sera (token + 2000 msec)
Si vous laissez l'utilitaire cman configurer votre délai d'expiration de consensus de cette manière, alors le déplacement ultérieur de deux à trois nœuds (ou plus) requerra le redémarrage du cluster, puisque le délai d'expiration du consensus devra changer vers cette valeur plus importante, basée sur le délai d'expiration du token.
Si vous configurez un cluster à deux nœuds et souhaitez le mettre à jour dans le futur à plus de deux nœuds, vous pouvez remplacer le délai d'expiration du consensus de manière à ce qu'un redémarrage du cluster ne soit pas requis lors du déplacement de deux à trois nœuds (ou plus). Ceci peut être effectué dans le fichier cluster.conf comme suit : 

<totem token="X" consensus="X + 2000" />
Remarquez que l'analyse de configuration (de l'anglais, « configuration parser ») ne calcule pas X + 2000 automatiquement. Une valeur entière doit être utilisée plutôt qu'une équation.
L'avantage offert par l'utilisation du délai d'expiration optimisé du consensus pour des clusters à deux nœuds est que le temps pris par le basculement est réduit pour les cas à deux nœuds puisque le consensus n'est pas une fonction du délai d'expiration du token.
Remarquez que pour l'autodétection de deux nœuds dans cman, le nombre de neouds physiques est le plus importants, et non la présence de la directive two_node=1 dans le fichier cluster.conf.