<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Feb 5, 2026 at 12:56 PM Anton Gavriliuk <<a href="mailto:Anton.Gavriliuk@hpe.ua">Anton.Gavriliuk@hpe.ua</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Correct, in addition to two cluster nodes, there is dedicated 3rd node physical server as qdevice.<br>
<br>
I'm thinking about two level fencing topology, 1st level - fence_ipmilan, 2nd - diskless sbd (hpwdt, /dev/watchdog)<br>
<br>
But I can't add sbd as a 2nd level fencing,<br>
<br>
[root@memverge2 ~]# pcs stonith level add 2 memverge watchdog<br>
Error: Stonith resource(s) 'watchdog' do not exist, use --force to override<br>
Error: Errors have occurred, therefore pcs is unable to continue<br>
[root@memverge2 ~]#<br>
<br>
So back to the original question - what is the most correct way of implementing STONITH/fencing with fence_iomilan + diskless sbd (hpwdt, /dev/watchdog) ?<br></blockquote><div><br></div><div>Sorry then that I had overlooked qdevice (actually I thought I checked for it but ...).</div><div>For adding the watchdog into a topology you have to make it visible before - just add it as any fencing-device with fence_watchdog as agent.</div><div>There is a fence_watchdog script but that is just for the meta-data. Pacemaker will recognize that hand handle the actual fencing internally.</div><div><br></div><div>Regards,</div><div>Klaus</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Anton<br>
<br>
<br>
-----Original Message-----<br>
From: Andrei Borzenkov <<a href="mailto:arvidjaar@gmail.com" target="_blank">arvidjaar@gmail.com</a>> <br>
Sent: Thursday, February 5, 2026 1:17 PM<br>
To: Cluster Labs - All topics related to open-source clustering welcomed <<a href="mailto:users@clusterlabs.org" target="_blank">users@clusterlabs.org</a>><br>
Cc: Anton Gavriliuk <<a href="mailto:Anton.Gavriliuk@hpe.ua" target="_blank">Anton.Gavriliuk@hpe.ua</a>><br>
Subject: Re: [ClusterLabs] Question about two level STONITH/fencing<br>
<br>
On Thu, Feb 5, 2026 at 2:07 PM Klaus Wenninger <<a href="mailto:kwenning@redhat.com" target="_blank">kwenning@redhat.com</a>> wrote:<br>
><br>
><br>
><br>
> On Wed, Feb 4, 2026 at 4:36 PM Anton Gavriliuk via Users <<a href="mailto:users@clusterlabs.org" target="_blank">users@clusterlabs.org</a>> wrote:<br>
>><br>
>><br>
>><br>
>> Hello<br>
>><br>
>><br>
>><br>
>> There is two-node (HPE DL345 Gen12 servers) shared-nothing DRBD-based sync (Protocol C) replication, distributed active/standby pacemaker storage metro-cluster. The distributed active/standby pacemaker storage metro-cluster configured with qdevice, heuristics (parallel fping) and fencing - fence_ipmilan and diskless sbd (hpwdt, /dev/watchdog). All cluster resources are configured to always run together on the same node.<br>
>><br>
>><br>
>><br>
>> The two storage cluster nodes and qdevice running on Rocky Linux 10.1<br>
>><br>
>> Pacemaker version 3.0.1<br>
>><br>
>> Corosync version 3.1.9<br>
>><br>
>> DRBD version 9.3.0<br>
>><br>
>><br>
>><br>
>> So, the question is – what is the most correct way of implementing STONITH/fencing with fence_iomilan + diskless sbd (hpwdt, /dev/watchdog) ?<br>
><br>
><br>
> The correct way of using diskless sbd with a two-node cluster is not <br>
> to use it ;-)<br>
><br>
> diskless sbd (watchdog-fencing) requires 'real' quorum and quorum <br>
> provided by corosync in two-node mode would introduce split-brain <br>
> which is the reason why sbd recognizes the two-node operation and <br>
> replaces quorum from corosync by the information that the peer node is currently in the cluster. This is fine for working with poison-pill fencing - a single single shared disk then doesn't become a single-point-of-failure as long as the peer is there. But for watchdog-fencing that doesn't help because the peer going away would mean you have to commit suicide.<br>
><br>
> and alternative with a two-node cluster is to step away from the actual two-node design and go with qdevice for 'real' quorum.<br>
<br>
Hmm ... the original description does mention qdevice, although it is not quite clear where it is located (is there the third node?)<br>
<br>
> You'll need some kind of 3rd node but it doesn't have to be a full cluster node.<br>
><br>
<br>
</blockquote></div></div>