Différences

Ci-dessous, les différences entre deux révisions de la page.

--- informatique:systeme:ha:pacemaker [2012/09/16 17:28] – bn8
+++ informatique:systeme:ha:pacemaker [2019/03/11 15:27] (Version actuelle) – [Exemple de mise en place d'une VIP] bn8
@@ Ligne 1: / Ligne 1: @@
 ====== Pacemaker ======
 ===== Installation =====
-<note warning>Il est tout d'abord très important que les machines puissent communiquer entre elle avec leur nom (court ou //fqdn//). Si la résolution DNS ne le permet pas, ajouter les lignes nécéssaires dans le fichier ///etc/hosts//.</note>
+<note warning>Il est tout d'abord très important que les machines puissent communiquer entre elle avec leur nom (court ou //fqdn//). Si la résolution DNS ne le permet pas, ajouter les lignes nécessaires dans le fichier ///etc/hosts//.</note>
-  * Installation sur les deux machines : <code>apt-get install pacemaker dlm-pcmk openais</code>
+  * Installation sur les deux machines : <code>apt-get install pacemaker crmsh</code>
-  * Création de la clé partagér :
+  * Sur la machine 1 :
-    * Sur la machine 1 : <code>corosync-keygen</code>
+    * Création de la clé partagér (**Astuce :** Pour la génération d'entropy si vous être connecté à distance vous pouvez utiliser [[informatique:outils:rng-tools]]) : <code>corosync-keygen</code>
-    * Sur la machine 2 : Récupérer le fichier ///etc/corosync/authkey// sur la machine 1. Il doit appartenir à //root:root// et avoir les droits //400//.
+    * Éditer le fichier ///etc/corosync/corosync.conf// :
-  * Sur les deux machines, éditer le fichier ///etc/corosync/corosync.conf// et modifier la partie configurant l'interface d'écoute :<code>        interface {
+      * ajuster le paramètre //cluster_name//
+      * modifier le paramètre //crypto_cipher// : //aes256//
+      * modifier le paramètre //crypto_hash// : //sha512//
+      * modifier la partie configurant l'interface d'écoute :<code>        interface {
                 # The following values need to be set based on your environment
                 ringnumber: 0
                 bindnetaddr: 192.168.3.0
-                mcastaddr: 226.94.1.1
+                mcastaddr: 239.255.1.1
                 mcastport: 5405
+                ttl: 1
         }</code>
-  * Si vous souhaitez utiliser une deuxième interfaces réseaux simultanément pour les dialogues entre les nodes corosync, il suffit ajouter un deuxième bloques //interface// en incrémentant //ringnumber//, en modifiant //bindnetaddr// et en veillant à se que //mcastaddr// et //mcasport// soient différents que pour l'autre interface. Il faudra également passer mettre //rrp_mode// à //active//.
+       * Si votre cluster n'est composé que de deux noeuds, ajouter le paramètre //two_node// à //1// dans la section //quorum//
-  * Si vous utilisez OCFS2 entre autre, il est nécéssaire d'activer le service //cktp// fournis par openais. Pour cela, créer le fichier ///etc/corosync/service.d/cktp// et ajouter y les lignes suivantes :<code>service {
+       * Ajouter une section //nodelist// comme suit et en ajuster l'IP d'écoute des noeuds : <code>nodelist {
+        node {
+                ring0_addr: 192.168.3.207
+        }
+        node {
+                ring0_addr: 192.168.3.208
+        }
+}</code>
+    * Si vous souhaitez utiliser une deuxième interfaces réseaux simultanément pour les dialogues entre les nodes corosync, il suffit ajouter un deuxième bloques //interface// en incrémentant //ringnumber//, en modifiant //bindnetaddr// et en veillant à se que //mcastaddr// et //mcasport// soient différents que pour l'autre interface. Il faudra également passer mettre //rrp_mode// à //active//.
+<note tip>Si vous utilisez OCFS2 entre autre, il est nécesaire d'activer le service //cktp// fournis par //openais// (le paquet du même nom doit être installé). Pour cela, créer le fichier ///etc/corosync/service.d/cktp// et ajouter y les lignes suivantes :<code>service {
         name: openais_ckpt
         ver: 0
-}</code>
+}</code></note>
-  * Sur les deux machines, activer le lancement du daemon corosync en éditant le fichier ///etc/default/corosync// et en mettant la variable //START// à //yes//
+  * Sur la machine 2, faite un rsync de l'ensemble du dossier ///etc/corosync//
-  * Sur les deux machines, lancer le daemon : <code>/etc/init.d/corosync start</code>
+  * Sur les deux machines, redémarrer le service //corosync// puis //pacemaker//
 L'installation est prête a être configurée. La commande //crm status// devrait retourné quelque chose comme :
