<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Thanks for answering. It helps.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
>Main scenario where poison pill shines is 2-node-clusters where you don't<br>
>have usable quorum for watchdog-fencing.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Not sure i understand. As if just 2 node and one node fails it cannot respond to the poision pilll. Maybe i mis your point.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
This also begs the followup question, what defines "usable quroum".  Do you mean for example on seperate  independent network hardware and power supply?</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
>Configured with pacemaker-awareness - default - availability of the shared-disk doesn't become an issue as, due to fallback to availability of the 2nd node,  the disk is >no spof (single point of failure) in these clusters.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
I did not get the jist of what you are trying to say here. ðŸ™‚<br>
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
>Other nodes btw. can still kill a node with watchdog-fencing. I</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
How does that work when would the killing node tell the other node not to keep triggering its watchdog? </div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Having written the above sentence maybe it should go and read up when does the poison pill get sent by the killing node!</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
>If the node isn't able to accept that wish of another</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
>node for it to die it will have lost quorum, have stopped triggering the watchdog anyway.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Yes that is clear to mean the self-fencing is quite powerful.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
Thanks for the response.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Users <users-bounces@clusterlabs.org> on behalf of users-request@clusterlabs.org <users-request@clusterlabs.org><br>
<b>Sent:</b> 10 October 2024 2:00 PM<br>
<b>To:</b> users@clusterlabs.org <users@clusterlabs.org><br>
<b>Subject:</b> Users Digest, Vol 117, Issue 5</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Send Users mailing list submissions to<br>
        users@clusterlabs.org<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
        <a href="https://lists.clusterlabs.org/mailman/listinfo/users">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
or, via email, send a message with subject or body 'help' to<br>
        users-request@clusterlabs.org<br>
<br>
You can reach the person managing the list at<br>
        users-owner@clusterlabs.org<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Users digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
   1. Re: Fencing Approach (Klaus Wenninger)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 9 Oct 2024 19:03:09 +0200<br>
From: Klaus Wenninger <kwenning@redhat.com><br>
To: Cluster Labs - All topics related to open-source clustering<br>
        welcomed <users@clusterlabs.org><br>
Cc: Angelo Ruggiero <angeloruggiero@yahoo.com><br>
Subject: Re: [ClusterLabs] Fencing Approach<br>
Message-ID:<br>
        <CALrDAo332oqdTEMX82nc-BPWJ=Ea4n_citY71HLamSOv3Kw-cA@mail.gmail.com><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Wed, Oct 9, 2024 at 3:08?PM Angelo Ruggiero via Users <<br>
