Extreme Stabilitätsprobleme seit PVE6

Jul 2, 2020
4
0
1
42
Hallo,

ich schreibe nochmals in der Hoffnung das mir jemand helfen kann. Ich habe PVE5 über lange Zeit betrieben und das System lief stabil wie ein Uhrwerk. Seit dem Update auf PVE6 (nach Anleitung) verabschiedet sich der Cluster regelmäßig. Die Umgebung steht in etwa monatlich. Ich hatte in 20 Jahren noch nie mit einem System so massive Probleme wie mit PVE6 seit einem viertel Jahr und "langsam" aber sicher (eigentlich eher "schnell" und sicher) muss ich mir eine Alternative, bzw. ein Migratiosszenario überlegen :-( Deshalb nochmals ein letzter Versuch hier im Forum.

Vorab: Ich habe viel im Forum gelesen und viele User haben oder hatten anscheinend dasselbe Problem, dass die Server ein Fencing durchgeführt haben. Es gibt hier mehrere Lösungsansätze aber nichts definitives. Und: Ich hatte beim ersten Auftreten einen Post bereits erfasst, dort wurde empfohlen die Clusterkommunikation über ein separates, physikalisches Interface zu handeln was so leider nicht ohne weiteres möglich ist (Bladesysteme, kaum erweiterbar) und meiner Meinung nach auch nicht erforderlich sein sollte, ich möchte das anhand unserer Infrastruktur kurz erklären. Außerdem möchte ich die Symptomatik des letzten Ausfalls gestern erklären.

Wir haben 6 Bladecenter von HPE. Die Bladecenter verfügen alle über 2 Switche (GbE2c oder ProCure 6120G/XG) und sind zu einem redundanten Coreswitch mit 10GB Uplink verbunden. Die Bladeserver selbst connektieren sich mit je einer NIC zu je einem Switch (1Gbit). Es gibt 23 Server im Proxmoxcluster die unterschiedlich über die 6 Bladecenter verteilt sind. Die Server verfügen größtenteils über eine Broadcom NetXtreme II Netzwerkkarte (Treiber bnx2x), 3 ältere Modelle noch über eine Emulex OneConnect (Treiber be2net). Dazu gibt es 20 VLANs. 1 VLAN ist für Management, 1 VLAN dediziert für corosync, 1 VLAN dediziert für Migrationstraffic. Die beiden Netzwerkkarten sind via Bonding verbunden. Bondmode 5, balance-tlb. Der Corosync Totem ist über 2 Ringe definiert (VLAN Management + VLAN Corosync). Abgesehen von den 2 Ringen war die Konfiguration unter PVE5 identisch (PVE5 transport udpe mit 1 Ring, PVE6 transport KNET mit 2 Ringen - den zweiten habe ich nach den ersten Ausfällen dazu gebaut). Und unter PVE5 lief es Jahrelang ohne Probleme, von daher frag ich mich ob eine dedizierte physikalische Netzwerkkarte nur für corosync wirklich der Grund sein kann (abgesehen davon, dass die Server baulich bedingt nicht wirklich erweiterbar sind). Tritt ein Fencing ein, fallen ungefähr 50% der Server weg, teilweise sogar mehr. Besonders spannend dabei ist, dass man kein System ableiten kann. So werden z. B. einige Server die im selben Bladecenter (selben Switch) stehen gekillt, andere nicht. In einem Bladecenter z. B. sind 9 Server. 4 wurden gekillt, 5 laufen weiter. Gleichzeitig wurden aber noch 4 weitere Server die sich in anderen Bladecenter befanden gekillt. Dort liefen wiederum andere Proxmoxserver aber fehlerfrei weiter. Wenn die Uplinkverbindung zum Coreswitch gestört wäre, dann müssten theoretisch alle 9 Server des besagten Bladecenter fencen.

Was ist gestern passiert:
Ich habe 3 neue Server zum Cluster hinzugefügt (20 -> 23). Diese 3 Server befanden sich (zusammen mit 2 anderen Servern) zwar im Cluster, aber in keiner HA Gruppe! Auf Server1 lief eine VM die ich über Server 6 (dieser ist Mitglied einer HA Gruppe, über den führe ich immer die Management-Tasks aus) auf Server2 Live migrieren wollte. Während der Livemigration waren plötzlich alle Server die im HA waren weg (nur die Server die ohne HA konfiguriert waren, waren noch online). Es hat also schon etwas mit der "Netzlast" zu tun, aber meine Vermutung ist eher die, dass der Netzwerkkartentreiber Probleme macht. Den im Netz selbst war nicht wirklich eine hohe Auslastung zu beobachten (und unter PVE5 gab das auch nie Probleme). Generell waren die Pingzeiten im Netz gut (ca. 0.145 ms im Schnitt, während der Migration gings auf dem betroffenen System mal vereinzelt auf 1.000 ms in etwa hoch). Und: Auf der Console sah man einen Crashdump von bnx2x (siehe Screenshot) mit der Meldung "Indicating link is down due to Tx-timeout". Generell sieht man - auch beim hochfahren - vielfach Meldungen von der Netzwerkkarte, z. B. beim booten:
Oct 13 00:01:46 ixsl0245 kernel: [ 185.076035] bnx2x 0000:06:00.0 eno49: using MSI-X IRQs: sp 77 fp[0] 79 ... fp[7] 86
Oct 13 00:01:46 ixsl0245 kernel: [ 185.079529] bond0: (slave eno49): link status down for active interface, disabling it in 200 ms
Oct 13 00:01:46 ixsl0245 kernel: [ 185.079530] bond0: (slave eno50): link status up, enabling it in 200 ms
Oct 13 00:01:46 ixsl0245 kernel: [ 185.087520] bond0: (slave eno49): link status down for active interface, disabling it in 200 ms

Daher denke ich, dass sich die Netzwerkschnittstelle verabschiedet und das ganze eher ein Treiberthema ist.

Aufgrund der Foren-Recherche habe ich gestern nach dem Ausfall mal folgende Punkte umgesetzt:
- Umstellung des Bonding von Balance-TLB auf Active-Passive (Mode 1)
- Corosync angepasst:
knet_ping_interval: 200
knet_ping_timeout: 5000
knet_pong_count: 1

Welche anderen Möglichkeiten bleiben mir noch? Corosync wieder auf udpu stellen (auch wenn das deprecated ist, aber unter PVE5 lief alles wunderbar; Momentan möchte ich einfach nur ein stabiles System haben)?
Oder wenns an der Netzwerkkarte liegen sollte: Hab für bnx2 gelesen, dass man beim Laden des Treibers "disable_msi=1" setzen soll. Gilt das auch für bnx2x?
Ich denke das Fehler Fehler entweder in KNET oder im Netzwerkkartentreiber liegt.

pveversion:
proxmox-ve: 6.2-2 (running kernel: 5.4.60-1-pve)
pve-manager: 6.2-11 (running version: 6.2-11/22fb4983)
pve-kernel-5.4: 6.2-6
pve-kernel-helper: 6.2-6
pve-kernel-5.4.60-1-pve: 5.4.60-2
pve-kernel-5.4.44-1-pve: 5.4.44-1
pve-kernel-4.15: 5.4-18
pve-kernel-4.15.18-29-pve: 4.15.18-57
pve-kernel-4.15.18-12-pve: 4.15.18-36
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.0.4-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: 0.8.35+pve1
libjs-extjs: 6.0.1-10
libknet1: 1.16-pve1
libproxmox-acme-perl: 1.0.5
libpve-access-control: 6.1-2
libpve-apiclient-perl: 3.0-3
libpve-common-perl: 6.2-2
libpve-guest-common-perl: 3.1-3
libpve-http-server-perl: 3.0-6
libpve-storage-perl: 6.2-6
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 4.0.3-1
lxcfs: 4.0.3-pve3
novnc-pve: 1.1.0-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.2-12
pve-cluster: 6.1-8
pve-container: 3.2-1
pve-docs: 6.2-5
pve-edk2-firmware: 2.20200531-1
pve-firewall: 4.1-2
pve-firmware: 3.1-3
pve-ha-manager: 3.1-1
pve-i18n: 2.2-1
pve-qemu-kvm: 5.1.0-2
pve-xtermjs: 4.7.0-2
qemu-server: 6.2-14
smartmontools: 7.1-pve2
spiceterm: 3.1-1
vncterm: 1.6-2
zfsutils-linux: 0.8.4-pve1


Anbei auch noch ein Syslogauszug unmittelbar vor dem fencing vom Server, von dem aus ich die Migration gestartet habe.

Über jede Hilfe dankbar...
Viele Grüße
 

Attachments

  • ausfall_20201012_syslogauszug.txt
    9.3 KB · Views: 1
  • ausfall_20201012_nic_server1.PNG
    ausfall_20201012_nic_server1.PNG
    138.5 KB · Views: 3
  • ausfall_20201012_nic_server2.PNG
    ausfall_20201012_nic_server2.PNG
    136.3 KB · Views: 2

dietmar

Proxmox Staff Member
Staff member
Apr 28, 2005
16,746
390
103
Austria
www.proxmox.com
Dazu gibt es 20 VLANs. 1 VLAN ist für Management, 1 VLAN dediziert für corosync, 1 VLAN dediziert für Migrationstraffic.
Mit VLAN trennst du den Traffilc nicht wirklich. Es läuft immer noch alles über das selbe Netzwerk, d.h. eine Migration kann den Cluster Traffic komplett lahmlegen.

Bin mir aber nicht sicher ob das was mit dem Problem zu tun hat. Bei "link status down" hätte ich eher den Switch im verdacht ...
 
Jul 2, 2020
4
0
1
42
Mit VLAN trennst du den Traffilc nicht wirklich. Es läuft immer noch alles über das selbe Netzwerk, d.h. eine Migration kann den Cluster Traffic komplett lahmlegen.

Bin mir aber nicht sicher ob das was mit dem Problem zu tun hat. Bei "link status down" hätte ich eher den Switch im verdacht ...
Hallo Dietmar,

danke für Dein Feedback. Das mit der VLAN Aufteilung ist mir so bewusst. Ich habe jetzt mal in die datacenter.cfg ein bwlimit aufgenommen für die Migration, denn in der Tat hat die gestrige Migration - nachdem es zu einem Ausfall kam - 1gbit/sec gezogen. Evtl. ist das ja die Lösung. Dennoch beunruhigt mich der Crashdump des Netzwerkkartentreibers... und die Tatsache das es unter PVE 5 nie zu einem solchen Vorfall kam (hier war der physikalische Aufbau und die Konfiguration bis auf die Tatsache das jetzt KNET statt udpu bei corosync verwendet wird identisch).
 
Last edited:

Stoiko Ivanov

Proxmox Staff Member
Staff member
May 2, 2018
4,303
536
118

MasterTH

Active Member
Jun 12, 2009
197
5
38
www.sonog.de
ich musste seit pve6 bei intel i219 und i218 chipsätzen das tcp-offloading deaktivieren. das hat bei uns auch zu problemen geführt.
wir haben zwar keine ha-vms aber dennoch waren die vms dann für kurze zeit nicht erreichbar (teilweise mehrere sekunden) so lange bis der kernel den adapter eben resettet hatte.

Code:
post-up ethtool -K enp0s25 gso off gro off tso off
 
Last edited:

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE and Proxmox Mail Gateway. We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get your own in 60 seconds.

Buy now!