Unterbruch während Bootvorgang

[FabianRn]

Hallo zusammen,

wir haben zum wiederholten Male ein recht unangenehmes Phänomen beobachtet:

Proxmox1 wird gebootet, was bei Proxmox2 dazu führt, dass es einen kurzen Netzwerkunterbruch gibt.

Gibt es hier bekannte ähnliche Fälle? Was genau tut ein Proxmox wenn er bootet, was so ein Verhalten verursachen könnte?

Gruß und besten Dank!

Fabian

 

[Matthias.]

Außer dir wird hier niemand wissen, was Proxmox1 und Proxmox2 sind Ich nehme an zwei Nodes im Cluster?
Ein paar Informationen zu deinem Setup wären sicherlich hilfreich.

 

[Dunuin]

Bist du sicher das der zweite node echt nur das Netzwerk verliert und nicht rebootet weil er das Quorum verloren hat?

 

[Chris Strauch]

Ich führe das mal ein wenig aus.

Wir haben derzeit 5 Cluster im Einsatz.

Bis jetzt ist uns zwei mal passiert das wenn wir einen Node rebooten auf einmal das ganze Netz auf allen Clustern hingen.

Das ganze ist jetzt auf zwei verschiedenen Nodes in Verschiedenen Clustern passiert.

Da wir derzeit ein wenig im Dunkeln fischen was es sein könnte was ein Proxmox boot so viel Netz Last verursacht das es in allen 5 Clustern unterbrüche gibt. Das muss ja irgendein broadcast sein der den Zentralen Switch Lahm legt oder ähnliches.

Gibt es hier etwas, was ein Proxmox beim booten macht, was so viel Netzlast verursacht ?
Wir setzten hier noch CEPH auf den Nodes ein, die eigentlich über einen Dedizierten Switch laufen, das heißt das Ceph selbst würde ich ausschließen.

Bzw beim neuen Cluster wo das passiert ist, ist das Ceph sogar einfach Queer verkabelt und läuft gar nicht mehr über einen Switch.

Lieben Gruß
Chris

 

[Chris Strauch]

Beispiel Config des Netzwerkes

auto lo
iface lo inet loopback

iface enp1s0f1np1 inet manual

iface enp67s0f0np0 inet manual

iface enp67s0f1np1 inet manual

iface enx7640941e82bb inet manual

iface eth0 inet manual

iface eno1 inet manual


iface enp129s0f0np0 inet manual


iface enp129s0f1np1 inet manual


iface enp1s0f0np0 inet manual


auto bond0
iface bond0 inet manual
        bond-slaves enp67s0f0np0 enp67s0f1np1 eth0 eno1
        bond-miimon 100
        bond-mode 802.3ad
        bridge-vids 2-4094
        bond-xmit-hash-policy layer3+4

auto vmbr0
iface vmbr0 inet static
        address 10.0.50.1/16
        gateway 10.0.254.254
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vlds 2-4094

auto bond1
iface bond1 inet static
        address 192.168.0.50/24
        bond-slaves enp129s0f0np0 enp1s0f1np1
        bond-miimon 100
        bond-mode balance-rr
        mtu 9000
        up ip route add 192.168.0.48/32 dev bond1
        down ip route del 192.168.0.48/32
#connected to sm48

auto bond2
iface bond2 inet static
        address 192.168.0.50/24
        bond-slaves enp129s0f1np1 enp1s0f0np0
        bond-miimon 100
        bond-mode balance-rr
        mtu 9000
        up ip route add 192.168.0.49/32 dev bond2
        down ip route del 192.168.0.49/32
#connected to sm49

 

[FabianRn]

Ich führe das mal ein wenig aus.

Wir haben derzeit 5 Cluster im Einsatz.

Bis jetzt ist uns zwei mal passiert das wenn wir einen Node rebooten auf einmal das ganze Netz auf allen Clustern hingen.

Das ganze ist jetzt auf zwei verschiedenen Nodes in Verschiedenen Clustern passiert.

Da wir derzeit ein wenig im Dunkeln fischen was es sein könnte was ein Proxmox boot so viel Netz Last verursacht das es in allen 5 Clustern unterbrüche gibt. Das muss ja irgendein broadcast sein der den Zentralen Switch Lahm legt oder ähnliches.

