informatique:systeme:ha:pacemaker

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
informatique:systeme:ha:pacemaker [2011/10/26 10:44] bn8informatique:systeme:ha:pacemaker [2019/03/11 15:27] (Version actuelle) – [Exemple de mise en place d'une VIP] bn8
Ligne 1: Ligne 1:
-====== Installation ====== +====== Pacemaker ====== 
-<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> + 
-  * Installation sur les deux machines : <code>apt-get install pacemaker dlm-pcmk openais</code> +===== Installation ===== 
-  * Création de la clé partagér :  +<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> 
-    Sur la machine 1 : <code>corosync-keygen</code> +  * Installation sur les deux machines : <code>apt-get install pacemaker crmsh</code> 
-    * Sur la machine 2 : Récupérer le fichier ///etc/corosync/authkey// sur la machine 1Il doit appartenir à //root:root// et avoir les droits //400//. +  * Sur la machine 1 :  
-  Sur les deux machines, éditer le fichier ///etc/corosync/corosync.conf// et modifier la partie configurant l'interface d'écoute :<code>        interface {+    * 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> 
 +    * Éditer le fichier ///etc/corosync/corosync.conf// : 
 +      * 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                  # The following values need to be set based on your environment 
                 ringnumber: 0                 ringnumber: 0
                 bindnetaddr: 192.168.3.0                 bindnetaddr: 192.168.3.0
-                mcastaddr: 226.94.1.1+                mcastaddr: 239.255.1.1
                 mcastport: 5405                 mcastport: 5405
 +                ttl: 1
         }</code>         }</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         name: openais_ckpt
         ver: 0         ver: 0
-}</code> +}</code></note
-  * Sur les deux machinesactiver le lancement du daemon corosync en éditant le fichier ///etc/default/corosync// et en mettant la variable //START// à //yes// +  * Sur la machine 2faite 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 : 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 updatedMon 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
-Version1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b +
-2 Nodes configured, 2 expected votes +
-0 Resources configured. +
-============+
  
-Online: [ srvvirt1 srvvirt2 ]</code>+2 nodes configured 
 +0 resources configured
  
-====== Configuration de base ======+Online: [ ldap1 ldap2 ] 
 + 
 +No resources 
 + 
 +</code> 
 + 
 +===== Communication Unicast ===== 
 + 
 +Par défaut, le dialogue entre les nodes se fait en multicast. Il peut être utile dans certain cas de configurer celui-ci en unicast. Pour cela, //**Corosync**// support l'//**UDP Unicast**// (ou //**UDPU**//) depuis sa version //1.3.0// (pour **Debian**, il faut au moins la version disponible dans //squeeze-backports//). 
 + 
 +La configuration du mode Unicast ce fait comme expliquer ci dessus aux exceptions décrite ci-dessous : 
 + 
 +<code> 
 +totem { 
 +        [...] 
 +        interface { 
 +                ringnumber: 0 
 +                bindnetaddr: 10.32.0. 
 +                member { 
 +                        memberaddr: 10.32.0.10 
 +                } 
 +                member { 
 +                        memberaddr: 10.32.1.11 
 +                } 
 +                mcastaddr: 226.94.1.6 
 +                mcastport: 5605 
 +        } 
 +        transport: udpu 
 +
 +</code> 
 + 
 +===== 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. 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
 crm(live)configure# edit</code> 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 \ primitive pinggw ocf:pacemaker:ping \
-        params host_list="172.16.0.1 172.16.0.2" multiplier="100dampen="5sname="pinggwval+ params host_list="192.168.3.1 192.168.3.2" multiplier=100 dampen=5s name=pinggwval \ 
-        op monitor interval="10stimeout="100s+ op monitor interval=10s timeout=100s \ 
-        op start interval="0timeout="100s+ op start interval=0 timeout=100s \ 
-        op stop interval="0timeout="100s+ op stop interval=0 timeout=100s
 clone clonepinggw pinggw 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" + stonith-enabled=false \ 
-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 ===== 
 + 
 +==== Eviter que l'arrêt de ressources clonés au redémarrage d'un node ==== 
 + 
 +- Lorsque des ressources clonés sont ordonnés, au redémarrage d'un node, pour respecter l'ordre, les ressources du node déjà actif sont arrêtées puis relancer en même temps que le node arrivant. Pour éviter cela définissez vos clones comme cela : <code>clone cl_res res \ 
 +        params interleave="true"</code> 
 +         
 +         
 +- Si une node a par exemple monté une ressource drbd suite à la défaillance du master et que vous voulez le repasser sur la machine de nouveau opérationnelle : 
 + 
 +On liste les ressources 
 + 
 +        crm_resource -l 
 + 
 +Puis on migre la resource
  
 +        crm_resource --resource <name> --move --node <node_name>
  
  • informatique/systeme/ha/pacemaker.1319625851.txt.gz
  • Dernière modification : 2011/10/26 10:44
  • de bn8