Stabilitätsprobleme nach Umstellung auf PVE6

[khblenk]

Hallo,

wir haben seit einigen Monaten PVE 5 im Einsatz, der Cluster mit derzeit 17 Nodes lief stabil und zuverlässig. Es gab 2 HA Gruppen auf dem Server mit über hundert Maschinen.

Vor kurzem haben wir das Update auf Debian Buster / PVE 6 gemäß der offiziellen Anleitung durchgeführt. Zunächst wurde Corosync upgedated, was problemlos funktioniert hat. Ich habe mir 2 leere Nodes vorbereitet und diese upgedated. Da es keine Downtime geben sollte habe ich per Bulk Migration die Nodes eines Servers auf einen der freien Server migriert (immer 2 Server parallel). Dann habe ich die 2 freigewordenen Server upgedated, neu gestartet und wieder zurück migriert. Dann ging der Vorgang von vorne los. Alles verlief zunächst problemlos und ohne Ausfälle. Es waren noch 7 Nodes zu machen. Bei der jüngsten Live-Migration kam es dann zum Worst Case: Es waren plötzlich um die 10 Server offline. Alle zur selben Zeit, ich habe vermutet, dass es am Fencing lag. Nachdem alle Nodes neu gestartet wurden, wurde der Cluster wieder "grün" und alles hat gepasst. 4 Server waren noch offline, als plötzlich wieder fast alle Nodes offline waren. Also wieder neu gestartet. Dann blieb zum Glück alles stabil. Ich habe dann versucht einen einzigen Server zu migrieren, dann kam erneut eine Fehlermeldung wegen eines Locks. Beim zweiten Versuch war die Migration "on-going" und der Speicher wurde abgeglichen, als der Servernode (auf dem sonst noch keine Maschine lief) wieder einen Neustart gemacht hat. Beim Booten wurde dann vom bnx2x Netzwerk-Treiber (HP Proliant Server, Firmware ist aktuell) ein Fehler ausgegeben.

Ich habe jetzt vorsorglich die HA Ressourcen aus der Gruppe entfernt und die HA Gruppen gelöscht in der Hoffnung, dass die Server jetzt stabiler laufen. An der Konfiguration hat sich nichts verändert (außer das Update von Debian und PVE). Unter Stretch / PVE5 lief alles stabil. Es hat wohl irgendwas mit der Live-Migration zu tun.

Wie können wir den Fehler näher eingrenzen und beheben? Hat oder hatte jemand ähnliche Probleme?

 

[aaron]

Wie schaut die Corosync config aus? Hat es ein eigenes Netz das auch physikalisch eigenständig ist? Also kein VLAN oder ähnliches.

Ansonsten in die Syslogs schauen und potentiell nach `corosync` filtern und schauen was an Problemen reportet wird. HA deaktivieren ist bei Corosync Problemen ein guter erster Schritt.

 

[khblenk]

Hallo Aaron,

die Netze sind alle über VLANs. Die 2 physikalischen Netzwerkkarten sind mit Bonding verbunden (2 Switche, alles redundant) und es gibt dann rund ein dutzend VLANs für die virtuellen Maschinen.
Was ich zwischenzeitlich noch gemacht habe ist, dass ich für corosync ein zusätzliches separates Netz eingerichtet habe und auch für die Live-Migration ein eigenes VLAN eingerichtet habe. Das war vor dem Update auf PVE6, bzw. zum Zeitpunkt der Fehler noch nicht der Fall. Seit dem konnte ich auch einige Maschinen migrieren, aber ein ungutes Gefühl bleibt.

corosync.conf (das ursprüngliche Netz war ring0, das ist aber kein dediziertes VLAN für corosync; Hab dann ring1 mit einem dedizierten Netz für corosync noch hinzugefügt nachdem die Probleme aufgetreten sind)
--
logging {
debug: off
to_syslog: yes
}
nodelist {
node {
name: server1
nodeid: 1
quorum_votes: 1
ring0_addr: 172.20.211.1
ring1_addr: 192.168.110.1
}
[… weitere Nodes analog zu server1 ...]
quorum {
provider: corosync_votequorum
}
totem {
cluster_name: pve
config_version: 20
interface {
bindnetaddr: 172.20.211.1
ringnumber: 0
}
ip_version: ipv4
secauth: on
version: 2
interface {
linknumber: 0
}
interface {
linknumber: 1
}
}
--

Seit dieser Anpassung ist der Fehler nicht mehr aufgetreten, aber seitdem habe ich auch nicht mehr so intensiv Live-Migrationen durchgeführt und hab ehrlich gesagt auch etwas Angst davor das nochmals auszutesten, da es sich um eine Produktivumgebung handelt.
Während der Livemigration geht aber die Pingdauer schon nach oben. Von daher könnte das schon mit einer generellen höheren Netzauslastung zusammenhängen. Kann man HA / Corosync hier evtl. etwas "toleranterer" einstellen, also z. B. timeouts erhöhen? Das physikalische Netzwerk ist 1 GBit / 10 GBit gemischt (Server zu den Bladeswitches 2x 1 GBit, Switches untereinander 2x 10 GBit).

 

[aaron]

die Netze sind alle über VLANs. Die 2 physikalischen Netzwerkkarten sind mit Bonding verbunden (2 Switche, alles redundant) und es gibt dann rund ein dutzend VLANs für die virtuellen Maschinen.

Corosync will durchgehend eine niedrige Latenz (braucht nicht viel Bandbreite). Deshalb ist die generelle Empfehlung auch, dass man dafür ein dediziertes physikalisches Netz nimmt. Wenn das nicht möglich ist, kann man noch versuchen mit QOS Corosync die Priorität zu geben damit durch andere Dienste die das Netz "verstopfen" die Latenz für Corosync nicht in die Höhe getrieben wird.

Für HA ist ein stabiles Corosync unabdingbar da bei einem Kontaktverlust mit dem Quorum sich Nodes mit HA Gästen nach circa 2 Minuten fencen (hard reset).

Kann man HA / Corosync hier evtl. etwas "toleranterer" einstellen, also z. B. timeouts erhöhen?

Ganz Ehrlich, "there will be dragons" wenn man sich mit diesen Parametern spielen will.

Das physikalische Netzwerk ist 1 GBit / 10 GBit gemischt (Server zu den Bladeswitches 2x 1 GBit, Switches untereinander 2x 10 GBit).

Das klingt ein bisschen Unterdimensioniert :/ Als Workaround könnte man noch in den `Datacenter -> Optionen` Limits für die Migration setzen. Aber dann ist nicht ausgeschlossen, dass ein anderer Dienst das Netz nicht wieder mal voll macht.

Deshalb am besten mehr NICs damit Corosync eine eigene bekommt und wenn das nicht geht kann man versuchen mit QOS Corosync zu bevorzugen damit die Latenzen immer niedrig bleiben, egal was sonst das Netz voll macht.