![\"twitter\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/twitter.png\" "\\"Share")
<\/a><\/a>![\"linkedin\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/linkedin.png\" "\\"Share")
<\/a>![\"mail\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/mail.png\" "\\"Share")
<\/a>Hello<\/p>\n
apr\u00e8s ces quelques mois d’absence li\u00e9s \u00e0 ces contraintes sanitaires, nous voici de retour pour un nouveau sujet AWS PostgreSQL.
\nNous avons r\u00e9cemment mis en place un cluster Haute Disponibilit\u00e9 chez un de nos clients en utilisant la solution PgPool-II.<\/p>\n
Ce produit a la particularit\u00e9 de g\u00e9rer de nombreux services, dont le pooling de connexions, mais aussi la haute disponibilit\u00e9 avec bascule d’IP virtuelle.<\/p>\n
Mais notre sujet du jour est de savoir comment configurer la solution Corosync \/ Pacemaker pour effecteur un “PostgreSQL Failover Automatic” sur des EC2 Amazon.<\/p>\n
De nombreux articles existent sur Internet pour la mise en place de ces fameux outils que sont Corosync et Pacemaker, bien connus du monde Unix.
\nCes derniers \u00e9tant largement utilis\u00e9s pour la gestion d’un serveur Web Apache ou Tomcat ou d’un serveur d’application, par exemple.<\/p>\n
Le SGBDR PostgreSQL est compatible avec cette solution de haute disponibilit\u00e9, cela en fait un serveur de bases de donn\u00e9es hautement disponible avec bascule rapide et automatique.<\/p>\n
<\/p>\n
Mais qu’en est-il de la gestion d’un PostgreSQL HD dans le cadre de l\u2019utilisation de VM AWS EC2 ?<\/p>\n
<\/p>\n
Rappelons que pour qu’une bascule via “fencing”, soit transparente, il est largement recommand\u00e9 d’installer une IP Virtuelle qui se d\u00e9clarera sur le noeud ou l’instance PostgreSQL est “primaire”. La solution Corosync \/ Pacemaker se chargera de basculer automatiquement les ressources associ\u00e9s, notamment PostgreSQL, et ainsi \u00e9viter un “split brain” (2 instances actives en m\u00eame temps).<\/p>\n
<\/p>\n
Dans notre exemple, nous partons avec 2 VM EC2 Amazon de type CentOS 7 install\u00e9es sur un subnet priv\u00e9.
\nCes VM ne sont donc pas accessibles via Internet, ce qui est recommand\u00e9 par les bonnes pratiques en mati\u00e8re de s\u00e9curit\u00e9 dans le cadre d’une architecture AWS\u00a0 pour un cluster de bases de donn\u00e9es.<\/p>\n
L’id\u00e9e est d’avoir ce sch\u00e9ma de connexions pour la mise en place de notre cluster<\/p>\n
<\/p>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2020\/09\/HD.jpg\")
<\/p>\n
<\/p>\n
Dans ce sch\u00e9ma, les IPs sont donn\u00e9es \u00e0 titre d’exemple.
\nTout au long de cette pr\u00e9sentation, nous travaillerons avec 2 VMs Amazon ayant les caract\u00e9ristiques suivantes :<\/p>\n
<\/p>\n
Nous avons install\u00e9s un cluster PostgreSQL version 12.4, avec la mise en place de la Streaming Replication. Cr\u00e9er les cl\u00e9s SSH pour root et pour postgres afin que les 2 serveurs n’aient pas \u00e0 saisir de password pour se connecter. <\/p>\n Service IAM<\/strong><\/span><\/p>\n Comme nous sommes sur des instances EC2 Amazon, nous devrons mettre \u00e0 jour nos strat\u00e9gies pour que nos VM puissent ex\u00e9cuter des op\u00e9rations sur les instances (arr\u00eat, red\u00e9marrage, changer une IP …). Nous verrons par la suite, en quoi consistent ces op\u00e9rations. Dans ce r\u00f4le, il faudra d\u00e9finir une nouvelle strat\u00e9gie, dans laquelle, chaque instance pourra effectuer les actions suivantes :<\/p>\n Cette strat\u00e9gie pourra comporter le document JSON suivant pour notre exemple :<\/p>\n Installer AWS CLI sur les EC2\u00a0<\/span><\/strong><\/p>\n Comme le cluster aura besoin d’agir directement par lignes de commandes sur les instances EC2 Amazon, il nous faudra l’outil AWS CLI sur les 2 VM. Notez que l’outil awscli est install\u00e9 dans \/usr\/local\/bin. Nous aurons besoin de connaitre ce “PATH” pour la suite. Par exemple, ici, connaitre le nom AWS de notre adaptateur r\u00e9seau de notre instance AWS.<\/p>\n Nos informations nous sont bien remont\u00e9es, nous pouvons alors d\u00e9buter l’installation du cluster.<\/p>\n <\/p>\n Chacune des actions suivantes devra \u00eatre effectu\u00e9e sur les 2 serveurs. Utiliser le compte root<\/strong> <\/span>pour l’installation des packages avec yum (Centos\/Red Hat).<\/p>\n Cela installera Corosync et Pacemaker ainsi que l’outil PCS qui sera tr\u00e8s utile pour l\u2019administration de notre cluster PGHD. et surtout, le package utilis\u00e9 dans le cadre d’un cluster sur des EC2 Amazon<\/p>\n L’installation de Corosync et Pacemaker a \u00e9galement cr\u00e9\u00e9 un nouveau compte syst\u00e8me nomm\u00e9 “hacluster”. Celui ci est utilis\u00e9 afin que tous les membres du cluster puissent communiquer ensemble. <\/p>\n Nous utiliserons l’outil PCS lanc\u00e9 via le daemon pcsd pour cr\u00e9er, configurer et administrer le cluster. Nous pourrons ainsi d\u00e9sactiver le d\u00e9marrage automatique des autres services, et ne laisser que pcsd actif lors du reboot de la VM EC2.<\/p>\n Notre cluster est maintenant install\u00e9, mais il n’est pas configur\u00e9. S’assurer que le daemon pcsd est bien d\u00e9marr\u00e9<\/p>\n <\/p>\n <\/p>\n V\u00e9rifier tout d’abord que les 2 VM communiquent bien ensemble via les cl\u00e9s SSH mises en place.<\/p>\n Nous sommes pr\u00eats \u00e0 configurer le cluster<\/p>\n Red\u00e9marrer le cluster complet<\/p>\n <\/p>\n La partie la plus critique pour un cluster est la partie fencing. Cette op\u00e9ration consiste a \u00e9vincer un n\u0153ud qui serait d\u00e9clar\u00e9 en \u00e9chec. La m\u00e9thode de fencing, forte mais radicale, est STONITH (Shoot The Other Node In The Head), le n\u0153ud d\u00e9clar\u00e9 en \u00e9chec est tout simplement red\u00e9marr\u00e9.<\/p>\n Tout d’abord, rep\u00e9rer l’id des 2 instance EC2 via la commande \u00e0 lancer sur les 2 VMs :<\/p>\n Une fois celles ci trouv\u00e9es, lancer la cr\u00e9ation du fencing :<\/p>\n Le fencing sera actif uniquement pour ces 2 instances EC2. La configuration a \u00e9t\u00e9 inscrite dans le fichier XML du cluster.<\/p>\n <\/p>\n Il s’agira de cr\u00e9er 4 ressources utilis\u00e9es pour la prise en charge de PostgreSQL Automatic Failover<\/p>\n Les cr\u00e9ations s’effectueront dans l’ordre suivant :<\/p>\n A noter que depuis la version 12 de PostgreSQL, il n’est plus n\u00e9cessaire de configurer le param\u00e8tre “recovery_template”, car il n’y a plus besoin de fichier “recovery.conf”. Les informations seront directement lues dans le fichier “postgresql.auto.conf”. Exemple pour le serveur ip-172-44-2-143<\/p>\n Une fois les informations concernant l’instance PostgreSQL cr\u00e9\u00e9s, nous cr\u00e9erons la ressource haute disponibilit\u00e9.<\/p>\n <\/p>\n Puis la partie Virtuelle IP noeud local et instance AWS. Nous affecterons ces 2 ressources dans un m\u00eame groupe nomm\u00e9 “aws-group”.<\/p>\n <\/p>\n Afin de configurer les d\u00e9pendances entre ces ressources, nous devrons nous appuyer sur les param\u00e8tres “colocation” et “order”. <\/p>\n Ordre de d\u00e9marrage en cas de “promote” de l’instance.<\/p>\n <\/p>\n Ordre d’arr\u00eat en cas de passage en mode standby.<\/p>\n <\/p>\n Cette configuration devra donc donner les informations suivantes avec un pcs status :<\/p>\n <\/p>\n Dans cette configuration, nous voyons bien que le n\u0153ud primaire est ip-172-44-2-143, celui ci porte la VIP syst\u00e8me et la seconde IP AWS. <\/p>\n et sur AWS<\/p>\n <\/p>\n <\/p>\n S’il l’on lance une connexion depuis un client PostgreSQL quelconque (exemple d’un VM dont l’IP est dans le m\u00eame subnet, \u00e0 savoir 172.44.2.194)<\/p>\n Nous avons donc r\u00e9aliser notre connexion sur la VIP 172.44.2.144 depuis une autre VM EC2 Amazon du m\u00eame subnet. Il suffira de jouer avec les “security groups” Amazon afin d’autoriser la connexion \u00e0 la VIP pour d’autres VMs d’un subnet diff\u00e9rent et pouvoir ainsi autoriser les connexions.<\/p>\n <\/p>\n Il sera tout \u00e0 fait possible d’effectuer un switchover d’instance PostgreSQL. <\/p>\n S’il l’on souhaite inverser les r\u00f4les, donc passer l’instance primaire sur ip-172-44-2-226, et la standby sur ip-172-44-2-143, nous lancerons la commande suivante;<\/p>\n <\/p>\n Dans le cas d’un cluster 3 noeuds et plus, ajouter \u00e0 la fin de la commande, le nom du noeud. <\/p>\n Nous remarquons \u00e9galement que la VIP locale et l’adresse IP secondaire Amazon ont bascul\u00e9es vers ip-172.44.2.226<\/p>\n <\/p>\n et sur AWS<\/p>\n <\/p>\n <\/p>\n Une connexion cliente viendra valider notre bascule. Notre connexion “repli” de l’instance standby se fait depuis ip-172-44-2-143.<\/p>\n <\/p>\n <\/p>\n <\/p>\n Lorsque nous avons effectu\u00e9 notre bascule de la ressource “pgsql-ha”, nous avons vu que nous sommes pass\u00e9s, pour l’instance PostgreSQL et la VIP, du noeud ip-172-44-2-143 vers ip-172-44-2-226.<\/p>\n En revanche, ce que nous voyons \u00e9galement, c’est que la ressource “clusterfence” est rest\u00e9e en mode master sur ip-172-44-2-143.<\/p>\n Cela veut dire que, au red\u00e9marrage complet du cluster, c’est ce n\u0153ud qui est configur\u00e9 comme master, et donc qui reprendra l’instance PostgreSQL en tant que primaire.<\/p>\n S’il l’on tente un fencing sur l’instance EC2 AWS ip-172-44-2-143.<\/p>\n Nous perdons imm\u00e9diatement la connexion au serveur ip-172-44-2-143. Celui ci doit red\u00e9marrer. <\/p>\n Il n’y a donc eu aucune interruption sur l’instance PostgreSQL. <\/p>\n Mais que se passe-t-il si c’est le n\u0153ud primaire qui “fence” ?<\/p>\n <\/p>\n <\/p>\n A noter que la commande met un peu plus de temps pour rendre la main, les op\u00e9rations en cours sont plus nombreuses. Et gr\u00e2ce \u00e0 PAF , aussit\u00f4t \u00e7a bascule !!<\/p>\n <\/p>\n <\/p>\n Le n\u0153ud ip-172-44-2-226 est not\u00e9 OFFLINE, mais nous r\u00e9cup\u00e9rons aussit\u00f4t l’instance primaire PostgreSQL sur ip-172-44-2-143.<\/p>\n Lorsque le n\u0153ud ip-172-44-2-226 a fini de red\u00e9marrer compl\u00e8tement, l’instance PostgreSQL passe en mode slave sur celui ci.<\/p>\n <\/p>\n <\/p>\n Une fois de plus, l’historique de fencing indique que tout s’est bien d\u00e9roul\u00e9<\/p>\n <\/p>\n <\/p>\n Gr\u00e2ce au package “fence-agents-aws” disponible dans les d\u00e9p\u00f4ts Red Hat CentOS, nous disposons d’une solution de fencing efficace dans le cadre de l’utilisation d’un cluster PostgreSQL HD sur des VM Amazon. <\/p>\n Il est \u00e9galement possible, gr\u00e2ce \u00e0 ce package, de travailler sur une Elastic IP :<\/p>\n <\/p>\n Cette Elastic IP pourra alors basculer d’une VM EC2 \u00e0 une autre dans le cadre du cluster. <\/p>\n @ bient\u00f4t<\/p>\n <\/p>\n Emmanuel RAMI<\/p>\n Hello apr\u00e8s ces quelques mois d’absence li\u00e9s \u00e0 ces contraintes sanitaires, nous voici de retour pour un nouveau sujet AWS PostgreSQL. Nous avons r\u00e9cemment mis en place un cluster Haute Disponibilit\u00e9 chez un de nos clients en utilisant la solution… Continuer la lecture
\nN’h\u00e9sitez pas \u00e0 consulter cet article<\/a> pour connaitre les \u00e9tapes \u00e0 suivre pour une mise en oeuvre.<\/p>\nConfiguration ssh<\/span><\/h4>\n
\nCeci est \u00e0 r\u00e9aliser sur les 2 VMs EC2<\/p>\n# cd ~\/.ssh\r\n# ssh-keygen -t rsa -f id_rsa\r\n# ssh-copy-id -i id_rsa.pub root@172.44.2.143\r\n# ssh-copy-id -i id_rsa.pub root@172.44.2.226\r\n\r\npostgres $ cd ~\/.ssh\r\npostgres $ ssh-keygen -t rsa -f id_rsa\r\npostgres $ ssh-copy-id -i id_rsa.pub postgres@172.44.2.143\r\npostgres $ ssh-copy-id -i id_rsa.pub postgres@172.44.2.226<\/pre>\n
Configuration AWS<\/span><\/h4>\n
\nDans la mesure du possible, et afin que vos instances EC2 respectent les fondamentaux en terme de s\u00e9curit\u00e9, il faudra vous cr\u00e9er un r\u00f4le IAM que vous affecterez \u00e0 vos 2 instances EC2.<\/p>\n\n
{\r\n\u00a0\u00a0\u00a0 \"Version\": \"2012-10-17\",\r\n\u00a0\u00a0\u00a0 \"Statement\": [\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 {\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"Sid\": \"VisualEditor0\",\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"Effect\": \"Allow\",\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"Action\": [\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"ec2:RebootInstances\",\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"ec2:DescribeInstances\",\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"ec2:DetachNetworkInterface\",\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"ec2:StartInstances\",\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"ec2:RunInstances\",\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"ec2:AssignPrivateIpAddresses\",\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"ec2:UnassignPrivateIpAddresses\",\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"ec2:AssociateAddress\",\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"ec2:StopInstances\"\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ],\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"Resource\": \"*\"\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 }\r\n\u00a0\u00a0\u00a0 ]\r\n}<\/pre>\n
\nNous pourrons l’installer gr\u00e2ce aux commandes suivantes :<\/p>\n# curl \"https:\/\/awscli.amazonaws.com\/awscli-exe-linux-x86_64.zip\" -o \"awscliv2.zip\"\r\n# unzip awscliv2.zip\r\n# cd aws\r\n# .\/install\r\n# aws --version<\/pre>\n
\nUne fois correctement configur\u00e9, lancez un “aws configure”. Puis interroger les caract\u00e9ristiques de votre instance pour valider la communication<\/p>\n# Instance_ID=`\/usr\/bin\/curl --silent http:\/\/169.254.169.254\/latest\/meta-data\/instance-id`\r\n# aws ec2 describe-instances --instance-ids $Instance_ID --region eu-west-3 | grep NetworkInterfaceId | awk -F '\"' '{print $4}'\r\neni-0e2b4ab8b3f9bc1fc\r\n\r\n<\/pre>\nInstallation des composants du cluster<\/h1>\n
# yum install -y pacemaker resource-agents pcs fence-agents-all<\/pre>\n
\nPar la suite il faudra installer le package li\u00e9 directement \u00e0 PostgreSQL Failover Automatic<\/p>\n# yum install -y resource-agents-paf<\/pre>\n
# yum install -y resource-agents-aws<\/pre>\n
\nIl faudra lui d\u00e9finir un password.<\/p>\n# password hacluster<\/pre>\n
\nCelui ci se chargera de modifier les fichiers de conf de Corosync, Pacemaker, mais aussi les ordres envoy\u00e9s \u00e0 AWS notamment pour le fencing.<\/p>\n# systemctl disable postgresql-12.service\r\n# systemctl disable corosync\r\n# systemctl disable pacemaker\r\n# systemctl enable pcsd.service\r\n# systemctl start pcsd.service<\/pre>\n
<\/h2>\n
Configuration du cluster<\/h2>\n
\nLa commande “pcs status” permet de v\u00e9rifier l’\u00e9tat de celui ci et des ressources qui lui sont rattach\u00e9s.<\/p>\n# systemctl status pcsd.service<\/span>\r\n\u25cf pcsd.service - PCS GUI and remote configuration interface\r\nLoaded: loaded (\/usr\/lib\/systemd\/system\/pcsd.service; enabled; vendor preset: disabled)\r\nActive: active (running) since Thu 2020-09-03 12:15:33 UTC; 2h 45min ago\r\nDocs: man:pcsd(8)\r\nman:pcs(8)\r\nMain PID: 1129 (pcsd)\r\nCGroup: \/system.slice\/pcsd.service\r\n\u251c\u2500 1129 \/usr\/bin\/ruby \/usr\/lib\/pcsd\/pcsd\r\n\u251c\u250013362 \/usr\/bin\/python2 -Es \/usr\/sbin\/pcs cluster stop --pacemaker --force\r\n\u2514\u250013365 \/bin\/systemctl stop pacemaker<\/pre>\nCr\u00e9ation du cluster<\/em><\/h3>\n
# pcs cluster auth ip-172-44-2-226 ip-172-44-2-143 -u hacluster<\/span>\r\nPassword: \r\nip-172-44-2-226: Authorized\r\nip-172-44-2-143: Authorized<\/pre>\n# pcs cluster setup --name cluster_pghd12 ip-172-44-2-226 ip-172-44-2-143<\/span>\r\nDestroying cluster on nodes: ip-172-44-2-226, ip-172-44-2-143...\r\nip-172-44-2-226: Stopping Cluster (pacemaker)...\r\nip-172-44-2-143: Stopping Cluster (pacemaker)...\r\nip-172-44-2-226: Successfully destroyed cluster\r\nip-172-44-2-143: Successfully destroyed cluster\r\n\r\nSending 'pacemaker_remote authkey' to 'ip-172-44-2-226', 'ip-172-44-2-143'\r\nip-172-44-2-226: successful distribution of the file 'pacemaker_remote authkey'\r\nip-172-44-2-143: successful distribution of the file 'pacemaker_remote authkey'\r\nSending cluster config files to the nodes...\r\nip-172-44-2-226: Succeeded\r\nip-172-44-2-143: Succeeded\r\n\r\nSynchronizing pcsd certificates on nodes ip-172-44-2-226, ip-172-44-2-143...\r\nip-172-44-2-226: Success\r\nip-172-44-2-143: Success\r\nRestarting pcsd on the nodes in order to reload the certificates...\r\nip-172-44-2-226: Success\r\nip-172-44-2-143: Success<\/pre>\n# pcs cluster start --all<\/span>\r\nip-172-44-2-226: Starting Cluster...\r\nip-172-44-2-143: Starting Cluster...<\/pre>\nConfigurer le fencing<\/em><\/h3>\n
\nCeci est effectu\u00e9 afin d’\u00e9viter le “split brain”, dans le cas d’un serveur de bases de donn\u00e9es, cela pourrait \u00eatre tr\u00e8s probl\u00e9matique si une m\u00e9thode de fencing n’est pas en place, car cela signifie que les 2 instances pourraient\u00a0 se d\u00e9synchroniser et \u00eatre vues comme autonomes.<\/p>\n# curl --silent http:\/\/169.254.169.254\/latest\/meta-data\/instance-id<\/pre>\n
# pcs cluster cib cluster1.xml\r\n\r\n<\/span># pcs stonith create clusterfence fence_aws region=eu-west-3 \\\r\n<\/span> pcmk_host_map=\"ip-172-44-2-226:i-0a72fb68be681f101;ip-172-44-2-143:i-0c6a7c72efad7e65e\" \\\r\n power_timeout=240 pcmk_reboot_timeout=480 pcmk_reboot_retries=3<\/pre>\n# pcs cluster cib-push cluster1.xml<\/span><\/pre>\n# pcs status<\/span><\/strong>\r\nCluster name: cluster_pghd12\r\nStack: corosync\r\nCurrent DC: ip-172-44-2-143 (version 1.1.21-4.el7-f14e36fd43) - partition with quorum\r\nLast updated: Thu Sep 3 11:53:24 2020\r\nLast change: Thu Sep 3 10:04:28 2020 by root via crm_resource on ip-172-44-2-226\r\n\r\n2 nodes configured\r\n1 resource configured\r\n\r\nOnline: [ ip-172-44-2-143 ip-172-44-2-226 ]\r\n\r\nFull list of resources:\r\n\r\nclusterfence (stonith:fence_aws): Started ip-172-44-2-143\r\n\r\nDaemon Status:\r\ncorosync: active\/enabled\r\npacemaker: active\/enabled\r\npcsd: active\/enabled<\/pre>\nCr\u00e9ation des ressources cluster<\/em><\/h3>\n
\n
# pcs cluster cib cluster1.xml\r\n# pcs resource create pgsqld ocf:heartbeat:pgsqlms \\\r\nbindir=\/usr\/pgsql-12\/bin pgdata=\/data\/postgres\/12 op start timeout=60s \\\r\nop stop timeout=60s \\\r\nop promote timeout=30s \\\r\nop demote timeout=120s \\\r\nop monitor interval=15s timeout=10s role=\"Master\" \\\r\nop monitor interval=16s timeout=10s role=\"Slave\" \\\r\nop notify timeout=60s<\/pre>\n
\nSeul le param\u00e8tre “application_name” devra appara\u00eetre avec le nom dns, ou l’IP du serveur sur lequel l’instance tourne.<\/p>\n $ cat postgresql.auto.conf<\/span>\r\n primary_conninfo = 'user=repli passfile=\/var\/lib\/pgsql\/.pgpass host=172.44.2.226 port=5432 application_name=ip-172-44-2-143<\/strong><\/span>'\r\n recovery_target_timeline='latest'\r\n restore_command='scp 172.44.2.226:\/data\/postgres\/archives\/%f %p'<\/pre>\n# pcs resource master pgsql-ha pgsqld notify=true<\/pre>\n
# pcs resource create pgsql-master-ip ocf:heartbeat:IPaddr2 ip=172.44.2.144 nic=eth0:1 cidr_netmask=24 op monitor interval=10s\r\n\r\n# pcs resource create pgsql_awsvip ocf:heartbeat:awsvip awscli=\/usr\/local\/bin\/aws secondary_private_ip=172.44.2.144 --group aws-group\r\n\r\n# pcs resource group add aws-group pgsql-master-ip<\/pre>\n
\nLa VIP doit d\u00e9pendre du d\u00e9marrage du n\u0153ud primaire.<\/p>\n# pcs constraint colocation add pgsql-master-ip with master pgsql-ha INFINITY\r\n# pcs constraint colocation add pgsql_awsvip with master pgsql-ha INFINITY\r\n<\/pre>\n
# pcs constraint order promote pgsql-ha then start pgsql-master-ip symmetrical=false kind=Mandatory\r\n# pcs constraint order promote pgsql-ha then start pgsql_awsvip symmetrical=false kind=Mandatory<\/pre>\n
# pcs constraint order demote pgsql-ha then stop pgsql-master-ip symmetrical=false kind=Mandatory\r\n# pcs constraint order demote pgsql-ha then stop pgsql_awsvip symmetrical=false kind=Mandatory\r\n# pcs cluster cib-push cluster1.xml<\/pre>\n
# pcs status --full<\/span><\/strong>\r\nCluster name: cluster_pghd12\r\nStack: corosync\r\nCurrent DC: ip-172-44-2-226 (1) (version 1.1.21-4.el7-f14e36fd43) - partition with quorum\r\nLast updated: Fri Sep 4 10:15:16 2020\r\nLast change: Fri Sep 4 10:12:37 2020 by root via cibadmin on ip-172-44-2-143\r\n\r\n2 nodes configured\r\n5 resources configured\r\n\r\nOnline: [ ip-172-44-2-143 (2) ip-172-44-2-226 (1) ]\r\n\r\nFull list of resources:\r\n\r\nMaster\/Slave Set: pgsql-ha [pgsqld]\r\npgsqld (ocf::heartbeat:pgsqlms): Slave ip-172-44-2-226\r\npgsqld (ocf::heartbeat:pgsqlms): Master ip-172-44-2-143\r\nMasters: [ ip-172-44-2-143 ]\r\nSlaves: [ ip-172-44-2-226 ]\r\nclusterfence (stonith:fence_aws): Started ip-172-44-2-143\r\nResource Group: aws-group\r\npgsql_awsvip (ocf::heartbeat:awsvip): Started ip-172-44-2-143\r\npgsql-master-ip (ocf::heartbeat:IPaddr2): Started ip-172-44-2-143\r\n\r\nNode Attributes:\r\n* Node ip-172-44-2-143 (2):\r\n+ master-pgsqld : 1001\r\n* Node ip-172-44-2-226 (1):\r\n+ master-pgsqld : 1000\r\n\r\nPCSD Status:\r\nip-172-44-2-143: Online\r\nip-172-44-2-226: Online\r\n\r\nDaemon Status:\r\ncorosync: active\/disabled\r\npacemaker: active\/disabled\r\npcsd: active\/enabled<\/pre>\n
\nL’instance PostgreSQL est primaire sur ce noeud. V\u00e9rifions les informations\u00a0 :<\/p>\n# ifconfig<\/span>\r\neth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>\u00a0 mtu 9001\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 inet 172.44.2.143\u00a0 netmask 255.255.255.0\u00a0 broadcast 172.44.2.255\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 inet6 fe80::845:a9ff:fec9:3e \u00a0prefixlen 64\u00a0 scopeid 0x20<link>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ether 0a:45:a9:c9:00:3e\u00a0 txqueuelen 1000\u00a0 (Ethernet)\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 RX packets 57218\u00a0 bytes 54966962 (52.4 MiB)\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 RX errors 0\u00a0 dropped 0\u00a0 overruns 0\u00a0 frame 0\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 TX packets 42097\u00a0 bytes 5473829 (5.2 MiB)\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u00a0TX errors 0\u00a0 dropped 0 overruns 0\u00a0 carrier 0\u00a0 collisions 0\r\n\r\n\r\neth0:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>\u00a0 mtu 9001\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 inet 172.44.2.144\u00a0 netmask 255.255.255.0\u00a0 broadcast 172.44.2.255\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ether 0a:45:a9:c9:00:3e\u00a0 txqueuelen 1000\u00a0 (Ethernet)<\/pre>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2020\/09\/ipsec_143.jpg\")
<\/p>\n[root@ip-172-44-2-143:0 ~]# Instance_ID=`\/usr\/bin\/curl --silent http:\/\/169.254.169.254\/latest\/meta-data\/instance-id`\r\n[root@ip-172-44-2-143:0 ~]# aws ec2 describe-instances --instance-ids\u00a0 $Instance_ID --region eu-west-3 | grep \"PrivateIpAddress\"\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"PrivateIpAddress\": \"172.44.2.143\",\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"PrivateIpAddress\": \"172.44.2.143\",\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"PrivateIpAddresses\": [\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"PrivateIpAddress\": \"172.44.2.143\"\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\"PrivateIpAddress\": \"172.44.2.144\"\r\n\r\n\r\n\r\n\r\n<\/pre>\n
[postgres@ip-172-44-2-194 ~]$ psql -h 172.44.2.144 -U manu manuelo<\/span>\r\nPassword for user manu:\r\npsql (12.0, server 12.4)\r\nType \"help\" for help.\r\n\r\nmanuelo=# select usename,client_addr,query from pg_stat_activity where usename is not null;\r\n usename | client_addr | query\r\n\u00a0----------+--------------+-----------------------------------------------------------------------------------\u00a0\r\n postgres | |\r\n repli | 172.44.2.226 |\r\n manu | 172.44.2.194 | select usename,client_addr,query from pg_stat_activity where usename is not null;\r\n\u00a0\r\n(3 rows)<\/pre>\n
\nNous voyons \u00e9galement que la r\u00e9plication, via le user “repli” est active depuis l’autre noeud du cluster portant l’IP 172.44.2.226.<\/p>\nExploitation du cluster<\/h2>\n
Cas d’une bascule d’instance PostgreSQL<\/span><\/em><\/h3>\n
\nRappelons que pour notre exemple, l’instance primaire est sur ip-172-44-2-143 et la standby sur ip-172-44-2-226 :<\/p>\n# pcs status --full\r\n\u2026..\r\n Master\/Slave Set: pgsql-ha [pgsqld]\r\n \u00a0\u00a0\u00a0 pgsqld\u00a0\u00a0\u00a0\u00a0 (ocf::heartbeat:pgsqlms):\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Slave ip-172-44-2-226\r\n \u00a0\u00a0\u00a0 pgsqld\u00a0\u00a0\u00a0\u00a0 (ocf::heartbeat:pgsqlms):\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Master ip-172-44-2-143<\/strong>\r\n \u00a0\u00a0\u00a0 Masters: [ ip-172-44-2-143 ]\r\n \u00a0\u00a0\u00a0 Slaves: [ ip-172-44-2-226 ]\r\nclusterfence\u00a0\u00a0 (stonith:fence_aws):\u00a0\u00a0\u00a0 Started ip-172-44-2-143\r\n Resource Group: aws-group\r\n \u00a0\u00a0\u00a0 pgsql_awsvip\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 (ocf::heartbeat:awsvip):\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Started ip-172-44-2-143\r\n\u00a0\u00a0\u00a0\u00a0 pgsql-master-ip\u00a0\u00a0\u00a0 (ocf::heartbeat:IPaddr2):\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Started ip-172-44-2-143<\/pre>\n
# pcs resource move --wait --master pgsql-ha\r\nResource 'pgsql-ha' is master on node ip-172-44-2-226; slave on node ip-172-44-2-143.<\/pre>\n
\nRegardons l’\u00e9tat du cluster, et de l’instance PostgreSQL :<\/p>\n[root@ip-172-44-2-226:0 ~]# pcs status --full\r\n...\r\n Master\/Slave Set: pgsql-ha [pgsqld]\r\n \u00a0\u00a0\u00a0 pgsqld\u00a0\u00a0\u00a0\u00a0 (ocf::heartbeat:pgsqlms):\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Master ip-172-44-2-226<\/strong>\r\n \u00a0\u00a0\u00a0 pgsqld\u00a0\u00a0\u00a0\u00a0 (ocf::heartbeat:pgsqlms):\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Slave ip-172-44-2-143\r\n \u00a0\u00a0\u00a0 Masters: [ ip-172-44-2-226 ]\r\n \u00a0\u00a0\u00a0 Slaves: [ ip-172-44-2-143 ]\r\n clusterfence\u00a0\u00a0 (stonith:fence_aws):\u00a0\u00a0\u00a0 Started ip-172-44-2-143\r\n Resource Group: aws-group\r\n \u00a0\u00a0\u00a0 pgsql_awsvip\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 (ocf::heartbeat:awsvip):\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Started ip-172-44-2-226\r\n\u00a0\u00a0\u00a0\u00a0 pgsql-master-ip\u00a0\u00a0\u00a0 (ocf::heartbeat:IPaddr2):\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Started ip-172-44-2-226<\/pre>\n
# ifconfig\r\n\r\neth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>\u00a0 mtu 9001\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 inet 172.44.2.226\u00a0 netmask 255.255.255.0\u00a0 broadcast 172.44.2.255\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 inet6 fe80::8ae:d4ff:feac:9526\u00a0 prefixlen 64\u00a0 scopeid 0x20<link>\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ether 0a:ae:d4:ac:95:26\u00a0 txqueuelen 1000\u00a0 (Ethernet)\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 RX packets 518354\u00a0 bytes 389187631 (371.1 MiB)\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 RX errors 0\u00a0 dropped 0\u00a0 overruns 0\u00a0 frame 0\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 TX packets 394871\u00a0 bytes 219328497 (209.1 MiB)\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 TX errors 0\u00a0 dropped 0 overruns 0\u00a0 carrier 0\u00a0 collisions 0\r\n\r\n\r\neth0:1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>\u00a0 mtu 9001\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 inet 172.44.2.144\u00a0 netmask 255.255.255.0\u00a0 broadcast 172.44.2.255\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ether 0a:ae:d4:ac:95:26\u00a0 txqueuelen 1000\u00a0 (Ethernet)<\/pre>\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2020\/09\/ipsec_226.jpg\")
<\/p>\n#\u00a0 aws ec2 describe-instances --instance-id $Instance_ID --region eu-west-3 | grep \"PrivateIpAddress\"\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"PrivateIpAddress\": \"172.44.2.226\",\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0\"PrivateIpAddress\": \"172.44.2.226\",\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"PrivateIpAddresses\": [\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"PrivateIpAddress\": \"172.44.2.226\"\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \"PrivateIpAddress\": \"172.44.2.144\"<\/pre>\n
[postgres@ip-172-44-2-194 ~]$ psql -h 172.44.2.144 -U manu manuelo\r\nPassword for user manu:\r\npsql (12.0, server 12.4)\r\nType \"help\" for help.\r\n\r\nmanuelo=# select usename,client_addr,query from pg_stat_activity where usename is not null;\r\n usename | client_addr | query\r\n ---------+--------------+-----------------------------------------------------------------------------------\r\n repli | 172.44.2.143 |\r\n postgres | |\r\n manu | 172.44.2.194 | select usename,client_addr,query from pg_stat_activity where usename is not null;\r\n\r\n(3 rows)<\/pre>\n
fencing de noeud<\/em><\/h3>\n
# pcs stonith fence ip-172-44-2-143\r\nNode: ip-172-44-2-143 fenced<\/pre>\n
\nAu red\u00e9marrage, celui ci revient, mais rien ne change, car “pgsql-ha” \u00e9tait d\u00e9j\u00e0 en mode primaire sur ip-172-44-2-226.<\/p>\nFull list of resources:\r\n\r\n Master\/Slave Set: pgsql-ha [pgsqld]\r\n \u00a0\u00a0\u00a0 pgsqld\u00a0\u00a0\u00a0\u00a0 (ocf::heartbeat:pgsqlms):\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Master ip-172-44-2-226<\/strong>\r\n \u00a0\u00a0\u00a0 pgsqld\u00a0\u00a0\u00a0\u00a0 (ocf::heartbeat:pgsqlms):\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Slave ip-172-44-2-143\r\n \u00a0\u00a0\u00a0 Masters: [ ip-172-44-2-226 ]\r\n \u00a0\u00a0\u00a0 Slaves: [ ip-172-44-2-143 ]\r\n clusterfence\u00a0\u00a0 (stonith:fence_aws):\u00a0\u00a0\u00a0 Started ip-172-44-2-143\r\n Resource Group: aws-group\r\n \u00a0\u00a0\u00a0 pgsql_awsvip\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 (ocf::heartbeat:awsvip):\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Started ip-172-44-2-226\r\n\u00a0\u00a0\u00a0\u00a0 pgsql-master-ip\u00a0\u00a0\u00a0 (ocf::heartbeat:IPaddr2):\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Started ip-172-44-2-226<\/pre>\n
\nOn peut d’ailleurs voir , avec la commande “pcs status –full”, l’historique de fencing pour ce cluster<\/p>\nFencing History:\r\n* reboot of ip-172-44-2-143 successful: delegate=ip-172-44-2-226, client=stonith_admin.24029, origin=ip-172-44-2-226,\r\ncompleted='Fri Sep 4 12:56:55 2020'<\/pre>\n
[root@ip-172-44-2-143:0 ~]# pcs stonith fence ip-172-44-2-226\r\nNode: ip-172-44-2-226 fenced<\/pre>\n
\n…<\/p>\n[root@ip-172-44-2-143:0 ~]# pcs status --full\r\n\u2026.\r\nOnline: [ ip-172-44-2-143 (2) ]\r\nOFFLINE: [ ip-172-44-2-226 (1) ]\r\n\r\nFull list of resources:\r\n\r\n Master\/Slave Set: pgsql-ha [pgsqld]\r\n \u00a0\u00a0\u00a0 pgsqld\u00a0\u00a0\u00a0\u00a0 (ocf::heartbeat:pgsqlms):\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Master ip-172-44-2-143<\/strong>\r\n \u00a0\u00a0\u00a0 pgsqld\u00a0\u00a0\u00a0\u00a0 (ocf::heartbeat:pgsqlms):\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Stopped\r\n \u00a0\u00a0\u00a0 Masters: [ ip-172-44-2-143 ]\r\n \u00a0\u00a0\u00a0 Stopped: [ ip-172-44-2-226 ]\r\n clusterfence\u00a0\u00a0 (stonith:fence_aws):\u00a0\u00a0\u00a0 Started ip-172-44-2-143\r\n Resource Group: aws-group\r\n \u00a0\u00a0\u00a0 pgsql_awsvip\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 (ocf::heartbeat:awsvip):\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Started ip-172-44-2-143\r\n\u00a0\u00a0\u00a0\u00a0 pgsql-master-ip\u00a0\u00a0\u00a0 (ocf::heartbeat:IPaddr2):\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Started ip-172-44-2-143<\/pre>\n
[root@ip-172-44-2-143:0 ~]# pcs status --full\r\n\u2026\r\nOnline: [ ip-172-44-2-143 (2) ip-172-44-2-226 (1) ]\r\n\r\nFull list of resources:\r\n\r\n\r\n Master\/Slave Set: pgsql-ha [pgsqld]\r\n \u00a0\u00a0\u00a0 pgsqld\u00a0\u00a0 \u00a0\u00a0(ocf::heartbeat:pgsqlms):\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Slave ip-172-44-2-226\r\n \u00a0\u00a0\u00a0 pgsqld\u00a0\u00a0\u00a0\u00a0 (ocf::heartbeat:pgsqlms):\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Master ip-172-44-2-143<\/strong>\r\n \u00a0\u00a0\u00a0 Masters: [ ip-172-44-2-143 ]\r\n \u00a0\u00a0\u00a0 Slaves: [ ip-172-44-2-226 ]\r\n clusterfence\u00a0\u00a0 (stonith:fence_aws):\u00a0\u00a0\u00a0 Started ip-172-44-2-143\r\n Resource Group: aws-group\r\n \u00a0\u00a0\u00a0 pgsql_awsvip\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 (ocf::heartbeat:awsvip):\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Started ip-172-44-2-143\r\n\u00a0\u00a0\u00a0\u00a0 pgsql-master-ip\u00a0\u00a0\u00a0 (ocf::heartbeat:IPaddr2):\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Started ip-172-44-2-143<\/pre>\n
Fencing History:\r\n* reboot of ip-172-44-2-226 successful: delegate=ip-172-44-2-143, client=stonith_admin.2316, origin=ip-172-44-2-143,\r\n\u00a0\u00a0\u00a0 completed='Fri Sep\u00a0 4 13:10:37 2020'<\/pre>\n
Conclusion<\/h2>\n
\nLa VIP, au sein de AWS, consiste alors \u00e0 fournir une seconde adresse IP au noeud portant l’instance primaire.<\/p>\n# pcs resource describe awseip\r\nAssumed agent name 'ocf:heartbeat:awseip' (deduced from 'awseip')\r\nocf:heartbeat:awseip - Amazon AWS Elastic IP Address Resource Agent\r\n\r\nResource Agent for Amazon AWS Elastic IP Addresses.\r\n\r\nIt manages AWS Elastic IP Addresses with awscli.<\/pre>\n
\nCeci peut \u00eatre utilis\u00e9 pour un site Web ou un serveur d’application avec haute disponibilit\u00e9 sur des VM Amazon n\u00e9cessitant une IP Publique.<\/p>\n<\/a><\/a><\/a>","protected":false},"excerpt":{"rendered":"