Cluster crash on update from 6.1-8 to 6.2-10

[Leah]

Hey,

yesterday I started to upgrade our cluster. Most of the 13 nodes where running 6.1-8 but two or three newer ones already used 6.2-10 as they where added in the last weeks or got upgraded already. No Problem so far. But yesterday I wanted to upgrade another node (node5) and after running the upgrade, just after apt stopped the upgrade process, everything crashed and the whole cluster went offline. All 13 nodes rebooted simultaneously in the same 30 seconds. It looks like the HA fancing was the problem and triggered the reboot but I have no glue why this was the case. The network was working properly and after the reboot everything was okay again. I will add some logs from different nodes...maybe someone can see something I have overseen.

Last part of apt term log:

Processing triggers for ca-certificates (20200601~deb10u1) ...^M
Updating certificates in /etc/ssl/certs...^M
0 added, 0 removed; done.^M
Running hooks in /etc/ca-certificates/update.d...^M
done.^M
Processing triggers for initramfs-tools (0.133+deb10u1) ...^M
update-initramfs: Generating /boot/initrd.img-5.4.44-2-pve^M
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^

Syslog from two randome node just before reboot:
node17: https://drop.leah.is/eTrgFxN9
node6: https://drop.leah.is/Rx9wTitp

And this is the syslog of the host I've upgraded:
https://drop.leah.is/GctH7J3Z

 

[tom]

Please post you corosync.conf:

> cat /etc/pve/corosync.conf

And you network setup (from one node):

> cat /etc/network/interfaces

And you storage.cfg:

> cat /etc/pve/storage.cfg

 

[Leah]

corosync:

logging {
  debug: off
  to_syslog: yes
}

nodelist {
  node {
    name: node10
    nodeid: 6
    quorum_votes: 1
    ring0_addr: 2a0b:20c0:2000:60:42a6::8350
  }
  node {
    name: node11
    nodeid: 7
    quorum_votes: 1
    ring0_addr: 2a0b:20c0:2000:60:3efd::d6f4
  }
  node {
    name: node12
    nodeid: 8
    quorum_votes: 1
    ring0_addr: 2a0b:20c0:2000:60:3efd::d730
  }
  node {
    name: node13
    nodeid: 9
    quorum_votes: 1
    ring0_addr: 2a0b:20c0:2000:60:6a05::5a4
  }
  node {
    name: node14
    nodeid: 10
    quorum_votes: 1
    ring0_addr: 2a0b:20c0:2000:60:42a6::4f8c
  }
  node {
    name: node15
    nodeid: 11
    quorum_votes: 1
    ring0_addr: 2a0b:20c0:2000:60:42a6::bd58
  }
  node {
    name: node16
    nodeid: 12
    quorum_votes: 1
    ring0_addr: 2a0b:20c0:2000:60:42a6::bb24
  }
  node {
    name: node17
    nodeid: 13
    quorum_votes: 1
    ring0_addr: 2a0b:20c0:2000:60:42a6::d0bc
  }
  node {
    name: node5
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 2a0b:20c0:2000:60:3efd::f4c5
  }
  node {
    name: node6
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 2a0b:20c0:2000:60:3efd::f388
  }
  node {
    name: node7
    nodeid: 3
    quorum_votes: 1
    ring0_addr: 2a0b:20c0:2000:60:3efd::ebac
  }
  node {
    name: node8
    nodeid: 4
    quorum_votes: 1
    ring0_addr: 2a0b:20c0:2000:60:3efd::a06c
  }
  node {
    name: node9
    nodeid: 5
    quorum_votes: 1
    ring0_addr: 2a0b:20c0:2000:60:3efd::d698
  }
}

quorum {
  provider: corosync_votequorum
}

totem {
  cluster_name: C1FRA3
  config_version: 13
  interface {
    linknumber: 0
  }
  ip_version: ipv4-6
  secauth: on
  version: 2
}

Network Config

# This file is managed by ansible - please do not edit it as changes will be reverted.

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# Disable onboard interfaces
iface enp3s0f1 inet manual

# Set production interfaces to manual configuration
iface ens4f0 inet manual
iface ens4f1 inet manual

# Aggregation interface (bridged in vmbr0)
auto bond0
iface bond0 inet manual
  bond-slaves ens4f0 ens4f1
  bond-miimon 100
  bond-mode active-backup

# Bridge interface
auto vmbr0
iface vmbr0 inet dhcp
  bridge-ports bond0
  bridge-stp off
  bridge-fd 0
 
