Forums PostgreSQL.fr

ioguix

Administrateur

Re : [RESOLU] [PAF] automatique failover postgresql / pacemaker /corosync

En fait je connais bien postgresql depuis plusieurs années et mes aventures avec PAF ont été tellement semées d'embuches et d’échecs que j'en suis venu à douter de mes propres connaissances :-(

La haute dispo étant un sujet complexe et semé d'embûches (en tout cas pour avoir quelque chose de correcte), nous avons prit le parti dans PAF d'être très rigoureux, stricte et de contrôler l'environnement au maximum . Malheureusement, avec Pacemaker, ça se traduit souvent par du fencing ou des ressources qui ne démarrent pas. Mais lui non plus n'a pas le choix. À partir du moment où l'on souhaite une prise de décision non humaine et ne pas avoir de split brain, il faut en arriver là...

Je me demande par contre pourquoi le heartbeat est "stopped".

Je ne vois que deux nœuds dans ce cluster. Or, vous avez configuré votre nombre d'instance possible à 3 ( "clone-max=3" ) et autorisé qu'une seule instance par nœud ( "clone-node-max=1" ), ce qui est normal pour ce dernier.

Du coup, Pacemaker prévoit 3 instances pgsql (appelés "clones") dans le cluster, mais ne peux démarrer la 3ème nulle part, faute de place. Si vous rajoutez un nœuds à votre cluster (avec une instance PostgreSQL prête à démarrer et entrer en réplication) Pacemaker y placera donc ce 3ème clone.

En attendant, si vous ne construisez qu'un cluster à deux nœuds, il suffit simplement de modifier "clone-max=2".

ioguix

Administrateur

Re : [RESOLU] [PAF] automatique failover postgresql / pacemaker /corosync

Je me demande par contre pourquoi le heartbeat est "stopped".

À noter que ce n'est pas un "heartbeat" qui est en stopped, mais un clone nommé "pgsqld" dans votre conf. Le reste de la ligne signifie que cette ressource est de type "OCF", distribué par "heartbeat" et dont le ressource agent s'appelle "pgsqlms", aussi indiqué sous la forme "ocf::heartbeat:pgsqlms" donc.

ruizsebastien

Membre

Re : [RESOLU] [PAF] automatique failover postgresql / pacemaker /corosync

Bonjour,

Merci pour les explications :-)

Je vais capitalisé sur tout ça et je vais ensuite vous faire un retour (constructif) sur tous les problèmes et les interrogations que j'ai eu par rapport à la doc (quick start for centos7).
Merci encore pour votre aide.
J'espère que tous nos échanges pourront servir à d'autres.

Dernière modification par ruizsebastien (20/03/2017 14:39:16)

---

Cordialement,

Sébastien.

ioguix

Administrateur

Re : [RESOLU] [PAF] automatique failover postgresql / pacemaker /corosync

Je vais capitalisé sur tout ça et je vais ensuite vous faire un retour (constructif) sur tous les problèmes et les interrogations que j'ai eu par rapport à la doc (quick start for centos7).

Excellent. Nous essaierons de faire avancer la doc dans le bon sens !

Merci encore pour votre aide.

Je vous en prie.

J'espère que tous nos échanges pourront servir à d'autres.

C'est l'intérêt des forums publiques, j'espère aussi du coup !

Pourriez-vous modifier le sujet de la discussion avec un tag "[résolu]" ? Merci !

ruizsebastien

Membre

Re : [RESOLU] [PAF] automatique failover postgresql / pacemaker /corosync

Bonjour,

