[ClusterLabs] questions about startup fencing

[Adam Spiers]

Kristoffer Gronlund <kgronlund at suse.com> wrote:
>Adam Spiers <aspiers at suse.com> writes:
>> Kristoffer Gronlund <kgronlund at suse.com> wrote:
>>>Adam Spiers <aspiers at suse.com> writes:
>>>
>>>> - The whole cluster is shut down cleanly.
>>>>
>>>> - The whole cluster is then started up again.  (Side question: what
>>>>   happens if the last node to shut down is not the first to start up?
>>>>   How will the cluster ensure it has the most recent version of the
>>>>   CIB?  Without that, how would it know whether the last man standing
>>>>   was shut down cleanly or not?)
>>>
>>>This is my opinion, I don't really know what the "official" pacemaker
>>>stance is: There is no such thing as shutting down a cluster cleanly. A
>>>cluster is a process stretching over multiple nodes - if they all shut
>>>down, the process is gone. When you start up again, you effectively have
>>>a completely new cluster.
>>
>> Sorry, I don't follow you at all here.  When you start the cluster up
>> again, the cluster config from before the shutdown is still there.
>> That's very far from being a completely new cluster :-)
>
>You have a new cluster with (possibly fragmented) memories of a previous
>life ;)

Well yeah, that's another way of describing it :-)

>> Yes, exactly.  If the first node to start up was not the last man
>> standing, the CIB history is effectively being forked.  So how is this
>> issue avoided?
>>
>>>The only way to bring up a cluster from being completely stopped is to
>>>treat it as creating a completely new cluster. The first node to start
>>>"creates" the cluster and later nodes join that cluster.
>>
>> That's ignoring the cluster config, which persists even when the
>> cluster's down.
>
>There could be a command in pacemaker which resets a set of nodes to a
>common known state, basically to pick the CIB from one of the nodes as
>the survivor and copy that to all of them. But in the end, that's just
>the same thing as just picking one node as the first node, and telling
>the others to join that one and to discard their configurations. So,
>treating it as a new cluster.

OK, so reading between the lines, if we don't want our cluster's
latest config changes accidentally discarded during a complete cluster
reboot, we should ensure that the last man standing is also the first
one booted up - right?

If so, I think that's a perfectly reasonable thing to ask for, but
maybe it should be documented explicitly somewhere?  Apologies if it
is already and I missed it.