[SOLVED] Ungeplanter Neustart aller Nodes im Cluster auf denen ceph läuft

[BenediktS]

Hallo an alle,

wir haben Folgendes Problem:

Es ist jetzt zum zweiten Mal vorgekommen, dass alle Nodes unseres Clusters, auf denen Ceph läuft, sich ohne Vorwarnung neu gestartet haben.
Wir finden den Grund nicht und hoffen das ihr uns Tipps geben könnt wo wir suchen können.

Cluster:

9 Nodes , Node 1-7 sind Storage-Nodes auf denen Ceph läuft, Node 8 und 9 sind "Compute-only-Nodes"

Netzwerkkonfiguration: Nodes 1-7 haben jeweils zwei Mellanox ConnectX3 Pro 2x40GBit/s Karten.
Diese sind an zwei 40GBit Switchen (Marke FS), jeweils eine Karte mit beiden Ports an einem Switch.
Die zweite Karte ist ausschließlich für das Rebalancing/Recovery von Ceph eingerichtet.

Beispiel der Netzwerkonfiguration der Nodes 1 - 7:

Nodes 8 und 9 haben jeweils nur eine Mellanox ConnectX3 mit 2 x 40GBit/s
Diese sind jeweils mit beiden Switches mit einem Port der Karte verbunden.

Beispiel der Netzwerkonfiguration der Nodes 8 und 9:


Log Einträge vor dem Crash sind im Anhang.

Linux Kernel: 6.1.2-1-pve #1 SMP PREEMPT_DYNAMIC PVE 6.1.2-1 (2023-01-10T00:00Z) x86_64 GNU/Linux
Ceph: 17.2.5 (e04241aa9b639588fa6c864845287d2824cb6b55) quincy (stable)

cluster:
id: 79093787-e47c-4099-bb68-caa12d18d996
health: HEALTH_OK

services:
mon: 3 daemons, quorum prox3,prox2,prox4 (age 3h)
mgr: prox2(active, since 3h), standbys: prox3
mds: 1/1 daemons up, 1 standby
osd: 33 osds: 33 up (since 3h), 33 in (since 3h)

data:
volumes: 1/1 healthy
pools: 5 pools, 1121 pgs
objects: 16.77M objects, 16 TiB
usage: 46 TiB used, 73 TiB / 119 TiB avail
pgs: 1121 active+clean


Wäre cool wen jemand eine Idee hat wonach wir suchen können.
Danke im Voraus!

 

[aaron]

Es gibt als HA konfigurierte VMs/CTs oder?

Wie sieht die Konfiguration von Corosync aus? Welche Netze darf es verwenden? Gibt es ein dediziertes physikalisches Netz dafür (mit anderen als Fallback)?

Der "klassiker" ist, dass Corosync nur das Ceph Netzwerk konfiguriert hat, oder sich das/die physikalische Netz(e) mit anderen Diensten teilt, die durchaus mal die gesamte Bandbreite in Beschlag nehmen können.

Dadurch steigt dann die Latenz für die Corosyncpakete. Wenn diese zu hoch ist, verliert Corosync, und somit der PVE Cluster die Verbindung. Wenn die Situation dann zu lange andauert, fencen sich die Nodes, da sie nicht mehr Teil des Quorums sind. Die Hoffnung ist, dass es noch einen quoraten rest-Cluster gibt der die HA Gäste dann wieder starten kann.

Aber wenn Ceph oder ähnliches der Grund ist, sind alle Nodes in der gleichen Situation -> gesamter Cluster fenced sich.

Wenn kein HA verwendet wird, laufen die Nodes weiter, aber /etc/pve ist im read-only modus, was diverse Aktionen die dort schreiben wollen, blockiert.

 

[BenediktS]

Danke für die schnelle Antwort,

ja wir haben eine HA Konfiguration.

Wir haben 2 getrennte Netzwerke für das Ceph Backend und für die VMs und Ceph Clients.
Das Chorosync läuft bei uns auf dem Netzwerk wo auch die VM/Ceph Client Daten transportiert werden.

Es ist gerade nicht dafür konfiguriert dass es auf beiden Netzwerken kommunizieren kann.

zwei Fragen

1) gibt es einen einfachen Weg Corosync auf beiden Netzwerken laufen zu lassen, oder müssen wir dafür die Datei /etc/pve/corosync.conf per Hand konfigurieren?
2) Kann man das Timeout erhöhen wie lange die Server sich gegenseitig nicht sehen dürfen?

Uns wäre vor dem Ausfall besonders hohe Netzwerklast aufgefallen.
Und beide Netzwerke sind mit jeweils 2 x 40Gbit/s angebunden.

Etwas das uns aufgefallen ist, ist dass Node 1 und 3 eine kurz vor dem Ausfall eine erhöhte CPU Last hatten (Normal ca. 15-20% die zwei Minuten vor dem Ausfall ca. 40-60)

 

[Falk R.]

