Putting the expected votes to one in both corosync and pacemaker allows the
cluster
to start with one node (not what I want). Unfortunately, it also does not
allow the
cluster to continue with 1 node after a failure because pacemaker remembers
the
two node cluster and increases its expected votes.
The idea of quorum does not seem to be closely coupled between corosync and
pacemaker. Running with expected votes of two, I halted a node and then
used
corosync-quorumtool to set the surviving nodes votes to two. Now corosync
says
it has quorum and pacemaker says it does not; i.e. the resources are not
able to run.
To sum up - as far as pacemaker behavior the two_node option does not seem
to
do anything. Further, if I plan to do quorum logic in corosync for the
bahavior
I want, I will also need to explore how to get pacemaker to use it.
Any comments are welcome.
Alan
On Mon, May 10, 2010 at 12:17 AM, Christine Caulfield
<ccaul...@redhat.com>wrote:
> On 08/05/10 01:02, Alan Jones wrote:
>
>> I'd like to modify the quorum behavior to require 2 nodes to start the
>> cluster but allow it to continue with only 1 node after a failure.
>> It seemed that the two_node option used with the votequorum provider
>> might provide what I'm looking for (corosync.conf section below).
>> However, I'm getting the first behavior (requiring 2 nodes to start)
>> without the second (continute with only 1 node).
>> Should I provide a votequorum device to add another vote after a failure?
>> Any other ideas?
>> Alan
>> ---
>> quorum {
>> provider: corosync_votequorum
>> expected_votes: 2
>> votes: 1
>> two_node: 1
>> }
>>
>>
>
> expected_votes should be set to 1 if you're using the two_node option. If
> you set it to 2, then it will always need both nodes to be up ... as you've
> discovered ;-)
>
> Chrissie
>
_______________________________________________
Openais mailing list
Openais@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/openais
