---
categories: cloud haute-disponibilite
title: HowTo Pacemaker
...
* Documentation :
**Pacemaker** est un gestionnaire de ressources en cluster permettant de gérer la haute disponibilité de ressources tournants sur plusieurs serveurs.
Pacemaker utilise [Corosync](https://corosync.github.io/corosync/) pour gérer la communication et les décisions entre les serveurs du cluster.
## Configuration d'un nouveau cluster
### Installation
~~~
# apt install pacemaker pacemaker-cli-utils
# pacemakerd --version
Pacemaker 2.0.5
Written by Andrew Beekhof
# pcs --version
0.10.8
~~~
Il faut ensuite définir un mot de passe pour l'utilisateur `hacluster`.
~~~
# passwd hacluster
~~~
Finalement nettoyer toute trace d'un cluster (Debian démarre le service pacemakerd par défaut, ce qui empêche la mise en place sans cette étape).
~~~
# pcs cluster destroy
~~~
### Définition du cluster
> Il faut en plus que les machines puissent se connecter en root entre elles.
Depuis l'une des machines du cluster (n'importe laquelle), configuré la connexion entre les serveurs du cluster.
> Cette commande peut être exécutée en plusieurs fois si le mot de passe de `hacluster` est différent sur les différents hôtes.
~~~
host1# pcs host auth [addr=] [addr=] [...]
~~~
Puis définir le cluster :
~~~
host1# pcs cluster setup [addr=] [addr=] [...]
host1# pcs cluster auth
~~~
Et finalement démarré le cluster (et faire en sorte que les services démarrent automatiquement au démarrage de la machine) :
~~~
host1# pcs cluster start --all
host1# pcs cluster enable --all
~~~
## Administration
### Activer ou désactiver le Fencing
Le **fencing** est géré via la configuration du `stonith` (Shoot The Other Node In The Head), dans le cas où il est activé, si une majorité des nodes d'un cluster n'arrivent pas à contacter un autre node alors le cluster éteindra automatiquement ce dernier node (généralement électriquement) d'une manière configurée, afin de protéger contre le split-brain.
Il est fortement recommandé de garder le fencing actif sur un cluster en production.
~~~
pcs property set stonith-enabled=
~~~
### Configuré le Fencing
~~~
# cib_path=
# pcs cluster cib "${cib_path:?}"
# pcs -f "${cib_path:?}" stonith create
# pcs -f "${cib_path:?}" property set stonith-enabled=true
# pcs cluster cib-push "${cib_path:?}"
~~~
Si le nom des nodes pour le cluster est différent des noms connus par le matériel utilisé, il faut définir le paramètre `pcmk_host_map` avec le format suivant : `:;:` (si le stonith utilise plusieurs noms/ports pour un node, ils sont à séparer par des virgules).
Pour obtenir la liste des matériels supportés, utilisé la commande suivante :
~~~
pcs stonith list
~~~
Pour connaître les options de configurations, utilisé la commande suivante :
~~~
pcs stonith describe
~~~
Il y a aussi des configurations communes documentées dans la page man `pacemaker-fenced(7)`.
### Définir la politique en cas de perte de quorum
Pour définir comment le cluster réagit en cas de perte du quorum, faire la commande suivante :
~~~
# pcs property set no-quorum-policy=
~~~
Valeurs :
* **stop**: Les services restant sont désactivés
* **freeze**: Rien n'est fait tant que le quorum n'est pas retrouvé
### Ajouter une ressource (service mis en cluster, ou état surveillé)
~~~
# pcs resource create [clone|promotable]
~~~
> La configuration `clone` signifie que la ressource peut se trouver active sur plusieurs machines en même temps, cela créé une ressource "locale" `_clone` qui est à utiliser pour les restrictions. `promotable` signifie que la ressource a une gestion interne de primaire/secondaire.
Les plugins de ressources disponibles à la définition sont obtenables avec les commandes suivantes (le format dans la commande de création de ressource est `::` :
~~~
# pcs resource standards
# pcs resource providers
# pcs resource agents :
~~~
Les configurations disponibles pour un plugin de ressource sont disponbiles avec la commande suivante :
~~~
# pcs resource describe ::
~~~
> Il est fortement recommandé d'utiliser les plugins du standard `ocf` si possible.
> Si un plugin gère le lancement d'un service système, il ne faut pas qu'il soit en `enable` dans systemd.
### Définition de restrictions entre resources
> Le score est un nombre ou `-INFINITY` ou `INFINITY` définissant le niveau d'importance de la restriction.
Pour définir une restriction de colocalisation de deux ressources (une ressource devant être sur un même serveur qu'un autre, ou le contraire) :
> Il est préférable de créer un groupe de ressource quand possible.
~~~
# pcs constraint colocation add with
~~~
Pour définir une restriction de localisation d'une ressource par rapport à une condition :
~~~
# pcs constraint location rule score=
~~~
Pour définir une restriction sur l'ordre de démarrage de ressources (`ressource1` doit être démarré avant `ressource2`) :
~~~
# pcs constraint order then
~~~
### Définition d'un groupe de ressources (étant donc contraint à être démarré sur le même node)
~~~
# cib_path=
# group_name=
# pcs cluster cib "${cib_path:?}"
# pcs -f "${cib_path:?}" resource create --group "${group_name:?}" <...> # définition de la première ressource
# pcs -f "${cib_path:?}" resource create --group "${group_name:?}" <...> # définition de la seconde ressource
[...]
# pcs cluster cib-push "${cib_path:?}"
~~~