Network redundancy between qnetd and qdevice - possible?

[pavlyuts]

Hello all,

Network redundancy works for ring 0/1 between corosync nodes. But there no native way to provide network redundancy between qdevice and qnetd.

The first idea is to define two or more IP addresses for qnetd node name via DNS/hosts and define node by name in corosync config. Theoretically, if one path got down, other IP should be used to reconnect.

May anyone tell me if the approach could work? Is there any other way to provide network redundancy between qdevice and qnetd?

Sincerely,

Alex

[zzhou1]

Can you leverage networking bonding in your environment?

[jfriesse]

Hi, multiple links feature is "tracked" in more generic #23.

Multiple DNS records solution should work today - qnetd is (by default) listening on all addresses and corosync-qdevice tries to reconnect when connection is lost.

Probably best way to increase redundancy is to clustered qnetd. It might sound a bit weird to have clustered qnetd, but if single instance of qnetd is used for multiple clusters it makes sense.

[pavlyuts]

Can you leverage networking bonding in your environment?

I do, but bonding only protect from single adapter/port failure. Sometimes problem is deeper in the network between, so both bonds are up and OK, but IP connectivity partly broken.

[pavlyuts]

Multiple DNS records solution should work today - qnetd is (by default) listening on all addresses and corosync-qdevice tries to reconnect when connection is lost.

Good news, I need to check if multiple ’/etc/hosts’ records will also work.

[pbhenson]

Good news, I need to check if multiple ’/etc/hosts’ records will also work.

By any chance have you had the time to test this yet? I was planning to try the same config, multiple /etc/hosts records. I confirmed that 'getent hosts' returns multiple IP addresses for a hostname with multiple entries in /etc/hosts so I assume it should.

[jfriesse]

@pbhenson Yup, just for sure tested right now it works. There is quite a large chunk of code to support this feature in

corosync-qdevice/qdevices/nss-sock.c

Line 300 in a8b3ef5

nss_sock_non_blocking_client_try_next(struct nss_sock_non_blocking_client *client)

(TL;DR - result of getaddrinfo is iterated until connect is successful or there is no other address to try).