Proxmox (Ceph) Cluster mit MS-01 - Thunderbolt vs SFP+

[anderl1969]

Hallo zusammen,

ich experimentiere gerade mit dem MS-01 von Minisforum und will einen 3 Node-Cluster mit HA und evtl. Ceph-Storage bauen. Ich muss vorausschicken, dass ich mit Ceph noch keinerlei Erfahrung habe (mein derzeitiger "Produktiv"-Cluster besteht aus 2 HPE Microserver Gen8 + QDevice; die Nodes haben jeweils ein lokales ZFS-Storage mit regelmäßiger Replizierung...)

Mein vorhandenes LAN ist ein reines 1Gb Netzwerk!

Auf den MS-01 nutze ich den 1. RJ45 (2.5 GBit) Port für Intel vPro und den 2. RJ45 (2.5 GBit) Port zur Anbindung ans 1GBit-LAN.

Für die Vernetzung der Nodes untereinander will ich eine dedizierte Lösung:

Meine erste Idee für eine hochperformante Vernetzung der Nodes war, mit den beiden USB4-Ports ein Thunderbolt-Networking eine Ring-Topologie zw. den Nodes aufzubauen. Aber je mehr ich mich mit dem Thema beschäftige, desto mehr Zweifel habe ich bzgl. Stabilität und Zuverlässigkeit.

Momentan tendiere ich mehr zu einem zusätzlichen kleinen (4-Port) 10Gbit Switch mit einem isolierten VLAN für die Node-zu-Node-Kommunikation.

• Von Unifi gibt's den Flex XG, der sich schön in meine Unifi Landschaft einfügen würde. Allerdings hat der RJ45 Ports und entsprechend müssten dann bei den MS-01 SFP+ Transceiver zum Einsatz kommen. Und hier habe ich leichte Sorgen, bzgl. der Hitze-Entwicklung dieser SFP+ auf RJ45 Transceiver
  
  
• Alternativ gäb's von MikroTik den CRS305-1G-4S+IN, ebenfalls mit 4x 10Gbit, aber als SFP+ Ports. Damit ließe sich die Vernetzung zw. Switch und Node mit passiven DAC-Kabeln realisieren, die deutlich weniger Wärme-Entwicklung haben sollen.

Wie sind Eure Erfahrungen dazu? Mache ich mir bzgl. Hitzeentwicklung von SFP+/RJ45 Adaptern zu viele Sorgen? Die Unifi Lösung ist zwar deutlich teurer, aber würde halt sauber in meine bestehende Infrastruktur reinpassen...

Freue mich auf Eure Meinungen/Erfahrungen.

 

[aaron]

Wie gut Netz über Thunderbolt geht ist die Frage. Ich habe keine persönliche Erfahrung, aber was man die letzten Monate so gelesen hat, war das eher so meh.
Die Kisten haben auch 2x 10G via SFP slots oder? Mit 3 günsten und wahrscheinlich kurzen DAC Kabeln, sollte sich da leicht ein Full-Mesh Netzwerk machen lassen. Siehe auch https://pve.proxmox.com/wiki/Full_Mesh_Network_for_Ceph_Server

 

[anderl1969]

Ja, die MS-01 nodes haben je 2 SFP+ Slots
Das hatte ich gar nicht auf dem Schirm, dass ich darüber auch das Mesh aufziehen kann. Besten Dank für den Hinweis samt Link. Jetzt muss ich nur noch rausarbeiten, welche Variante ich umsetzen will...

 

[UdoB]

3 Node-Cluster mit HA und evtl. Ceph

Drei Nodes sind das absolute Minimum für Ceph. Sobald ein Knoten ausfällt, ist Ceph "degraded". Und da es keinen Knoten zum ausweichen gibt, bleibt das dann dauerhaft so. Dies gilt für die übliche size=3/min_size=2 Konfiguration. Auch dies (3/2) ist das akzeptable Minimum, bitte nicht verringern.

