On 05/27/14 13:34, Andrew Beekhof wrote: > > On 27 May 2014, at 3:12 pm, Gao,Yan <y...@suse.com> wrote: > >> On 05/27/14 08:07, Andrew Beekhof wrote: >>> >>> On 26 May 2014, at 10:47 pm, Christian Ciach <derein...@gmail.com> wrote: >>> >>>> I am sorry to get back to this topic, but I'm genuinely curious: >>>> >>>> Why is "demote" an option for the ticket "loss-policy" for >>>> multi-site-clusters but not for the normal "no-quorum-policy" of local >>>> clusters? This seems like a missing feature to me. >>> >>> Or one feature too many. >>> Perhaps Yan can explain why he wanted demote as an option for the >>> loss-policy. >> Loss-policy="demote" is a kind of natural default if the "Master" mode >> of a resource requires a ticket like: >> <rsc_ticket rsc="ms1" rsc-role="Master" ticket="ticketA"/> >> >> The idea is for running stateful resource instances across clusters. And >> loss-policy="demote" provides the possibility if there's the need to >> still run the resource in slave mode for any reason when losing the >> ticket, rather than stopping it or fencing the node hosting it. > > I guess the same logic applies to the single cluster use-case too and we > should allow no-quorum-policy=demote. > > One question though... do we still stop non-master/slave resources for > loss-policy=demote? Yes, we currently demote them from "Started" to "Stopped" ;-) Loss-policy is specified for per-dependency (rsc_ticket). Strictly speaking, it actually doesn't make sense to specify loss-policy=demote for a non-m/s resource. While we assume the user needs some sort of "demote" if he does so.
Hmm, not quite sure what's the best for no-quorum-policy="demote" though, since it'd be global. In either way, it seems we'd better let "demote" behave consistently. Regards, Yan > >> >> Regards, >> Yan >> >>> >>>> >>>> Best regards >>>> Christian >>>> >>>> >>>> 2014-04-07 9:54 GMT+02:00 Christian Ciach <derein...@gmail.com>: >>>> Hello, >>>> >>>> I am using Corosync 2.0 with Pacemaker 1.1 on Ubuntu Server 14.04 (daily >>>> builds until final release). >>>> >>>> My problem is as follows: I have a 2-node (plus a quorum-node) cluster to >>>> manage a multistate-resource. One node should be the master and the other >>>> one the slave. It is absolutely not allowed to have two masters at the >>>> same time. To prevent a split-brain situation, I am also using a third >>>> node as a quorum-only node (set to standby). There is no redundant >>>> connection because the nodes are connected over the internet. >>>> >>>> If one of the two nodes managing the resource becomes disconnected, it >>>> loses quorum. In this case, I want this resource to become a slave, but >>>> the resource should never be stopped completely! This leaves me with a >>>> problem: "no-quorum-policy=stop" will stop the resource, while >>>> "no-quorum-policy=ignore" will keep this resource in a master-state. I >>>> already tried to demote the resource manually inside the monitor-action of >>>> the OCF-agent, but pacemaker will promote the resource immediately again. >>>> >>>> I am aware that I am trying the manage a multi-site-cluster and there is >>>> something like the booth-daemon, which sounds like the solution to my >>>> problem. But unfortunately I need the location-constraints of pacemaker >>>> based on the score of the OCF-agent. As far as I know location-constraints >>>> are not possible when using booth, because the 2-node-cluster is >>>> essentially split into two 1-node-clusters. Is this correct? >>>> >>>> To conclude: Is it possible to demote a resource on quorum loss instead of >>>> stopping it? Is booth an option if I need to manage the location of the >>>> master based on the score returned by the OCF-agent? >>>> >>>> >>>> _______________________________________________ >>>> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org >>>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker >>>> >>>> Project Home: http://www.clusterlabs.org >>>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >>>> Bugs: http://bugs.clusterlabs.org >>> >> >> -- >> Gao,Yan <y...@suse.com> >> Software Engineer >> China Server Team, SUSE. >> >> _______________________________________________ >> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org >> http://oss.clusterlabs.org/mailman/listinfo/pacemaker >> >> Project Home: http://www.clusterlabs.org >> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf >> Bugs: http://bugs.clusterlabs.org > > > > _______________________________________________ > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org > -- Gao,Yan <y...@suse.com> Software Engineer China Server Team, SUSE. _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
