Probleme mit Thunderbolt-Netzwerk nach Upgrade auf v9

[frantek]

Hallo,

ich hab einen Cluster mit 3 Nodes und Ceph auf Basis von Minisorum MS-01 PCs. Für die Cluster und Ceph-Kommunikation habe ich auf den Thunderbolt-Ports einen Netzwerk-Ring. Das funktioniert seit gut einem Jahr mit der v8 problemlos. Heute habe ich da Upgrade auf die v9 gemacht und habe recht massive Probleme. Es ging so los, dass der "dritte" (also der zu letzt gestartete ...) Node die TB-Interfaces gar nicht gesehen hat. Nach ein bisschen Kabel ziehen und stecken und Reboots kam dann doch am dritten Node eines der beiden Interfaces auf. Folgendes ist der aktuelle Stand: Stecke ich alle Kabel und starte den "dritten" Node kommt keines der beiden TB-Interfaces auf. Wenn ich den "dritten" Node nur mit einem der beiden Anderen verbinde startet der "dritte" Node und die Verbindung funktioniert auch. Stecke ich dann mit Betrieb das zweite TB-Kabel in den "dritten" Node geht der einfach aus, so als hätte ich den Strom ausgeschaltet.

Da das mit der v8 alles sehr lange ohne Probleme funktioniert hat meine ich könnte das ein Bug im Kernel, TB-Treiber, etc. sein. Weiss jemand Rat?

TIA
Matthias

 

[frantek]

Aus unerklärlichen Gründen ist das Problem weg. Das ist zwar gut, aber auch nicht, denn ohne den Grund zu kennen könnte es ja jeder Zeit wieder passieren ...

 

[micneu]

Ich denke die wenigsten werden so ein Setup am Laufen haben.
Wenn du den Fehler gefunden hast, kannst du es ja hier Kommunizieren oder einen Bugreport machen.

Was ich auch noch nicht ganz verstanden habe, ich war immer der Meinung das für CEPH-Kluster die Empfehlung ist mit 5 Nodes zu arbeiten. Ich hoffe dein Cluster ist kein Produktiv System.

 

[frantek]

Den Grund konnte ich nicht ermitteln. Doch, der ist schon produktiv, seit gut einem Jahr. So weit ohne Probleme. Das einzig weniger schöne ist halt, dass man auf EEC-Ram verzichten muss. Ich werde ihn aber demnächst um einen 4. Node erweitern.

 

[Falk R.]

Ich denke die wenigsten werden so ein Setup am Laufen haben.
Wenn du den Fehler gefunden hast, kannst du es ja hier Kommunizieren oder einen Bugreport machen.

Was ich auch noch nicht ganz verstanden habe, ich war immer der Meinung das für CEPH-Kluster die Empfehlung ist mit 5 Nodes zu arbeiten. Ich hoffe dein Cluster ist kein Produktiv System.

Empfehlungen gibt es ganz viele. Mit 5 Nodes hast du den Vorteil, dass du einen Node in Wartung nehmen kannst und ein zweiter gleichzeitig ausfallen kann, aber auch nur wenn du die Verfügbarkeit in deinem Pool von 3/2 auf 4/2 anhebst.
Produktiv kannst du immer einen 3 Node Cluster fahren und die meisten sind fein damit, dass wenn ein Node Ausfällt, während der 10 Minuten wo ein anderer Node gerede in Wartung ist und neu startet, dann hat man halt Downtime.
Hier geht es immer um eine Risiko/Kostenabwägung und da können 99% mit 3 Nodes leben.

 

[Johannes S]

Ich denke da liegt ein Missverständnis wegen so Artikeln wie von @UdoB vor:

[TUTORIAL] Thread 'FabU: can I use Ceph in a _very_ small cluster?'

Dec 26, 2024

Ceph is great, but it needs some resources above the theoretical minimum to work reliably. My assumptions for the following text:

• you want to use Ceph because... why not?
• you want to use High Availability - which requires Shared Storage (note that a complete solution needs more things like a redundant network stack and power supplies)
• you want to start as small (and cheap) as possible, because this is... “only” a Homelab

You plan for three Nodes. Each node has s single dedicated disk for use as an “OSD”. This is the documented...

• UdoB
• ceph cluster mini pc minimize shared filesystem storage
• Replies: 38
• Forum: Proxmox VE: Installation and configuration

• 

Der beschreibt ja Setups, die nicht nur wegen der Knotenanzahl, sondern auch den sonstigen Rahmenbedingungen "built to break" sind: Drei Knoten, nur eine OSD pro Knoten,nur eine ( dazu lahme ( unter 10Gbit) Netzwerkverbindung etc pp

Bei drei Knoten mit jeweils mindestens vier OSDs und eigenen Ceph- und Corosync-Netzwerken ( gerne redundant und für Ceph 25 oder 100Gbit) schaut das schon anders aus, als bei
aus Restposten zusammengefrickelten Homelabs

 

[UdoB]

Bei drei Knoten mit jeweils mindestens vier OSDs und eigenen Ceph- und Corosync-Netzwerken ( gerne redundant und für Ceph 25 oder 100Gbit) schaut das schon anders aus

Das fundamentale Problem, dass kein Reserve-Node vorhanden ist, der für self-healing notwendig wäre, bleibt dennoch.

Aber ja, mein Artikel treibt die Problemfindung etwas auf die Spitze - das ist natürlich Absicht: mit Problemzonen, die man kennt, kann man möglicherweise leben.

Und im Homelab kann man schon mal flexibel sein

 

[Falk R.]

Naja Selfhealing ist super für Systeme auf Schiffen oder wenn der Zugang limitiert ist. Mit Monitoring und flinken Händen, ist ein Node bei Bedarf auch schnell gefixt. Einzelne Diskausfälle sollten natürlich immer möglich sein. Daher sollte man ja mit 4-5 Disks beginnen und niemals mit 1. Auch in meinem Homelab habe ich nur je 2 SSDs, aber der Pool ist nur zu 30% voll, da reicht das auch.