Damit Ceph sich selbst reparieren kann, braucht man also mindestens vier Knoten, die durchgehend verfügbar sind. Und aus anderen Gründen (Mehrheiten bilden sich einfacher bei ungerader Anzahl) eigentlich eher fünf.

Das andere Problem mit drei Knoten tritt auf, wenn nur ein sehr wenige - vielleicht nur zwei - OSD pro Knoten existieren: wenn ein OSD ausfällt, muss der Verbleibende die Daten des Toten aufnehmen. Verschieben auf einen anderen (vierten!) Knoten geht ja nicht. Somit darf dieser OSD vorher nur halb befüllt gewesen sein. Mit nur zwei OSD und nur drei Knoten kann man also alle OSD nur zu maximal ~45 Prozent befüllen.

Mit mehr Disks pro Knoten wird dieser Effekt geringer; mit mehr Knoten verschwindet er praktisch.

Ceph ist toll und skaliert nach oben ins Unendliche. Bei Konstellationen am unteren Ende gibt es aber diverse Fallstricke, die problematisch sein können, weil sie nicht offensichtlich sind. Nach der Installation läuft ja erstmal alles prima...

Nebenbei: obiges unterschlägt den Performance-Aspekt. Netzwerkdateisysteme sind um Größenordnungen langsamer als lokale Speicher. Mit 3/2 muss ja jeweils einmal via Netzwerk geschrieben werden, bevor zwei von den dreien "fertig" melden können. Darum will man ein schnelles Netzwerk haben.

Allerdings gilt wie immer: ymmv, jeder hat andere Ansprüche und akzeptiert unterschiedliche Langsamkeit.

Disclaimer: ich nutze das nur "halbherzig" im Homelab und auch nur in einer Konstellation unterhalb des Wünschenswerten...

 

[Falk R.]

Die RJ45 10G werden schon etwas warm aber das ist kein Problem. Die SFPs sind im Vergleich recht teuer und brauchen deutlich mehr Strom.
Das Ceph Netz solltest du eh trennen, daher zwei kleine CRS305 hinlegen und laufen lassen. Die sind Robust und kannst du redundant mit Strom versorgen.
Das wäre simpler als Full Mesh. Bei Full Mesh sparst du dir aber den Invest und ein klein wenig Strom.
Da du nur 3 NVMe rein bekommst musst du wie oben erwähnt mit der Befüllung der OSDs aufpassen. Ich habe zuhause im Spielcluster 4 SSDs pro Node aus dem Grund.
Außerdem bei dem MS-01 mit VMs aufpassen. Mit den Intel CPUs die E+P Cores haben, gibts je nach genutzter Software in den VMs richtig Probleme. Wenn du eh LXC nutzt würde ich persönlich lieber zu ZFS tendieren. Ist aber nur meine Meinung.

 

[Neobin]

Von Unifi gibt's den Flex XG, der sich schön in meine Unifi Landschaft einfügen würde. Allerdings hat der RJ45 Ports und entsprechend müssten dann bei den MS-01 SFP+ Transceiver zum Einsatz kommen.

Alternativ gäb's von MikroTik den CRS305-1G-4S+IN, ebenfalls mit 4x 10Gbit, aber als SFP+ Ports.

Die Unifi Lösung ist zwar deutlich teurer, aber würde halt sauber in meine bestehende Infrastruktur reinpassen...

USW-Aggregation?:

• https://eu.store.ui.com/eu/en/category/all-switching/products/usw-aggregation
• https://geizhals.de/ubiquiti-unifis...-managed-switch-usw-aggregation-a2459430.html

 

[anderl1969]

USW-Aggregation?:

• https://eu.store.ui.com/eu/en/category/all-switching/products/usw-aggregation
• https://geizhals.de/ubiquiti-unifis...-managed-switch-usw-aggregation-a2459430.html

Danke! Den hatte ich im Produktportfolio von Ubiquiti ja komplett übersehen.

 

[anderl1969]

