<div dir="ltr">Thank you Ken, this is very helpful, I was hoping for this kind of feedback, a chance to step back and rethink.<div><br></div><div>I didn't realize that SBD could get the quorum information from Pacemaker for instance.</div><div><br></div><div>I don't know how I can get around 'softdog' since I am running entirely in Hyper-V.  </div><div><br></div><div>I think one of my questions is answered by your observation that I should 'tie my DRBD fencing scripts into pacemaker.'</div><div><br></div><div>I am configured with the DRBD fencing scripts, but I'm running DRBD 8.X.  DRBD9 explicitly announces that 9 supports 'fencing in pacemaker', which makes me think that 8.x might not.</div><div><br></div><div>I am ready to roll onto DRBD 9 but I need to suspend for a short time because I'm missing my production window.  </div><div><br></div><div>I don't want to dump my logs and configs here without more insight because I'd be cluttering up the thread a lot.  </div><div><br></div><div>Thanks,</div><div><br></div><div>Rick</div><div><div><div dir="ltr" class="m_-8862151202167467440gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 15, 2019 at 5:27 PM Ken Gaillot <<a href="mailto:kgaillot@redhat.com" target="_blank">kgaillot@redhat.com</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">On Thu, 2019-08-15 at 11:25 -0400, Nickle, Richard wrote:<br>
> <br>
> My objective is two-node active/passive DRBD device which would<br>
> automatically fail over, a secondary objective would be to use<br>
> standard, stock and supported software distributions and repositories<br>
> with as little customization as possible.<br>
> <br>
> I'm using Ubuntu 18.04.3, plus the DRBD, corosync and Pacemaker that<br>
> are in the (LTS) repositories.  DRBD drbdadm reports version 8.9.10. <br>
> Corosync is 2.4.3, and Pacemaker is 0.9.164.<br>
> <br>
> For my test scenario, I would have two nodes up and running, I would<br>
> reboot, disconnect or shut down one node, and the other node would<br>
> then after a delay take over.  That's the scenario I wanted to<br>
> cover:  unexpected loss of a node.  The application is supplementary<br>
> and isn't life safety or mission critical, but it would be measured,<br>
> and the goal would be to stay above 4 nines of uptime annually.<br>
> <br>
> All of this is working for me, I can manually failover by telling PCS<br>
> to move my resource from one node to another.  If I reboot the<br>
> primary node, the failover will not complete until the primary is<br>
> back online.  Occasionally I'd get split-brain by doing these hard<br>
> kills, which would require manual recovery.<br>
> <br>
> I added STONITH and watchdog using SBD with an iSCSI block device and<br>
> softdog.  <br>
<br>
So far, so good ... except for softdog. Since it's a kernel module, if<br>
something goes wrong at the kernel level, it might fail to execute, and<br>
you might still get split-brain (though much less likely than without<br>
fencing at all). A hardware watchdog or external power fencing is much<br>
more reliable, and if you're looking for 4 9s, it's worth it.<br>
<br>
> I added a qdevice to get an odd-numbered quorum.<br>
> <br>
> When I run crm_simulate on this, the simulation says that if I down<br>
> the primary node, it will promote the resource to the secondary.<br>
> <br>
> And yet I still see the same behavior:  crashing the primary, there<br>
> is no promotion until after the primary returns online, and after<br>
> that the secondary is smoothly promoted and the primary demoted.<br>
> <br>
> Getting each component of this stack configured and running has had<br>
> substantial challenges, with regards to compatibility, documentation,<br>
> integration bugs, etc.<br>
> <br>
> I see other people reporting problems similar to mine, I'm wondering<br>
> if there's a general approach, or perhaps I need a nudge in a new<br>
> direction to tackle this issue?<br>
> <br>
> * Should I continue to focus on the existing Pacemaker<br>
> configuration?  perhaps there's some hidden or absent<br>
> order/constraint/weighting that is causing this behavior?<br>
<br>
It's hard to say without configuration and logs. I'd start by checking<br>
the logs to see whether fencing succeeded when the node was killed. If<br>
fencing fails, pacemaker can't recover anything from the dead node.<br>
<br>
> * Should I dig harder at the DRBD configuration?  Is it something<br>
> about the fencing scripts?<br>
<br>
It is a good idea to tie DRBD's fencing scripts to pacemaker. The<br>
LINBIT DRBD docs are the best info for that, where it mentions setting<br>
fence-peer to a crm-fence-peer script.<br>
<br>
> * Should I try stripping this back down to something more basic?  Can<br>
> I have a reliable failover without STONITH, SBD and an odd-numbered<br>
> quorum?<br>
<br>
There's nothing wrong with having both SBD with shared disk, and<br>
qdevice, but you don't need both. If you run qdevice, SBD can get the<br>
quorum information from pacemaker, so it doesn't require the shared<br>
disk.<br>
<br>
> * It seems possible that moving to DRBD 9.X might take some of the<br>
> problem off of Pacemaker altogether since it has built in failover<br>
> apparently, is that an easier win?<br>
> * Should I go to another stack?  I'm trying to work within LTS<br>
> releases for stability, but perhaps I would get better integrations<br>
> with RHEL 7, CentOS 7, an edge release of Ubuntu, or some other<br>
> distribution?<br>
<br>
There are advantages and disadvantages to changing either of the above,<br>
but I doubt any choice will be easier, just a different set of<br>
roadblocks to work through.<br>
<br>
> Thank you for your consideration!<br>
> <br>
-- <br>
Ken Gaillot <<a href="mailto:kgaillot@redhat.com" target="_blank">kgaillot@redhat.com</a>><br>
<br>
_______________________________________________<br>
Manage your subscription:<br>
<a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
<br>
ClusterLabs home: <a href="https://www.clusterlabs.org/" rel="noreferrer" target="_blank">https://www.clusterlabs.org/</a><br>
<br>
</blockquote></div>