Cluster fällt aus - vom Switch abhängig

[arnaud056]

Nabend,

ich habe meine Hausinstallation als 3-Node Cluster umgebaut und treffe Probleme, die ich nicht erwartet habe: mit dem großen managed Switch (HPE 1820) kriege ich den Cluster nicht am Laufen, mit einem billigen unmanaged 0815-Switch geht es... fast!

Die Umgebung:
- 3 Nodes mit jeweils 1 USB-LAN Adapter als NIC (Delock 66039 - liefen bis jetzt problemlos mit PVE für "normale" Netzwerkdienste) für Corosync
- Netzwerk für Corosync ist separat von den anderen Netzwerke
- Corosync ist nicht als VLAN in den PVEs configuriert, läuft untagged als VLAN10 (Ports vom großen Switch für VLAN10 konfiguriert) im Switch
- alle pingen sich gegenseitig und verbinden sich SSH auch gegenseitig
- gar kein Ceph
- alles soll 1Gbit-fähig sein

Was passiert (grob): ich verliere die Verbindung zum Cluster ein paar Sekunden nachdem die PVEs hochgefahren sind.
Das eine PVE schreibt seitenweise

[TOTEM ] Retransmit List: 14 15 1c 1d 1f 20 23 24

in den logs,
Das Zweite ist nicht so eindeutig, aber es gibt in regelmäßigen Abstände

TOTEM ] A new membership (1.2f6) was formed. Members left: 2 3

zu lesen
Das Dritte komme ich (bis auf SSH) gar nicht darauf.

Ich fahre das ganze per SSH runter, stöpsle die 3 NICS in den billigen Switch ein, fahre die PVEs hoch und der Cluster ist sofort da, alles ist grün und ich kann keine Probleme aus den Logs erkennen.

Was ich vermute, gesucht und gefunden habe:

• "TOTEM ] Retransmit" deutet auf Netzwerkprobleme auf (ach nein!!) - schlechte Verbindung
• "IGMP snooping" vom Switch kann Probleme machen. Bei mir ist es deaktiviert, so wie alle andere "Sicherheitsfeatures"
• MPU ist oft im Spiel: Da ist alles bei mir original. D.h. 1500 für die Interfaces und 1518 im (großen) Switch
• Ping-Zeiten: ca. 3-4ms mit dem billigen Switch und ca. 0,5ms kürzer mit dem Großen
• Einzelcast - Multicast ????

/etc/pve/corosync.conf:

logging {
  debug: off
  to_syslog: yes
}

nodelist {
  node {
    name: pve-a320m
    nodeid: 3
    quorum_votes: 1
    ring0_addr: 192.168.90.3
  }
  node {
    name: pve-c2550
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 192.168.90.1
  }
  node {
    name: pve-optiplex3020
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 192.168.90.2
  }
}

quorum {
  provider: corosync_votequorum
}

totem {
  cluster_name: cluster-GuedeL
  config_version: 3
  interface {
    linknumber: 0
  }
  ip_version: ipv4-6
  link_mode: passive
  secauth: on
  version: 2
}

/etc/network/interfaces

auto lo
iface lo inet loopback

iface enp7s0 inet manual

iface enp8s0 inet manual

iface enx00133bb2d0c9 inet manual

iface enx00133bace4f4 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.168.20.156/24
    gateway 192.168.20.70
    bridge-ports enp7s0
    bridge-stp off
    bridge-fd 0
#LAN

auto vmbr1
iface vmbr1 inet manual
    bridge-ports enp8s0
    bridge-stp off
    bridge-fd 0
#WAN

auto vmbr2
iface vmbr2 inet manual
    bridge-ports enx00133bb2d0c9
    bridge-stp off
    bridge-fd 0
#DMZ1

auto vmbr3
iface vmbr3 inet static
    address 192.168.90.1/24
    bridge-ports enx00133bace4f4
    bridge-stp off
    bridge-fd 0
#corosync

Das Phänomen des 3. Nodes: dieser Node (hat z.Z. keine VM oder CT) ist nach ein paar Minuten/Stunden nicht mehr in der Lage weder die Anderen zu pingen, noch gepingt zu werden. Aber sich selbst geht. In den Logs sehe ich nichts verdächtiges und plötzlich ist der Quorum verloren.
Sein iplink:

ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp4s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:blabla4f brd ff:ff:ff:ff:ff:ff
3: enp27s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UP mode DEFAULT group default qlen 1000
    link/ether 30:blabla:c2 brd ff:ff:ff:ff:ff:ff
4: enx00133bace58a: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr3 state UP mode DEFAULT group default qlen 1000
    link/ether 00:blabla:8a brd ff:ff:ff:ff:ff:ff
5: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 30:blabla:c2 brd ff:ff:ff:ff:ff:ff
6: vmbr3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 00:blabla:8a brd ff:ff:ff:ff:ff:ff

Ich muss dann den Node neustarten.
Edit: und genau jetzt geht es trotz Neustart nicht mehr!!

=> könnte jemand mir, was dazu sagen? Sind solche Netzwerk-adapter überhaupt für Corosync geeignet?
Danke.
Gruß Arnaud

 

