HA-Cluster mit Ceph in 2 Brandabschnitten

[Firebat]

Hallo Leute,
Langsam wird mein Proxmox-Szenario konkreter, mit der Hardwareplanung bin ich schon recht weit fortgeschritten (Danke an dieser Stelle an @SkyDiver79 ). Jetzt möchte ich allerdings nochmal auf das Wissen aller hier zurückgreifen und ein paar Anregungen dazu, wie man einen Ceph-Cluster am elegantesten auf zwei Brandabschnitte verteilt um den Ausfall eines Abschnitts kompensieren zu können.

Folgende Hardware ist geplant:
6x Supermicro 1114S-WN10RT mit je 10 NVMe-SSDs als OSDs, 2 M.2 SSDs für's Betriebssystem, 2x 25G als Storage-Netzwerk und 6x 10G für Corosync, GUI und die VMs, EPYC 74F3, 512GB RAM

Um bei einem Ausfall das (?) Quorom erreichen zu können, brauche ich an irgendeiner Stelle einen zusätzlichen ceph-mon (und einen corosync-knoten?), wie ich das realisiere weiß ich noch nicht genau. Da wären Ideen und Vorschläge auf jeden Fall gerne gesehen

Wie man sich sicherlich an Hand der Config denken kann, stehen in jedem Brandabschnitt drei Supermicro-Maschinen. Ich habe zwischen den beiden Serverräumen 48 OM4 Fasern auf ca. 165m liegen. Das ergibt 24 anschließbare Module/GBICs, aktuell belegt sind 4. Sprich 20 hätte ich zur freien Verfügung. Außer, dass es "nur" OM4 ist, nicht die schlechtesten Voraussetzungen für das Vorhaben. Glaube ich jedenfalls bis jetzt ;-)

Ceph bietet mit Stretch Clusters im Prinzip genau das an, wie das im Zusammenspiel mit Proxmox funktioniert (oder ob es überhaupt funktioniert) weiß ich aber nicht. Bei meiner Recherche bin ich immer wieder darüber gestolpert, dass die Kommunikation der einzelnen Ceph-Knoten und auch Corosync sehr latenzkritisch wäre. Ob mein geplantes 25G-Netz über 165m aber performant genug funktioniert oder nicht, konnte ich mir bisher nicht herleiten.

Falls die erdachte Konstellation völliger Mist ist, wäre ich für andere Ideen sehr dankbar.

 

[fabian]

ja, dafuer muesstest du noch einen node in nem dritten brandabschnitt mit entsprechender anbindung haben, um dort den tie-braker ceph mon und die tie-braker corosync instanz laufen zu lassen (ohne ceph waere auch ein qdevice eine option, aber nachdem du sowieso ne ordentliche CPU fuer den monitor brauchst kann die instanz gleich ein richtiger PVE node sein auf dem halt nie gaeste laufen und keine OSDs liegen), und den ceph cluster entsprechend der doku konfigurieren.

im PVE management fuer ceph ist das nicht vorgesehen, muss also selbst / haendisch gemacht werden (ohne gewaehr):
- ceph cluster normal mittels pveceph/GUI aufsetzen
- schritte aus der ceph doku befolgen
- ab jetzt keine aenderungen mehr an monitoren mittels pveceph vornehmen

wenns mal aufgesetzt ist seh ich keinen grund warum das nicht funktionieren sollte (inkl. dashboard in der PVE GUI, pools/storages anlegen usw). gibt soweit ich weiss auch cluster die genau so ein setup fahren - vielleicht kommt ja noch input von leuten mit konkreten erfahrungen

bitte beachten dass ein stretch cluster im vergleich zu einem normalen cluster aehnlicher groesse mehr resourcen braucht (5 monitore statt 3, mind. 4/2 replication statt mind. 3/2) und gewisse dinge nicht gehen/anders funktionieren (kein EC - fuer PVE nicht wirklich relevant, aber falls ihr vorhabt auch noch radosgw drauf zu fahren, im degraded fall wird mit 2/1 gefahren was mehr potential fuer datenverlust mit sich bringt, ..). und natuerlich gilt - je exotischer das setup, desto besser sollte es getestet werden, inkl. disaster und recovery!

 

