Pacemaker

• Installation sur les deux machines :

  apt-get install pacemaker crmsh

• Sur la machine 1 :
  • Création de la clé partagér (Astuce : Pour la génération d'entropy si vous être connecté à distance vous pouvez utiliser rng-tools) :

    corosync-keygen

  • É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 :

              interface {
                      # The following values need to be set based on your environment 
                      ringnumber: 0
                      bindnetaddr: 192.168.3.0
                      mcastaddr: 239.255.1.1
                      mcastport: 5405
                      ttl: 1
              }

    • Si votre cluster n'est composé que de deux noeuds, ajouter le paramètre two_node à 1 dans la section quorum
    • Ajouter une section nodelist comme suit et en ajuster l'IP d'écoute des noeuds :

      nodelist {
              node {
                      ring0_addr: 192.168.3.207
              }
              node {
                      ring0_addr: 192.168.3.208
              }
      }

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

service {
        name: openais_ckpt
        ver: 0
}

• Sur la machine 2, faite un rsync de l'ensemble du dossier /etc/corosync
• 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 :

Stack: corosync
Current DC: ldap1 (version 1.1.16-94ff4df) - partition with quorum
Last updated: Mon Mar 11 15:54:50 2019
Last change: Mon Mar 11 15:54:25 2019 by hacluster via crmd on ldap1

2 nodes configured
0 resources configured

Online: [ ldap1 ldap2 ]

No resources

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 :

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
}

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 :

  root@ldap1:~# crm
  crm(live)# configure
  crm(live)configure# edit

• Un éditeur vous ouvrira alors la configuration du cluster. Modifier la comme dans l'exemple suivant :

  node 1084754508: ldap1
  node 1084754509: ldap2
  primitive pinggw ocf:pacemaker:ping \
  	params host_list="192.168.3.1 192.168.3.2" multiplier=100 dampen=5s name=pinggwval \
  	op monitor interval=10s timeout=100s \
  	op start interval=0 timeout=100s \
  	op stop interval=0 timeout=100s
  clone clonepinggw pinggw
  property cib-bootstrap-options: \
  	have-watchdog=false \
  	dc-version=1.1.16-94ff4df \
  	cluster-infrastructure=corosync \
  	cluster-name=ldap \
  	stonith-enabled=false \
  	no-quorum-policy=ignore

• Si vous ne souhaitez pas que vos ressources migrent après un recovery ajouter :

  rsc_defaults rsc-options: \
  	resource-stickiness=100

• 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

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 :

  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

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

clone cl_res res \
        params interleave="true"

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