Proxmox cluster rebooted after restart a crashed node

C

Chris Strauch

Well-Known Member
Proxmox Subscriber
Nov 6, 2018
38
2
48
41
Hallo zusammen,

ich hatte heute morgen ein seltsames verhalten.
Wir betreiben in der Dev Umgebung einen Cluster mit 3 Nodes. Auf der Proxmox Version: pve-manager/7.0-11/63d82f4e (running kernel: 5.11.22-4-pve).

Diese Nacht ist uns ein Node gecrashed.
Die Container wurden zu den anderen beiden Nodes gemoved automatisch, Bis auf ein paar die nicht im HAManager waren. Also alles wie erwartet.

Nachdem ich dann heute morgen den gecrashten Node gebootet habe, sind sofort die beiden anderen Nodes auch gebootet und hatte den Cluster dann einmal kurz komplett Offline.

Wie kommt sowas ? Wie kann ich sowas verhindern ?

Lieben Gruß
Chris
 
bitte einmal pveversion -v und logs von vor dem crash (z.b., journalctl -b-1 von allen nodes posten. danke!
 
Node1:
Code: 
proxmox-ve: 7.0-2 (running kernel: 5.11.22-4-pve)
pve-manager: 7.0-11 (running version: 7.0-11/63d82f4e)
pve-kernel-5.11: 7.0-7
pve-kernel-helper: 7.0-7
pve-kernel-5.4: 6.4-5
pve-kernel-5.11.22-4-pve: 5.11.22-8
pve-kernel-5.4.128-1-pve: 5.4.128-2
pve-kernel-5.4.114-1-pve: 5.4.114-1
pve-kernel-5.4.78-2-pve: 5.4.78-2
pve-kernel-5.4.73-1-pve: 5.4.73-1
ceph: 15.2.14-pve1
ceph-fuse: 15.2.14-pve1
corosync: 3.1.5-pve1
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown: 0.8.36+pve1
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.22-pve1
libproxmox-acme-perl: 1.3.0
libproxmox-backup-qemu0: 1.2.0-1
libpve-access-control: 7.0-4
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.0-6
libpve-guest-common-perl: 4.0-2
libpve-http-server-perl: 4.0-2
libpve-storage-perl: 7.0-11
libqb0: 1.0.5-1
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 4.0.9-4
lxcfs: 4.0.8-pve2
novnc-pve: 1.2.0-3
proxmox-backup-client: 2.0.9-2
proxmox-backup-file-restore: 2.0.9-2
proxmox-mini-journalreader: 1.2-1
proxmox-widget-toolkit: 3.3-6
pve-cluster: 7.0-3
pve-container: 4.0-9
pve-docs: 7.0-5
pve-edk2-firmware: 3.20200531-1
pve-firewall: 4.2-3
pve-firmware: 3.3-1
pve-ha-manager: 3.3-1
pve-i18n: 2.5-1
pve-qemu-kvm: 6.0.0-4
pve-xtermjs: 4.12.0-1
qemu-server: 7.0-13
smartmontools: 7.2-pve2
spiceterm: 3.2-2
vncterm: 1.7-1
zfsutils-linux: 2.0.5-pve1

Node2:
Code: 
proxmox-ve: 7.0-2 (running kernel: 5.11.22-4-pve)
pve-manager: 7.0-11 (running version: 7.0-11/63d82f4e)
pve-kernel-5.11: 7.0-7
pve-kernel-helper: 7.0-7
pve-kernel-5.4: 6.4-5
pve-kernel-5.11.22-4-pve: 5.11.22-8
pve-kernel-5.4.128-1-pve: 5.4.128-2
pve-kernel-5.4.114-1-pve: 5.4.114-1
pve-kernel-5.4.78-2-pve: 5.4.78-2
pve-kernel-5.4.34-1-pve: 5.4.34-2
ceph: 15.2.14-pve1
ceph-fuse: 15.2.14-pve1
corosync: 3.1.5-pve1
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown: 0.8.36+pve1
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.22-pve1
libproxmox-acme-perl: 1.3.0
libproxmox-backup-qemu0: 1.2.0-1
libpve-access-control: 7.0-4
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.0-6
libpve-guest-common-perl: 4.0-2
libpve-http-server-perl: 4.0-2
libpve-storage-perl: 7.0-11
libqb0: 1.0.5-1
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 4.0.9-4
lxcfs: 4.0.8-pve2
novnc-pve: 1.2.0-3
proxmox-backup-client: 2.0.9-2
proxmox-backup-file-restore: 2.0.9-2
proxmox-mini-journalreader: 1.2-1
proxmox-widget-toolkit: 3.3-6
pve-cluster: 7.0-3
pve-container: 4.0-9
pve-docs: 7.0-5
pve-edk2-firmware: 3.20200531-1
pve-firewall: 4.2-3
pve-firmware: 3.3-1
pve-ha-manager: 3.3-1
pve-i18n: 2.5-1
pve-qemu-kvm: 6.0.0-4
pve-xtermjs: 4.12.0-1
qemu-server: 7.0-13
smartmontools: 7.2-pve2
spiceterm: 3.2-2
vncterm: 1.7-1
zfsutils-linux: 2.0.5-pve1

Node3:
Code: 
proxmox-ve: 7.0-2 (running kernel: 5.11.22-4-pve)
pve-manager: 7.0-11 (running version: 7.0-11/63d82f4e)
pve-kernel-5.11: 7.0-7
pve-kernel-helper: 7.0-7
pve-kernel-5.4: 6.4-5
pve-kernel-5.11.22-4-pve: 5.11.22-8
pve-kernel-5.4.128-1-pve: 5.4.128-2
pve-kernel-5.4.114-1-pve: 5.4.114-1
pve-kernel-5.4.78-2-pve: 5.4.78-2
pve-kernel-5.4.34-1-pve: 5.4.34-2
ceph: 15.2.14-pve1
ceph-fuse: 15.2.14-pve1
corosync: 3.1.5-pve1
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown: 0.8.36+pve1
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.22-pve1
libproxmox-acme-perl: 1.3.0
libproxmox-backup-qemu0: 1.2.0-1
libpve-access-control: 7.0-4
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.0-6
libpve-guest-common-perl: 4.0-2
libpve-http-server-perl: 4.0-2
libpve-storage-perl: 7.0-11
libqb0: 1.0.5-1
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 4.0.9-4
lxcfs: 4.0.8-pve2
novnc-pve: 1.2.0-3
proxmox-backup-client: 2.0.9-2
proxmox-backup-file-restore: 2.0.9-2
proxmox-mini-journalreader: 1.2-1
proxmox-widget-toolkit: 3.3-6
pve-cluster: 7.0-3
pve-container: 4.0-9
pve-docs: 7.0-5
pve-edk2-firmware: 3.20200531-1
pve-firewall: 4.2-3
pve-firmware: 3.3-1
pve-ha-manager: 3.3-1
pve-i18n: 2.5-1
pve-qemu-kvm: 6.0.0-4
pve-xtermjs: 4.12.0-1
qemu-server: 7.0-13
smartmontools: 7.2-pve2
spiceterm: 3.2-2
vncterm: 1.7-1
zfsutils-linux: 2.0.5-pve1




Logs folgen.
 
koenntest du vom proxmoxsm27 noch die logs vom aktuellen boot anfuegen? derzeit enden sie mit 6:35 (vermute da war der erste crash?), die der anderen nodes gehen bis 10:xx
 
das scheint nochmal das gleiche file zu sein ;)
 
