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 trustIl 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
notifyLa 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.logEn 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.
]]>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.
]]>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 !
]]>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.
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.
]]>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".
]]>Merci en tout cas pour vos conseils :-)
-------------------------------------------------------
[MAJ après corrections]
-------------------------------------------------------
Après avoir appliquer les dernières recommandations de ioguix, le cluster fonctionne :-)
[root@pouj-pgsql-3 corosync]# pcs status --full
Cluster name: cluster_xxx
Stack: corosync
Current DC: pouj-pgsql-3.xxx.lan (1) (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
Last updated: Sun Mar 19 11:59:00 2017 Last change: Sun Mar 19 11:53:22 2017 by root via crm_attribute on pouj-pgsql-3.xxx.lan2 nodes and 6 resources configured
Online: [ pouj-pgsql-3.xxx.lan (1) pouj-pgsql-4.xxx.lan (2) ]
Full list of resources:
fence_vm_pouj-pgsql-3.xxx.lan (stonith:fence_vmware_soap): Started pouj-pgsql-4.xxx.lan
fence_vm_pouj-pgsql-4.xxx.lan (stonith:fence_vmware_soap): Started pouj-pgsql-3.xxx.lan
pgsql-master-ip (ocf::heartbeat:IPaddr2): Started pouj-pgsql-3.xxx.lan
Master/Slave Set: pgsql-ha [pgsqld]
pgsqld (ocf::heartbeat:pgsqlms): Master pouj-pgsql-3.xxx.lan
pgsqld (ocf::heartbeat:pgsqlms): Slave pouj-pgsql-4.xxx.lan
pgsqld (ocf::heartbeat:pgsqlms): Stopped
Masters: [ pouj-pgsql-3.xxx.lan ]
Slaves: [ pouj-pgsql-4.xxx.lan ]Node Attributes:
* Node pouj-pgsql-3.xxx.lan (1):
+ master-pgsqld : 1001
* Node pouj-pgsql-4.xxx.lan (2):
+ master-pgsqld : 1000Migration Summary:
* Node pouj-pgsql-3.xxx.lan (1):
fence_vm_pouj-pgsql-4.xxx.lan: migration-threshold=5 fail-count=1 last-failure='Sun Mar 19 11:07:07 2017'
* Node pouj-pgsql-4.xxx.lan (2):Failed Actions:
* fence_vm_pouj-pgsql-4.xxx.lan_monitor_60000 on pouj-pgsql-3.xxx.lan 'not running' (7): call=75, status=complete, exitreason='none',
last-rc-change='Sun Mar 19 11:07:07 2017', queued=0ms, exec=1msPCSD Status:
pouj-pgsql-3.xxx.lan: Online
pouj-pgsql-4.xxx.lan: OnlineDaemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
Je me demande par contre pourquoi le heartbeat est "stopped".
]]>Notez que je suis disposé à vous aider, mais disons que votre question sur le PGDATA m'a fait pensé que vous n'aviez pas lu la documentation. Plutôt que de longue phrases ici, autant profiter de la documentation que nous avons mis du temps à écrire
Pour le reste, si les pg_hba.conf présentés ici sont complets, il y a plusieurs erreurs. Pour commencer, les messages suivants de PostgreSQL indiquent qu'une connexion via un socket unix local est refusée car aucune ligne ne correspond dans le pg_hba:
FATAL: no pg_hba.conf entry for host "[local]", user "postgres", database "postgres", SSL off
J'imagine que ces connexions viennent de PAF...
Rajoutez donc en début de fichier la ligne suivante:
local all postgres peer
Reste que ça ne laisse pas beaucoup de place pour les connexions distantes d'une applications...
Ensuite, il semble que sur "pouj-pgsql-4", vous rejetiez les connexions de réplication non pas de "pouj-pgsql-4", mais de "pouj-pgsql-3"...
]]>Je crois que je suis allé au bout de ce que je pouvais faire en relisant toutes les docs que je pouvais et en repointant tous les prérequis.
Tout fonctionne (fencing, ip virtuelle) mais dès que je créai les resources postgresql, c'est la cata...
Si vous pouviez me donner un dernier coup de main ? Après je laisse tomber.
Voici les infos recueillies :
pouj-pgsql-3 :
traces postgresql (décalage d'1 heure car log_timezone non définit dans postgresql.conf)
2017-03-18 17:02:08 GMT [5234]: [3-1] user=,db= LOG: restored log file "000000010000003F000000B5" from archive
2017-03-18 17:02:08 GMT [5234]: [4-1] user=,db= LOG: consistent recovery state reached at 3F/B5000090
2017-03-18 17:02:08 GMT [5234]: [5-1] user=,db= LOG: record with zero length at 3F/B5000090
2017-03-18 17:02:08 GMT [5232]: [3-1] user=,db= LOG: database system is ready to accept read only connections
2017-03-18 17:02:08 GMT [5271]: [1-1] user=,db= LOG: started streaming WAL from primary at 3F/B5000000 on timeline 1
2017-03-18 17:02:09 GMT [5289]: [1-1] user=postgres,db=postgres FATAL: no pg_hba.conf entry for host "[local]", user "postgres", database "postgres", SSL off
2017-03-18 17:02:09 GMT [5291]: [1-1] user=postgres,db=postgres FATAL: no pg_hba.conf entry for host "[local]", user "postgres", database "postgres", SSL off
2017-03-18 17:02:09 GMT [5293]: [1-1] user=postgres,db=postgres FATAL: no pg_hba.conf entry for host "[local]", user "postgres", database "postgres", SSL off
2017-03-18 17:02:09 GMT [5337]: [1-1] user=postgres,db=postgres FATAL: no pg_hba.conf entry for host "[local]", user "postgres", database "postgres", SSL off
2017-03-18 17:02:09 GMT [5339]: [1-1] user=postgres,db=postgres FATAL: no pg_hba.conf entry for host "[local]", user "postgres", database "postgres", SSL off
2017-03-18 17:03:09 GMT [5300]: [1-1] user=postgres,db=[unknown] LOG: terminating walsender process due to replication timeout
pg_hba.conf :
host replication postgres 172.31.3.99/32 reject
host replication postgres pouj-pgsql-3 reject
host replication postgres 0.0.0.0/0 trust
[root@pouj-pgsql-3 cluster]# grep "^pgsqlms" /var/log/cluster/corosync.log
pgsqlms(pgsqld)[5215]: 2017/03/18_18:02:09 ERROR: _confirm_role: psql could not connect to instance "pgsqld"
pgsqlms(pgsqld)[5215]: 2017/03/18_18:02:09 ERROR: pgsql_start: instance "pgsqld" is not running as a slave (returned 1)
pgsqlms(pgsqld)[5327]: 2017/03/18_18:02:09 ERROR: _confirm_role: psql could not connect to instance "pgsqld"
pgsqlms(pgsqld)[5327]: 2017/03/18_18:02:09 WARNING: pgsql_stop: unexpected state for instance "pgsqld" (returned 1)
[root@pouj-pgsql-3 cluster]# grep error corosync.log
Mar 18 18:02:09 [1826] pouj-pgsql-3.xxx.lan crmd: notice: process_lrm_event: Result of start operation for pgsqld on pouj-pgsql-3.xxx.lan: 1 (unknown error) | call=111 key=pgsqld_start_0 confirmed=true cib-update=100
Mar 18 18:02:09 [1826] pouj-pgsql-3.xxx.lan crmd: info: process_graph_event: Detected action (49.12) pgsqld_start_0.111=unknown error: failed
Mar 18 18:02:09 [1826] pouj-pgsql-3.xxx.lan crmd: info: process_graph_event: Detected action (49.12) pgsqld_start_0.111=unknown error: failed
Mar 18 18:02:09 [1826] pouj-pgsql-3.xxx.lan crmd: info: process_graph_event: Detected action (49.14) pgsqld_start_0.21=unknown error: failed
Mar 18 18:02:09 [1826] pouj-pgsql-3.xxx.lan crmd: info: process_graph_event: Detected action (49.14) pgsqld_start_0.21=unknown error: failed
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: unpack_rsc_op_failure: Processing failed op start for pgsqld:0 on pouj-pgsql-3.xxx.lan: unknown error (1)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: unpack_rsc_op_failure: Processing failed op start for pgsqld:0 on pouj-pgsql-3.xxx.lan: unknown error (1)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: unpack_rsc_op_failure: Processing failed op start for pgsqld:1 on pouj-pgsql-4.xxx.lan: unknown error (1)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: unpack_rsc_op_failure: Processing failed op start for pgsqld:1 on pouj-pgsql-4.xxx.lan: unknown error (1)
Mar 18 18:02:09 [1826] pouj-pgsql-3.xxx.lan crmd: notice: process_lrm_event: Result of stop operation for pgsqld on pouj-pgsql-3.xxx.lan: 1 (unknown error) | call=114 key=pgsqld_stop_0 confirmed=true cib-update=102
Mar 18 18:02:09 [1826] pouj-pgsql-3.xxx.lan crmd: info: process_graph_event: Detected action (50.3) pgsqld_stop_0.114=unknown error: failed
Mar 18 18:02:09 [1826] pouj-pgsql-3.xxx.lan crmd: info: process_graph_event: Detected action (50.3) pgsqld_stop_0.114=unknown error: failed
Mar 18 18:02:09 [1826] pouj-pgsql-3.xxx.lan crmd: info: process_graph_event: Detected action (50.5) pgsqld_stop_0.24=unknown error: failed
Mar 18 18:02:09 [1826] pouj-pgsql-3.xxx.lan crmd: info: process_graph_event: Detected action (50.5) pgsqld_stop_0.24=unknown error: failed
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: unpack_rsc_op_failure: Processing failed op stop for pgsqld:0 on pouj-pgsql-3.xxx.lan: unknown error (1)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: unpack_rsc_op_failure: Processing failed op stop for pgsqld:0 on pouj-pgsql-3.xxx.lan: unknown error (1)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: unpack_rsc_op_failure: Processing failed op stop for pgsqld:1 on pouj-pgsql-4.xxx.lan: unknown error (1)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: unpack_rsc_op_failure: Processing failed op stop for pgsqld:1 on pouj-pgsql-4.xxx.lan: unknown error (1)
Mar 18 18:02:20 [1824] pouj-pgsql-3.xxx.lan stonith-ng: error: remote_op_done: Operation reboot of pouj-pgsql-3.xxx.lan by <no-one> for crmd.1826@pouj-pgsql-3.xxx.lan.9239a0fd: No such device
[root@pouj-pgsql-3 cluster]# grep warning corosync.log
Mar 18 18:02:09 [1826] pouj-pgsql-3.xxx.lan crmd: warning: status_from_rc: Action 12 (pgsqld:0_start_0) on pouj-pgsql-3.xxx.lan failed (target: 0 vs. rc: 1): Error
Mar 18 18:02:09 [1826] pouj-pgsql-3.xxx.lan crmd: warning: status_from_rc: Action 12 (pgsqld:0_start_0) on pouj-pgsql-3.xxx.lan failed (target: 0 vs. rc: 1): Error
Mar 18 18:02:09 [1826] pouj-pgsql-3.xxx.lan crmd: warning: status_from_rc: Action 14 (pgsqld:1_start_0) on pouj-pgsql-4.xxx.lan failed (target: 0 vs. rc: 1): Error
Mar 18 18:02:09 [1826] pouj-pgsql-3.xxx.lan crmd: warning: status_from_rc: Action 14 (pgsqld:1_start_0) on pouj-pgsql-4.xxx.lan failed (target: 0 vs. rc: 1): Error
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: unpack_rsc_op_failure: Processing failed op monitor for fence_vm_pouj-pgsql-4.xxx.lan on pouj-pgsql-3.xxx.lan: not running (7)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: unpack_rsc_op_failure: Processing failed op start for pgsqld:0 on pouj-pgsql-3.xxx.lan: unknown error (1)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: unpack_rsc_op_failure: Processing failed op start for pgsqld:0 on pouj-pgsql-3.xxx.lan: unknown error (1)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: unpack_rsc_op_failure: Processing failed op start for pgsqld:1 on pouj-pgsql-4.xxx.lan: unknown error (1)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: unpack_rsc_op_failure: Processing failed op start for pgsqld:1 on pouj-pgsql-4.xxx.lan: unknown error (1)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: check_migration_threshold: Forcing pgsql-ha away from pouj-pgsql-3.xxx.lan after 1000000 failures (max=5)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: check_migration_threshold: Forcing pgsql-ha away from pouj-pgsql-3.xxx.lan after 1000000 failures (max=5)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: check_migration_threshold: Forcing pgsql-ha away from pouj-pgsql-3.xxx.lan after 1000000 failures (max=5)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: check_migration_threshold: Forcing pgsql-ha away from pouj-pgsql-4.xxx.lan after 1000000 failures (max=5)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: check_migration_threshold: Forcing pgsql-ha away from pouj-pgsql-4.xxx.lan after 1000000 failures (max=5)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: check_migration_threshold: Forcing pgsql-ha away from pouj-pgsql-4.xxx.lan after 1000000 failures (max=5)
Mar 18 18:02:09 [1826] pouj-pgsql-3.xxx.lan crmd: warning: status_from_rc: Action 3 (pgsqld_stop_0) on pouj-pgsql-3.xxx.lan failed (target: 0 vs. rc: 1): Error
Mar 18 18:02:09 [1826] pouj-pgsql-3.xxx.lan crmd: warning: status_from_rc: Action 3 (pgsqld_stop_0) on pouj-pgsql-3.xxx.lan failed (target: 0 vs. rc: 1): Error
Mar 18 18:02:09 [1826] pouj-pgsql-3.xxx.lan crmd: warning: status_from_rc: Action 5 (pgsqld_stop_0) on pouj-pgsql-4.xxx.lan failed (target: 0 vs. rc: 1): Error
Mar 18 18:02:09 [1826] pouj-pgsql-3.xxx.lan crmd: warning: status_from_rc: Action 5 (pgsqld_stop_0) on pouj-pgsql-4.xxx.lan failed (target: 0 vs. rc: 1): Error
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: unpack_rsc_op_failure: Processing failed op monitor for fence_vm_pouj-pgsql-4.xxx.lan on pouj-pgsql-3.xxx.lan: not running (7)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: unpack_rsc_op_failure: Processing failed op stop for pgsqld:0 on pouj-pgsql-3.xxx.lan: unknown error (1)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: unpack_rsc_op_failure: Processing failed op stop for pgsqld:0 on pouj-pgsql-3.xxx.lan: unknown error (1)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: pe_fence_node: Node pouj-pgsql-3.xxx.lan will be fenced because of resource failure(s)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: unpack_rsc_op_failure: Processing failed op stop for pgsqld:1 on pouj-pgsql-4.xxx.lan: unknown error (1)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: unpack_rsc_op_failure: Processing failed op stop for pgsqld:1 on pouj-pgsql-4.xxx.lan: unknown error (1)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: pe_fence_node: Node pouj-pgsql-4.xxx.lan will be fenced because of resource failure(s)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: check_migration_threshold: Forcing pgsql-ha away from pouj-pgsql-3.xxx.lan after 1000000 failures (max=5)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: check_migration_threshold: Forcing pgsql-ha away from pouj-pgsql-3.xxx.lan after 1000000 failures (max=5)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: check_migration_threshold: Forcing pgsql-ha away from pouj-pgsql-3.xxx.lan after 1000000 failures (max=5)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: check_migration_threshold: Forcing pgsql-ha away from pouj-pgsql-4.xxx.lan after 1000000 failures (max=5)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: check_migration_threshold: Forcing pgsql-ha away from pouj-pgsql-4.xxx.lan after 1000000 failures (max=5)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: check_migration_threshold: Forcing pgsql-ha away from pouj-pgsql-4.xxx.lan after 1000000 failures (max=5)
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: stage6: Scheduling Node pouj-pgsql-3.xxx.lan for STONITH
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: stage6: Scheduling Node pouj-pgsql-4.xxx.lan for STONITH
Mar 18 18:02:09 [16703] pouj-pgsql-3.xxx.lan pengine: warning: process_pe_message: Calculated transition 51 (with warnings), saving inputs in /var/lib/pacemaker/pengine/pe-warn-21.bz2
Mar 18 18:02:20 [1824] pouj-pgsql-3.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[5342] stderr: [ /usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html ]
Mar 18 18:02:20 [1824] pouj-pgsql-3.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[5342] stderr: [ InsecureRequestWarning) ]
Mar 18 18:02:36 [1824] pouj-pgsql-3.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[5537] stderr: [ /usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html ]
Mar 18 18:02:36 [1824] pouj-pgsql-3.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[5537] stderr: [ InsecureRequestWarning) ]
Mar 18 18:03:44 [1824] pouj-pgsql-3.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[5889] stderr: [ /usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html ]
Mar 18 18:03:44 [1824] pouj-pgsql-3.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[5889] stderr: [ InsecureRequestWarning) ]
Mar 18 18:04:51 [1824] pouj-pgsql-3.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[6193] stderr: [ /usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html ]
Mar 18 18:04:51 [1824] pouj-pgsql-3.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[6193] stderr: [ InsecureRequestWarning) ]
Mar 18 18:05:59 [1824] pouj-pgsql-3.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[6544] stderr: [ /usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html ]
Mar 18 18:05:59 [1824] pouj-pgsql-3.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[6544] stderr: [ InsecureRequestWarning) ]
Mar 18 18:07:06 [1824] pouj-pgsql-3.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[6920] stderr: [ /usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html ]
Mar 18 18:07:06 [1824] pouj-pgsql-3.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[6920] stderr: [ InsecureRequestWarning) ]
Mar 18 18:08:14 [1824] pouj-pgsql-3.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[7282] stderr: [ /usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html ]
Mar 18 18:08:14 [1824] pouj-pgsql-3.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[7282] stderr: [ InsecureRequestWarning) ]
Mar 18 18:09:21 [1824] pouj-pgsql-3.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[7586] stderr: [ /usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html ]
Mar 18 18:09:21 [1824] pouj-pgsql-3.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[7586] stderr: [ InsecureRequestWarning) ]
Mar 18 18:10:28 [1824] pouj-pgsql-3.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[7936] stderr: [ /usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html ]
Mar 18 18:10:28 [1824] pouj-pgsql-3.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[7936] stderr: [ InsecureRequestWarning) ]
pouj-pgsql-4 :
pas de traces postgresql
pg_hba.conf :
host replication postgres 172.31.3.99/32 reject
host replication postgres pouj-pgsql-3 reject
host replication postgres 0.0.0.0/0 trust
[root@pouj-pgsql-4 cluster]# grep "^pgsqlms" /var/log/cluster/corosync.log
[root@pouj-pgsql-4 cluster]#
[root@pouj-pgsql-4 cluster]# grep error /var/log/cluster/corosync.log
[root@pouj-pgsql-4 cluster]#
[root@pouj-pgsql-4 cluster]# grep warning /var/log/cluster/corosync.log
Mar 18 18:01:12 [15463] pouj-pgsql-4.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[15494] stderr: [ /usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html ]
Mar 18 18:01:12 [15463] pouj-pgsql-4.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[15494] stderr: [ InsecureRequestWarning) ]
Mar 18 18:01:21 [15463] pouj-pgsql-4.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[15601] stderr: [ /usr/lib/python2.7/site-packages/urllib3/connectionpool.py:769: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html ]
Mar 18 18:01:21 [15463] pouj-pgsql-4.xxx.lan stonith-ng: warning: log_action: fence_vmware_soap[15601] stderr: [ InsecureRequestWarning) ]
que doit-on mettre dans "pgdata" ?
est-ce le répertoire où on trouve le postgresql.conf, les repertoires pg_xxlog, pg_clog, pg_tblspc, etc... ?
Je me permets de vous rediriger vers le chapitre concerné dans la documentation... : http://dalibo.github.io/PAF/configurati … parameters
Et plus globalement, pensez à revoir cette page en entier à propos des autres pré-requis ou configuration à respecter.
Encore une fois, si l'ensemble de la documentation n'est pas suffisante (les pages d'installation, configuration, fencing, les admin cookbook, les quick start), n'hésitez pas à l'étoffer ou à proposer des améliorations.
++
]]>Après création des ressources postgresql, j'obtiens ceci :
[root@pouj-pgsql-3 corosync]# pcs status --full
Cluster name: cluster_xxx
Stack: corosync
Current DC: pouj-pgsql-4.xxx.lan (2) (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
Last updated: Fri Mar 17 10:39:12 2017 Last change: Fri Mar 17 10:38:38 2017 by root via cibadmin on pouj-pgsql-3.xxx.lan2 nodes and 6 resources configured
Online: [ pouj-pgsql-3.xxx.lan (1) pouj-pgsql-4.xxx.lan (2) ]
Full list of resources:
fence_vm_pouj-pgsql-3.xxx.lan (stonith:fence_vmware_soap): Started pouj-pgsql-4.xxx.lan
fence_vm_pouj-pgsql-4.xxx.lan (stonith:fence_vmware_soap): Started pouj-pgsql-3.xxx.lan
pgsql-master-ip (ocf::heartbeat:IPaddr2): Started pouj-pgsql-3.xxx.lan
Master/Slave Set: pgsql-ha [pgsqld]
pgsqld (ocf::heartbeat:pgsqlms): Slave pouj-pgsql-4.xxx.lan
pgsqld (ocf::heartbeat:pgsqlms): Stopped
pgsqld (ocf::heartbeat:pgsqlms): Stopped
Slaves: [ pouj-pgsql-4.xxx.lan ]
Stopped: [ pouj-pgsql-3.xxx.lan ]Node Attributes:
* Node pouj-pgsql-3.xxx.lan (1):
* Node pouj-pgsql-4.xxx.lan (2):Migration Summary:
* Node pouj-pgsql-4.xxx.lan (2):
fence_vm_pouj-pgsql-3.xxx.lan: migration-threshold=5 fail-count=1 last-failure='Fri Mar 17 09:37:34 2017'
* Node pouj-pgsql-3.xxx.lan (1):
fence_vm_pouj-pgsql-4.xxx.lan: migration-threshold=5 fail-count=1 last-failure='Fri Mar 17 09:37:44 2017'Failed Actions:
* fence_vm_pouj-pgsql-3.xxx.lan_monitor_60000 on pouj-pgsql-4.xxx.lan 'unknown error' (1): call=37, status=Timed Out, exitreason='none',
last-rc-change='Fri Mar 17 09:37:14 2017', queued=0ms, exec=20019ms
* fence_vm_pouj-pgsql-4.xxx.lan_monitor_60000 on pouj-pgsql-3.xxx.lan 'unknown error' (1): call=17, status=Timed Out, exitreason='none',
last-rc-change='Fri Mar 17 09:37:24 2017', queued=0ms, exec=20015msPCSD Status:
pouj-pgsql-3.xxx.lan: Online
pouj-pgsql-4.xxx.lan: OnlineDaemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
et juste après la VM pouj-pgsql-3 s'arrête (commande halt envoyé par pacemaker ou corosync ou pcs, je ne sais pas).
les traces de corosync sur pgsqlms :
[root@pouj-pgsql-3 corosync]# grep "^pgsqlms" /var/log/cluster/corosync.log
[root@pouj-pgsql-3 corosync]#
-----------------------------------------------------------------------------
[root@pouj-pgsql-4 corosync]# grep "^pgsqlms" /var/log/cluster/corosync.log
pgsqlms(pgsqld)[1207]: 2017/03/17_10:38:42 INFO: pgsql_start: instance "pgsqld" started
il y a aussi ça qui me pose problème :
pcs -f cluster1.xml resource create pgsqld ocf:heartbeat:pgsqlms \
bindir=/logiciels/postgres/product/9.3/bin pgdata=/xxx/admin \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=30s \
op demote timeout=120s \
op monitor interval=15s timeout=10s role="Master" \
op monitor interval=16s timeout=10s role="Slave" \
op notify timeout=60s \
que doit-on mettre dans "pgdata" ?
est-ce le répertoire où on trouve le postgresql.conf, les repertoires pg_xxlog, pg_clog, pg_tblspc, etc... ?
Ce paramètre est mauvais: "clone-node-max=2 ". Vous ne pouvez pas avoir deux instances fait parti du même groupe de réplication sur le même nœud...
Pour le reste, isolez les lignes qui commencent par "pgsqlms" dans vos logs, ce sont tous les messages de l'agent PAF lui même. Vous y trouverez peut-être d'autres réponses.
]]>J'ai pas mal avancé : le fencing fontionne enfin, les nodes sont online du point de vue pcs et l'adresse ip virtuelle est ok :
[root@pouj-pgsql-3 ~]# pcs status --full
Cluster name: cluster_xxx
Stack: corosync
Current DC: pouj-pgsql-3.xxx.lan (1) (version 1.1.15-11.el7_3.4-e174ec8) - partition with quorum
Last updated: Thu Mar 16 14:09:38 2017 Last change: Thu Mar 16 13:54:49 2017 by root via cibadmin on pouj-pgsql-3.xxx.lan2 nodes and 3 resources configured
Online: [ pouj-pgsql-3.xxx.lan (1) pouj-pgsql-4.xxx.lan (2) ]
Full list of resources:
fence_vm_pouj-pgsql-3.xxx.lan (stonith:fence_vmware_soap): Started pouj-pgsql-4.xxx.lan
fence_vm_pouj-pgsql-4.xxx.lan (stonith:fence_vmware_soap): Started pouj-pgsql-3.xxx.lan
pgsql-master-ip (ocf::heartbeat:IPaddr2): Started pouj-pgsql-3.xxx.lanNode Attributes:
* Node pouj-pgsql-3.xxx.lan (1):
* Node pouj-pgsql-4.xxx.lan (2):Migration Summary:
* Node pouj-pgsql-4.xxx.lan (2):
* Node pouj-pgsql-3.xxx.lan (1):
fence_vm_pouj-pgsql-4.xxx.lan: migration-threshold=5 fail-count=1 last-failure='Thu Mar 16 13:47:25 2017'Failed Actions:
* fence_vm_pouj-pgsql-4.xxx.lan_monitor_60000 on pouj-pgsql-3.xxx.lan 'not running' (7): call=17, status=complete, exitreason='none',
last-rc-change='Thu Mar 16 13:47:25 2017', queued=0ms, exec=0msPCSD Status:
pouj-pgsql-4.xxx.lan: Online
pouj-pgsql-3.xxx.lan: OnlineDaemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
Par contre dès que je créer les ressources pour postgresql, ça se gatte : le serveur pouj-pgsql-3 s'arrête et l'instance sur pouj-pgsql-4 est démarrée mais en mode recovery.
voici les commandes passées pour créer les ressources de postgresql :
# pgsqld
pcs -f cluster1.xml resource create pgsqld ocf:heartbeat:pgsqlms \
bindir=/logiciels/postgres/product/9.3/bin pgdata=/xxx/admin \
op start timeout=60s \
op stop timeout=60s \
op promote timeout=30s \
op demote timeout=120s \
op monitor interval=15s timeout=10s role="Master" \
op monitor interval=16s timeout=10s role="Slave" \
op notify timeout=60s \# pgsql-ha
pcs -f cluster1.xml resource master pgsql-ha pgsqld \
master-max=1 master-node-max=1 \
clone-max=3 clone-node-max=2 notify=true
pcs -f cluster1.xml constraint colocation add pgsql-master-ip with master pgsql-ha INFINITY;
pcs -f cluster1.xml constraint order promote pgsql-ha then start pgsql-master-ip symmetrical=false;
pcs -f cluster1.xml constraint order demote pgsql-ha then stop pgsql-master-ip symmetrical=false;
En recommençant depuis le début step by step, je constate ça :
Dès que je créai la ressource pgsqld, l'instance sur pouj-pgsql-4 est démarrée mais pas celle de pouj-pgsql-3 :
2 nodes and 4 resources configured
Online: [ pouj-pgsql-3.xxx.lan (1) pouj-pgsql-4.xxx.lan (2) ]
Full list of resources:
fence_vm_pouj-pgsql-3.xxx.lan (stonith:fence_vmware_soap): Started pouj-pgsql-4.xxx.lan
fence_vm_pouj-pgsql-4.xxx.lan (stonith:fence_vmware_soap): Started pouj-pgsql-3.xxx.lan
pgsql-master-ip (ocf::heartbeat:IPaddr2): Started pouj-pgsql-3.xxx.lan
pgsqld (ocf::heartbeat:pgsqlms): Started pouj-pgsql-4.xxx.lan
extrait des log de corosync :
Mar 16 14:34:09 [16703] pouj-pgsql-3.xxx.lan pengine: info: LogActions: Leave fence_vm_pouj-pgsql-3.xxx.lan (Started pouj-pgsql-4.xxx.lan)
Mar 16 14:34:09 [16703] pouj-pgsql-3.xxx.lan pengine: info: LogActions: Leave fence_vm_pouj-pgsql-4.xxx.lan (Started pouj-pgsql-3.xxx.lan)
Mar 16 14:34:09 [16703] pouj-pgsql-3.xxx.lan pengine: info: LogActions: Leave pgsql-master-ip (Started pouj-pgsql-3.xxx.lan)
Mar 16 14:34:09 [16703] pouj-pgsql-3.xxx.lan pengine: notice: LogActions: Start pgsqld (pouj-pgsql-4.xxx.lan)
Mar 16 14:34:09 [16703] pouj-pgsql-3.xxx.lan pengine: notice: process_pe_message: Calculated transition 15, saving inputs in /var/lib/pacemaker/pengine/pe-input-8.bz2
Mar 16 14:34:09 [19963] pouj-pgsql-3.xxx.lan crmd: info: do_state_transition: State transition S_POLICY_ENGINE -> S_TRANSITION_ENGINE | input=I_PE_SUCCESS cause=C_IPC_MESSAGE origin=handle_response
Mar 16 14:34:09 [19963] pouj-pgsql-3.xxx.lan crmd: info: do_te_invoke: Processing graph 15 (ref=pe_calc-dc-1489671249-86) derived from /var/lib/pacemaker/pengine/pe-input-8.bz2
Mar 16 14:34:09 [19963] pouj-pgsql-3.xxx.lan crmd: notice: te_rsc_command: Initiating monitor operation pgsqld_monitor_0 on pouj-pgsql-4.xxx.lan | action 6
Mar 16 14:34:09 [19963] pouj-pgsql-3.xxx.lan crmd: notice: te_rsc_command: Initiating monitor operation pgsqld_monitor_0 locally on pouj-pgsql-3.xxx.lan | action 5
Mar 16 14:34:09 [16701] pouj-pgsql-3.xxx.lan lrmd: info: process_lrmd_get_rsc_info: Resource 'pgsqld' not found (3 active resources)
Mar 16 14:34:09 [16701] pouj-pgsql-3.xxx.lan lrmd: info: process_lrmd_rsc_register: Added 'pgsqld' to the rsc list (4 active resources)
Mar 16 14:34:09 [19963] pouj-pgsql-3.xxx.lan crmd: info: do_lrm_rsc_op: Performing key=5:15:7:09e12e8c-e581-4c7d-a45b-6945b91a1b83 op=pgsqld_monitor_0
Mar 16 14:34:09 [19963] pouj-pgsql-3.xxx.lan crmd: info: action_synced_wait: Managed pgsqlms_meta-data_0 process 24573 exited with rc=0
Mar 16 14:34:09 [19963] pouj-pgsql-3.xxx.lan crmd: notice: process_lrm_event: Result of probe operation for pgsqld on pouj-pgsql-3.xxx.lan: 7 (not running) | call=49 key=pgsqld_monitor_0 confirmed=true cib-update=173
Mar 16 14:34:09 [19963] pouj-pgsql-3.xxx.lan crmd: notice: process_lrm_event: pouj-pgsql-3.xxx.lan-pgsqld_monitor_0:49 [ /tmp:5432 - no response\npg_ctl: no server running\n ]
Dans quelle direction dois-je chercher ?
]]>Oui, d'autres l'ont fait, mais il faut utiliser l'agent de fencing "fence_vmware" dans ce cas et non "fence_virsh".
]]>Je travaille toujours dessus et je coince toujours à cause de cette partie :
pcs -f cluster1.xml stonith create fence_vm_pouj-pgsql-3.poujoulat.lan fence_virsh pcmk_host_check="static-list" pcmk_host_list="pouj-pgsql-3.xxx.lan" ipaddr="172.31.3.97" login="sru" port="pouj-pgsql-3" action="off" passwd="xxxxx";
pcs -f cluster1.xml stonith create fence_vm_pouj-pgsql-4.poujoulat.lan fence_virsh pcmk_host_check="static-list" pcmk_host_list="pouj-pgsql-4.xxx.lan" ipaddr="172.31.3.98" login="sru" port="pouj-pgsql-4" action="off" passwd="xxxxx";
J'attends toujours de mes admin système qu'il me donne ce user qui fait le lien entre les vm et vcenter pour faire le fencing. Mais ils sont...réticents...
Mais j'ai une question : est-ce que la doc d'install de PAF (https://dalibo.github.io/PAF/Quick_Start-CentOS-7.html) est applicable dans un environnement vmware ?
est-ce que quelqu'un l'a déjà fait ?
NOTA : les ip ci-dessus ont changées. C'est normal. J'ai déplacé les vm dans un autre esxi.
]]>