[ClusterLabs] Antw: [EXT] Coming in Pacemaker 2.1.0: noncritical resources

[Ulrich Windl]

>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 22.01.2021 um 00:51 in
Nachricht
<ffb31a4b0cc5ddfd2821d7a8d63961afcdce05d1.camel at redhat.com>:
> Hi all,
> 
> A recurring request we've seen from Pacemaker users is a feature called
> "non‑critical resources" in a proprietary product and "independent
> subtrees" in the old rgmanager project.
> 
> An example is a large database with an occasionally used reporting
> tool. The reporting tool is colocated or grouped with the database. If
> the reporting tool fails enough times to meet its migration‑threshold,
> Pacemaker would traditionally move both resources to another node, to
> be able to keep them both running.

My opinion is "beware of the bloatware": Do we really need this? Maybe work on
a more stable basement instead.
Couldn't this be done with on-fail=block already? I mean: primarily the
reporting tool should be fixed, and if it's not essential, it's seems OK that
it won't start automatically after failure.
Also one may ask: If it's not essential, why does it run in a cluster?
Another alternative could be: Make the cluster define a cron job that starts
the reporting tool if it's crashed. The cron job would follow the database.
(Actually I implemented a similar thing)

> 
> However, the database may be essential, and take a long time to stop
> and start, whereas the reporting tool may not be that important. So,
> the user would rather stop the reporting tool in the failure scenario,
> rather than cause a database outage to move both.
> 
> With the upcoming Pacemaker 2.1.0, this can be controlled with two new
> options.
> 
> Colocation constraints may take a new "influence" option that
> determines whether the dependent resource influences the location of
> the main resource, if the main resource is already active. The default
> of true preserves the previous behavior. Setting it to false makes the
> dependent resource stop rather than move the main resource.
> 
> Resources may take a new "critical" meta‑attribute that serves as a
> default for "influence" in all colocation constraints involving the
> resource as the dependent, as well as all groups involving the
> resource.
> 
> In our above example, either the colocation constraint could be marked
> with influence=false, or the reporting tool resource could be give the
> meta‑attribute critical=false, to achieve the desired effect.

I wonder: How would the cluster behave if the colocation score is zero?

Regards,
Ulrich

> 
> A big list of all changes for 2.1.0 can be found at:
> 
>  https://wiki.clusterlabs.org/wiki/Pacemaker_2.1_Changes 
> ‑‑ 
> Ken Gaillot <kgaillot at redhat.com>
> 
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users 
> 
> ClusterLabs home: https://www.clusterlabs.org/