<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 3, 2024 at 8:59 PM <<a href="mailto:alexey@pavlyuts.ru">alexey@pavlyuts.ru</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">Hi,<br>
<br>
> > Also, I've done wireshark capture and found great mess in TCP, it<br>
> > seems like connection between qdevice and qnetd really stops for some<br>
> > time and packets won't deliver.<br>
> <br>
> Could you check UDP? I guess there is a lot of UDP packets sent by<br>
corosync<br>
> which probably makes TCP to not go thru.<br>
Very improbably.  UPD itself can't prevent TCP from working, and 1GB links<br>
seems too wide for corosync may overload it.<br>
Also, overload usually leads to SOME packets drop, but there absolutely<br>
other case: NO TCP packet passed, I got two captures from two side and I see<br>
that for some time each party sends TCP packets, but other party do not<br>
receive it at all.<br>
<br>
> ><br>
> > For my guess, it match corosync syncing activities, and I suspect that<br>
> > corosync prevent any other traffic on the interface it use for rings.<br>
> ><br>
> > As I switch qnetd and qdevice to use different interface it seems to<br>
> > work fine.<br>
> <br>
> Actually having dedicated interface just for corosync/knet traffic is<br>
optimal<br>
> solution. qdevice+qnetd on the other hand should be as close to "customer"<br>
as<br>
> possible.<br>
> <br>
I am sure qnetd is not intended to proof of network reachability, it only an<br>
arbiter to provide quorum resolution. Therefore, as for me it is better to<br>
keep it on the intra-cluster network with high priority transport. If we<br>
need to make a solution based on network reachability, there other ways to<br>
provide it.<br></blockquote><div><br></div><div>This is an example how you could use network reachability to give </div><div>preference to a node with better reachability in a 2-node-fencing-race.</div><div>There is text in the code that should give you an idea how it is supposed</div><div>to work. </div><div><a href="https://github.com/ClusterLabs/fence-agents/blob/main/agents/heuristics_ping/fence_heuristics_ping.py">https://github.com/ClusterLabs/fence-agents/blob/main/agents/heuristics_ping/fence_heuristics_ping.py</a> </div><div>If you think of combining with priority-fencing ...</div><div>Of course this idea can be applied for other ways of evaluation of a</div><div>running node. I did implement fence_heuristics_ping both for an</div><div>explicit use-case and to convey the basic idea back then - having in mind that</div><div>others might come up with different examples.</div><div><br></div><div>Guess the main idea of having qdevice+qnetd outside of each of the</div><div>2 data-centers (if we're talking about a scenario of this kind) is to be</div><div>able to cover the case where one of these data-centers becomes </div><div>disconnected for whatever reason. Correct me please if there is more to it!</div><div>In this scenario you could use e.g. SBD watchdog-fencing to be able</div><div>to safely recover resources from a disconnected data-center (or site of any</div><div>kind) .</div><div><br></div><div>Klaus</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> So if you could have two interfaces (one just for corosync, second for<br>
> qnetd+qdevice+publicly accessible services) it might be a solution?<br>
> <br>
Yes, this way it works, but I wish to know WHY it won't work on the shared<br>
interface.<br>
<br>
> > So, the question is: does corosync really temporary blocks any other<br>
> > traffic on the interface it uses? Or it is just a coincidence? If it<br>
> > blocks, is<br>
> <br>
> Nope, no "blocking". But it sends quite some few UDP packets and I guess<br>
it can<br>
> really use all available bandwidth so no TCP goes thru.<br>
Use all available 1GBps? Impossible.<br>
<br>
<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><br>
<br>
</blockquote></div></div>