Pacemaker

Installation

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.

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.

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 :

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

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 :

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
}

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

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 :

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

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 :

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>