-<code>============
+<code>Stack: corosync
-Last updated: Mon Dec  6 18:38:18 2010
+Current DC: ldap1 (version 1.1.16-94ff4df) - partition with quorum
-Stack: openais
+Last updated: Mon Mar 11 15:54:50 2019
-Current DC: srvvirt1 - partition with quorum
+Last change: Mon Mar 11 15:54:25 2019 by hacluster via crmd on ldap1
-Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
-Nodes configured, 2 expected votes
-Resources configured.
-============
-Online: [ srvvirt1 srvvirt2 ]</code>
+nodes configured
+resources configured
+Online: [ ldap1 ldap2 ]
+No resources
+</code>
 ===== Communication Unicast =====
@@ Ligne 60: / Ligne 75: @@
 </code>
-===== Configuration de base =====
+===== Configuration de base pour un cluster à deux nœuds =====
 Nous allons entre autre mettre en place un //ping// régulier pour s'assurer de la bonne connectivité réseaux des machines. Cette //primitive// pourra être utilisé pour établir les règles de localisation des ressources.
-  * Pour accéder à la configuration du cluster pacemaker, entrer dans //crm//, passer en mode //configure// et utilisez la commande //edit// pour éditer la configuration : <code>root@srvvirt1:~# crm
+  * Pour accéder à la configuration du cluster pacemaker, entrer dans //crm//, passer en mode //configure// et utilisez la commande //edit// pour éditer la configuration : <code>root@ldap1:~# crm
 crm(live)# configure
 crm(live)configure# edit</code>
-  * Un éditeur vous ouvrira alors la configuration du cluster. Modifier la comme dans l'exemple suivant : <code>node srvvirt1 \
+  * Un éditeur vous ouvrira alors la configuration du cluster. Modifier la comme dans l'exemple suivant : <code>node 1084754508: ldap1
-        attributes standby="off"
+node 1084754509: ldap2
-node srvvirt2 \
-        attributes standby="off"
 primitive pinggw ocf:pacemaker:ping \
-        params host_list="172.16.0.1 172.16.0.2" multiplier="100" dampen="5s" name="pinggwval" \
+	params host_list="192.168.3.1 192.168.3.2" multiplier=100 dampen=5s name=pinggwval \
-        op monitor interval="10s" timeout="100s" \
+	op monitor interval=10s timeout=100s \
-        op start interval="0" timeout="100s" \
+	op start interval=0 timeout=100s \
-        op stop interval="0" timeout="100s"
+	op stop interval=0 timeout=100s
 clone clonepinggw pinggw
-property $id="cib-bootstrap-options" \
+property cib-bootstrap-options: \
-        dc-version="1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b" \
+	have-watchdog=false \
-        cluster-infrastructure="openais" \
+	dc-version=1.1.16-94ff4df \
-        expected-quorum-votes="2" \
+	cluster-infrastructure=corosync \
-        stonith-enabled="false" \
+	cluster-name=ldap \
-        no-quorum-policy="ignore"</code>
+	stonith-enabled=false \
-  * Si vous ne souhaitez pas que vos ressources migrent après un //recovery// ajouter : <code>rsc_defaults $id="rsc-options" \
+	no-quorum-policy=ignore</code>
-        resource-stickiness="100"</code>
+  * Si vous ne souhaitez pas que vos ressources migrent après un //recovery// ajouter : <code>rsc_defaults rsc-options: \
+	resource-stickiness=100</code>
+  * Quitter l'éditeur en enregistrant
+  * Appliquer la nouvelle configuration en exécutant la commande //commit//
+  * Vous pouvez constater le nouveau status en remontant d'un niveau avec la commande //cd// puis en exécutant la commande //status//
+===== Exemple de mise en place d'une VIP =====
+Nous allons mettre en place dans cette exemple :
+  * Une primitive //vip-ldap// correspondant à la VIP
+  * Une règle de location //vip-ldap-on-connected-host-only// définissant que la VIP ne doit tourner que sur un noeud connecté au réseau (sur la base de l'état de la valeur de la variable //pinggwval// défini par la primitive //pinggw// cloné sur les deux machines sous le nom //clonepinggw//).
+  * Une règle de location //vip-ldap-on-ldap1// indiquant une préférence pour faire tourner la VIP sur la machine //ldap1//
+Pour cela :
+  * Éditer la configuration du cluster et ajouter les lignes suivantes en ajustant de paramètre de configuration de la VIP : <code>primitive vip-ldap IPaddr2 \
+	params ip=192.168.3.79 nic=ens192 cidr_netmask=24 \
+	meta migration-threshold=2 \
+	op monitor interval=20 timeout=60 on-fail=restart
+location vip-ldap-on-connected-host-only vip-ldap \
+	rule -inf: not_defined pinggwval or pinggwval lt 100
+location vip-ldap-on-ldap1 vip-ldap 50: ldap1</code>
 ===== Trucs et astuces =====
@@ Ligne 102: / Ligne 133: @@
         crm_resource --resource <name> --move --node <node_name>