[ClusterLabs] How to reduce SBD watchdog timeout?

[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).
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.

Klaus
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
>
> ClusterLabs home: https://www.clusterlabs.org/