[Firebat]

Könnte der Tiebraker für Ceph so konfiguriert werden, dass dieser nie Master werden kann? Die Doku sagt, man könne die Ceph-Mon grundsätzlich so konfigurieren. Hat das Auswikrungen auf Proxmox? Eventuell könnte man die Hardware dann etwas kleiner dimensionieren...

Das Problem ist, ich habe eigentlich nur die Möglichkeit, Hardware in den genannten zwei Räumen unterzubringen. Einen dritten Raum mit USV, Kühlung usw. habe ich nicht. Wenn es die Chance gäbe, den tiebraker ceph-mon und corosync-knoten performant (!) auf weniger anspruchsvoller Hardware zu betreiben, ließe sich das Setup ja ganz gut realisieren. Wenn ich tatsächlich einen "vollwertigen" dritten Serverraum brauche, um das sinnvoll und sicher zu betreiben, dann ist das Setup eigentlich gestorben.

 

[fabian]

der stretch mode macht genau das - der betreffende monitor wird (meines wissens nach) nie "leader", und redet auch nie direkt mit OSDs. eventuell waere das folgende setup dann eher eine option?

- manuelle gemanagtes ceph im stretch mode, in PVE einfach nur als "externer" ceph cluster eingebunden und nicht ueber pveceph verwaltet (=> mehr arbeit/weniger komfort, aber vom feature-set usw her gleichwertig)
- "tie-breaker" node ist kein vollwertiger PVE node, sondern lediglich tie-breaker ceph monitor + qdevice als corosync tie-braker

damit sind die anforderungen was latenz usw des tie-breakers betrifft deutlich geringer - laut ceph doku duerfte der tie-breaker ceph monitor sogar in ner VM irgendwo laufen, qdevice braucht ueberhaupt quasi nix ausser ne netzwerkanbindung.

 

[Firebat]

Das wäre denkbar, ja. Aber damit fällt eines der Killerkriterien weg, nämlich Ceph nicht manuell abfrühstücken zu müssen ;-) Wobei ich von dem Punkt aus mal gestartet bin. Ceph als Ablöse für unser bisheriges Storage...

Ich könnte die 6 Maschinen also trotzdem PVE und Ceph machen lassen, nur eben nicht "managed by Proxmox", richtig?

€dit:

der stretch mode macht genau das - der betreffende monitor wird (meines wissens nach) nie "leader", und redet auch nie direkt mit OSDs.

Du hast recht, ich war mir nicht sicher, ob man das manuell machen musste oder ob das mit dem Betrieb als stretched cluster automatisch einhergeht.

>> This mode also supports disallowing monitors from being the leader using the same commands as above in disallow.

 

[fabian]

Das wäre denkbar, ja. Aber damit fällt eines der Killerkriterien weg, nämlich Ceph nicht manuell abfrühstücken zu müssen ;-) Wobei ich von dem Punkt aus mal gestartet bin. Ceph als Ablöse für unser bisheriges Storage...

Ich könnte die 6 Maschinen also trotzdem PVE und Ceph machen lassen, nur eben nicht "managed by Proxmox", richtig?

genau, der ceph-management teil faellt dann weg, weil der davon ausgeht dass alle ceph nodes auch vollwertige PVE nodes sind. ceph wird selbst konfiguriert, anschliessend werden entsprechend storage eintraege angelegt: https://pve.proxmox.com/pve-docs/pve-admin-guide.html#ceph_rados_block_devices

€dit:

Du hast recht, ich war mir nicht sicher, ob man das manuell machen musste oder ob das mit dem Betrieb als stretched cluster automatisch einhergeht.

>> This mode also supports disallowing monitors from being the leader using the same commands as above in disallow.