Das Problem ist, Knoten 8 und 9 brauchen ebenfalls eine Verbindung in das zweite Netz.
Entweder die beiden Nodes mit in das andere Netzwerk verbinden oder wenn noch GBit Interfaces frei sind ein dediziertes Netzwerk für Corosync aufbauen.
Dann die corosync.conf auf der CLI anpassen.
Das ist garantiert die Lösung eures Problems.

 

[aaron]

1) gibt es einen einfachen Weg Corosync auf beiden Netzwerken laufen zu lassen, oder müssen wir dafür die Datei /etc/pve/corosync.conf per Hand konfigurieren?

Wie im Admin Guide beschrieben, die Corosync.conf anpassen. Das TL;DR ist:
/etc/pve/corosync.conf bearbeiten (wichtig, damit die Änderungen im Cluster übernommen werden. NICHT die /etc/corosync/corosync.conf. Die ist nur für die aktuelle Node gültig. Das pmxcfs erkennt wenn die Config in /etc/pve geändert wurde und schreibt die Datei ins /etc/corosync Verzeichnis.

1. Jeder Node den weiteren ringX_addr parameter konfigurieren.
2. Eine neue neue totem -> interface Sektion erstellen und X referenzieren.
3. Ganz wichtig, die config_version hochzählen

2) Kann man das Timeout erhöhen wie lange die Server sich gegenseitig nicht sehen dürfen?

Nein, das ist nicht konfigurierbar.


Ihr könnt euch die syslogs /journal der Nodes anschauen. Wie viel vor dem Ausfall sichtbar ist, hängt davon ab, wie kurz vor dem fencing die Logs auf die Disk geschrieben wurden. Evtl. meckern auch manche Texteditoren, weil es auch vorkommen kann, dass im syslog ein bisschen "Müll" steht, wenn die letzte Schreiboperation nicht mehr ganz durchging.

Evtl. seht ihr auch immer wieder mal, dass corosync sich beschwert, dass der Link down ist. Kann sein, dass er aber meistens innerhalb kurzer Zeit wieder da ist. Das ist aber normalerweise auch ein Anzeichen, dass das Netz immer wieder mal voll ist, oder instabil. Am besten mal nach "corosync" filtern und schauen was ihr so findet

 

[BenediktS]

Vielen Dank für die Antwort.

Wir haben nun einen zeiten Ring konfiguriert.
Und ja wir sehen bereits hin und wieder dass er den zweiten Ring als Backup vernwendet.

Feb 20 20:51:56 prox1 corosync[1650]: [KNET ] link: host: 7 link: 0 is down Feb 20 20:51:56 prox1 corosync[1650]: [KNET ] host: host: 7 (passive) best link: 1 (pri: 1) Feb 20 20:52:00 prox1 corosync[1650]: [KNET ] rx: host: 7 link: 0 is up Feb 20 20:52:00 prox1 corosync[1650]: [KNET ] link: Resetting MTU for link 0 because host 7 joined Feb 20 20:52:00 prox1 corosync[1650]: [KNET ] host: host: 7 (passive) best link: 0 (pri: 1) Feb 20 20:52:00 prox1 corosync[1650]: [KNET ] pmtud: Global data MTU changed to: 1397

Danke für den Hinweis, und wir werden die Tage noch einen reinen Corosync Ring mit 1Gbit Switch aufmachen.

Einen schönen Tag euch allen.

 

[Falk R.]

Vielen Dank für die Antwort.

Wir haben nun einen zeiten Ring konfiguriert.
Und ja wir sehen bereits hin und wieder dass er den zweiten Ring als Backup vernwendet.

Feb 20 20:51:56 prox1 corosync[1650]: [KNET ] link: host: 7 link: 0 is down Feb 20 20:51:56 prox1 corosync[1650]: [KNET ] host: host: 7 (passive) best link: 1 (pri: 1) Feb 20 20:52:00 prox1 corosync[1650]: [KNET ] rx: host: 7 link: 0 is up Feb 20 20:52:00 prox1 corosync[1650]: [KNET ] link: Resetting MTU for link 0 because host 7 joined Feb 20 20:52:00 prox1 corosync[1650]: [KNET ] host: host: 7 (passive) best link: 0 (pri: 1) Feb 20 20:52:00 prox1 corosync[1650]: [KNET ] pmtud: Global data MTU changed to: 1397

Danke für den Hinweis, und wir werden die Tage noch einen reinen Corosync Ring mit 1Gbit Switch aufmachen.

Einen schönen Tag euch allen.

Dann bitte diesen dedizierten Ring als primären machen, damit er nicht so oft schwenken muss.

 

[BenediktS]

So, der dedizierte Ring ist konfiguriert und als primärer Ring eingerichtet. Seit der Einrichtung scheinem im Log keine "[TOTEM ] Retransmit List: 3811f1 3811f2 3811f3"
mehr aufzutauchen. Es scheint sich also etwas getan zu haben.

Wir gehen jetzt mal davon aus, dass das unser Problem gelöst hat. Sollten dennoch weitere Probleme oder Unklarheiten auftauchen, werden wir uns erneut an euch wenden!

Vielen Dank für die guten Antworten!