12.02.2018 18:46, Klaus Wenninger пишет:
> Maybe a few notes on the other way ;-) In general it is not easy to
> have a reliable answer to the question if the other node is down
> within just let's say 100ms. Think of network-hickups, scheduling
> issues and alike ... But if you are willing to accept
> false-positives you can reduce the token timeout of corosync instead
> of having another script that tries to do the job corosync is (amonst
> other things) made for (At least that is how I understood what you
> are aiming to do.).
> Regards, Klaus
Thank you again, Klaus.
Your description helps me to recognize a situation better (i've
overworked a bit and can't this this not so nontrivial think by myself =)).
I've a scenario in the mind when an ability to mark a corosync ring as
failed would be useful, but It doesn't relate to this topic.
It implemention on a corosync side would require some additional
functionality for "checking" (let's call them so) rings that can be used
only for network checking (not for cluster data synchronization). And
the brokage of all "checking" rings (or some more enhanced logic) would
indicate that the node is down or has the split brain. Just an idea.
No the ability? Ok, i try to deal with it )
Users mailing list: Users@clusterlabs.org
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf