[SOLVED] Cluster Upgrade Problem (5.2-10 -> 5.3-5)

[Ingo Alt]

Hallo zusammen,

wir betreiben ein 4 Node Cluster und ich habe gerade auf einem Node das Upgrade von 5.2-10 auf 5.3-5 durchgeführt. Dies führte dazu, dass (auch nach Reboot) der Node den Rest des Clusters nicht mehr sieht und umgekehrt die anderen Nodes ihn nicht.

root@pve04:~# pvecm status
Quorum information
------------------
Date: Wed Jan 2 11:33:31 2019
Quorum provider: corosync_votequorum
Nodes: 1
Node ID: 0x00000002
Ring ID: 2/404
Quorate: No

Votequorum information
----------------------
Expected votes: 4
Highest expected: 4
Total votes: 1
Quorum: 3 Activity blocked
Flags:

Membership information
----------------------
Nodeid Votes Name
0x00000002 1 192.168.43.14 (local)
root@pve04:~#


root@pve01:~# pvecm status
Quorum information
------------------
Date: Wed Jan 2 11:25:25 2019
Quorum provider: corosync_votequorum
Nodes: 3
Node ID: 0x00000004
Ring ID: 4/2744
Quorate: Yes

Votequorum information
----------------------
Expected votes: 4
Highest expected: 4
Total votes: 3
Quorum: 3
Flags: Quorate

Membership information
----------------------
Nodeid Votes Name
0x00000004 1 192.168.43.11 (local)
0x00000001 1 192.168.43.12
0x00000003 1 192.168.43.13
root@pve01:~#

Ist dieses Verhalten normal (aufgrund von Inkompatibilität verschiedener Versionen in einem Cluster)? Wenn ich mich nicht täusche, gab es dieses Problem aber beim Upgrade von 5.1 auf 5.2 nicht...

Ich habe zunächst auf keinem weiteren Node das Upgrade gestartet, da ich nicht dauerhaft das Quorum im verbliebenen Cluster verlieren möchte (das Problem hätte ich mit der zu bevorzugenden ungeraden Anzahl von Nodes natürlich nicht, aber zur Zeit ist das Setup leider so), falls es sich um ein anderes Problem handelt.

Falls das Verhalten normal ist: gibt es eine Möglichkeit, das Upgrade auf dem Cluster ohne Downtime sämtlicher VMs durchzuführen (migrieren kann ich sie ja nicht, wenn die Nodes mit 5.2 und 5.3 sich nie gegenseitig sehen)?

Vielen Dank im voraus für die Hilfe!

 

[tim]

Was steht denn im Syslog bei dem betroffenen Host?
Wie wurde das Update per Webinterface oder command line durchgeführt?
Sollte letzteres der Fall sein, welches Kommando wurde genau ausgeführt?

 

[sb-jw]

Wie sieht denn deine Corosync config aus? Sind eventuell noch Pakete offen die du installieren musst? Gibt es Pakete die vielleicht fehlerhaft installiert wurden? Gibt es vielleicht Pakete, die warum auch immer, entfernt wurden?

 

[Ingo Alt]

Hi,

danke für die Rückmeldung!

Das Upgrade wurde per Webinterface durchgeführt und der Node war schon im Verlauf des Upgrades (vor dem Reboot) irgendwann nicht mehr im Cluster sichtbar.

Laut apt-Log wurde eigentlich nichts entfernt (und es zeigt auch aktuell keine Probleme oder "Reste"):

Start-Date: 2019-01-02 10:48:16
Commandline: apt-get dist-upgrade
Install: pve-kernel-4.15.18-9-pve:amd64 (4.15.18-30, automatic), libjson-c3:amd64 (0.12.1-1.1, automatic)
Upgrade: proxmox-widget-toolkit:amd64 (1.0-20, 1.0-22), corosync:amd64 (2.4.2-pve5, 2.4.4-pve1), perl-base:amd64 (5.24.1-3+deb9u4, 5.24.1-3+deb9u5), libcmap4:amd64 (2.4.2-pve5, 2.4.4-pve1), libpve-
access-control:amd64 (5.0-8, 5.1-3), libpve-storage-perl:amd64 (5.0-30, 5.0-33), openssl:amd64 (1.1.0f-3+deb9u2, 1.1.0j-1~deb9u1), libwbclient0:amd64 (2:4.5.12+dfsg-2+deb9u3, 2:4.5.12+dfsg-2+deb9u4
), libquorum5:amd64 (2.4.2-pve5, 2.4.4-pve1), libarchive13:amd64 (3.2.2-2, 3.2.2-2+deb9u1), perl-modules-5.24:amd64 (5.24.1-3+deb9u4, 5.24.1-3+deb9u5), pve-docs:amd64 (5.2-9, 5.3-1), zfs-initramfs:
amd64 (0.7.11-pve2~bpo1, 0.7.12-pve1~bpo1), libtotem-pg5:amd64 (2.4.2-pve5, 2.4.4-pve1), pve-firewall:amd64 (3.0-14, 3.0-16), pve-container:amd64 (2.0-29, 2.0-31), libqb0:amd64 (1.0.1-1, 1.0.3-1~bp
o9), pve-cluster:amd64 (5.0-30, 5.0-31), zfsutils-linux:amd64 (0.7.11-pve2~bpo1, 0.7.12-pve1~bpo1), libperl5.24:amd64 (5.24.1-3+deb9u4, 5.24.1-3+deb9u5), samba-libs:amd64 (2:4.5.12+dfsg-2+deb9u3, 2
:4.5.12+dfsg-2+deb9u4), pve-i18n:amd64 (1.0-6, 1.0-9), pve-manager:amd64 (5.2-10, 5.3-5), libvotequorum8:amd64 (2.4.2-pve5, 2.4.4-pve1), spl:amd64 (0.7.11-pve2~bpo1, 0.7.12-pve1~bpo1), libzfs2linux
:amd64 (0.7.11-pve2~bpo1, 0.7.12-pve1~bpo1), samba-common:amd64 (2:4.5.12+dfsg-2+deb9u3, 2:4.5.12+dfsg-2+deb9u4), libpve-common-perl:amd64 (5.0-41, 5.0-43), lxc-pve:amd64 (3.0.2+pve1-3, 3.0.2+pve1-
5), qemu-server:amd64 (5.0-38, 5.0-43), libcfg6:amd64 (2.4.2-pve5, 2.4.4-pve1), libsmbclient:amd64 (2:4.5.12+dfsg-2+deb9u3, 2:4.5.12+dfsg-2+deb9u4), smbclient:amd64 (2:4.5.12+dfsg-2+deb9u3, 2:4.5.1
2+dfsg-2+deb9u4), libzpool2linux:amd64 (0.7.11-pve2~bpo1, 0.7.12-pve1~bpo1), pve-edk2-firmware:amd64 (1.20180612-1, 1.20181023-1), perl:amd64 (5.24.1-3+deb9u4, 5.24.1-3+deb9u5), pve-kernel-4.15:amd
64 (5.2-11, 5.2-12), libssl1.1:amd64 (1.1.0f-3+deb9u2, 1.1.0j-1~deb9u1), libnvpair1linux:amd64 (0.7.11-pve2~bpo1, 0.7.12-pve1~bpo1), libuutil1linux:amd64 (0.7.11-pve2~bpo1, 0.7.12-pve1~bpo1), libcp
g4:amd64 (2.4.2-pve5, 2.4.4-pve1), libcorosync-common4:amd64 (2.4.2-pve5, 2.4.4-pve1), libssl1.0.2:amd64 (1.0.2l-2+deb9u3, 1.0.2q-1~deb9u1), proxmox-ve:amd64 (5.2-2, 5.3-1)
End-Date: 2019-01-02 10:49:28

An der corosyc-config hat sich auch nichts geändert:

logging {
debug: off
to_syslog: yes
}

nodelist {
node {
name: pve01
nodeid: 4
quorum_votes: 1
ring0_addr: 192.168.43.11
ring1_addr: 192.168.44.11
}
node {
name: pve02
nodeid: 1
quorum_votes: 1
ring0_addr: 192.168.43.12
ring1_addr: 192.168.44.12
}
node {
name: pve03
nodeid: 3
quorum_votes: 1
ring0_addr: 192.168.43.13
ring1_addr: 192.168.44.13
}
node {
name: pve04
nodeid: 2
quorum_votes: 1
ring0_addr: 192.168.43.14
ring1_addr: 192.168.44.14
}
}

quorum {
provider: corosync_votequorum
}

totem {
cluster_name: pveware
config_version: 4
interface {
bindnetaddr: 192.168.43.0
ringnumber: 0
}
interface {
bindnetaddr: 192.168.43.0
ringnumber: 1
}
ip_version: ipv4
rrp_mode: passive
secauth: on
version: 2
}

Es kommt mir jetzt allerdings komisch vor, dass dort
interface {
bindnetaddr: 192.168.43.0
ringnumber: 1
}
und nicht:
interface {
bindnetaddr: 192.168.44.0
ringnumber: 1
}

Könnte das ein Problem sein? Allerdings sehen alle anderen Nodes auch so aus.

