Hi, On Mon, Apr 16, 2018 at 01:22:08PM +0200, Kristoffer Grönlund wrote: > Zach Anderson <zpanderso...@gmail.com> writes: > > > Hey all, > > > > new user to pacemaker/booth and I'm fumbling my way through my first proof > > of concept. I have a 2 site configuration setup with local pacemaker > > clusters at each site (running rabbitmq) and a booth arbitrator. I've > > successfully validated the base failover when the "granted" site has > > failed. My question is if there are any other ways to configure failover, > > i.e. using resource health checks or the like?
You can take a look at "before-acquire-handler" (quite a mouthful there). The main motivation was to add an ability to verify that some other conditions at _the site_ are good, perhaps using environment sensors, say to measure temperature, or if the aircondition works, or such. Nothing stopping you from doing there a resource health check, but it could probably be deemed as something on a rather different "level". > > Hi Zach, > > Do you mean that a resource health check should trigger site failover? > That's actually something I'm not sure comes built-in.. There's nothing really specific about a resource, because booth knows nothing about resources. The tickets are the only way it can describe the world ;-) Cheers, Dejan > though making a > resource agent which revokes a ticket on failure should be fairly > straight-forward. You could then group your resource which the ticket > resource to enable this functionality. > > The logic in the ticket resource ought to be something like "if monitor > fails and the current site is granted, then revoke the ticket, else do > nothing". You would probably want to handle probe monitor invocations > differently. There is a ocf_is_probe function provided to help with > this. > > Cheers, > Kristoffer > > > Thanks! > > _______________________________________________ > > Users mailing list: Users@clusterlabs.org > > 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 > > -- > // Kristoffer Grönlund > // kgronl...@suse.com > _______________________________________________ > Users mailing list: Users@clusterlabs.org > 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: Users@clusterlabs.org 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