>>> Ken Gaillot <[email protected]> schrieb am 22.01.2021 um 00:51 in Nachricht <[email protected]>: > 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 <[email protected]> > > _______________________________________________ > Manage your subscription: > https://lists.clusterlabs.org/mailman/listinfo/users > > ClusterLabs home: https://www.clusterlabs.org/ _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
