Thanks for responding Andrei. How would i enable monitors on inactive nodes? I thought monitors runs on all nodes that the resource is on. Would you be able to provide a configuration sample that i can refer to? Or will it be possible to configure the cluster to perform a probe in a given interval? Will appreciate some guidance on this. Thanks
On Mon., Oct. 29, 2018, 13:20 Andrei Borzenkov, <[email protected]> wrote: > 29.10.2018 20:04, [email protected] пишет: > > Hi Guys, > > > > I'm a new user of pacemaker clustering software and I've just configured > a > > cluster with a single systemd resource. I have the following cluster and > > resource configurations below. Failover works perfectly between the two > > nodes however, i wanted to have a constraint/rule or a config that will > > ensure that my resource has a single instance running on the cluster at > all > > times. I'd like to avoid the situation where the resource gets started > > manually and ends up running on both cluster nodes. Hoping to get your > > advice on how to achieve this. Thanks in advance. > > pacemaker does one time probe on each node when pacemaker is started. > This covers the case when resource was manually started before > pacemaker. You can enable monitor on inactive nodes which should also > detect if resource was started outside of pacemaker. But note that it > leaves you some window (up to monitoring interval) when multiple > instances may be up on different nodes until pacemaker is aware of it. > > > > > ---- > > Cluster Name: cluster1 > > Corosync Nodes: > > node1 node2 > > Pacemaker Nodes: > > node1 node2 > > > > Resources: > > Resource: app1_service (class=systemd type=app1-server) > > Operations: monitor interval=10s (app1_service-monitor-interval-10s) > > start interval=0s timeout=120s > > (app1_service-start-interval-0s) > > stop interval=0s timeout=120s > (app1_service-stop-interval-0s) > > failure interval=0s timeout=120s > > (app1_service-failure-interval-0s) > > > > Stonith Devices: > > Fencing Levels: > > > > Location Constraints: > > Ordering Constraints: > > Colocation Constraints: > > Ticket Constraints: > > > > Alerts: > > No alerts defined > > > > Resources Defaults: > > resource-stickiness: 100 > > migration-threshold: 1 > > failure-timeout: 120s > > Operations Defaults: > > No defaults set > > > > Cluster Properties: > > cluster-infrastructure: corosync > > dc-version: 1.1.18-11.el7_5.3-2b07d5c5a9 > > have-watchdog: false > > last-lrm-refresh: 1540829641 > > no-quorum-policy: ignore > > stonith-enabled: false > > symmetric-cluster: true > > > > Quorum: > > Options: > > > > > > _______________________________________________ > > Users mailing list: [email protected] > > https://lists.clusterlabs.org/mailman/listinfo/users > > > > Project Home: http://www.clusterlabs.org > > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > > Bugs: http://bugs.clusterlabs.org > > > > _______________________________________________ > Users mailing list: [email protected] > https://lists.clusterlabs.org/mailman/listinfo/users > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org >
_______________________________________________ Users mailing list: [email protected] https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
