[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