[ClusterLabs] qdevice network redundancy

Paul B. Henson henson at acm.org
Wed Oct 1 19:54:01 UTC 2025


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 
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.

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?

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 
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"?

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



More information about the Users mailing list