<div dir="ltr">Thanks Ken. Let me check resource-stickiness property at my end.<div><br></div><div>Regards,</div><div>Rohit</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 25, 2020 at 8:07 PM Ken Gaillot <<a href="mailto:kgaillot@redhat.com">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 Tue, 2020-08-25 at 12:28 +0530, Rohit Saini wrote:<br>
> Hi All,<br>
> I am seeing the following behavior. Can someone clarify if this is<br>
> intended behavior. If yes, then why so? Please let me know if logs<br>
> are needed for better clarity.<br>
> <br>
> 1. Without Stonith:<br>
> Continuous corosync kill on master causes switchover and makes<br>
> another node as master. But as soon as this corosync recovers, it<br>
> becomes master again. Shouldn't it become slave now?<br>
<br>
Where resources are active or take on the master role depends on the<br>
cluster configuration, not past node issues.<br>
<br>
You may be interested in the resource-stickiness property:<br>
<br>
<a href="https://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/2.0/html-single/Pacemaker_Explained/index.html#_resource_meta_attributes" rel="noreferrer" target="_blank">https://clusterlabs.org/pacemaker/doc/en-US/Pacemaker/2.0/html-single/Pacemaker_Explained/index.html#_resource_meta_attributes</a><br>
<br>
<br>
> 2. With Stonith:<br>
> Sometimes, on corosync kill, that node gets shooted by stonith but<br>
> sometimes not. Not able to understand this fluctuating behavior. Does<br>
> it have to do anything with faster recovery of corosync, which<br>
> stonith fails to detect?<br>
<br>
It's not failing to detect it, but recovering satisfactorily without<br>
fencing.<br>
<br>
At any given time, one of the cluster nodes is elected the designated<br>
controller (DC). When new events occur, such as a node leaving the<br>
corosync ring unexpectedly, the DC runs pacemaker's scheduler to see<br>
what needs to be done about it. In the case of a lost node, it will<br>
also erase the node's resource history, to indicate that the state of<br>
resources on the node is no longer accurately known.<br>
<br>
If no further events happened during that time, the scheduler would<br>
schedule fencing, and the cluster would carry it out.<br>
<br>
However, systemd monitors corosync and will restart it if it dies. If<br>
systemd respawns corosync fast enough (it often is sub-second), the<br>
node will rejoin the cluster before the scheduler completes its<br>
calculations and fencing is initiated. Rejoining the cluster includes<br>
re-sync'ing its resource history with the other nodes.<br>
<br>
The node join is considered new information, so the former scheduler<br>
run is cancelled (the "transition" is "aborted") and a new one is<br>
started. Since the node is now happily part of the cluster, and the<br>
resource history tells us the state of all resources on the node, no<br>
fencing is needed.<br>
<br>
<br>
> I am using<br>
> corosync-2.4.5-4.el7.x86_64<br>
> pacemaker-1.1.19-8.el7.x86_64<br>
> centos 7.6.1810<br>
> <br>
> Thanks,<br>
> Rohit<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>
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>
</blockquote></div>