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.
- 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 decluster.conf: configuration de base ». - (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'optiontwo_nodedu fichiercluster.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'optiontwo_node, reportez-vous à l'Exemple 7.2, « Exemple decluster.conf: configuration à deux nœuds de base ».\n\n\t\n - Spécifiez le nom du cluster ainsi que son numéro de version de configuration à l'aide des attributs
cluster:nameetconfig_version(reportez-vous à l'Exemple 7.1, « Exemple decluster.conf: configuration de base » ou à l'Exemple 7.2, « Exemple decluster.conf: configuration à deux nœuds de base »). - Dans la section
clusternodes, spécifiez le nom du nœud et l'ID du nœud de chaque nœud utilisant les attributsclusternode:nameetnodeid. - Enregistrez
/etc/cluster/cluster.conf. - Validez le fichier avec le schéma du cluster (
cluster.rng) en exécutant la commandeccs_config_validate. Par exemple :[root@example-01 ~]#
ccs_config_validateConfiguration validates - 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 commandescp.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 decman_tool version -r. Il est possible d'utiliser la commandescppour 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 commandescp. En outre, vous devriez exécuterccs_config_validatesi vous propagez un fichier de configuration mis à jour via la commandescp.Note
Tandis que d'autres éléments et attributs sont présents dans l'exemple du fichier de configuration (par exemple,fenceetfencedevices), 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. - Démarrez le cluster. Exécutez la commande suivante sur chaque nœud de cluster :
service cman startPar exemple :[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 ] - Sur n'importe quel nœud de cluster, exécutez
cman_tool nodespour 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 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 - 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
consensussera (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
consensussera (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.