Comme promis voici mes remarques liées aux difficultées que j'ai rencontré lors de la mise en place de PAF / pacemaker / corosync.
(j'ai utilisé https://dalibo.github.io/PAF/Quick_Start-CentOS-7.html )
1 - quel agent de fencing installer ?
Tout dépend du type d'architecture on utilise (serveurs physiques, vmware, etc...)
Dans la doc on utilise l'agent fence-agents-virsh. Dans mon cas (vmware) il fallait utiliser l'agent fence-agents-vmware-soap.
Pour savoir si l'agent est déjà installé sur le serveur (pcs doit être installé au préalable) :

pcs stonith list

Si l'agent nécessaire n'est pas dans la liste, il faut l'installer.
Une petite liste de correspondance des agents à utiliser selon l'architecture cible, ce serait vraiment royal
2 - corosync.conf
Après l'installation de corsync, le processus refuse de se lancer car il ne trouve pas le fichier corosync.conf.
Il faut donc le créer vide :

cp /etc/corosync/corosync.conf.example /etc/corosync/corosync.conf

3 - recovery.conf.pcmk :
il manque la commande "restore_command = 'xxxxxxxxx' "

4 - pg_hba.conf :
Je me suis fait avoir sur cette partie. Il faut ajouter les lignes de la doc avant les autres lignes déjà existantes.
Il faut bien comprendre que le pg_hba.conf "avant PAF" doit fonctionner correctement pour la réplication et les connections applicatives.
Évidemment ne pas oublier d'alimenter le .pgpass si on est en authentification md5 (par exemple).
La partie mise en place de la replication postgresql dans la doc peut porter à confusion.
Par exemple, ça ne marchera pas si on ne met que ces 3 lignes dans le pg_hba.conf :

host replication postgres 192.168.122.50/32 reject
host replication postgres $(hostname -s) reject
host replication postgres 0.0.0.0/0 trust

Il manque au minimum les connexions "local"
5 - clef d'authentification pour corosync :
Je ne sais plus exactement pourquoi, mais à un moment donné j'ai eu une erreur et en lisant la doc officielle de corosync, j'ai vu qu'il fallait créer une clef pour que les processus distants puissent dialoguer.
Je ne sais pas si c'est réellement indispensable mais dans mon cas ça m'a débloqué.

cd /etc/corosync
corosync-keygen
chown root:root /etc/corosync/authkey
chmod 400 /etc/corosync/authkey
+ copier la clef sur l'autre serveur dans /etc/corosync/

6 - STONITH resources :
Le point le plus compliqué à mettre en oeuvre car les paramètres ne sont pas très intuitifs.
Une petite explication de chaque paramètre aurait été un vrai plus (vous me direz : RTFM...)
Ce qui m'a aidé : lancer la commande de fencing directement en mode verbeux et avant de créer la ressource pour voir ce qui ne va pas.
Par exemple dans le cadre de vmware :

fence_vmware_soap --action=status --ip=(ip de l'hyperviseur) --plug=(nom du serveur tel qu'il est vu par l'hyperviseur) --username=(user créer dans l'hyperviseur qui a les droits d'agir sur la vm) --password=(passwd de ce user) --ssl --ssl-insecure -v
(ssl-insecure : si on a des problème de certificat sur l'hyperviseur)

Les paramètres de la commande de fencing correspondent à ceci dans la commande de création de la ressource stonith :

pcmk_host_list = hostname complet du serveur
ipaddr = --ip
port = --plug
login = --username
passwd = --password
action = --action

dans la création de la ressource que signifie INFINITY ?

7 - resource pgsqld :
Il faudrait décrire ce que signifie :

master-max
master-node-max
clone-max
clone-node-max
notify

La aussi je me suis fait avoir.

Pour le reste, c'était clair.

Quelques commande qui pourrait aider à comprendre et débugger l'installation :

pcs status --full
crm_mon -Afr -1
corosync-cfgtool -s
pcs property show
pcs resource show --full
traces corosync dans /var/log/cluster/corosync.log

En tout cas merci encore pour votre aide et votre travail sur ce produit.

---

Cordialement,

Sébastien.

ioguix

Administrateur

Re : [RESOLU] [PAF] automatique failover postgresql / pacemaker /corosync

1 - quel agent de fencing installer ?
Tout dépend du type d'architecture on utilise (serveurs physiques, vmware, etc...)
Dans la doc on utilise l'agent fence-agents-virsh. Dans mon cas (vmware) il fallait utiliser l'agent fence-agents-vmware-soap.
Pour savoir si l'agent est déjà installé sur le serveur (pcs doit être installé au préalable) :

pcs stonith list

Si l'agent nécessaire n'est pas dans la liste, il faut l'installer.
Une petite liste de correspondance des agents à utiliser selon l'architecture cible, ce serait vraiment royal

Oui, effectivement, le fencing est souvent compliqué à mettre en œuvre la première fois quand on découvre le principe. J'imagine que ça aurait plus sa place dans la page de documentation concernant le fencing justement et qui est pointée dans les pages de "Quick Start": https://dalibo.github.io/PAF/fencing.html

D'ailleurs, si vous avez un bout de doc concernant le fencing avec vmWare, je suis preneur pour l'intégrer dans cette page.

2 - corosync.conf
Après l'installation de corsync, le processus refuse de se lancer car il ne trouve pas le fichier corosync.conf.
Il faut donc le créer vide :

cp /etc/corosync/corosync.conf.example /etc/corosync/corosync.conf

Alors ça c'est bizarre. L'une des grandes force ce pcs/pcsd est justement de ne pas avoir à toucher à ce fichier une seule fois. Tout se fait directement en ligne de commande avec pcs.

Le fichier corosync.conf est normalement généré par la commande "pcs cluster setup [...]" indiquée dans le quick start.

3 - recovery.conf.pcmk :
il manque la commande "restore_command = 'xxxxxxxxx' "

"Normal". La page de quick start n'a pas vocation à détailler la configuration et mise en œuvre de la réplication PostgreSQL. D'autant que le log shipping n'est pas du tout obligatoire dans le cadre de la réplication. Le quick start étant un "pied à l'étrier", nous avons fait le choix de la simplicité et de nous en passer afin d'éviter que le quick start ne devienne un "long and laborious start"

Et puis le log shipping requiers le plus souvent plusieurs prises de décisions concernant l'architecture (pousser les WAL ? Les tirer ? montage NFS ? SSH ? ...).

4 - pg_hba.conf :
Je me suis fait avoir sur cette partie. Il faut ajouter les lignes de la doc avant les autres lignes déjà existantes.
Il faut bien comprendre que le pg_hba.conf "avant PAF" doit fonctionner correctement pour la réplication et les connections applicatives.
Évidemment ne pas oublier d'alimenter le .pgpass si on est en authentification md5 (par exemple).
La partie mise en place de la replication postgresql dans la doc peut porter à confusion.
Par exemple, ça ne marchera pas si on ne met que ces 3 lignes dans le pg_hba.conf :

host replication postgres 192.168.122.50/32 reject
host replication postgres $(hostname -s) reject
host replication postgres 0.0.0.0/0 trust

Il manque au minimum les connexions "local"

Le quick start part du fichier pg_hba.conf par défaut, possédant déjà les connexions locales. Les commandes indiquées ne font qu'ajouter à la fin les règles concernant la réplication.

Néanmoins, je retiens que le chapitre sur PostgreSQL est peut-être un peu trop expéditif (malgré l'avertissement en début de chapitre). Je vais voir à l'étoffer un peu en tenant compte de ces remarques.

5 - clef d'authentification pour corosync :
Je ne sais plus exactement pourquoi, mais à un moment donné j'ai eu une erreur et en lisant la doc officielle de corosync, j'ai vu qu'il fallait créer une clef pour que les processus distants puissent dialoguer.
Je ne sais pas si c'est réellement indispensable mais dans mon cas ça m'a débloqué.

cd /etc/corosync
corosync-keygen
chown root:root /etc/corosync/authkey
chmod 400 /etc/corosync/authkey
+ copier la clef sur l'autre serveur dans /etc/corosync/

Ce n'est pas nécessaire. Toute cette partie corosync me semble bizarre étant donné que sous les EL7, dans 90% des cas, il n'est plus nécessaire d'y toucher comme je l'indiquais plus tôt.

Voir le quick start sous Debian 8 (où le corosync.conf n'est pas généré par l'outil client) pour un exemple de fichier corosync, sans clé d'authentification.

6 - STONITH resources :
Le point le plus compliqué à mettre en oeuvre car les paramètres ne sont pas très intuitifs.
Une petite explication de chaque paramètre aurait été un vrai plus (vous me direz : RTFM...)
Ce qui m'a aidé : lancer la commande de fencing directement en mode verbeux et avant de créer la ressource pour voir ce qui ne va pas.
Par exemple dans le cadre de vmware :

fence_vmware_soap --action=status --ip=(ip de l'hyperviseur) --plug=(nom du serveur tel qu'il est vu par l'hyperviseur) --username=(user créer dans l'hyperviseur qui a les droits d'agir sur la vm) --password=(passwd de ce user) --ssl --ssl-insecure -v
(ssl-insecure : si on a des problème de certificat sur l'hyperviseur)

Les paramètres de la commande de fencing correspondent à ceci dans la commande de création de la ressource stonith :

pcmk_host_list = hostname complet du serveur
ipaddr = --ip
port = --plug
login = --username
passwd = --password
action = --action

C'est peut-être dans la page consacrée au fencing que ça aurait sa place donc.

dans la création de la ressource que signifie INFINITY ?

RTFM ?

Ce  n'est pas la création de la ressource mais de la contrainte de positionnement. Avec une contrainte de location "avoids", plus le score est élevé, et plus la ressource évitera le nœud. Ici, "avoids srv1=INFINITY" signifie que la ressource ne doit jamais se trouver sur ce nœud.

Notez qu'il est possible d'inverser le résonnement en remplaçant "avoids" par "prefers". Auquel cas, plus le score est élevé, plus la ressource préférera démarrer sur le nœud indiqué.

7 - resource pgsqld :
Il faudrait décrire ce que signifie :

master-max
master-node-max
clone-max
clone-node-max
notify

La aussi je me suis fait avoir.

Bien vu, je vais détailler un peu cette partie.

Pour le reste, c'était clair.

Quelques commande qui pourrait aider à comprendre et débugger l'installation :

pcs status --full
crm_mon -Afr -1
corosync-cfgtool -s
pcs property show
pcs resource show --full
traces corosync dans /var/log/cluster/corosync.log

En tout cas merci encore pour votre aide et votre travail sur ce produit.

Merci à vous d'avoir prit le temps d'écrire ce long message de retour, bien détaillé et intéressant. Je ferais évoluer la doc quand j'aurais un peu de temps à y consacrer.