Token has not been received in x ms

[vdm]

Hallo,

es gibt einige Posts zu diesem Thema, aber mit keinem komme ich weiter, daher bitte ich hier um Unterstützung.

3 Nodes sollen es im Cluster werden. (2 Nodes im Netzwerk A, 1 Node im Netzwerk B)
2 Nodes sind schon drinnen. (1 Node aus Netzwerk A mit einer Node aus Netzwerk B - hier musste ich erst auf die richtige MTU kommen, damit das funktioniert hat)

Die Node 2 vom Netzwerk A lässt sich auf Teufel komm raus einfach nicht in den Cluster packen, jeweils weil er wohl den Token nicht rechtzeitig bekommt? Warum?

2023-12-13T19:32:02.734740+01:00 truhe pmxcfs[2341]: [dcdb] notice: cpg_send_message retry 10
2023-12-13T19:32:02.748934+01:00 truhe pmxcfs[2341]: [status] notice: cpg_send_message retry 60
2023-12-13T19:32:03.379108+01:00 truhe corosync[3309]: [TOTEM ] Token has not been received in 6449 ms
2023-12-13T19:32:03.736175+01:00 truhe pmxcfs[2341]: [dcdb] notice: cpg_send_message retry 20
2023-12-13T19:32:03.750488+01:00 truhe pmxcfs[2341]: [status] notice: cpg_send_message retry 70

Eigentlich kenne ich das ja von Netzwerk-übergreifend her, wo wenn die MTU nicht passt, es den selben Effekt des nicht-clusterings zeigt. Aber die MTU passt zwischen allen Nodes (MTU 1336 in der corosync.conf). Jeweils eine OPNSense auf beiden Netzwerkseiten mit Wireguard verbunden (MTU 1412).

# pvecm status
Cluster information
-------------------
Name: manythings
Config Version: 22
Transport: knet
Secure auth: on

Quorum information
------------------
Date: Wed Dec 13 19:48:25 2023
Quorum provider: corosync_votequorum
Nodes: 2
Node ID: 0x00000001
Ring ID: 1.f31
Quorate: Yes

Votequorum information
----------------------
Expected votes: 2
Highest expected: 2
Total votes: 2
Quorum: 2
Flags: Quorate Qdevice

Membership information
----------------------
Nodeid Votes Qdevice Name
0x00000001 1 NA,NV,NMW 192.168.14.10 (local)
0x00000002 1 NA,NV,NMW 192.168.15.11
0x00000000 0 Qdevice (votes 0)

pvecm add <Cluster-IP> hab ich mit und ohne QDevice ausprobiert.
Nach jedem Versuch wurde der Cluster cleaned-up.

Ein neu installiertes Proxmox in Netzwerk A konnte mit dem selben Fehler dem Cluster in Netzwerk A nicht beitreten.
Ein neu installiertes Netzwerk in Netzwerk B konnte dem Cluster in Netzwerk A sauber beitreten.

Liegt es jetzt am Netzwerk, oder am Cluster? Ich weiss, es deutet vieles aufs Netzwerk hin, aber zwischen den Nodes ist nur ein dummer Switch, mit dem es schon funktioniert hat.

 

[cheiss]

Hi,

Aber die MTU passt zwischen allen Nodes (MTU 1336 in der corosync.conf). Jeweils eine OPNSense auf beiden Netzwerkseiten mit Wireguard verbunden (MTU 1412).

Zum Verständnis: Netzwerk A und B sind an verschiedenen, physischen Standorten, die über WireGuard verbunden sind?

Corosync ist ausschließlich für low-latency Netzwerke ausgelegt, d.h. LANs mit <5ms Latenz. Also am besten gar nicht versuchen, das bringt mehr Probleme als es überhaupt löst. Siehe auch u.a. Network Requirements in der Dokumentation.

Du kannst natürlich die 2 Nodes im Netzwerk A clustern, mit einem QDevice. Aber ein Cluster "über das Internet" wird so nicht funktionieren.

 

[vdm]

Hi Christoph,

Das Netz A und Netz B sind in der Tat sogar über 2 Länder gestreckt und sind über Wireguard verbunden.

Die letzten 10 Jahre hatte ich eine Sophos Home UTM und seit ein paar Jahren den Proxmox Cluster und das hat sogar bisher ganz prima funktioniert - bis ich über 50 IP's gekommen bin und nun auf die OPNSense umsteigen musste.

Und um das ganze noch verwunderlicher zu machen... habe ich den Cluster gestern nochmal komplett aufgelöst und "Reihenfolgen" ausprobiert und siehe da, man muss die beiden Netz A Nodes zuerst verclustern, dann konnte ich die Node aus dem Netz B (komplett andere Lokation) auch reinclustern.

Wenn das kein Geist ist, der sich selbst mal ruft. Jedenfalls, Migration und Replikation funktionieren wieder "einwandfrei", bis auf diese paar Logmeldungen hier, wenn eine Replikation läuft:

2023-12-11T21:55:18.106812+01:00 truhe systemd[1]: Started pmlogger_check.service - Check pmlogger instances are running.
2023-12-11T21:55:18.204828+01:00 truhe systemd[1]: pmlogger_farm_check.service: Deactivated successfully.
2023-12-11T21:55:18.436836+01:00 truhe systemd[1]: pmlogger_check.service: Deactivated successfully.
2023-12-11T21:55:18.801441+01:00 truhe corosync[149549]: [TOTEM ] Retransmit List: 51d1 51d2 51d3
2023-12-11T21:55:45.406064+01:00 truhe corosync[149549]: [TOTEM ] Retransmit List: 5284 5285
2023-12-11T21:55:49.076547+01:00 truhe corosync[149549]: [TOTEM ] Retransmit List: 52a0 52a1 52a2 52a3 52a4 52a5
2023-12-11T21:56:03.703160+01:00 truhe pveproxy[1342144]: worker exit
2023-12-11T21:56:03.726591+01:00 truhe pveproxy[436570]: worker 1342144 finished
2023-12-11T21:56:03.726708+01:00 truhe pveproxy[436570]: starting 1 worker(s)
2023-12-11T21:56:03.728937+01:00 truhe pveproxy[436570]: worker 1349368 started
2023-12-11T21:56:05.808608+01:00 truhe corosync[149549]: [TOTEM ] Retransmit List: 530d 530e 530f 5310 5311
2023-12-11T21:56:43.493332+01:00 truhe pveproxy[1349368]: Clearing outdated entries from certificate cache

Re-Transmits sind doch nie was Gutes, oder?

 

[vdm]

And I want to share some details, to highlight Proxmox-PVE-Software, the Team behind and their people great support, even for the unsupported.

traceroute to 192.168.x.y (192.168.x.y), 30 hops max, 60 byte packets
1 _gateway (192.168.y.x) 5.534 ms 5.486 ms 5.478 ms
2 10.2.y.x (10.2.y.x) 56.837 ms 56.824 ms 56.817 ms
3 192.168.x.y (192.168.x.y) 55.472 ms 58.960 ms 58.954 ms

traceroute to 192.168.y.x (192.168.y.x), 30 hops max, 60 byte packets
1 _gateway (192.168.x.y) 0.113 ms 0.082 ms 0.068 ms
2 10.2.x.y (10.2.x.y) 52.991 ms 52.992 ms 53.461 ms
3 192.168.y.x (192.168.y.x) 55.249 ms 55.961 ms 55.550 ms

It is about 800km distance between the nodes with 50/10Mbit on one end and 150/50Mbit on the other.

Thank you for this great software!