[Falk R.]

Hi, USB Adapter würde ich auch zuhause nur im äußersten Notfall benutzen. Wenn du Ping Laufzeiten von 3-4ms hast, dann stört irgend wer im Netzwerk extrem. Normalerweise solltest du am selben Switch angeschlossen niemals über 0,2 ms Latenz haben.
Leg doch mal den Corosync Link0 auf vmbr0 und guck ob der Cluster dann wenigstens läuft. Dann mal die USB Netzwerkkarten komplett überprüfen.

 

[ce3rd]

hi, nur so, ich glaub nicht, dass das probleme macht, aber da du vermutlich nie eine VM in dein cluster netzwerk hängen wirst, kannst du die 192.168.90er IPs direkt aufs interface binden (zb enx00133bace4f4) ohne bridge vmbr3

 

[UdoB]

Da du ja "alles neu" machst: manchmal gibt es bei der Inbetriebnahme Probleme mit profanen Dingen wie mangelhafte Kabel --> einfach mal gegen andere Exemplare austauschen.

Dass USB häufiger als "richtige Hardware" Problem macht, hatte Falk ja bereits betont. (Ich selber hatte gerade miese Erfahrungen mit NVMe via USB gemacht.)

Eventuell funktionieren USB-NICs eines anderen Herstellers mit einem anderen Chipsatz besser...

Viel Erfolg!

 

[arnaud056]

Guten Abend,
und vielen Dank für euren Einsätze, nach so ein schreckliches WE Opfer von Murphys Gesetz tut es gut, sich nicht allein zu fühlen...
Ich fange an:
Nach dem Post von gestern Abend ging es nichts mehr. Node3 ohne Corosync nach 1 Minute...Node 1 oder 2 liefen kaum länger als 2-3 Minuten bis eins von beiden aufgab..... => ich musste "mal eben" den Cluster definitiv sprengen und zusehen, dass Node1 (da habe ich z.Z. alle VMs und CTs) in Einzelbetrieb weiter läuft. Ist mir auch gelungen - damit ist schon viel Druck vom Kessel runtergekommen.

Heute als erstes habe ich Node2 und Node3 wieder mal neu installiert und die Pings gecheckt. Tatsächlich, wenn wenn vom Onboard-NIC zum Onboard-NIC geping wird, gings bei 0,2-0,3ms (auf dem großen Switch). Sobald ein USB-Adapter im Spiel ist, kommen ca. 1,5ms dazu. 2x usb => 3ms...
Dabei hat Node3 die Netzwerkverbindung mit seinem USB wieder verloren....

Ich habe jetzt testweise Node2, Node3 + 1 Raspberry als Qdevice (weil Node1 bleibt erstmal allein) in Cluster zum testen. Die USB-LAN rausgenommen und alles auf dem primären NIC am Laufen.
Das Einrichten ging so wie ich es mir vorgestellt hatte.....keine 5 Minuten!
Bis jetzt sieht alles super aus, vielleicht packe ich unnötige VMs-CTs darauf, um zu gucken, ob alels etwas Belastung auch stand hält.

da du vermutlich nie eine VM in dein cluster netzwerk hängen wirst, kannst du die 192.168.90er IPs direkt aufs interface binden (zb enx00133bace4f4) ohne bridge vmbr3

ursprünglich wollte ich das pfSync der OPNSense (von der VM <=>Hardware-Maschine) als VLAN tagged auch darauf laufen lassen.
Und dann habe ich mich nicht getraut, die IP da direkt einzurichten, weil out of the box die primäre Interface auch ohne IP ist und die IP wird im vmbr0 gesetzt.

Dass USB häufiger als "richtige Hardware" Problem macht, hatte Falk ja bereits betont

Ich hatte vorher im www recherchiert und es gab positive Rückmeldung mit Linux zum Chipsatz ASIX AX88179A, was im Delock 66039 verbaut ist.
3 davon habe ich für pfSync sowie für Zugänge in der DMZ seit 1-2 Jahren im Betrieb. Eigentlich haben die immer sehr gut gelaufen.....also habe ich den "Umbau" darauf geplant und bin gnadenlos auf dem Bauch gelandet.

Im ww gibt es auch viele Proxmox-Erfolgsmeldungen bassieren auf USB-Apater. Ich weiß aber nicht, ob die im Corosync verbaut wurden, oder "nur" für Dinge wie einen DMZ-Zugang.

Könnt ihr welche empfehlen?

Ich werde anfangen nach 2-fach oder 4-fach Netzwerkkarten zu gucken. Das wird aber tricky sein, weil ich mit PCie-freie Plätze sehr begrenzt bin bzw. ist nicht möglich: Node2 ist ein Dell Optiplex3020mini.
Node 1 hat ein Asrock c2550 als Board (ich glaube, der PCIe ist noch frei) und der Node3 hat ein Asrock A320M mit bereits ein eSATA als PCIe (vielleicht hat das Board 2 Stück davon...).....

Danke nochmal!
Gruß Arnaud