On 4/3/19 9:47 AM, Andrei Borzenkov wrote: > On Tue, Apr 2, 2019 at 8:49 PM Digimer <[email protected]> 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/ _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