ich habs so verstanden dass stretched cluster den connectivity mode fuer leader elections verwenden und entsprechend den tie-breaker konfigurieren (der muss ja explizit angegeben werden beim einschalten des stretch modes). aber ohne gewaehr

 

[Falk R.]

Bei PVE ist das mit streched Ceph nur mit manueller Anpassung im Ceph möglich.
Das Setup machst du aber nur einmal, wenn dein Pool steht, nutzt du den wie gewohnt in der GUI und das Monitoring funktioniert bei mir auch sauber. Der Zeigt bei jedem Reboot sauber an wie viele PGs gesynct werden müssen und wenn wieder alles Healthy ist.
Im Normalfall schraubst du ja nicht ständig an der Konfig rum.

Das das Thema Streched Cluster eher ein Deutsches/Europäisches Thema ist, bekommst du leider aus der restlichen Welt nicht so viel dazu.
Microsoft hat das aber auch gelernt und supportet Streched HCI Cluster, bisher ebenfalls nur manuell per Powershell.
Demnächst auch über das Admin Center.

Aus aktuellem Anlass, da unsere Regierung ja jetzt endlich Open Source in den Behörden bevorzugen möchte und ich einige Städte und Landkreise kenne, welche Streched Cluster fahren, könnte man falls Ressourcen da sind ja mal an eine GUI Implementierung bei PVE nachdenken. :wink:

 

[Firebat]

Das das Thema Streched Cluster eher ein Deutsches/Europäisches Thema ist, bekommst du leider aus der restlichen Welt nicht so viel dazu.

Das wundert mich sowieso, diese Anforderungen sollten doch eigentlich nicht so exotisch sein? Oder gibt's da etwas grundsätzliches, was ich übersehe und man könnte das viel einfacher lösen? Das manuelle Einrichten von Ceph schreckt mich einfach noch etwas ab...

Ich sag's mal so, wenn ich die VMs mit kurzer Downtime im zweiten Serverraum wieder starten kann, ohne Datenverlust, wäre die Anforderung für mich schon erfüllt. Vll muss man nicht "stretchen" sondern kann in relativ kurzen Abständen syncen? Geht das zwischen zwei Ceph-Clustern?

Ich werfe einfach ein paar Ideen in den Raum, bremst mich ggf. wieder ein ;-)

 

[Falk R.]

Die Anforderungen sind typisch Mittelstand. Sowas gibts in USA, China und anderen großen Märkten außerhalb Europas extrem wenig.
Nicht umsonst ist Deutschland die weltweite Nr.1 bei Active-Active Mirror und Transparentem Failover. In den uSA ist das ja eher Ostküste-Westküste und dann asynchron.

Die Replikation geht auf jeden Fall mit ZFS, mit Ceph habe ich noch nichts dazu gelesen. Auf welcher Ebene das bei Ceph funktioniert und ob PVE das kann, weiß ich nicht. Für mich war es bisher einfacher in der Ceph Konfiguration 2 DataCenter anzulegen.

 

[crmspezi]

ceph habe ich verworfen. Viel zu viel Resourcen, Performanceverlust, Know-How wie beim letzten "CLS" notwendig. Ich will da keine ganze IT-Abteilung mit Spezialisten abbilden müssen.

3x NAS mit ZFS over iSCSI (zrep oder anderes), von mir aus drbd, 100G oder 40G. Mehr Feuer und geringere Latenz kannst Du nicht haben.

ceph ist schick aber nicht geil!

VG crmspezi

 

[itNGO]

3x NAS mit ZFS over iSCSI (zrep oder anderes), von mir aus drbd, 100G oder 40G. Mehr Feuer und geringere Latenz kannst Du nicht haben.

Ok, aber Äpfel und Birnen... CEPH ist einfach eine andere LIGA. Ein mal richtig konfiguriert auch völlig wartungsarm und nahezu unkaputtbar.

 

[crmspezi]