danke!
 
wir sind gemeinsam mit den corosync/kronosnet entwicklerInnen dran, die ursache zu analysieren. falls es auch moeglich ist auf einem testcluster das verhalten zu reproduzieren, waere das sehr hilfreich - leider haben wir es bis jetzt nur sehr eingeschraenkt geschafft das problem nachzuvollziehen.
 
falls die option besteht in einem gewissen zeitfenster "experimente" zu probieren, bitte bescheid geben dann poste ich welche versionskombinationen/tests interessant waeren.

generell waere es noch interessant mehr details zu eurem netzwerksetup zu erfahren - auf was fuer hardware laufen die corosync links, ist der link geteilt mit anderer nutzung oder nur fuer corosync, MTU oder sonstige besondernheiten, ...
 
Ich gebe bescheid falls ich ein Test Fenster bekomme.

Infos zum Netzwerk:
Wir gehen mit einem 4er Netzwerkkarte an unseren Switch, über den Läuft der Corosync und auch andere Dienste.
Das Ceph haben wir über einen extra Link / Switch laufen.
Als Beispiel hier die config von einem Server, der rest ist genau so aufgebaut.
MTU ist Default 1500 und nicht geändert.



Code: 
auto lo
iface lo inet loopback
iface ens1f0 inet manual
iface ens1f1 inet manual
iface ens1f2 inet manual
iface ens1f3 inet manual
iface eno1 inet manual
iface eno2 inet manual
iface enp2s0f0 inet manual
iface enp2s0f1 inet manual