Gibt es hier etwas, was ein Proxmox beim booten macht, was so viel Netzlast verursacht ?
Wir setzten hier noch CEPH auf den Nodes ein, die eigentlich über einen Dedizierten Switch laufen, das heißt das Ceph selbst würde ich ausschließen.

Bzw beim neuen Cluster wo das passiert ist, ist das Ceph sogar einfach Queer verkabelt und läuft gar nicht mehr über einen Switch.

Lieben Gruß
Chris

Danke dir!

 

[FabianRn]

Ich push den Beitrag nochmal, vielleicht kann jemand helfen

 

[B.Otto]

Beispiel Config des Netzwerkes

auto lo
iface lo inet loopback

iface enp1s0f1np1 inet manual

iface enp67s0f0np0 inet manual

iface enp67s0f1np1 inet manual

iface enx7640941e82bb inet manual

iface eth0 inet manual

iface eno1 inet manual


iface enp129s0f0np0 inet manual


iface enp129s0f1np1 inet manual


iface enp1s0f0np0 inet manual


auto bond0
iface bond0 inet manual
        bond-slaves enp67s0f0np0 enp67s0f1np1 eth0 eno1
        bond-miimon 100
        bond-mode 802.3ad
        bridge-vids 2-4094
        bond-xmit-hash-policy layer3+4

auto vmbr0
iface vmbr0 inet static
        address 10.0.50.1/16
        gateway 10.0.254.254
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vlds 2-4094

auto bond1
iface bond1 inet static
        address 192.168.0.50/24
        bond-slaves enp129s0f0np0 enp1s0f1np1
        bond-miimon 100
        bond-mode balance-rr
        mtu 9000
        up ip route add 192.168.0.48/32 dev bond1
        down ip route del 192.168.0.48/32
#connected to sm48

auto bond2
iface bond2 inet static
        address 192.168.0.50/24
        bond-slaves enp129s0f1np1 enp1s0f0np0
        bond-miimon 100
        bond-mode balance-rr
        mtu 9000
        up ip route add 192.168.0.49/32 dev bond2
        down ip route del 192.168.0.49/32
#connected to sm49

Hallo,

wie werden denn die Bonds verwendet? bond0/vmbr0 wird wohl das Netzwerk für die VMs/Proxmox Management sein. Für was werden bond1 und bond2 genutzt?

Eigentlich sollte ein Proxmox-Cluster ein eigenes 'Subnetz' (besser: zwei) für die Clusterkommunikation per Corosync haben.

Viele Grüße,
Benedikt

 

[Chris Strauch]

Hi Benedikt,
danke für deine Antwort.
Genau, das vmbr0 ist für den Corosync als auch für die Kommunikation der VMs.
bond1/bond2 sind für das Ceph direkt Verbindungen zu den jeweils anderen 2 Nodes. Also auch ein Physikalisch getrenntes Netzwerk,

Grüße
Chris

 

[Dunuin]

Corosync sollte eigentlich auch ein eigenes Netz/NIC haben, dass da VM Kommunikation nicht die Latenz soweit einbrechen lassen kann, dass da die Clusterkommunikation zusammenbricht und dir dann wegen Quorum-Verlust die Nodes rebooten.

 

[Chris Strauch]

Das kann man sicherlich noch verbessern. Das ist aber derzeit gar nicht unser Problem, das Problem ist / war, das bei einem Boot von einem Node, das ganze Netz hing. Und das ist uns leider schon 2 mal passiert bei komplett unterschiedlichen Nodes. Aus unterschiedlichen Clustern. Wir haben nur derzeit Probleme überhaupt auf die Spur zu kommen woran es liegen könnte.

 

[FabianRn]

Sind wir demnach die Einzigen mit dem Problem?

 

[fabian]

koenntet ihr wenn das problem auftritt bitte folgende infos zusammentragen und posten?

- 'pveversion -v' von allen nodes
- corosync.conf inhalt
- /etc/network/interfaces inhalt von allen nodes
- 'journalctl -u corosync -u pve-cluster --since REPLACEME --until REPLACEME' von allen nodes (REPLACEME entsprechend ersetzen damit der gesamte zeitraum + ein bisschen davor/danach umfasst ist)