[ClusterLabs] How to reduce SBD watchdog timeout?

[Andrei Borzenkov]

03.04.2019 13:04, Klaus Wenninger пишет:
> On 4/3/19 9:47 AM, Andrei Borzenkov wrote:
>> On Tue, Apr 2, 2019 at 8:49 PM Digimer <lists at alteeve.ca> wrote:
>>> It's worth noting that SBD fencing is "better than nothing", but slow.
>>> IPMI and/or PDU fencing completes a lot faster.
>>>
>> Current GIT documentation says
>>
>> Set watchdog timeout to N seconds. This depends mostly on your storage
>> latency; the majority of devices must be successfully read within this
>> time, or else the node will self-fence.
>>
>> If your sbd device(s) reside on a multipath setup or iSCSI, this
>> should be the time required to detect a path failure. You may be able
>> to reduce this if your device outages are independent, or if you are
>> using the Pacemaker integration.
> You might consider time needed for a firmware-update on
> your storage-solution as well if you intend to cover this
> without measures taken before firmware-updates.
>>
>> But it never explains how pacemaker integration affects this timeout
>> (except that stonith timeout must be at least as high as msgwait == 2
>> * watchdog timeout). Could someone shed the light?
> Pacemaker integration means that you basically aren't using
> a disk to exchange messages but sbd is instead reading
> health from the cib - assuming that a quorate node sees
> what the scheduler has written. So you should stay well above the time
> corosync needs to detect quorum-loss (token-timeout).

After reading sources and experimenting I still do not see how it can
help in two node cluster. In this case SBD will assume both nodes are
out of quorum and both nodes will commit suicide. To be used as primary
fencing agent pacemaker integration requires 2*n+1 cluster or at least
2*n + qdevice (and when n == 1 two_node must then be disabled so sbd
considers only quorate node state).

Pacemaker integration may be useful in two node cluster as backup to
avoid suicide in case of temporary disk access issues, but we still need
disk as primary channel with all associated considerations for proper
timeouts.

> Distribution of the health via cib should probably be taken
> care of already via the virtual-synchrony.
> Otherwise you can go down with the watchdog-timeout as
> long as stonith-watchog-timeout stays at about double the
> value and you are confident load issues won't prevent
> kicking the watchdog within time.
> On the other hand I would assume that values for
> watchdog-timeout below 5s are not very well tested.
>