Re: [ClusterLabs] Resource-stickiness is not working
On Wed, 2018-06-06 at 07:47 +0800, Confidential Company wrote: > On Sat, 2018-06-02 at 22:14 +0800, Confidential Company wrote: > > On Fri, 2018-06-01 at 22:58 +0800, Confidential Company wrote: > > > Hi, > > >? > > > I have two-node active/passive setup. My goal is to failover a > > > resource once a Node goes down with minimal downtime as possible. > > > Based on my testing, when Node1 goes down it failover to Node2. > If > > > Node1 goes up after link reconnection (reconnect physical cable), > > > resource failback to Node1 even though I configured resource- > > > stickiness. Is there something wrong with configuration below? > > >? > > > #service firewalld stop > > > #vi /etc/hosts --> 192.168.10.121 (Node1) / 192.168.10.122 > (Node2) > > -- > > > --- Private Network (Direct connect) > > > #systemctl start pcsd.service > > > #systemctl enable pcsd.service > > > #passwd hacluster --> define pw > > > #pcs cluster auth Node1 Node2 > > > #pcs setup --name Cluster Node1 Node2 > > > #pcs cluster start -all > > > #pcs property set stonith-enabled=false > > > #pcs resource create ClusterIP ocf:heartbeat:IPaddr2 > > > ip=192.168.10.123 cidr_netmask=32 op monitor interval=30s > > > #pcs resource defaults resource-stickiness=100 > > >? > > > Regards, > > > imnotarobot > > > > Your configuration is correct, but keep in mind scores of all kinds > > will be added together to determine where the final placement is. > > > > In this case, I'd check that you don't have any constraints with a > > higher score preferring the other node. For example, if you > > previously? > > did a "move" or "ban" from the command line, that adds a constraint > > that has to be removed manually if you no longer want it. > > --? > > Ken Gaillot > > > > > > >> > > I'm confused. constraint from what I think means there's a > preferred > > node. But if I want my resources not to have a preferred node is > that > > possible? > > > > Regards, > > imnotarobot > > Yes, that's one type of constraint -- but you may not have realized > you > added one if you ran something like "pcs resource move", which is a > way > of saying there's a preferred node. > > There are a variety of other constraints. For example, as you add > more > resources, you might say that resource A can't run on the same node > as > resource B, and if that constraint's score is higher than the > stickiness, A might move if B starts on its node. > > To see your existing constraints using pcs, run "pcs constraint > show". > If there are any you don't want, you can remove them with various pcs > commands. > -- > Ken Gaillot > > > >> > Correct me if I'm wrong. So resource-stickiness policy can not be > used alone. A constraint configuration should be setup in order to > make it work but will also be dependent on the level of scores that > was setup between the two. Can you suggest what type of constraint > configuration should i set to achieve the simple goal above? Not quite -- stickiness can be used alone. However, scores from all sources are combined and compared when placing resources, so anything else in the configuration that generates a score (like constraints) will have an effect, if present. Looking at your test scenario again, I see the problem is the lack of stonith, and has nothing to do with stickiness. When you pull the cable, neither node can see the other. The isolated node is still running the IP address, even though it can't do anything with it. The failover node thinks it is the only node remaining, and brings up the IP address there as well. This is a split-brain situation. When you reconnect the cable, the nodes can see each other again, and *both are already running the IP*. The cluster detects this, and stops the IP on both nodes, and brings it up again on one node. Since the IP is not running at that point, stickiness doesn't come into play. If stonith were configured, one of the two nodes would kill the other, so only one would be running the IP at any time. If the dead node came back up and rejoined, it would not be running the IP, and stickiness would keep the IP where it was. Which node kills the other is a bit tricky in a two-node situation. If you're interested mainly in IP availability, you can use fence_heuristic_ping to keep a node with a nonfunctioning network from killing the other. Another possibility is to use qdevice on a third node as a tie-breaker. In any case, stonith is how to avoid a split-brain situation. > > Regards, > imnotarobot > Ken Gaillot ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Resource-stickiness is not working
On Sat, 2018-06-02 at 22:14 +0800, Confidential Company wrote: > On Fri, 2018-06-01 at 22:58 +0800, Confidential Company wrote: > > Hi, > >? > > I have two-node active/passive setup. My goal is to failover a > > resource once a Node goes down with minimal downtime as possible. > > Based on my testing, when Node1 goes down it failover to Node2. If > > Node1 goes up after link reconnection (reconnect physical cable), > > resource failback to Node1 even though I configured resource- > > stickiness. Is there something wrong with configuration below? > >? > > #service firewalld stop > > #vi /etc/hosts --> 192.168.10.121 (Node1) / 192.168.10.122 (Node2) > -- > > --- Private Network (Direct connect) > > #systemctl start pcsd.service > > #systemctl enable pcsd.service > > #passwd hacluster --> define pw > > #pcs cluster auth Node1 Node2 > > #pcs setup --name Cluster Node1 Node2 > > #pcs cluster start -all > > #pcs property set stonith-enabled=false > > #pcs resource create ClusterIP ocf:heartbeat:IPaddr2 > > ip=192.168.10.123 cidr_netmask=32 op monitor interval=30s > > #pcs resource defaults resource-stickiness=100 > >? > > Regards, > > imnotarobot > > Your configuration is correct, but keep in mind scores of all kinds > will be added together to determine where the final placement is. > > In this case, I'd check that you don't have any constraints with a > higher score preferring the other node. For example, if you > previously? > did a "move" or "ban" from the command line, that adds a constraint > that has to be removed manually if you no longer want it. > --? > Ken Gaillot > > > >> > I'm confused. constraint from what I think means there's a preferred > node. But if I want my resources not to have a preferred node is that > possible? > > Regards, > imnotarobot Yes, that's one type of constraint -- but you may not have realized you added one if you ran something like "pcs resource move", which is a way of saying there's a preferred node. There are a variety of other constraints. For example, as you add more resources, you might say that resource A can't run on the same node as resource B, and if that constraint's score is higher than the stickiness, A might move if B starts on its node. To see your existing constraints using pcs, run "pcs constraint show". If there are any you don't want, you can remove them with various pcs commands. -- Ken Gaillot >> Correct me if I'm wrong. So resource-stickiness policy can not be used alone. A constraint configuration should be setup in order to make it work but will also be dependent on the level of scores that was setup between the two. Can you suggest what type of constraint configuration should i set to achieve the simple goal above? Regards, imnotarobot ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Resource-stickiness is not working
On Sat, 2018-06-02 at 22:14 +0800, Confidential Company wrote: > On Fri, 2018-06-01 at 22:58 +0800, Confidential Company wrote: > > Hi, > > > > I have two-node active/passive setup. My goal is to failover a > > resource once a Node goes down with minimal downtime as possible. > > Based on my testing, when Node1 goes down it failover to Node2. If > > Node1 goes up after link reconnection (reconnect physical cable), > > resource failback to Node1 even though I configured resource- > > stickiness. Is there something wrong with configuration below? > > > > #service firewalld stop > > #vi /etc/hosts --> 192.168.10.121 (Node1) / 192.168.10.122 (Node2) > -- > > --- Private Network (Direct connect) > > #systemctl start pcsd.service > > #systemctl enable pcsd.service > > #passwd hacluster --> define pw > > #pcs cluster auth Node1 Node2 > > #pcs setup --name Cluster Node1 Node2 > > #pcs cluster start -all > > #pcs property set stonith-enabled=false > > #pcs resource create ClusterIP ocf:heartbeat:IPaddr2 > > ip=192.168.10.123 cidr_netmask=32 op monitor interval=30s > > #pcs resource defaults resource-stickiness=100 > > > > Regards, > > imnotarobot > > Your configuration is correct, but keep in mind scores of all kinds > will be added together to determine where the final placement is. > > In this case, I'd check that you don't have any constraints with a > higher score preferring the other node. For example, if you > previously > did a "move" or "ban" from the command line, that adds a constraint > that has to be removed manually if you no longer want it. > -- > Ken Gaillot > > > >> > I'm confused. constraint from what I think means there's a preferred > node. But if I want my resources not to have a preferred node is that > possible? > > Regards, > imnotarobot Yes, that's one type of constraint -- but you may not have realized you added one if you ran something like "pcs resource move", which is a way of saying there's a preferred node. There are a variety of other constraints. For example, as you add more resources, you might say that resource A can't run on the same node as resource B, and if that constraint's score is higher than the stickiness, A might move if B starts on its node. To see your existing constraints using pcs, run "pcs constraint show". If there are any you don't want, you can remove them with various pcs commands. -- Ken Gaillot ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] Resource-stickiness is not working
On Fri, 2018-06-01 at 22:58 +0800, Confidential Company wrote: > Hi, > > I have two-node active/passive setup. My goal is to failover a > resource once a Node goes down with minimal downtime as possible. > Based on my testing, when Node1 goes down it failover to Node2. If > Node1 goes up after link reconnection (reconnect physical cable), > resource failback to Node1 even though I configured resource- > stickiness. Is there something wrong with configuration below? > > #service firewalld stop > #vi /etc/hosts --> 192.168.10.121 (Node1) / 192.168.10.122 (Node2) -- > --- Private Network (Direct connect) > #systemctl start pcsd.service > #systemctl enable pcsd.service > #passwd hacluster --> define pw > #pcs cluster auth Node1 Node2 > #pcs setup --name Cluster Node1 Node2 > #pcs cluster start -all > #pcs property set stonith-enabled=false > #pcs resource create ClusterIP ocf:heartbeat:IPaddr2 > ip=192.168.10.123 cidr_netmask=32 op monitor interval=30s > #pcs resource defaults resource-stickiness=100 > > Regards, > imnotarobot Your configuration is correct, but keep in mind scores of all kinds will be added together to determine where the final placement is. In this case, I'd check that you don't have any constraints with a higher score preferring the other node. For example, if you previously did a "move" or "ban" from the command line, that adds a constraint that has to be removed manually if you no longer want it. -- Ken Gaillot ___ Users mailing list: Users@clusterlabs.org https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [ClusterLabs] resource-stickiness
On 09/02/2015 08:11 AM, Rakovec Jost wrote: > Hi > > Can I ask something else in this thred or shoud I open a new one? Either is fine but a new one is probably more helpful to people searching online later :) > questions: > > 1. whta is the purpos of "meta target-role=Started" in > > primitive apache apache \ > params configfile="/etc/apache2/httpd.conf" \ > op monitor timeout=20s interval=10 \ > op stop timeout=60s interval=0 \ > op start timeout=40s interval=0 \ > meta target-role=Started > > I just find that if I tray to "start Parent:" it don't start any resource > from group. But if I remove "meta target-role=Started" then it start all > resources. target-role=started is the default, so I'm not sure why you're seeing that behavior. It just means that the cluster should try to keep the service running. If you set it to stopped, the cluster will try to keep it stopped. (For master/slave resources, there's also master, for running in the master state.) I'm also not sure what "start Parent:" means. I haven't used crm in a while, so maybe it's crm-specific? In general, the cluster manages starting and stopping of services automatically, and you can use target-role to tell it what you want it to do. > 2. How can I just change something by CLI crm for example: > > I have this in my configuration: > > primitive stonith_sbd stonith:external/sbd > > but I would like to add this: > > crm(live)configure# stonith_sbd stonith:external/sbd \ >> params pcmk_delay_max="30" > ERROR: configure.stonith_sbd: No such command > > I know that I can delete and then add new, but I don't like this solution. > > 3. Do I need to add colocation and order: > > colocation apache-with-fs-ip inf: fs myip apache > > and > > order apache-after-fs-ip Mandatory: fs myip apache > > > if I'm using group like this: > > group web fs myip apache \ > meta target-role=Started is-managed=true resource-stickiness=1000 You don't need them. A group is essentially a shorthand for colocation and order constraints for all its members in the order they're listed. There are minor differences between the two approaches, but the effect is the same. In fact, when you're using groups, it's recommended not to use the individual members in any constraints. You can use the group itself in a constraint though, to order/colocate the entire group with some other resource. > On 08/28/2015 03:39 AM, Rakovec Jost wrote: >> Hi >> >> Ok thanks. I find this on your howto >> >> http://clusterlabs.org/doc/en-US/Pacemaker/1.1-plugin/html/Clusters_from_Scratch/ch06s08.html >> >> so basically I just remove temporary constraint by using >> >> crm resource unmove aapche >> >> and cluster work as I want. >> >> 1.Can you please explain me why is this temporary constraint necessary since >> I don't see any benefit, just more work for sysadmin? > > It is created when you do "crm resource move". > > The cluster itself has no concept of "moving" resources; it figures out > the best place to put each resource, adjusting continuously for > configuration changes, failures, etc. > > So how tools like crm implement "move" is to change the configuration, > by adding the temporary constraint. That tells the cluster "this > resource should be on that node". The cluster adjusts its idea of "best" > and moves the resource to match it. > >> 2.Is this possible to disable some how? > > Sure, "crm resource unmove" :) > > The constraint can't be removed automatically because neither the > cluster nor the tool knows when you no longer prefer the resource to be > at the new location. You have to tell it. > > If you have resource-stickiness, you can "unmove" as soon as the move is > done, and the resource will stay where it is (unless some other > configuration is stronger than the stickiness). If you don't have > resource-stickiness, then once you "unmove", the resource may move to > some other node, as the cluster adjusts its idea of "best". > >> Thanks >> >> Jost >> >> >> >> >> >> From: Ken Gaillot <kgail...@redhat.com> >> Sent: Thursday, August 27, 2015 4:00 PM >> To: users@clusterlabs.org >> Subject: Re: [ClusterLabs] resource-stickiness >> >> On 08/27/2015 02:42 AM, Rakovec Jost wrote: >>> Hi >>> >>> >>> it doesn't work as I expected, I change name to: >>> >>> location loc
Re: [ClusterLabs] resource-stickiness
Hi Ok thanks. I find this on your howto http://clusterlabs.org/doc/en-US/Pacemaker/1.1-plugin/html/Clusters_from_Scratch/ch06s08.html so basically I just remove temporary constraint by using crm resource unmove aapche and cluster work as I want. 1.Can you please explain me why is this temporary constraint necessary since I don't see any benefit, just more work for sysadmin? 2.Is this possible to disable some how? Thanks Jost From: Ken Gaillot kgail...@redhat.com Sent: Thursday, August 27, 2015 4:00 PM To: users@clusterlabs.org Subject: Re: [ClusterLabs] resource-stickiness On 08/27/2015 02:42 AM, Rakovec Jost wrote: Hi it doesn't work as I expected, I change name to: location loc-aapche-sles1 aapche role=Started 10: sles1 but after I manual move resource via HAWK to other node it auto add this line: location cli-prefer-aapche aapche role=Started inf: sles1 so now I have both lines: location cli-prefer-aapche aapche role=Started inf: sles1 location loc-aapche-sles1 aapche role=Started 10: sles1 When you manually move a resource using a command-line tool, those tools accomplish the moving by adding a constraint, like the one you see added above. Such tools generally provide another option to clear any constraints they added, which you can manually run after you are satisfied with the state of things. Until you do so, the added constraint will remain, and will affect resource placement. and resource-stickiness doesn't work since after fence node1 the resource is move back to node1 after node1 come back and this is what I don't like. I know that I can remove line that was added by cluster, but this is not the proper solution. Please tell me what is wrong. Thanks. My config: Resource placement depends on many factors. Scores affect the outcome; stickiness has a score, and each constraint has a score, and the active node with the highest score wins. In your config, resource-stickiness has a score of 1000, but cli-aapche-sles1 has a score of inf (infinity), so sles1 wins when it comes back online (infinity 1000). By contrast, loc-aapche-sles1 has a score of 10, so by itself, it would not cause the resource to move back (10 1000). To achieve what you want, clear the temporary constraint added by hawk, before sles1 comes back. node sles1 node sles2 primitive filesystem Filesystem \ params fstype=ext3 directory=/srv/www/vhosts device=/dev/xvdd1 \ op start interval=0 timeout=60 \ op stop interval=0 timeout=60 \ op monitor interval=20 timeout=40 primitive myip IPaddr2 \ params ip=10.9.131.86 \ op start interval=0 timeout=20s \ op stop interval=0 timeout=20s \ op monitor interval=10s timeout=20s primitive stonith_sbd stonith:external/sbd \ params pcmk_delay_max=30 primitive web apache \ params configfile=/etc/apache2/httpd.conf \ op start interval=0 timeout=40s \ op stop interval=0 timeout=60s \ op monitor interval=10 timeout=20s group aapche filesystem myip web \ meta target-role=Started is-managed=true resource-stickiness=1000 location cli-prefer-aapche aapche role=Started inf: sles1 location loc-aapche-sles1 aapche role=Started 10: sles1 property cib-bootstrap-options: \ stonith-enabled=true \ no-quorum-policy=ignore \ placement-strategy=balanced \ expected-quorum-votes=2 \ dc-version=1.1.12-f47ea56 \ cluster-infrastructure=classic openais (with plugin) \ last-lrm-refresh=1440502955 \ stonith-timeout=40s rsc_defaults rsc-options: \ resource-stickiness=1000 \ migration-threshold=3 op_defaults op-options: \ timeout=600 \ record-pending=true BR Jost From: Andrew Beekhof and...@beekhof.net Sent: Thursday, August 27, 2015 12:20 AM To: Cluster Labs - All topics related to open-source clustering welcomed Subject: Re: [ClusterLabs] resource-stickiness On 26 Aug 2015, at 10:09 pm, Rakovec Jost jost.rako...@snt.si wrote: Sorry one typo: problem is the same location cli-prefer-aapche aapche role=Started 10: sles2 Change the name of your constraint. The 'cli-prefer-’ prefix is reserved for “temporary” constraints created by the command line tools (which therefor feel entitled to delete them as necessary). to: location cli-prefer-aapche aapche role=Started inf: sles2 It keep change to infinity. my configuration is: node sles1 node sles2 primitive filesystem Filesystem \ params fstype=ext3 directory=/srv/www/vhosts device=/dev/xvdd1 \ op start interval=0 timeout=60 \ op stop interval=0 timeout=60 \ op monitor interval=20 timeout=40 primitive myip IPaddr2 \ params ip=x.x.x.x \ op start interval=0 timeout=20s \ op stop interval=0 timeout=20s
Re: [ClusterLabs] resource-stickiness
On 08/27/2015 02:42 AM, Rakovec Jost wrote: Hi it doesn't work as I expected, I change name to: location loc-aapche-sles1 aapche role=Started 10: sles1 but after I manual move resource via HAWK to other node it auto add this line: location cli-prefer-aapche aapche role=Started inf: sles1 so now I have both lines: location cli-prefer-aapche aapche role=Started inf: sles1 location loc-aapche-sles1 aapche role=Started 10: sles1 When you manually move a resource using a command-line tool, those tools accomplish the moving by adding a constraint, like the one you see added above. Such tools generally provide another option to clear any constraints they added, which you can manually run after you are satisfied with the state of things. Until you do so, the added constraint will remain, and will affect resource placement. and resource-stickiness doesn't work since after fence node1 the resource is move back to node1 after node1 come back and this is what I don't like. I know that I can remove line that was added by cluster, but this is not the proper solution. Please tell me what is wrong. Thanks. My config: Resource placement depends on many factors. Scores affect the outcome; stickiness has a score, and each constraint has a score, and the active node with the highest score wins. In your config, resource-stickiness has a score of 1000, but cli-aapche-sles1 has a score of inf (infinity), so sles1 wins when it comes back online (infinity 1000). By contrast, loc-aapche-sles1 has a score of 10, so by itself, it would not cause the resource to move back (10 1000). To achieve what you want, clear the temporary constraint added by hawk, before sles1 comes back. node sles1 node sles2 primitive filesystem Filesystem \ params fstype=ext3 directory=/srv/www/vhosts device=/dev/xvdd1 \ op start interval=0 timeout=60 \ op stop interval=0 timeout=60 \ op monitor interval=20 timeout=40 primitive myip IPaddr2 \ params ip=10.9.131.86 \ op start interval=0 timeout=20s \ op stop interval=0 timeout=20s \ op monitor interval=10s timeout=20s primitive stonith_sbd stonith:external/sbd \ params pcmk_delay_max=30 primitive web apache \ params configfile=/etc/apache2/httpd.conf \ op start interval=0 timeout=40s \ op stop interval=0 timeout=60s \ op monitor interval=10 timeout=20s group aapche filesystem myip web \ meta target-role=Started is-managed=true resource-stickiness=1000 location cli-prefer-aapche aapche role=Started inf: sles1 location loc-aapche-sles1 aapche role=Started 10: sles1 property cib-bootstrap-options: \ stonith-enabled=true \ no-quorum-policy=ignore \ placement-strategy=balanced \ expected-quorum-votes=2 \ dc-version=1.1.12-f47ea56 \ cluster-infrastructure=classic openais (with plugin) \ last-lrm-refresh=1440502955 \ stonith-timeout=40s rsc_defaults rsc-options: \ resource-stickiness=1000 \ migration-threshold=3 op_defaults op-options: \ timeout=600 \ record-pending=true BR Jost From: Andrew Beekhof and...@beekhof.net Sent: Thursday, August 27, 2015 12:20 AM To: Cluster Labs - All topics related to open-source clustering welcomed Subject: Re: [ClusterLabs] resource-stickiness On 26 Aug 2015, at 10:09 pm, Rakovec Jost jost.rako...@snt.si wrote: Sorry one typo: problem is the same location cli-prefer-aapche aapche role=Started 10: sles2 Change the name of your constraint. The 'cli-prefer-’ prefix is reserved for “temporary” constraints created by the command line tools (which therefor feel entitled to delete them as necessary). to: location cli-prefer-aapche aapche role=Started inf: sles2 It keep change to infinity. my configuration is: node sles1 node sles2 primitive filesystem Filesystem \ params fstype=ext3 directory=/srv/www/vhosts device=/dev/xvdd1 \ op start interval=0 timeout=60 \ op stop interval=0 timeout=60 \ op monitor interval=20 timeout=40 primitive myip IPaddr2 \ params ip=x.x.x.x \ op start interval=0 timeout=20s \ op stop interval=0 timeout=20s \ op monitor interval=10s timeout=20s primitive stonith_sbd stonith:external/sbd \ params pcmk_delay_max=30 primitive web apache \ params configfile=/etc/apache2/httpd.conf \ op start interval=0 timeout=40s \ op stop interval=0 timeout=60s \ op monitor interval=10 timeout=20s group aapche filesystem myip web \ meta target-role=Started is-managed=true resource-stickiness=1000 location cli-prefer-aapche aapche role=Started 10: sles2 property cib-bootstrap-options: \ stonith-enabled=true \ no-quorum-policy=ignore \ placement-strategy=balanced
Re: [ClusterLabs] resource-stickiness
Hi it doesn't work as I expected, I change name to: location loc-aapche-sles1 aapche role=Started 10: sles1 but after I manual move resource via HAWK to other node it auto add this line: location cli-prefer-aapche aapche role=Started inf: sles1 so now I have both lines: location cli-prefer-aapche aapche role=Started inf: sles1 location loc-aapche-sles1 aapche role=Started 10: sles1 and resource-stickiness doesn't work since after fence node1 the resource is move back to node1 after node1 come back and this is what I don't like. I know that I can remove line that was added by cluster, but this is not the proper solution. Please tell me what is wrong. Thanks. My config: node sles1 node sles2 primitive filesystem Filesystem \ params fstype=ext3 directory=/srv/www/vhosts device=/dev/xvdd1 \ op start interval=0 timeout=60 \ op stop interval=0 timeout=60 \ op monitor interval=20 timeout=40 primitive myip IPaddr2 \ params ip=10.9.131.86 \ op start interval=0 timeout=20s \ op stop interval=0 timeout=20s \ op monitor interval=10s timeout=20s primitive stonith_sbd stonith:external/sbd \ params pcmk_delay_max=30 primitive web apache \ params configfile=/etc/apache2/httpd.conf \ op start interval=0 timeout=40s \ op stop interval=0 timeout=60s \ op monitor interval=10 timeout=20s group aapche filesystem myip web \ meta target-role=Started is-managed=true resource-stickiness=1000 location cli-prefer-aapche aapche role=Started inf: sles1 location loc-aapche-sles1 aapche role=Started 10: sles1 property cib-bootstrap-options: \ stonith-enabled=true \ no-quorum-policy=ignore \ placement-strategy=balanced \ expected-quorum-votes=2 \ dc-version=1.1.12-f47ea56 \ cluster-infrastructure=classic openais (with plugin) \ last-lrm-refresh=1440502955 \ stonith-timeout=40s rsc_defaults rsc-options: \ resource-stickiness=1000 \ migration-threshold=3 op_defaults op-options: \ timeout=600 \ record-pending=true BR Jost From: Andrew Beekhof and...@beekhof.net Sent: Thursday, August 27, 2015 12:20 AM To: Cluster Labs - All topics related to open-source clustering welcomed Subject: Re: [ClusterLabs] resource-stickiness On 26 Aug 2015, at 10:09 pm, Rakovec Jost jost.rako...@snt.si wrote: Sorry one typo: problem is the same location cli-prefer-aapche aapche role=Started 10: sles2 Change the name of your constraint. The 'cli-prefer-’ prefix is reserved for “temporary” constraints created by the command line tools (which therefor feel entitled to delete them as necessary). to: location cli-prefer-aapche aapche role=Started inf: sles2 It keep change to infinity. my configuration is: node sles1 node sles2 primitive filesystem Filesystem \ params fstype=ext3 directory=/srv/www/vhosts device=/dev/xvdd1 \ op start interval=0 timeout=60 \ op stop interval=0 timeout=60 \ op monitor interval=20 timeout=40 primitive myip IPaddr2 \ params ip=x.x.x.x \ op start interval=0 timeout=20s \ op stop interval=0 timeout=20s \ op monitor interval=10s timeout=20s primitive stonith_sbd stonith:external/sbd \ params pcmk_delay_max=30 primitive web apache \ params configfile=/etc/apache2/httpd.conf \ op start interval=0 timeout=40s \ op stop interval=0 timeout=60s \ op monitor interval=10 timeout=20s group aapche filesystem myip web \ meta target-role=Started is-managed=true resource-stickiness=1000 location cli-prefer-aapche aapche role=Started 10: sles2 property cib-bootstrap-options: \ stonith-enabled=true \ no-quorum-policy=ignore \ placement-strategy=balanced \ expected-quorum-votes=2 \ dc-version=1.1.12-f47ea56 \ cluster-infrastructure=classic openais (with plugin) \ last-lrm-refresh=1440502955 \ stonith-timeout=40s rsc_defaults rsc-options: \ resource-stickiness=1000 \ migration-threshold=3 op_defaults op-options: \ timeout=600 \ record-pending=true and after migration: node sles1 node sles2 primitive filesystem Filesystem \ params fstype=ext3 directory=/srv/www/vhosts device=/dev/xvdd1 \ op start interval=0 timeout=60 \ op stop interval=0 timeout=60 \ op monitor interval=20 timeout=40 primitive myip IPaddr2 \ params ip=10.9.131.86 \ op start interval=0 timeout=20s \ op stop interval=0 timeout=20s \ op monitor interval=10s timeout=20s primitive stonith_sbd stonith:external/sbd \ params pcmk_delay_max=30 primitive web apache \ params configfile=/etc/apache2/httpd.conf \ op start interval=0 timeout=40s \ op stop interval=0 timeout=60s \ op
Re: [ClusterLabs] resource-stickiness
Sorry one typo: problem is the same location cli-prefer-aapche aapche role=Started 10: sles2 to: location cli-prefer-aapche aapche role=Started inf: sles2 It keep change to infinity. my configuration is: node sles1 node sles2 primitive filesystem Filesystem \ params fstype=ext3 directory=/srv/www/vhosts device=/dev/xvdd1 \ op start interval=0 timeout=60 \ op stop interval=0 timeout=60 \ op monitor interval=20 timeout=40 primitive myip IPaddr2 \ params ip=x.x.x.x \ op start interval=0 timeout=20s \ op stop interval=0 timeout=20s \ op monitor interval=10s timeout=20s primitive stonith_sbd stonith:external/sbd \ params pcmk_delay_max=30 primitive web apache \ params configfile=/etc/apache2/httpd.conf \ op start interval=0 timeout=40s \ op stop interval=0 timeout=60s \ op monitor interval=10 timeout=20s group aapche filesystem myip web \ meta target-role=Started is-managed=true resource-stickiness=1000 location cli-prefer-aapche aapche role=Started 10: sles2 property cib-bootstrap-options: \ stonith-enabled=true \ no-quorum-policy=ignore \ placement-strategy=balanced \ expected-quorum-votes=2 \ dc-version=1.1.12-f47ea56 \ cluster-infrastructure=classic openais (with plugin) \ last-lrm-refresh=1440502955 \ stonith-timeout=40s rsc_defaults rsc-options: \ resource-stickiness=1000 \ migration-threshold=3 op_defaults op-options: \ timeout=600 \ record-pending=true and after migration: node sles1 node sles2 primitive filesystem Filesystem \ params fstype=ext3 directory=/srv/www/vhosts device=/dev/xvdd1 \ op start interval=0 timeout=60 \ op stop interval=0 timeout=60 \ op monitor interval=20 timeout=40 primitive myip IPaddr2 \ params ip=10.9.131.86 \ op start interval=0 timeout=20s \ op stop interval=0 timeout=20s \ op monitor interval=10s timeout=20s primitive stonith_sbd stonith:external/sbd \ params pcmk_delay_max=30 primitive web apache \ params configfile=/etc/apache2/httpd.conf \ op start interval=0 timeout=40s \ op stop interval=0 timeout=60s \ op monitor interval=10 timeout=20s group aapche filesystem myip web \ meta target-role=Started is-managed=true resource-stickiness=1000 location cli-prefer-aapche aapche role=Started inf: sles2 property cib-bootstrap-options: \ stonith-enabled=true \ no-quorum-policy=ignore \ placement-strategy=balanced \ expected-quorum-votes=2 \ dc-version=1.1.12-f47ea56 \ cluster-infrastructure=classic openais (with plugin) \ last-lrm-refresh=1440502955 \ stonith-timeout=40s rsc_defaults rsc-options: \ resource-stickiness=1000 \ migration-threshold=3 op_defaults op-options: \ timeout=600 \ record-pending=true From: Rakovec Jost Sent: Wednesday, August 26, 2015 1:33 PM To: users@clusterlabs.org Subject: resource-stickiness Hi list, I have configure simple cluster on sles 11 sp4 and have a problem with “auto_failover off. The problem is that when ever I migrate resource group via HAWK my configuration change from: location cli-prefer-aapche aapche role=Started 10: sles2 to: location cli-ban-aapche-on-sles1 aapche role=Started -inf: sles1 It keep change to inf. and then after fance node, resource is moving back to original node which I don't want. How can I avoid this situation? my configuration is: node sles1 node sles2 primitive filesystem Filesystem \ params fstype=ext3 directory=/srv/www/vhosts device=/dev/xvdd1 \ op start interval=0 timeout=60 \ op stop interval=0 timeout=60 \ op monitor interval=20 timeout=40 primitive myip IPaddr2 \ params ip=x.x.x.x \ op start interval=0 timeout=20s \ op stop interval=0 timeout=20s \ op monitor interval=10s timeout=20s primitive stonith_sbd stonith:external/sbd \ params pcmk_delay_max=30 primitive web apache \ params configfile=/etc/apache2/httpd.conf \ op start interval=0 timeout=40s \ op stop interval=0 timeout=60s \ op monitor interval=10 timeout=20s group aapche filesystem myip web \ meta target-role=Started is-managed=true resource-stickiness=1000 location cli-prefer-aapche aapche role=Started 10: sles2 property cib-bootstrap-options: \ stonith-enabled=true \ no-quorum-policy=ignore \ placement-strategy=balanced \ expected-quorum-votes=2 \ dc-version=1.1.12-f47ea56 \ cluster-infrastructure=classic openais (with plugin) \ last-lrm-refresh=1440502955 \ stonith-timeout=40s rsc_defaults rsc-options: \ resource-stickiness=1000 \ migration-threshold=3 op_defaults op-options: \ timeout=600 \ record-pending=true and after migration:
