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/
_______________________________________________
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/users
ClusterLabs home: https://www.clusterlabs.org/
