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

2024-05-06 Thread Ken Gaillot
for 100% > > from > > short-time parallel runs. > > Certainly -- with fencing enabled, the cluster will not recover > resources elsewhere until fencing succeeds. > > > > That does complicate the situation. Ideally there would be some > > > way > > &

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

2024-05-06 Thread Ken Gaillot
wn but an immediate halt. > > > > Please, mind all the above is from my common sense and quite poor > > > fundamental knowledge in clustering. And please be so kind to > > > correct > > > me if I am wrong at any point. > > > > > > Sincerely,

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

2024-05-06 Thread Klaus Wenninger
On Fri, May 3, 2024 at 8:59 PM wrote: > Hi, > > > > 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

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

2024-05-03 Thread alexey
Hi, > > 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

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

2024-05-03 Thread alexey
wrong at any point. > > > > Sincerely, > > > > Alex > > -Original Message- > > From: Users On Behalf Of Ken Gaillot > > Sent: Thursday, May 2, 2024 5:55 PM > > To: Cluster Labs - All topics related to open-source clustering > > welcom

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

2024-05-03 Thread Jan Friesse
Hi, some of your findings are really interesting. On 02/05/2024 01:56, ale...@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

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

2024-05-02 Thread Ken Gaillot
mind all the above is from my common sense and quite poor > fundamental knowledge in clustering. And please be so kind to correct > me if I am wrong at any point. > > Sincerely, > > Alex > -Original Message- > From: Users On Behalf Of Ken Gaillot > Sent: Thursda

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

2024-05-02 Thread alexey
welcomed Subject: Re: [ClusterLabs] Fast-failover on 2 nodes + qnetd: qdevice connenction disrupted. I don't see fencing times in here -- fencing is absolutely essential. With the setup you describe, I would drop qdevice. With fencing, quorum is not strictly required in a two-node cluster (two_no

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

2024-05-02 Thread Ken Gaillot
I don't see fencing times in here -- fencing is absolutely essential. With the setup you describe, I would drop qdevice. With fencing, quorum is not strictly required in a two-node cluster (two_node should be set in corosync.conf). You can set priority-fencing-delay to reduce the chance of

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

2024-05-01 Thread alexey
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. For some reason I can't use 3-node then I have to use qnetd+qdevice 3.0.1. The main goal Is to protect custom app which is not