Just that we can come to common terms, do you mean the effective
reachability from the other site, as opposed to plain locally known
fact that that respective assigned virtual IP is up, and perhaps
responding (not necessarily meaning that address would be reachable
from the outside)?
>> Yes, I am talking about directly reachability between two booth-ip only.
Since I will be using manual tickets, I am interested in some kind of event
from pcs/booth which tells me that booth peer is down or unreachable,
so I can grant manual ticket to myself and become active.
We can ignore split-brain scenarios as of now since I will handling that
via some other way.
You can always crank up your own down-to-socket-communication
monitoring and hook it into your "beyond pacemaker/booth alone"
>> This would be the last solution I would like to go for. I will have
anyways application TCP link between these two booth-ips.
But still I would prefer some pcs/booth notification if possible, rather
implementing my own logic.
On Wed, Aug 21, 2019 at 6:07 PM Jan Pokorný wrote:
> On 21/08/19 14:49 +0530, Rohit Saini wrote:
> > I am using booth (two clusters) using manual ticket. Is there any
> > way for cluster-1 to know if peer cluster-2 booth-ip is not
> > reachable. Here I am looking to know if there both the sites are
> > connected and reachable via each other's booth-ip.
>
> Just that we can come to common terms, do you mean the effective
> reachability from the other site, as opposed to plain locally known
> fact that that respective assigned virtual IP is up, and perhaps
> responding (not necessarily meaning that address would be reachable
> from the outside)?
>
> I think having a detached arbitrator on a 3rd site (that is, without
> reachability biases amongst other issues, should it be located with
> either of the production sites) is the best way to address such
> a concern, at least unless manual ticket mode of operation is in place.
> TBH, haven't thought of consequences in that very case.
>
> > pcs alerts gives notification about cluster resources/nodes whenever
> > they start or join the cluster but there seems to be no option for
> > booth notifications.
>
> Naturally, it's above pacemaker's ("local cluster only") level of
> reasoning, and only pacemaker talks such "hook execution language" at
> the moment (putting before-acquire-handler of booth aside as not
> relevant here universally, AFAICT).
>
> You can always crank up your own down-to-socket-communication
> monitoring and hook it into your "beyond pacemaker/booth alone"
> decision engine you seem to be building anyway. Just be cautious
> about the mentioned network-proximity biases if you want (you shall)
> as objective picture as feasible.
>
> --
> Jan (Poki)
> ___
> 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/
