[ClusterLabs] recommendations for corosync totem timeout for CentOS 7 + VMware?

[Jan Pokorný]

On 22/03/19 15:44 -0400, Brian Reichert wrote:
> On Fri, Mar 22, 2019 at 11:07:55AM +0100, Jan Pokorn?? wrote:
>> On 21/03/19 12:21 -0400, Brian Reichert wrote:
>>> I've followed several tutorials about setting up a simple three-node
>>> cluster, with no resources (yet), under CentOS 7.
>>> 
>>> I've discovered the cluster won't restart upon rebooting a node.
>>> 
>>> The other two nodes, however, do claim the cluster is up, as shown
>>> with 'pcs status cluster'.
>> 
>> Please excuse the lack of understanding perhaps owing to the Friday
>> mental power phenomena, but:
>> 
>> 1. what do you mean with "cluster restart"?
>>    local instance of cluster services being started anew once
>>    the node at hand finishes booting?
> 
> I mean that when I reboot node1, node1 reports the cluster is up,
> via 'pcs cluster status'.

Ok, so my assumption fits in this case, in the context of node1.

And only now I can see the source of this overall confusion, glad
you've tracked that down.

>> 2. why shall a single malfunctioned node (out of three) irrefutably
>>    result in dismounting of otherwise healthy cluster?
>>    (if that's indeed what you presume)
> 
> I don't presume that.

That was my slightly obtuse attempt to unfold the seemingly incomplete
or downright confusing picture (subject to interpreting "however" in
the original report).  Sorry for that, luckily, you seem to have all
the answers by now.

As for systemd, you can also use "systemctl is-active <unit>", and
within pcs context, "pcs status" will also serve a "Daemon Status"
at the bottom of its output, where also corosync should be detailed
unambiguously.

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20190325/f71b3fc7/attachment.sig>