[ClusterLabs] Fast-failover on 2 nodes + qnetd: qdevice connenction disrupted.

Jan Friesse jfriesse at redhat.com
Fri May 3 05:34:50 EDT 2024


Hi,
some of your findings are really interesting.

On 02/05/2024 01:56, alexey at pavlyuts.ru wrote:
> Hi All,
> 
>   
> 
> I am trying to build application-specific 2-node failover cluster using
> ubuntu 22, pacemaker 2.1.2 + corosync 3.1.6 and DRBD 9.2.9, knet transport.
> 

...

>   
> 
> Also, I've done wireshark capture and found great mess in TCP, it seems like
> connection between qdevice and qnetd really stops for some time and packets
> won't deliver.

Could you check UDP? I guess there is a lot of UDP packets sent by 
corosync which probably makes TCP to not go thru.

> 
>   
> 
> For my guess, it match corosync syncing activities, and I suspect that
> corosync prevent any other traffic on the interface it use for rings.
> 
>   
> 
> As I switch qnetd and qdevice to use different interface it seems to work
> fine.

Actually having dedicated interface just for corosync/knet traffic is 
optimal solution. qdevice+qnetd on the other hand should be as close to 
"customer" as possible.

So if you could have two interfaces (one just for corosync, second for 
qnetd+qdevice+publicly accessible services) it might be a solution?

> 
>   
> 
> So, the question is: does corosync really temporary blocks any other traffic
> on the interface it uses? Or it is just a coincidence? If it blocks, is

Nope, no "blocking". But it sends quite some few UDP packets and I guess 
it can really use all available bandwidth so no TCP goes thru.

Honza

> there a way to manage it?
> 
>   
> 
> Thank you for any suggest on that!
> 
>   
> 
> Sincerely,
> 
>   
> 
> Alex
> 
>   
> 
>   
> 
> 
> 
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
> 
> ClusterLabs home: https://www.clusterlabs.org/
> 



More information about the Users mailing list