[ClusterLabs] Coming in Pacemaker 2.0.5: better start-up/shutdown coordination with sbd

Vladislav Bogdanov bubble at hoster-ok.com
Sun Aug 23 06:39:43 EDT 2020


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.

Thank you!

On August 23, 2020 1:23:37 PM Klaus Wenninger <kwenning at redhat.com> wrote:
> On 8/21/20 8:55 PM, Vladislav Bogdanov wrote:
>> Hi,
>>
>> btw, is sbd is now able to handle cib diffs internally?
>> Last time I tried to use it with frequently changing CIB, it became a CPU 
>> hog - it requested full CIB copy on every change.
> Actually sbd should have been able to handle cib-diffs since ever.
> Are you sure it requested a full copy of the CIB with every change?
> Atm it should request a full update roughly twice every watchdog-timeout
> and in between just noop-pings to the cib-api - as long as imbedding the
> diffs goes OK of course.
> In general we need full cib-updates as otherwise loss of a cib-diff
> would mean possibly missing node-state updates.
> What it on top does is convert the cib to a cluster-state roughly
> every second or with every 10th cib-diff. The latter might impose
> some cpu-usage when cib is updating at a high rate of course and
> might not be really needed.
> With the new pacemakerd-API we don't need the cib-diffs anymore
> for graceful-shutdown-detection. Thus easiest might be to disable
> diff-handling completely when pacemakerd-API is used.
>>
>>
>> Fri, 21/08/2020 в 13:16 -0500, Ken Gaillot wrote:
>>> Hi all,
>>>
>>> Looking ahead to the Pacemaker 2.0.5 release expected toward the end of
>>> this year, we will have improvements of interest to anyone running
>>> clusters with sbd.
>>>
>>> Previously at start-up, if sbd was blocked from contacting Pacemaker's
>>> CIB in a way that looked like pacemaker wasn't running (SELinux being a
>>> good example), pacemaker would run resources without protection from
>>> sbd. Now, if sbd is running, pacemaker will wait until sbd contacts it
>>> before it will start any resources, so the cluster is protected in this
>>> situation.
>>>
>>> Additionally, sbd will now periodically contact the main pacemaker
>>> daemon for a status report. Currently, this is just an immediate
>>> response, but it ensures that the main pacemaker daemon is responsive
>>> to IPC requests. This is a bit more assurance that pacemaker is not
>>> only running, but functioning properly. In future versions, we will
>>> have even more in-depth health checks as part of this feature.
>>>
>>> Previously at shutdown, sbd determined a clean pacemaker shutdown by
>>> checking whether any resources were running at shutdown. This would
>>> lead to sbd fencing if pacemaker shut down in maintenance mode with
>>> resources active. Now, sbd will determine clean shutdowns as part of
>>> the status report described above, avoiding that situation.
>>>
>>> These behaviors will be controlled by a new option in
>>> /etc/sysconfig/sbd or /etc/default/sbd, SBD_SYNC_RESOURCE_STARTUP. This
>>> defaults to "no" for backward compatibility when a newer sbd is used
>>> with an older pacemaker or vice versa. Distributions may change the
>>> value to "yes" since they can ensure both sbd and pacemaker versions
>>> support it; users who build their own installations can set it
>>> themselves if both versions support it.
>>
>>
>> _______________________________________________
>> Manage your subscription:
>> https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: 
>> https://www.clusterlabs.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clusterlabs.org/pipermail/users/attachments/20200823/2f0d5881/attachment-0001.htm>


More information about the Users mailing list