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
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