unkaputtbar - stimmt nur bei mehr als 3 Nodes
wartungsarm - vergiss es, Du bist nur am monitoren
Performance - unterer Durchschnitt
andere LIGA - ja beim Preis was die Hardware angeht - sonst nur Wunschdenken
Nutzen? - gerechtfertigt wenn Geld und Performance egal sind >>> KO Kriterium für mich.

 

[itNGO]

unkaputtbar - stimmt nur bei mehr als 3 Nodes
wartungsarm - vergiss es, Du bist nur am monitoren
Performance - unterer Durchschnitt
andere LIGA - ja beim Preis was die Hardware angeht - sonst nur Wunschdenken
Nutzen? - gerechtfertigt wenn Geld und Performance egal sind >>> KO Kriterium für mich.

Sorry, aber da magst du andere Erlebnisse gehabt haben als wir.
Wir befeuern da ganze Rechenzentren mit. Und das läuft und läuft und läuft.... Richtig langweilig im ZABBIX....
Und bei uns sind das immer 3 oder 5 Node Islands.... dutzende.... Wenn wir die 5nine nicht halten würden, käme uns das schnell sehr teuer....

Performance? Nun, die Default-Config ist natürlich eher Semi, bzw. eher auf läuft und gut ist... aber wir holen da schon vergleichbar das raus, was wir vorher mit Storages Spaces Direct erreicht haben. Und auch S2D mussten wir diverse dutzend Parameter mitgeben, damit das "brauchbar" bencht. Natürlich erreichte man mit solchen HCIs nie das, was die nativen Disks könnten, aber das ist ja auch gar nicht das Hauptziel.

Was den Preis angeht... um einiges günstiger als nen S2D-HCI, aber natürlich sprechen wir immer noch von Enterprise-Hardware. Aber genau da will die Lösung ja auch sein... ;-)

 

[crmspezi]

Ich stimme Dir da überwiegend zu. Mir geht es nur um das Kosten/Nutzen/Leistungs- Verhältnis. Ich mache privat als Hobby Wetterberechnungen (DACH), mein RZ hat wirklich extrem viel RAM und hunderte (!) hochgetaktete Kerne. Ceph ist sicher "sicher", aber eben ein "normaler Passat" und kein Aston Martin.

Ich will nur meine Erfahrung darstellen, ceph ist wirklich nicht "Volldampf", kann es auch nicht auf Grund der Technologie. Und HA brauche ich genau wie Du auch. Das muss aber eben nicht ceph sein!

Wenn absolute Sicherheit wie bei euch vorgeht, verstehe ich Dein Anwendungsgebiet durchaus. "Bums" ist aber was anderes. MS Storages Spaces sind absolut schlecht in der Performance. Da kann ich den Vergleich gut verstehen.

Liebe Grüße
crmspezi

 

[Falk R.]

Ich stimme Dir da überwiegend zu. Mir geht es nur um das Kosten/Nutzen/Leistungs- Verhältnis. Ich mache privat als Hobby Wetterberechnungen (DACH), mein RZ hat wirklich extrem viel RAM und hunderte (!) hochgetaktete Kerne. Ceph ist sicher "sicher", aber eben ein "normaler Passat" und kein Aston Martin.

Ich will nur meine Erfahrung darstellen, ceph ist wirklich nicht "Volldampf", kann es auch nicht auf Grund der Technologie. Und HA brauche ich genau wie Du auch. Das muss aber eben nicht ceph sein!

Wenn absolute Sicherheit wie bei euch vorgeht, verstehe ich Dein Anwendungsgebiet durchaus. "Bums" ist aber was anderes. MS Storages Spaces sind absolut schlecht in der Performance. Da kann ich den Vergleich gut verstehen.

Liebe Grüße
crmspezi

Ich kann irgendwie deinen Bench nicht nachvollziehen.
Ich habe hochperformante S2D Installationen produktiv laufen und wenn ich Enterprise SSDs/NVMe teste, performt Ceph besser als ZFS. Was man nicht vernachlässigen darf, der Storage Part auf dem Hypervisor benötigt auch eine ganze Menge CPU.
Das ist auch der Grund warum NVMeoF Storages gerade großen Absatz finden.

 