iface vmbr0 inet6 static
  address 2a0b:20c0:2000:60:3efd::f4c5
  netmask 64
  autoconf 1
  accept_ra 2

Storage:

dir: local
    path /var/lib/vz
    content iso,rootdir,snippets,vztmpl,images
    maxfiles 0

rbd: HDD
    content images,rootdir
    krbd 0
    pool HDD

rbd: SSD
    content images,rootdir
    krbd 0
    pool SSD

cephfs: cephfs
    path /mnt/pve/cephfs
    content vztmpl,iso,backup

 

[tom]

Der komplette Traffic (corosync, ceph, VMs) läuft über dasselbe Netzwerk und HA ist aktiviert?

Keine gute Idee, das erklärt das Verhalten.

Bitte die Netze trennen (ceph, corosync), dann wirds auch stabil laufen. Siehe Empfehlungen in der Doku.

Auf jeden Fall HA deaktiveren, solange dies nicht entsprechend umgebaut ist.

 

[Leah]

Ich gebe zu, dass ist die naheliegendste Erklärung. Leider dürfte sie hier aber nicht die Richtige sein. Ob der Aufbau an sich klug ist oder nicht sei mal dahin gestellt.

Das ist Setup besteht aus einem 10G Netz das nicht mal zu einem Viertel ausgelastet ist. Während dem Ausfall und auch davor und danach gab es keine Spitzen die das Probleme erklären würden. Der zu rebootende Knoten war komplett evakuiert, an irgendwelchen Kopiervorgängen sollte es also auch nicht liegen. Das Ceph braucht etwa 250Mbit/s pro Host...das also auch nicht. Dazu ist das Problem bisher in keiner Weise aufgetreten, auch nicht bei den vorherigen Hosts letzte Woche.

Die VMs sind übrigens via VLAN und Bandbreiten-Limitierungen getrennt. Auch das ist nicht optimal, aber reicht aktuell.

Ich gehe also schwer davon aus, dass es eine andere Erklärung geben muss.

 

[tom]

Also vielleicht gibt es noch einen anderen Vorschlag was es gewesen ist.

Dies war kein Vorschlag, sondern die Analyse des Problems. Wenn corosysnc Netzwerk überlastet ist und die Kommunikaktion nicht funktioniert, fencen sich die Nodes und rebooten - genau das sehen wir hier.

Corosync sollte auf eigenem Netzwerkkarten laufen, kein VLAN, und natürlich mit zumindest einem zweite Link. Latenz sollte bei ca. 2 ms liegen.

HA bring bei diesem Setup wenig, bzw. erhöht HA konfigurieren die Ausfälle, also das Gegenteil was gewünscht ist.

 

[Leah]

Dies war kein Vorschlag, sondern die Analyse des Problems

Ich hab den Text gerade nochmal etwas präzisiert, vielleicht hilft das. Kannst Du mir erklären was da die freien 7G belegt haben soll (während ich ein Update installiere)?

Hier zwei Ausschnitte aus dem Monitorring. Gesamttraffic alles Proxmox Knoten:


Und hier direkt von den Switchen:



Der Peak etwa 15 Minuten vor dem Ausfall war die Migration der VMs auf einen anderen Knoten.

Es deutet übrigens nichts auf eine erhöhte Latenz hin, die Auslastung der Netzwerk Hardware lag durchgehend bei weniger als 20%

 

[tom]

Es geht hier nicht um die gesamte Bandbreite, sondern um die Verfügbarkeit des corosync Netzwerks.

Best practice für HA:

• eigene Netzwerkkarte nur für corosync
• mindestens 2 getrennte corosync links, auf verschiedenen netzwerkswitches (redundanz)
• latency 2ms oder weniger

Wenn dies so gemacht wird, funktioniert HA wie es soll. Alles andere ist nicht empfohlen.

 

[Leah]

Moin,
leider ist das Problem gestern wieder aufgetreten. Diesmal zum Glück nur bei einem Knoten. Nachdem wir Freitag bis Montag keinerlei Probleme hatten hat gestern wieder ein node spontan rebooted, und zwar 15 Minuten und einen absichtlichen reboot nach dem Update auf 6.2-10. Ich verstehe wirklich nicht, warum es exakt dann passiert wenn wir einen Knoten updaten und sonst seit Monaten und dazwischen nie. Das ist für mein Gefühl zu viel Zufall. Übrigens ist es nur bei einem von zwei nodes passiert die ich gestern auf 6.2-10 aktualisiert habe. Diesmal finde ich auch nichts vom corosync im log...