Im Syslog sehe ich auch nichts Auffälliges, ausser wiederkehrender:

Jan 2 10:50:08 pve04 pvesr[56222]: trying to acquire cfs lock 'file-replication_cfg' ...
Jan 2 10:50:09 pve04 pvesr[56222]: error with cfs lock 'file-replication_cfg': no quorum!
Jan 2 10:50:09 pve04 systemd[1]: pvesr.service: Main process exited, code=exited, status=13/n/a
Jan 2 10:50:09 pve04 systemd[1]: Failed to start Proxmox VE replication runner.
Jan 2 10:50:09 pve04 systemd[1]: pvesr.service: Unit entered failed state.
Jan 2 10:50:09 pve04 systemd[1]: pvesr.service: Failed with result 'exit-code'.
Jan 2 10:51:00 pve04 systemd[1]: Starting Proxmox VE replication runner...
Jan 2 10:51:00 pve04 pvesr[57073]: trying to acquire cfs lock 'file-replication_cfg' ...

Ich habe corosync auch nochmal manuell neu gestartet - ebenfalls ihne Erfolg...

 

[sb-jw]

Es kommt mir jetzt allerdings komisch vor, dass dort
interface {
bindnetaddr: 192.168.43.0
ringnumber: 1
}
und nicht:
interface {
bindnetaddr: 192.168.44.0
ringnumber: 1
}

AFAIK sollte tatsächlich bei "ringnumber: 1" die 44 und nicht 43 stehen. Ich denke aber auch nicht, dass das ein Problem darstellen sollte.

- Es heißt aber, dass alle Nodes noch in der Corosync Config vorhanden sind?
- Stimmt die Version auf allen überein?
- Kannst du ohne weiteres von jedem Node auf jeden Connecten (mit SSH Keys) ohne Passwort?
- Kann jeder Node angepingt werden über jede Adresse (ring 0 und ring 1)?
- Sind eventuell noch Pakete offen die du installieren musst?
- Gibt es Pakete die vielleicht fehlerhaft installiert wurden?

 

[Ingo Alt]

AFAIK sollte tatsächlich bei "ringnumber: 1" die 44 und nicht 43 stehen. Ich denke aber auch nicht, dass das ein Problem darstellen sollte.

sehe ich auch so - das ist ja (wenn) ein "Bestandsproblem"

- Es heißt aber, dass alle Nodes noch in der Corosync Config vorhanden sind?

richtig

- Stimmt die Version auf allen überein?

nein, das war im Prinzip Teil meiner ersten Frage: auf dem einen Node ist jetzt (im Rahmen des Upgrades) "2.4.4-pve1", auf den anderen dreien noch "2.4.2-pve5"

- Kannst du ohne weiteres von jedem Node auf jeden Connecten (mit SSH Keys) ohne Passwort?

ja, das geht (die Keys sind o.k.) - hatte ich schon geprüft

- Kann jeder Node angepingt werden über jede Adresse (ring 0 und ring 1)?

ja, das geht - hatte ich schon geprüft

- Sind eventuell noch Pakete offen die du installieren musst?

nein (s.o.)

- Gibt es Pakete die vielleicht fehlerhaft installiert wurden?

nein (s.o.)

 

[sb-jw]

- Stimmt die Version auf allen überein?

nein, das war im Prinzip Teil meiner ersten Frage: auf dem einen Node ist jetzt (im Rahmen des Upgrades) "2.4.4-pve1", auf den anderen dreien noch "2.4.2-pve5"

Sorry, etwas unpräzise formuliert von mir
Meine Frage bezog sich auf die Version in der Corosync Config.

Ist der Node noch in der PVE GUI zu sehen und in der Clusterübersicht noch vorhanden?

Läuft das PVE Filesystem denn noch auf dem Node, der nicht mehr richtig funktioniert? Also z.B. "/etc/pve/nodes/pve02/qemu-server" aufrufen und schauen ob die Configs sichtbar sind oder einfach mit "systemctl status pve-cluster.service" prüfen. Ansonsten könntest du vielleicht auch hier nochmal schauen, ob alles auf dem pve04 noch passt: https://pve.proxmox.com/wiki/Proxmox_Cluster_File_System_(pmxcfs)

 

[Ingo Alt]

Danke für die Hilfe!

O.k. - Missverständnis... Ja, die ist mit "config_version: 4" überall identisch und auch das PVE-Filesystem ist in überall Ordnung (hatte ich mir schon angesehen) und eben nur auf dem einen Node read-only.

Eigenartig ist auch, dass ich den Node mit allen Leistungswerten auf der Weboberfläche (anderer Host) sehen kann - ich kann nur nichts damit machen, weil er kein Quorum hat.

Die beiden corosync-Ringe habe ich mit "omping" getestet - alles gut...

Allerdings sieht der corosync-Status "verdächtig" aus - mir ist ein Rätsel, wie er auf die gleichen Adressen kommt (das sieht auf den drei "alten" Nodes so aus - auf dem zweiten Ring müsste eigentlich jeweils eine 192.168.44.0/24 Adresse liegen und das ist gemäss "ip a" auch so) und warum er den Ring "FAULTY" markiert:
root@pve03:~# corosync-cfgtool -s
Printing ring status.
Local node ID 3
RING ID 0
id = 192.168.43.13
status = Marking ringid 0 interface 192.168.43.13 FAULTY
RING ID 1
id = 192.168.43.13
status = ring 1 active with no faults
root@pve03:~#

Der aktualisierte Node liefert das (sieht aber die anderen Nodes nicht):
root@pve04:~# corosync-cfgtool -s
Printing ring status.
Local node ID 2
RING ID 0
id = 192.168.43.14
status = ring 0 active with no faults
RING ID 1
id = 192.168.44.14
status = ring 1 active with no faults
root@pve04:~#

Das würde erklären, warum der Node sich separiert (Adressen der anderen Nodes auf dem zweiten Ring sind "falsch" und damit nicht erreichbar)

Die Schnittstellen habe ich allerdings alle geprüft (ping und omping) - sehr mysteriös...

Wenn es keine logische Erklärung gibt, muss ich vermutlich mal einen weiteren Node durchstarten - in der Hoffung dass er sich dann nicht auch separiert und für eine der beiden Seiten entscheidet. Gefällt mir allerdings nicht...

 

[Ingo Alt]

Das Problem ist gelöst: es gab gar keinen Zusammenhang mit dem Update (was natürlich naheliegend erschien), sondern es hatte sich (wie auch immer) irgendwann ein Bug in unsere corosync-Konfiguration eingeschlichen, der nach dem ersten Reboot der letzten zwei Monate nun Wirkung zeigte.

Positiv daran: wieder ein paar Feinheiten und nützliche Kommandos dazugelernt...

Vielen Dank für die Hilfe!

 

[sb-jw]

Positiv daran: wieder ein paar Feinheiten und nützliche Kommandos dazugelernt...

Vielleicht magst du das ja mal mit uns teilen? Würde mich auch interessieren, was genau das Problem war und woran man es vielleicht erkennen kann

 

[Ingo Alt]

Klar, im Prinzip ist es das, was sich oben angedeutet hatte - gleiche "bindnetaddr" auf beiden Ringen (192.168.43.0/24 und 192.168.44.0/24) in der corosync.conf und damit falsch auf dem zweiten Ring (ID 1):
...
totem {
cluster_name: pveware
config_version: 4
interface {
bindnetaddr: 192.168.43.0
ringnumber: 0
}
interface {
bindnetaddr: 192.168.43.0
ringnumber: 1
}
ip_version: ipv4
rrp_mode: passive
secauth: on
version: 2
}
...

Irgendwie führte das dann im Betrieb (eventuell auch, weil wir zwischenzeitlich einen Ausfall des ersten Rings getestet hatten) zu:
root@pve03:~# corosync-cfgtool -s
Printing ring status.
Local node ID 3
RING ID 0
id = 192.168.43.13
status = Marking ringid 0 interface 192.168.43.13 FAULTY
RING ID 1
id = 192.168.43.13
status = ring 1 active with no faults
root@pve03:~#

Nach dem Reboot sah es so aus:
root@pve04:~# corosync-cfgtool -s
Printing ring status.
Local node ID 2
RING ID 0
id = 192.168.43.14
status = ring 0 active with no faults
RING ID 1
id = 192.168.44.14
status = ring 1 active with no faults
root@pve04:~#

Das führte dann dazu, dass "pve04" auf dem ersten Ring die anderen Nodes nicht sehen konnte (da er dort "FAULTY" war) und ebenfalls nicht auf dem zweiten Ring, da sie dort im falschen Netzsegment unterwegs waren...

Nachdem ich die Konfiguration bereinigt hatte:
...
totem {
cluster_name: pveware
config_version: 5
interface {
bindnetaddr: 192.168.43.0
ringnumber: 0
}
interface {
bindnetaddr: 192.168.44.0
ringnumber: 1
}
ip_version: ipv4
rrp_mode: passive
secauth: on
version: 2
}
...
war nach Reboot der vier Nodes wieder alles in Ordnung.

Immer wieder die alte Regel: "Boot tut gut" ;-)