Danke erstmal für alle Eure Tipps und Hinweise zu Ceph.

Ich habe mir zum Testen virtuelle Proxmox-Cluster aufgebaut, um mal zu vestehen, wie Ceph in den unterschiedlichen Szenarien reagiert:

• 3 Node Cluster mit je 2x OSD + Q-device mit 2 Votes
• 4 Node Cluster mit je 2x OSD + Q-device mit 1 Vote

Das Q-Device habe ich hinzugefügt, weil ich den Proxmox-Cluster hochverfügbar halten wollte, selbst wenn 2 Nodes "down" sind.

In beiden Szenarien habe ich bzgl. Ceph keinen Unterschied erkennen können:

• 1 Node "down":
  • Ceph ist "degraded", aber verfügbar.
  • keine Selbstheilung, solange der fehlende Node nicht wieder online geht
  • VMs und Container weiter online und bedienbar
  • Ceph innerhalb Proxmox-GUI bedienbar
• 2 Nodes "down":
  • Proxmox ist zwar noch bedienbar und der Cluster erfüllt auch noch das Quorum...
  • aber Ceph ist innerhalb der Proxmox GUI nicht mehr bedienbar (Time Out)
  • die VMs und Container scheinen noch weiter zu leben und migrieren auch bei Bedarf...
  • aber über die Proxmox-Konsole reagieren sie nicht mehr
  • Wenn mind. 1 Node wieder online geht, lassen sich die VMs und Container wieder über die Proxmox-Konsole bedienen. Sie scheinen auch "überlebt" zu haben

Speziell das Verhalten bei 4 Nodes insgesamt überrascht micht. Hier hätte ich erwartet, dass bei...

• 1 Node down sich Ceph mit 3 verbleibenden Nodes (und 6 von 8 OSDs) selbst repariert.
  Vor allem weil auch, wenn 2 Nodes down waren und einer von den beiden wieder "hoch" kommt, dann ist Ceph sehr wohl in der Lage mit 3 von 4 Nodes alle PGs auf active+clean zu bringen.
• 2 Node down Ceph bedienbar bleibt, wenn auch degraded (analog zu 1 von 3 Nodes down)

4 Nodes kommen für mein Home-Lab aber eh nicht in Frage (das sind eigentlich 3 schon Overkill)!

 

[quanto11]

hier hat jemand etwas ähnliches durchgesetzt, welches wohl ziemlich gut läuft. Vielleicht hilft es dir.

https://gist.github.com/scyto/76e94832927a89d977ea989da157e9dc

 

[UdoB]

Speziell das Verhalten bei 4 Nodes insgesamt überrascht micht. Hier hätte ich erwartet, dass bei...

• 1 Node down sich Ceph mit 3 verbleibenden Nodes (und 6 von 8 OSDs) selbst repariert.

Mit size=3/min_size=2 erwarte auch ich das. (Und in meinen eigenen Experimenten hatte das auch so funktioniert, wie es dokumentiert ist.)

Hast du lange genug in dem "einer von den Vieren ist aus" verweilt? Diese Art der Reparatur beginnt erst nach 10 Minuten oder so. Es soll ja nicht gleich triggern, wenn ein Node mal eben rebootet - was ja durchaus auch mal zwei oder drei Minuten dauern kann, zumindest bei klassischen Servern.

Und es darf natürlich nicht "noout"/"norebalance" (oder so) gesetzt sein.

 

[UdoB]

Speziell das Verhalten bei 4 Nodes insgesamt überrascht micht. Hier hätte ich erwartet, dass bei...

• 2 Node down Ceph bedienbar bleibt, wenn auch degraded

Die Chunks sind gleichmäßig auf den OSDs verteilt. Default ist size=3/min_size=2. Wenn du zwei Nodes abschaltest ist die Wahrscheinlich sehr hoch, dass von etlichen (nicht allen) Chunks zwei der drei verschwinden.

