[ClusterLabs] qdevice network redundancy

[Jan Friesse]

On 01/10/2025 21:54, Paul B. Henson via Users wrote:
> On 10/1/2025 1:27 AM, Jan Friesse wrote:
> 
>> you mostly answered all your questions yourself correctly :)
> 
> Heh, yah, I guess I should've gone source code spelunking before 
> pestering the mailing list rather than after :).
> 
>> why there is no multiple links supported (yet) is really it is not 
>> implemented - it's one of todo (https://github.com/corosync/corosync- 
>> qdevice/issues/23).
> 
> In the context of that feature request, "multiple links" would mean 
> maintaining more than one connection simultaneously rather than having 
> to reinitiate a connection when the current open one fails? So rather 

Right

> than having to take the time to connect, you could simply immediately 
> communicate on a different link when communication on the currently 
> active one failed.

Yup, that's the idea and, what is actually more important, right now 
after disconnect cast vote is removed simply to stay on safe side, with 
multiple links vote can remain until there is at least one link working.

> 
> Would you want to mimic the link mode as defined by the corosync 
> protocol, and have passive/active/rr options available? Or do something 
> simpler?

That's tough question and something where I don't have definitive answer 
yet. Advantage of passive is lower bandwidth needed (just regular hb 
packet), disadvantage is, sender cannot throw message until it's known 
it arrived to receiver side. Active doesn't have this problem (all 
packets are sent to all links and worst what can happen is all links 
fail, what is same situation as is now) but higher bandwidth is needed 
and it's unclear what to do with super slow links (should we wait till 
packet is send to all links even slowest one? Have buffer and if buffer 
is too full mark the link failed even if it is not failed just too slow? 
Something else?). RR probably no, because it seems to be combination of 
worst of Passive and Active :) and I don't see any advantage.


> 
> Then presumably there should be some keep alive traffic on links not in 
> use to prevent any intermediate network equipment from timing out state.
> 
> Adding this feature would only require updating the qdevice-net code, 
> not the qnetd code, as the latter already listens on all available 
> interfaces? Unless something was needed on that side for keep alive 

Qnetd update will be needed as well at least because it must be able to 
handle two connections with same node id, right now this is strictly 
prohibited. Also qnetd protocol is not only qdevice request/qnetd reply. 
There is also "Vote info, type 14" 
(https://github.com/corosync/corosync-qdevice/wiki/QNetd-protocol) 
issued by qnetd.

> traffic I suppose.
> 
> Configuration wise, would it accept multiple Host entries rather than 
> just one, and each one would define a single IP address or a set of IP 
> addresses mapped from a hostname that would be used for that "link"?

In config it could be host1: ip, host2: ip, ... hostN: hostname, or 
host: ip1, ip2, ... hostname (or some other delimiter), that's really 
detail.

> 
> Thanks for the reply, I might take a look at implementing this...

Yw and please don't hesitate to ask more questions especially if you 
really decide to implement this feature.

Regards
   Honza

> 
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
> 
> ClusterLabs home: https://www.clusterlabs.org/
>