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. 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