Meine Vermutung: diese Chunks sind dann wahrscheinlich readonly. Sobald eine VM etwas schreiben will, blockiert sie - und das wirkt wie abgestürzt, weil die VM gar nicht mehr reagiert. Wenn Ceph schnell wieder verfügbar ist, läuft die VM einfach weiter. Wenn es zu lange dauert, bemerkt die VM Timeouts und meldet Fehler.

Die Anzahl der Nodes, die ausfallen dürfen ist immer "size - min_size", im Default-Fall also 3-2 = 1. Nur ein Node darf ausfallen. Auch wenn man ein Dutzend davon hat!

Wenn ein vier Node Cluster zwei Ausfälle vertragen können soll, müsste man size=4/min_size=2 einstellen, 4-2 = 2. (Mit ist gerade unklar, ob das nicht eher 5/3 sein müsste - eine gerade Anzahl wie "4" ist möglicherweise ungünstig.)

Es ist ein Unterschied, wie "schnell" die beiden ausfallen. Zumindest "langsam", also einen Node abschalten, dann die Reparatur abwarten und erst danach den zweiten Node ausfallen lassen, hatte ich für mich getestet. (Vermutlich mit 5/3, nicht 4/2...)

Disclaimer: ich bin kein Ceph-Spezialist...

 

[anderl1969]

Mit size=3/min_size=2 erwarte auch ich das. (Und in meinen eigenen Experimenten hatte das auch so funktioniert, wie es dokumentiert ist.)

Hast du lange genug in dem "einer von den Vieren ist aus" verweilt? Diese Art der Reparatur beginnt erst nach 10 Minuten oder so. Es soll ja nicht gleich triggern, wenn ein Node mal eben rebootet - was ja durchaus auch mal zwei oder drei Minuten dauern kann, zumindest bei klassischen Servern.

Und es darf natürlich nicht "noout"/"norebalance" (oder so) gesetzt sein.

Du hast Recht, ich war zu ungeduldig. Hab den "Versuchsaufbau" 1 Node von 4 geht "down" jetzt mal über Mittag sein Ding machen lassen. Und tatsächlich hat er sich mit ausreichend Zeit dann doch selbst repariert.

Deinen 2. Post muss ich erst noch sacken lassen ;-)

 

[UdoB]

In beiden Szenarien habe ich bzgl. Ceph keinen Unterschied erkennen können:

Auch für mich ist Ceph Neuland, und ich bin ebenfalls "am unteren Ende", also eher unterhalb der empfohlenen Ausstattung. (Mein Homelab, nicht mein "dayjob-cluster".)

Um das Verhalten von Ceph für meine Belange testen zu können, hatte ich mir "einfach" einen virtuellen PVE-Cluster eingerichtet. Ich hatte 6 Nodes mit einer separaten virtuellen Platte zum booten und jeweils zwei 32 GB Platten als OSD vorgesehen. Damit konnte ich dann diverse Ausfall-Szenarien ausprobieren, ohne dass Datenverlust drohte

Mich interessierte vor allem auch "Erasure Coding". Mit so etwas wie "pveceph pool create ec33 --erasure-coding k=3,m=3" ergeben sich durchaus neue Aspekte. Sofern man nicht in Deutschland wohnt bzw. den Strom nicht selber bezahlen muss - das Beispiel benötigt sechs Nodes...

 

[Falk R.]

Das Setup mit 3 Nodes und 2 dürfen ausfallen, funktioniert so einfach nicht. Du könntest die Policy auf 3/1 setzen, dann bleibt der Pool auch bei 1 Datenkopie online. Aber bitte nur in Spielumgebungen so nutzen.
Nächstes Problem, die Monitor Services sind auch gleichzeitig Quorum und brauchen eine einfache Mehrheit von 51%.
Daher bräuchtest du beim Ausfall von 2 Nodes trotzdem mindestens 2 Monitor online und nur einen ausgefallenen.

Wenn du ein realistisches Setup haben möchtest, plane lieber 3/2.