[Pacemaker] configuration variants for 2 node cluster

[Kostiantyn Ponomarenko]

Digimer,

Yes, wait_for_all is a part of votequorum in Corosync v2.

Thank you,
Kostya


On Tue, Jun 24, 2014 at 6:47 PM, Digimer <lists at alteeve.ca> wrote:

> On 24/06/14 03:55 AM, Christine Caulfield wrote:
>
>> On 23/06/14 15:49, Digimer wrote:
>>
>>> Hi Kostya,
>>>
>>>    I'm having a little trouble understanding your question, sorry.
>>>
>>>    On boot, the node will not start anything, so after booting it, you
>>> log in, check that it can talk to the peer node (a simple ping is
>>> generally enough), then start the cluster. It will join the peer's
>>> existing cluster (even if it's a cluster on just itself).
>>>
>>>    If you booted both nodes, say after a power outage, you will check
>>> the connection (again, a simple ping is fine) and then start the cluster
>>> on both nodes at the same time.
>>>
>>
>>
>> wait_for_all helps with most of these situations. If a node goes down
>> then it won't start services until it's seen the non-failed node because
>> wait_for_all prevents a newly rebooted node from doing anything on its
>> own. This also takes care of the case where both nodes are rebooted
>> together of course, because that's the same as a new start.
>>
>> Chrissie
>>
>
> This isn't available on RHEL 6, is it? iirc, it's a Corosync v2 feature?
>
>
> --
> Digimer
> Papers and Projects: https://alteeve.ca/w/
> What if the cure for cancer is trapped in the mind of a person without
> access to education?
>
> _______________________________________________
> Pacemaker mailing list: Pacemaker at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20140624/c742d837/attachment-0003.html>