Vermutlich werden wir jetzt den HA Manager deaktivieren weil es nicht anders vertretbar ist, aber es wäre doch spannend herauszufinden woran es liegt. Gegen das Netzwerk als alleiniger Auslöser spricht ja eigentlich, dass es diesmal nur einen Knoten erwischt hat und auch sonst wieder alles okay aussah.

Hier übrigens das Syslog vom node:

Aug  4 13:27:04 node7 qmeventd[1328]: Starting cleanup for 168
Aug  4 13:27:04 node7 qmeventd[1328]: trying to acquire lock...
Aug  4 13:27:05 node7 pvesr[16115]: trying to acquire cfs lock 'file-replication_cfg' ...
Aug  4 13:27:05 node7 qmeventd[1328]:  OK
Aug  4 13:27:05 node7 qmeventd[1328]: Finished cleanup for 168
Aug  4 13:27:05 node7 pve-ha-lrm[15693]: <root@pam> end task UPID:node7:00003D50:0002584F:5F2945CA:qmshutdown:168:root@pam: OK
Aug  4 13:27:05 node7 pve-ha-lrm[15693]: service status vm:168 stopped
Aug  4 13:27:07 node7 systemd[1]: pvesr.service: Succeeded.
Aug  4 13:27:07 node7 systemd[1]: Started Proxmox VE replication runner.
Aug  4 13:27:09 node7 pmxcfs[2190]: [status] notice: received log
Aug  4 13:27:12 node7 pve-ha-lrm[16214]: starting service vm:168
Aug  4 13:27:12 node7 pve-ha-lrm[16216]: start VM 168: UPID:node7:00003F58:00027365:5F294610:qmstart:168:root@pam:
Aug  4 13:27:12 node7 pve-ha-lrm[16214]: <root@pam> starting task UPID:node7:00003F58:00027365:5F294610:qmstart:168:root@pam:
Aug  4 13:27:12 node7 systemd[1]: Started 168.scope.
Aug  4 13:27:12 node7 systemd-udevd[16223]: Using default interface naming scheme 'v240'.
Aug  4 13:27:12 node7 systemd-udevd[16223]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Aug  4 13:27:12 node7 systemd-udevd[16223]: Could not generate persistent MAC address for tap168i0: No such file or directory
Aug  4 13:27:13 node7 kernel: [ 1607.076265] device tap168i0 entered promiscuous mode
Aug  4 13:27:13 node7 systemd-udevd[16223]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Aug  4 13:27:13 node7 systemd-udevd[16223]: Could not generate persistent MAC address for fwbr168i0: No such file or directory
Aug  4 13:27:13 node7 systemd-udevd[16226]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Aug  4 13:27:13 node7 systemd-udevd[16226]: Using default interface naming scheme 'v240'.
Aug  4 13:27:13 node7 systemd-udevd[16226]: Could not generate persistent MAC address for fwpr168p0: No such file or directory
Aug  4 13:27:13 node7 systemd-udevd[16224]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Aug  4 13:27:13 node7 systemd-udevd[16224]: Using default interface naming scheme 'v240'.
Aug  4 13:27:13 node7 systemd-udevd[16224]: Could not generate persistent MAC address for fwln168i0: No such file or directory
Aug  4 13:27:13 node7 kernel: [ 1607.134221] fwbr168i0: port 1(fwln168i0) entered blocking state
Aug  4 13:27:13 node7 kernel: [ 1607.134225] fwbr168i0: port 1(fwln168i0) entered disabled state
Aug  4 13:27:13 node7 kernel: [ 1607.134366] device fwln168i0 entered promiscuous mode
Aug  4 13:27:13 node7 kernel: [ 1607.134450] fwbr168i0: port 1(fwln168i0) entered blocking state
Aug  4 13:27:13 node7 kernel: [ 1607.134453] fwbr168i0: port 1(fwln168i0) entered forwarding state
Aug  4 13:27:13 node7 kernel: [ 1607.141649] vmbr0v52: port 2(fwpr168p0) entered blocking state
Aug  4 13:27:13 node7 kernel: [ 1607.141653] vmbr0v52: port 2(fwpr168p0) entered disabled state
Aug  4 13:27:13 node7 kernel: [ 1607.141810] device fwpr168p0 entered promiscuous mode
Aug  4 13:27:13 node7 kernel: [ 1607.141879] vmbr0v52: port 2(fwpr168p0) entered blocking state
Aug  4 13:27:13 node7 kernel: [ 1607.141881] vmbr0v52: port 2(fwpr168p0) entered forwarding state
Aug  4 13:27:13 node7 kernel: [ 1607.146589] fwbr168i0: port 2(tap168i0) entered blocking state
Aug  4 13:27:13 node7 kernel: [ 1607.146590] fwbr168i0: port 2(tap168i0) entered disabled state
Aug  4 13:27:13 node7 kernel: [ 1607.146770] fwbr168i0: port 2(tap168i0) entered blocking state
Aug  4 13:27:13 node7 kernel: [ 1607.146771] fwbr168i0: port 2(tap168i0) entered forwarding state
Aug  4 13:27:13 node7 kernel: [ 1607.201058] HTB: quantum of class 10001 is big. Consider r2q change.
Aug  4 13:27:13 node7 pve-ha-lrm[16214]: <root@pam> end task UPID:node7:00003F58:00027365:5F294610:qmstart:168:root@pam: OK
Aug  4 13:27:13 node7 pve-ha-lrm[16214]: service status vm:168 started
Aug  4 13:27:24 node7 pmxcfs[2190]: [status] notice: received log
Aug  4 13:27:39 node7 pmxcfs[2190]: [status] notice: received log
Aug  4 13:27:54 node7 pmxcfs[2190]: [status] notice: received log
Aug  4 13:28:00 node7 systemd[1]: Starting Proxmox VE replication runner...
Aug  4 13:28:00 node7 systemd[1]: pvesr.service: Succeeded.
Aug  4 13:28:00 node7 systemd[1]: Started Proxmox VE replication runner.
Aug  4 13:28:09 node7 pmxcfs[2190]: [status] notice: received log
Aug  4 13:28:24 node7 pmxcfs[2190]: [status] notice: received log
Aug  4 13:28:39 node7 pmxcfs[2190]: [status] notice: received log
Aug  4 13:28:44 node7 pmxcfs[2190]: [status] notice: received log
Aug  4 13:28:54 node7 pmxcfs[2190]: [status] notice: received log
Aug  4 13:28:56 node7 pmxcfs[2190]: [status] notice: received log
Aug  4 13:29:00 node7 systemd[1]: Starting Proxmox VE replication runner...
Aug  4 13:29:01 node7 systemd[1]: pvesr.service: Succeeded.
Aug  4 13:29:01 node7 systemd[1]: Started Proxmox VE replication runner.
Aug  4 13:30:00 node7 ceph-osd[2809]: 2020-08-04 13:29:43.777 7f060e84c700 -1 osd.11 31539 heartbeat_check: no reply from [2a0b:20c0:2000:60:3efd:feff:fed0:f4c5]:6820 osd.0 since back 2020-08-04 13:29:03.102552 front 2020-08-04 13:29:03.109081 (oldest deadline 2020-08-04 13:29:31.134020)
Aug  4 13:30:04 node7 ceph-osd[2808]: 2020-08-04 13:29:57.257 7fef3dc3d700 -1 osd.8 31539 heartbeat_check: no reply from [2a0b:20c0:2000:60:3efd:feff:fed0:f4c5]:6820 osd.0 since back 2020-08-04 13:29:01.109643 front 2020-08-04 13:29:01.109530 (oldest deadline 2020-08-04 13:29:32.226926)
Aug  4 13:30:08 node7 ceph-osd[2808]: 2020-08-04 13:29:59.281 7fef3dc3d700 -1 osd.8 31539 heartbeat_check: no reply from [2a0b:20c0:2000:60:3efd:feff:fed0:f4c5]:6806 osd.1 since back 2020-08-04 13:29:01.109447 front 2020-08-04 13:29:01.109758 (oldest deadline 2020-08-04 13:29:32.226926)
Aug  4 13:32:15 node7 systemd-modules-load[784]: Inserted module 'vhost_net'
Aug  4 13:32:15 node7 systemd[1]: Starting Flush Journal to Persistent Storage...
Aug  4 13:32:15 node7 systemd[1]: Started Flush Journal to Persistent Storage.
Aug  4 13:32:15 node7 systemd[1]: Started udev Coldplug all Devices.
Aug  4 13:32:15 node7 systemd[1]: Starting Helper to synchronize boot up for ifupdown...
Aug  4 13:32:15 node7 kernel: [    0.000000] microcode: microcode updated early to revision 0xb000038, date = 2019-06-18

 

[Leah]

As we got not the help we whised for we decided to disable the HA manager. We removed all VM ressources form the HA manager and also deleted the HA group. Now there is still one question. Is it normal that the status is still active for the lrm or do we need to do a further step to fully disable the HA manager and the fencing.