[ClusterLabs] qdevice network redundancy
Paul B. Henson
henson at acm.org
Wed Oct 1 00:09:53 UTC 2025
I recently deployed a corosync cluster for the first time in the context
of proxmox. We only had two nodes and needed a qdevice for quorum purposes.
The nodes themselves have two fully redundant network connections;
Different subnets for each network, physically different ports for each
network, physically different switches for the ports.
I set up the system running the qdevice similarly, and was surprised
that when I went to add it to the cluster it appears to only support a
single IP address for communicating with it?
While certainly having the qdevice makes the cluster more reliable than
not, the lack of multiple network support makes it less reliable than
having a true third node which could provide quorum in more failure
scenarios.
I was curious why this is the case; is there some underlying design
reason that would prevent a qdevice from communicating over multiple
subnets with the other cluster members? Or is it just something that has
never been implemented? I understand the qdevice doesn't use the
corosync protocol, but just a TCP connection. It looks like
corosync-qnetd listens on the wildcard address and hence accepts
connections on any interface or any IP address associated with the
system it is running on. Is it just a matter of updating the
corosync-qnetd plug-in to accept multiple IP addresses and failover
between them while communicating?
Thanks…
More information about the Users
mailing list