I'm playing around with Red Hat's High Availability Add-On, everything seems working fine however I have one issue:
Whenever I reboot one of nodes 7test2
, resource group g1
migrates to 7test1
(by design) and then when 7test2
comes back online resource group g1
migrates back, it's like it has some sort of stickiness or something.
[root@7test1 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.1 (Maipo)
[root@7test1 ~]# rpm -q pcs
pcs-0.9.137-13.el7.x86_64
[root@7test1 ~]# pcs status
Cluster name: 7test
Last updated: Thu Apr 23 17:11:10 2015
Last change: Thu Apr 23 17:00:02 2015
Stack: corosync
Current DC: 7test1.uftwf.local (1) - partition with quorum
Version: 1.1.12-a14efad
2 Nodes configured
3 Resources configured
Online: [ 7test1.uftwf.local 7test2.uftwf.local ]
Full list of resources:
rhevm (stonith:fence_rhevm): Started 7test1.uftwf.local
Resource Group: g1
IPaddr (ocf::heartbeat:IPaddr2): Started 7test2.uftwf.local
MailTo (ocf::heartbeat:MailTo): Started 7test2.uftwf.local
PCSD Status:
7test1.uftwf.local: Online
7test2.uftwf.local: Online
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled
[root@7test1 ~]#
How can I set resource stickiness in pacemaker?
You can set the value of
resource-stickiness
, a resource meta option that indicates how much the resource prefers to stay where it is (the default value is 0) for a given resource or group whith the following command:# pcs resource meta resource_id resource-stickiness=100
For example:
# pcs resource meta dns_ip resource-stickiness=100
# pcs resource show dns_ip Resource: dns_ip (class=ocf provider=heartbeat type=IPaddr2) Attributes: ip=10.0.0.1 cidr_netmask=24 Meta Attrs: resource-stickiness=100 Operations: start interval=0s timeout=20s (dns_ip-start-timeout-20s)
To display the current value of a specific cluster property, use the following command.
To display the current value of a specific cluster property, use the following command.
To set the value of a cluster property, use the following pcs command.
⸺ from clusterlabs.org