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? > > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 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
