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