auto bond0
iface bond0 inet manual
        bond-slaves ens1f0 ens1f1 ens1f2 ens1f3
        bond-miimon 100
        bond-mode 802.3ad
        bond-xmit-hash-policy layer3+4

auto bond1
iface bond1 inet static
        address 192.168.0.27/24
        bond-slaves enp2s0f0 enp2s0f1
        bond-miimon 100
        bond-mode balance-rr

auto vmbr0
iface vmbr0 inet static
        address 10.0.27.1/16
        gateway 10.0.254.254
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
 
kannst du mir noch die corosync config posten (IPs scheinen ja eh alle intern zu sein ;))?
 
Hi Fabian,

klar, die IPs sind nur im Privaten Bereich, daher kein großes Geheimnis :D

Code: 
logging {
  debug: off
  to_syslog: yes
}

nodelist {
  node {
    name: proxmoxsm26
    nodeid: 3
    quorum_votes: 1
    ring0_addr: 10.0.26.1
  }
  node {
    name: proxmoxsm27
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 10.0.27.1
  }
  node {
    name: proxmoxsm44
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 10.0.44.1
  }
}

quorum {
  provider: corosync_votequorum
}

totem {
  cluster_name: EQ-Devcluster
  config_version: 3
  interface {
    linknumber: 0
  }
  ip_version: ipv4-6
  link_mode: passive
  secauth: on
  version: 2
}
 
Hoi Fabian,

ich hatte heute die Möglichkeit den Server nochmal mit einem harten PowerOff abstürzen zu lassen, jedoch ist diesmal der Cluster nicht neu gebootet.

Also bekomme den Fall nicht wirklich reproduziert.
 
danke trotzdem fuer den versuch!
 
wir haben den bug uebrigens gefunden (und noch ein paar andere ;)) - pakete mit den fixes sind bereits auf no-subscription. sh. https://bugzilla.proxmox.com/show_bug.cgi?id=3672 - und den folgenden hinweis von dort (nicht uebersetzt, hoffe das ist okay ;)):

for people who triggered this easily because of their particular load/network situation, it might be advisable to follow the following procedure to avoid triggering it again when installing the fixed versions:

stop the HA services (first LRM on all nodes, then CRM on all nodes - this disables HA, but also disarms the watchdog so you don't risk fencing)

then upgrade all nodes (this will automatically restart corosync, which will pick up the fixed libknet as well)

then start the HA services again (again first LRM on all nodes, then CRM) to re-enable HA features
Click to expand...
 
  • Like
Reactions: Chris Strauch, foxpalace, Falk R. and 2 others
You must log in or register to reply here.
Top Bottom