users@clusterlabs.org> wrote:<br>
<br>
> Hello,<br>
><br>
> My setup....<br>
><br>
><br>
>    - We are setting up a pacemaker cluster to run SAP runnig on RHEL on<br>
>    Vmware virtual machines.<br>
>    - We will have two nodes for the application server of SAP and 2 nodes<br>
>    for the Hana database. SAP/RHEL provide good support on how to setup the<br>
>    cluster. ?<br>
>    - SAP will need a number of floating Ips to be moved around as well<br>
>    mountin/unmounted NFS file system coming from a NetApp device. SAP will<br>
>    need processes switching on and off when something happens planned or<br>
>    unplanned.I am not clear if the netapp devic is active and the other site<br>
>    is DR but what i know is the ip addresses just get moved during a DR<br>
>    incident. Just to be complete the HANA data sync is done by HANA itself<br>
>    most probably async with an RPO of 15mins or so.<br>
>    -  We will have a quorum node also with hopefully a seperate network<br>
>    not sure if it will be on a seperate vmware infra though.<br>
>    - I am hoping to be allowed to use the vmware watchdog although it<br>
>    might take some persuading as declared as "non standard" for us by our<br>
>    infra people. I have it already in DEV to play with now.<br>
><br>
> I managed to set the above working just using a floating ip and a nfs<br>
> mount as my resources and I can see the following. The self fencing<br>
> approach works fine i.e the servers reboot when they loose network<br>
> connectivity and/or become in quorate as long as they are offering<br>
> resources.<br>
><br>
> So my questions are in relation to further fencing .... I did a lot of<br>
> reading and saw various reference...<br>
><br>
><br>
>    1. Use of sbd shared storage<br>
><br>
> The question is what does using sbd with a shated storage really give me.<br>
> I need to justify why i need this shared storage again to the infra guys<br>
> but to be honest also to myself.   I have been given this infra and will<br>
> play with it next few days.<br>
><br>
><br>
>    2. Use of fence vmware<br>
><br>
> In addition there is the ability of course to fence using the fence_vmware<br>
> agents and I again I need to justify why i need this. In this particular<br>
> cases it will be a very hard sell because the dev/test and prod<br>
> environments run on the same vmware infra so to use fence_vmware would<br>
> effectively mean dev is connected to prod i.e the user id for a dev or test<br>
> box is being provided by a production environment. I do not have this<br>
> ability at all so cannot play with it.<br>
><br>
><br>
><br>
> My current thought train...i.e the typical things i think about...<br>
><br>
> Perhaps someone can help me be clear on the benefits of 1 and 2 over and<br>
> above the setup i think it doable.<br>
><br>
><br>
>    1.  gives me the ability to use poison pill<br>
><br>
>    But what scenarios does poison pill really help why would the other<br>
>    parts of the cluster want to fence the node if the node itself has not<br>
>    killed it self as it lost quorum either because quorum devcice gone or<br>
>    network connectivity failed and resources needs to be switched off.<br>
><br>
>               What i get is that it is very explict i.e the others nodes<br>
> tell the other server to die. So it must be a case initiated by the other<br>
> nodes.<br>
>               I am struggling to think of a scenarios where the other<br>
> nodes would want to fence it.<br>
><br>
<br>
Main scenario where poison pill shines is 2-node-clusters where you don't<br>
have usable quorum for watchdog-fencing.<br>
Configured with pacemaker-awareness - default - availability of the<br>
shared-disk doesn't become an issue as, due to<br>
fallback to availability of the 2nd node,  the disk is no spof (single<br>
point of failure) in these clusters.<br>
Other nodes btw. can still kill a node with watchdog-fencing. If the node<br>
isn't able to accept that wish of another<br>
node for it to die it will have lost quorum, have stopped triggering the<br>
watchdog anyway.<br>
<br>
Regards,<br>
Klaus<br>
<br>
><br>
> Possible Scenarios, did i miss any?<br>
><br>
>    - Loss of network connection to the node. But that is covered by the<br>
>    node self fencing<br>
>    - If some monitoring said the node was not healthly or responding...<br>
>    Maybe this is the case it is good for but then it must be a partial failure<br>
>    where the node is still part fof the cluster and can respond. I.e not OS<br>
>    freeze or only it looses connection as then the watchdog or the self<br>
>    fencing will kick in.<br>
>    - HW failures, cpu, memory, disk For virtual hardware does that<br>
>    actually ever fail? Sorry if stupid question. I could ask our infra guys<br>
>    but....,<br>
>    So is virtual hardware so reliable that hw failures can be ignored.<br>
>    - Loss of shared storage SAP uses a lot of shared storage via NFS. Not<br>
>    sure what happens when that fails need to research it a bit but each node<br>
>    will sort that out itself I am presuming.<br>
>    - Human error: but no cluster will fix that and the human who makes a<br>
>    change will realise it and revert. ?<br>
><br>
>        2. Fence vmware<br>
><br>
>       I see this as a better poision pill as it works at the hardware<br>
> level. But if I do not need poision pill then i do not need this.<br>
><br>
> In general OS freezes or even panics if take took long are covered by the<br>
> watchdog.<br>
><br>
> regards<br>
> Angelo<br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Manage your subscription:<br>
> <a href="https://lists.clusterlabs.org/mailman/listinfo/users">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
><br>
> ClusterLabs home: <a href="https://www.clusterlabs.org/">https://www.clusterlabs.org/</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.clusterlabs.org/pipermail/users/attachments/20241009/b9a58eb1/attachment-0001.htm">https://lists.clusterlabs.org/pipermail/users/attachments/20241009/b9a58eb1/attachment-0001.htm</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
Manage your subscription:<br>
<a href="https://lists.clusterlabs.org/mailman/listinfo/users">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
<br>
ClusterLabs home: <a href="https://www.clusterlabs.org/">https://www.clusterlabs.org/</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Users Digest, Vol 117, Issue 5<br>
*************************************<br>
</div>
</span></font></div>
</body>
</html>