<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<body>
<div dir="auto">
<div dir="auto">Good to know it is now not needed. You are correct about logic, yes, I just forgot details. I just recall that sbd added too much load during cluster start and recoveries.</div><div dir="auto"><br></div><div dir="auto">Thank you!</div><div dir='auto'><br></div>
<div id="aqm-original" style="color: black;">
<!-- body start -->
<div class="aqm-original-body">
<div style="color: black;">
<p style="color: black; font-size: 10pt; font-family: sans-serif; margin: 8pt 0;">On August 23, 2020 1:23:37 PM Klaus Wenninger <kwenning@redhat.com> wrote:</p>
<blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #808080; padding-left: 0.75ex;">
    <div class="moz-cite-prefix">On 8/21/20 8:55 PM, Vladislav Bogdanov
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:f16f1c7717b388fcd1445b74340c1372719c2d7e.camel@hoster-ok.com">
      
      <div>Hi,</div>
      <div><br>
      </div>
      <div>btw, is sbd is now able to handle cib diffs internally?</div>
      <div>Last time I tried to use it with frequently changing CIB, it
        became a CPU hog - it requested full CIB copy on every change.</div>
    </blockquote>
    <tt>Actually sbd should have been able to handle cib-diffs since
      ever.</tt><tt><br>
    </tt><tt>Are you sure it requested a full copy of the CIB with every
      change?</tt><tt><br>
    </tt><tt>Atm it should request a full update roughly twice every
      watchdog-timeout</tt><tt><br>
    </tt><tt>and in between just noop-pings to the cib-api - as long as
      imbedding the</tt><tt><br>
    </tt><tt>diffs goes OK of course.</tt><tt><br>
    </tt><tt>In general we need full cib-updates as otherwise loss of a
      cib-diff</tt><tt><br>
    </tt><tt>would mean possibly missing node-state updates.</tt><tt><br>
    </tt><tt>What it on top does is convert the cib to a cluster-state
      roughly</tt><br>
    <tt>every second or with every 10th cib-diff. The latter might
      impose</tt><br>
    <tt>some cpu-usage when cib is updating at a high rate of course and</tt><br>
    <tt>might not be really needed.</tt><br>
    <tt>With the new pacemakerd-API we don't need the cib-diffs anymore</tt><br>
    <tt>for graceful-shutdown-detection. Thus easiest might be to
      disable</tt><br>
    <tt>diff-handling completely when pacemakerd-API is used.<br>
    </tt>
    <blockquote type="cite" cite="mid:f16f1c7717b388fcd1445b74340c1372719c2d7e.camel@hoster-ok.com">
      <div><br>
      </div>
      <div><br>
      </div>
      <div>Fri, 21/08/2020 в 13:16 -0500, Ken Gaillot wrote:</div>
      <blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px
        #729fcf solid;padding-left:1ex">
        <pre>Hi all,</pre>
        <pre></pre>
        <pre>Looking ahead to the Pacemaker 2.0.5 release expected toward the end of</pre>
        <pre>this year, we will have improvements of interest to anyone running</pre>
        <pre>clusters with sbd.</pre>
        <pre></pre>
        <pre>Previously at start-up, if sbd was blocked from contacting Pacemaker's</pre>
        <pre>CIB in a way that looked like pacemaker wasn't running (SELinux being a</pre>
        <pre>good example), pacemaker would run resources without protection from</pre>
        <pre>sbd. Now, if sbd is running, pacemaker will wait until sbd contacts it</pre>
        <pre>before it will start any resources, so the cluster is protected in this</pre>
        <pre>situation.</pre>
        <pre></pre>
        <pre>Additionally, sbd will now periodically contact the main pacemaker</pre>
        <pre>daemon for a status report. Currently, this is just an immediate</pre>
        <pre>response, but it ensures that the main pacemaker daemon is responsive</pre>
        <pre>to IPC requests. This is a bit more assurance that pacemaker is not</pre>
        <pre>only running, but functioning properly. In future versions, we will</pre>
        <pre>have even more in-depth health checks as part of this feature.</pre>
        <pre></pre>
        <pre>Previously at shutdown, sbd determined a clean pacemaker shutdown by</pre>
        <pre>checking whether any resources were running at shutdown. This would</pre>
        <pre>lead to sbd fencing if pacemaker shut down in maintenance mode with</pre>
        <pre>resources active. Now, sbd will determine clean shutdowns as part of</pre>
        <pre>the status report described above, avoiding that situation.</pre>
        <pre></pre>
        <pre>These behaviors will be controlled by a new option in</pre>
        <pre>/etc/sysconfig/sbd or /etc/default/sbd, SBD_SYNC_RESOURCE_STARTUP. This</pre>
        <pre>defaults to "no" for backward compatibility when a newer sbd is used</pre>
        <pre>with an older pacemaker or vice versa. Distributions may change the</pre>
        <pre>value to "yes" since they can ensure both sbd and pacemaker versions</pre>
        <pre>support it; users who build their own installations can set it</pre>
        <pre>themselves if both versions support it.</pre>
      </blockquote>
      <div><br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Manage your subscription:
<a class="moz-txt-link-freetext" href="https://lists.clusterlabs.org/mailman/listinfo/users">https://lists.clusterlabs.org/mailman/listinfo/users</a>

ClusterLabs home: <a class="moz-txt-link-freetext" href="https://www.clusterlabs.org/">https://www.clusterlabs.org/</a>
</pre>
    </blockquote>
    <br>
  </blockquote>
</div>
</div>
<!-- body end -->

</div><div dir="auto"><br></div>
</div></body>
</html>