[itNGO]

Ich kann irgendwie deinen Bench nicht nachvollziehen.
Ich habe hochperformante S2D Installationen produktiv laufen und wenn ich Enterprise SSDs/NVMe teste, performt Ceph besser als ZFS. Was man nicht vernachlässigen darf, der Storage Part auf dem Hypervisor benötigt auch eine ganze Menge CPU.
Das ist auch der Grund warum NVMeoF Storages gerade großen Absatz finden.

Dann hast du ja sicher nichts dagegen diese Wunder-Hochleistung-IOPS-Config die du in CEPH einsetzt, unabhängig von der Hardware mal mit uns zu teilen? Da hätten wir sicher Verwendung für.... Wir nutzen als Basis derzeit immer diesen Guide mit spezifischen Anpassungen für unsere Zwecke.... https://support.huaweicloud.com/intl/en-us/tngg-kunpengsdss/kunpengcephobject_05_0008.html

 

[Falk R.]

Ich habe auch keine Wunder-Konfig.
Ich habe das ohne mega Tuning auf sehr performanter Hardware am laufen gehabt.
Ich habe in 2-3 wochen meine testhardware frei und könnte mal echte Zahlen liefern.
Zur verwendeten Hardware: 3 Server mit je:
2x Xeon Gold 6346
512 GB RAM
1TB Optane
4x Kioxia CD6-R NVME 7,68TB
1x SATA SSD fürs OS
2x 10GBit
2x 100 GBIt Intel 810 NICs (nur fürs Ceph)

Damit kommt schon gut was bei rum, derzeit teste ich aber gerade NVMe over TCP damit.

 

[itNGO]

Ich habe auch keine Wunder-Konfig.
Ich habe das ohne mega Tuning auf sehr performanter Hardware am laufen gehabt.
Ich habe in 2-3 wochen meine testhardware frei und könnte mal echte Zahlen liefern.
Zur verwendeten Hardware: 3 Server mit je:
2x Xeon Gold 6346
512 GB RAM
1TB Optane
4x Kioxia CD6-R NVME 7,68TB
1x SATA SSD fürs OS
2x 10GBit
2x 100 GBIt Intel 810 NICs (nur fürs Ceph)

Damit kommt schon gut was bei rum, derzeit teste ich aber gerade NVMe over TCP damit.

Ein paar echte Zahlen wären sicher mal interessant... aber zu sagen das bencht und dann mit Ferrari oder Lamborghini-Motoren zu kommen ist meiner Meinung nach, doch etwas gewagt.... das hat ja nicht jeder rumstehen.... ich glaube eher das @crmspezi davon sprach das mit etwas "einfacherer" Hardware ohne CEPH bei ihm die Performance besser ausgefallen ist im Vergleich... Preis/Leistung....

 

[Falk R.]

Mir ging es aber etwas um das Verhältnis Ceph zu ZFS. Da sollte die Hardware egal sein und sich Prozentual ähnlich wiederspiegeln. Auf meiner privaten Hardware mit 4 Consumer SSDs pro Rechner. (2 Node Cluster) hatte ich am Anfang ZFS getestet und dann Ceph. Mit Ceph kommt ungefähr das raus was die SSDs nativ liefern (4 fach Mirror) da habe ich netto das was 2 SSDs im Raid0 schaffen. Mit ZFS war es ca. 20-25% weniger.
Das Netzwerk mit 10 GBit begrenzt Zuhause nicht, da ich nie über 600MB/s komme und die CPUs haben gut zu tun aber reichen mit 12 Threads noch aus.
Die schnelle HW macht wegen der CPUs bei 2Mio I/Os dicht, aber prozentual würde ich einen ähnlichen Unterschied erwarten.

 

[Firebat]

Super, dass die Diskussion noch an Fahrt aufnimmt. Ich bin sehr gespannt.