Pve Ceth Cluster und Snapshots

[crmspezi]

Hallo zusammen,
Ich möchte gerne die Ceph Performance testen, brauche aber wie bei zfs over iscsi Snapshots.

Deshalb frage ich mal vorab gern hier.

1. Gibt es bei Ceph die Möglichkeit von Snapshots, wie bei zfs. Ich habe leider nichts gefunden.
2. Ich plane ein Pve Cluster mit 9 Nodes, 3 davon sollen den Shared Storage mit Ceth bereitstellen.
3. Welche Performance kann ich mit 25 GBit/s und SSDs erwarten. Nvme sollen nicht zum Einsatz kommen.
4. Ich brauche sehr geringe Latenz, ähnlich wie bei zfs over iscsi.

Danke euch.

 

[gurubert]

Sehr geringe Latenz ist bei Ceph nur schwer zu erreichen, gerade bei nur 3 Knoten.
Warum nicht in allen 9 Knoten OSDs ausrollen?

Snapshots sind problemlos möglich.

 

[crmspezi]

Sehr geringe Latenz ist bei Ceph nur schwer zu erreichen, gerade bei nur 3 Knoten.
Warum nicht in allen 9 Knoten OSDs ausrollen?

Snapshots sind problemlos möglich.

Ich danke Dir sehr.
Ich dachte bei 9x Osd habe ich den 9 fachen Speicherbedarf? Verwechsel ich hier was?

Snapshots ist super!

 

[gurubert]

Nein, die dreifache Replikation bezieht sich auf den Pool und die Objekte darin.
OSDs kann ein Ceph-Cluster tausende haben. Die Objektkopien werden gleichmäßig auf sie verteilt.

 

[Falk R.]

Niedrige Latenz wirst du eher mit NVMe erreichen können. Aber testen kannst du ja schon mal und wenn du Performancewerte hast, können wir dir sagen ob und wie man eventuell etwas verbessern kann.

 

[crmspezi]

Nein, die dreifache Replikation bezieht sich auf den Pool und die Objekte darin.
OSDs kann ein Ceph-Cluster tausende haben. Die Objektkopien werden gleichmäßig auf sie verteilt.

Ja, Du hast recht, Ceth skaliert auch in die Breite. Ich ahtte es nur nicht richtig verstanden und habe nachgelesen. Danke Dir!

 

[crmspezi]

Niedrige Latenz wirst du eher mit NVMe erreichen können. Aber testen kannst du ja schon mal und wenn du Performancewerte hast, können wir dir sagen ob und wie man eventuell etwas verbessern kann.

Danke Falk, mache ich. Aber eben nvme kann ich kaum in die Breite skallieren, im Vergleich zur SATA Backplanes. U2 wäre eine Alternative, aber eben deutlich teurer und komplexer, weil ich Hotswap brauche.

 

[Falk R.]

U2 NVMe sind genau so teuer und manchmal günstiger als gleichwertige Enterprise SATA SSDs.
Wenn du Performance brauchst, solltest du eh Enterprise Hardware benutzen und die neuen Chassis haben oft eh komplett NVMe Backplanes.

 

[crmspezi]

U2 NVMe sind genau so teuer und manchmal günstiger als gleichwertige Enterprise SATA SSDs.
Wenn du Performance brauchst, solltest du eh Enterprise Hardware benutzen und die neuen Chassis haben oft eh komplett NVMe Backplanes.

Danke für die Rückmeldung, ich schaue mir das nochmal an.

 

[crmspezi]

Hallo zusammen.
Was ist leider wahrscheinlich nicht richtig verstanden habe möchte ich hier nachfragen:

• Wenn ich ein Ceth Cluster mit 9 Maschinen hätte und eine 3-er Kopie habe, werden dann alle Daten verteilt auf 9 Maschinen gespeichert, aber nur Teile davon, so dass nur der 3-fache Speicherplatz einer VM verwendet wird und dadurch schnellere Zugriffszeiten erreicht werden?
• Ist es auch möglich das ein Ceph Cluster aus nur 2 physischen Hosts mit QDevice für den PVE besteht oder wird zwingend ein dritter Ceph Host benötigt? Meine Überlegung dazu ist auf einem kleinen Ceph Cluster dann nur eine VM als ZFS over iSCSI Target für andere PVEs zu betreiben. Da wäre ich sehr flexibel und hätte hohe Sicherheit mit wenig Aufwand ohne zfs asynchrone Replikationen.

Ist zwar sehr speziell, trotzdem hoffe ich auf Rückmeldung.

Viele Grüße

 

[UdoB]

Wenn ich ein Ceth Cluster mit 9 Maschinen hätte und eine 3-er Kopie habe, werden dann alle Daten verteilt auf 9 Maschinen gespeichert, aber nur Teile davon, so dass nur der 3-fache Speicherplatz einer VM verwendet wird und dadurch schnellere Zugriffszeiten erreicht werden?

Korrekt. Wobei nicht schnellere Zugriffszeiten sondern Redundanz das Wichtige ist.

Ist es auch möglich das ein Ceph Cluster aus nur 2 physischen Hosts mit QDevice für den PVE besteht oder wird zwingend ein dritter Ceph Host benötigt?

Du brauchst mindestens drei Maschinen, die OSDs (Object Storage Daemon, meist identisch mit "Festplatte") zur Verfügung stellen.

Zumindest im Standardszenario mit size=3/min_size=2; das ist das Minimum und die Fehlerdomain ist "host".

In englischer Sprache habe ich das dort erläutert: https://forum.proxmox.com/threads/fabu-can-i-use-ceph-in-a-_very_-small-cluster.159671/

 

[crmspezi]

Korrekt. Wobei nicht schnellere Zugriffszeiten sondern Redundanz das Wichtige ist.


Du brauchst mindestens drei Maschinen, die OSDs (Object Storage Daemon, meist identisch mit "Festplatte") zur Verfügung stellen.

Zumindest im Standardszenario mit size=3/min_size=2; das ist das Minimum und die Fehlerdomain ist "host".

In englischer Sprache habe ich das dort erläutert: https://forum.proxmox.com/threads/fabu-can-i-use-ceph-in-a-_very_-small-cluster.159671/

Herzlichen Dank Udo. lese ich mir gleich mit durch. Ich verstehe aber Deine Aussage mit Redundanz nicht ganz. Bei 9 Hosts mit Ceth Cluster mit nur 3/2 OSD ist doch die Redundanz immer 3 im Normalfall. Die anderen Hosts des 9-er Cephcluster mit 3/2 liefern dann nicht nur 1/3 der Fragmente von Daten, also 3-fache Geschwindigkeit wie bei einem Ceth-Cluster mit nur 3 Hosts und 3/2?

Jetzt bin ich verwirrt. Bitte erkläre mir warum bei einer 3/2 Stategie hier die Redundanz besser wird mit mehr Hosts mit 3/2 bleibt? Ich dachte nur die Performance nimmt zu. Was habe ich hier falsch verstanden?

Habe jetzt Deinen Beitrag gelesen und verstehe es besser. Scheinbar bleibt die Strategie 3/2 bestehen und Ceth macht kein RO im Cluster?

 

[Johannes S]

Hallo zusammen.
Was ist leider wahrscheinlich nicht richtig verstanden habe möchte ich hier nachfragen:

• Wenn ich ein Ceth Cluster mit 9 Maschinen hätte und eine 3-er Kopie habe, werden dann alle Daten verteilt auf 9 Maschinen gespeichert, aber nur Teile davon, so dass nur der 3-fache Speicherplatz einer VM verwendet wird und dadurch schnellere Zugriffszeiten erreicht werden?

Ich habe nicht wirklich Ahnung von Ceph, aber nach meinen Verständnis der Doku werden beim Defaultwert 3/2 zwei Kopien der Daten erzeugt (3) und es müssen zwei zugänglich sein, damit der Cluster nicht in einen Fehlerzustand wechselt. Bei neun Knoten, liegen die Daten also auf zwei Knoten.

• Ist es auch möglich das ein Ceph Cluster aus nur 2 physischen Hosts mit QDevice für den PVE besteht oder wird zwingend ein dritter Ceph Host benötigt?

Nein, das ist so nicht ohne weiteres möglich. Mit Gefrickel kriegt man das vermutlich schon hin, aber so ziemlich jede mir bekannte Dokumentation sagt recht deutlich, dass es für eine Produktionsumgebung mindestens drei Knoten sein müssen, und das eher als Minimum zu betrachten ist:
https://docs.redhat.com/en/document...e_selection_guide/ceph-hardware-min-recommend ( Minimum of three nodes required.)

Hier im Forum wurden in der Vergangenheit öfters mal sogar fünf Knoten als Minimum empfohlen.
Eine öfter mal genannte Alternative für kleine Cluster ist Starwinds VSAN, aber das kostet natürlich auch:
https://de.starwindsoftware.com/starwind-virtual-san

• Meine Überlegung dazu ist auf einem kleinen Ceph Cluster dann nur eine VM als ZFS over iSCSI Target für andere PVEs zu betreiben. Da wäre ich sehr flexibel und hätte hohe Sicherheit mit wenig Aufwand ohne zfs asynchrone Replikationen.

Naja für solche kleinen Cluster ist ja eher der gängige Ansatz, das über eine NAS/SAS abzufackeln

 

[UdoB]

Ich verstehe aber Deine Aussage mit Redundanz nicht ganz. Bei 9 Hosts mit Ceth Cluster mit nur 3/2 OSD ist doch die Redundanz immer 3 im Normalfall.

Jeder Datenblock liegt auf drei Rechnern, sofern kein Defekt vorliegt.

Die anderen Hosts des 9-er Cephcluster mit 3/2 liefern dann nicht nur 1/3 der Fragmente von Daten, also 3-fache Geschwindigkeit wie bei einem Ceth-Cluster mit nur 3 Hosts und 3/2?

Das habe ich noch nie untersucht, ich lehne mich hier also eventuell etwas weit aus dem Fenster: jeder zu lesende Datenblock muss von irgendeinem Rechner geliefert werden - die anderen zwei Kopien können da nix beisteuern. Ob das einer von drei oder einer von 99 ist, ist zunächst egal. Zumindest, wenn der Cluster insgesamt nicht unter Last steht.

Der Sonderfall ist natürlich 3/2 mit genau drei Knoten: da ja jeder Block auf jedem Rechner vorhanden ist, braucht beim Lesen gar kein Netzwerkzugriff stattfinden - die Daten sind ja schon hier.

Ceph brilliert mit der Anzahl der Nodes/OSDs: mehr davon --> mehr Performance - insbesondere auch IOPS, nicht nur Bandbreite. (Im Homelab ist wohl meist das physische Netzwerk der begrenzende Faktor.)

Jetzt bin ich verwirrt. Bitte erkläre mir warum bei einer 3/2 Stategie hier die Redundanz besser wird mit mehr Hosts mit 3/2 bleibt? Ich dachte nur die Performance nimmt zu. Was habe ich hier falsch verstanden?

Ich glaube den Satz habe ich nicht richtig verstanden.

Die Fehlerdomain ist "host". Mit 3/2 werden alle Blöcke an drei Hosts gesendet. Erst wenn zwei den Empfang bestätigen, gilt der Block als geschrieben.

Bis dahin gilt das unabhängig von der Anzahl der eingebunden Ceph-Knoten, egal ob 3 Nodes oder 99.

 

[crmspezi]

Jeder Datenblock liegt auf drei Rechnern, sofern kein Defekt vorliegt.


Das habe ich noch nie untersucht, ich lehne mich hier also eventuell etwas weit aus dem Fenster: jeder zu lesende Datenblock muss von irgendeinem Rechner geliefert werden - die anderen zwei Kopien können da nix beisteuern. Ob das einer von drei oder einer von 99 ist, ist zunächst egal. Zumindest, wenn der Cluster insgesamt nicht unter Last steht.

Der Sonderfall ist natürlich 3/2 mit genau drei Knoten: da ja jeder Block auf jedem Rechner vorhanden ist, braucht beim Lesen gar kein Netzwerkzugriff stattfinden - die Daten sind ja schon hier.

Ceph brilliert mit der Anzahl der Nodes/OSDs: mehr davon --> mehr Performance - insbesondere auch IOPS, nicht nur Bandbreite. (Im Homelab ist wohl meist das physische Netzwerk der begrenzende Faktor.)


Ich glaube den Satz habe ich nicht richtig verstanden.

Die Fehlerdomain ist "host". Mit 3/2 werden alle Blöcke an drei Hosts gesendet. Erst wenn zwei den Empfang bestätigen, gilt der Block als geschrieben.

Bis dahin gilt das unabhängig von der Anzahl der eingebunden Ceph-Knoten, egal ob 3 Nodes oder 99.

Danke, ich habe es nun auch verstanden, Dein Link weiter oben ist sehr ausführlich.

 

[Falk R.]

Die Performance von Ceph bei großen Clustern steigt aber nur wenn viele Verbraucher (VMs) vorhanden sind. Habe ich nur eine VM, ändert sich die Performance zwischen 3 und 9 Nodes kaum.
Wenn du eine große Datenbank hast die Mega Performance braucht, solltest du lieber ZFS oder wenn shared eine externe Speicherlösung nutzen. Für die paar tausend I/O die eine DB bei einem mittelständischen Betrieb macht, kommt man auch locker mit Ceph hin, solange die SSDs und das Netzwerk schnell genug sind.

Wenn du die zu erwartende Storagelast kennst (Blockgrößen, I/O pro Sek.) dann kann man schon eine Hardwareempfehlung aussprechen. leider hat man selten vorher gute Werte zum kalkulieren, außer man kann an einem Bestandssystem selbst messen.

 

[crmspezi]

Die Performance von Ceph bei großen Clustern steigt aber nur wenn viele Verbraucher (VMs) vorhanden sind. Habe ich nur eine VM, ändert sich die Performance zwischen 3 und 9 Nodes kaum.
Wenn du eine große Datenbank hast die Mega Performance braucht, solltest du lieber ZFS oder wenn shared eine externe Speicherlösung nutzen. Für die paar tausend I/O die eine DB bei einem mittelständischen Betrieb macht, kommt man auch locker mit Ceph hin, solange die SSDs und das Netzwerk schnell genug sind.

Wenn du die zu erwartende Storagelast kennst (Blockgrößen, I/O pro Sek.) dann kann man schon eine Hardwareempfehlung aussprechen. leider hat man selten vorher gute Werte zum kalkulieren, außer man kann an einem Bestandssystem selbst messen.

Danke Falk für die Winweise. Mir macht nur nach dem Studium der Hinweise (https://forum.proxmox.com/threads/fabu-can-i-use-ceph-in-a-_very_-small-cluster.159671/) von Udo Sorgen, der RO Status von Ceth, wenn nicht genug Ceth Hosts vorhanden sind. Derzeit setze ich zfs over iscsi ein und bin total zufrieden. Mit Ceth wollte ich von einer async Replikation zur sync. Replikation kommen, um mehr Sicherheit und geringere Downzeiten zu erreichen, bei gleichbleibender Latenz. Da scheint aber Ceth weniger geeignet zu sein (habe viele VMs mit MSSQL/u.a. DB's), nachdem ich Dank euch hier mehr Infos habe.

Johannes schreibt "Naja für solche kleinen Cluster ist ja eher der gängige Ansatz, das über eine NAS/SAS abzufackeln". Wie meint er das, ich stehe auf dem Schlauch.

 

[Johannes S]

Johannes schreibt "Naja für solche kleinen Cluster ist ja eher der gängige Ansatz, das über eine NAS/SAS abzufackeln". Wie meint er das, ich stehe auf dem Schlauch.

Dass man eine NAS oder ein per FibreChannel angebunden StorageArray hat und dieses über ISCSI oder NFS an diese PVE-Hosts anbindet

 

[Falk R.]

Danke Falk für die Winweise. Mir macht nur nach dem Studium der Hinweise (https://forum.proxmox.com/threads/fabu-can-i-use-ceph-in-a-_very_-small-cluster.159671/) von Udo Sorgen, der RO Status von Ceth, wenn nicht genug Ceth Hosts vorhanden sind. Derzeit setze ich zfs over iscsi ein und bin total zufrieden. Mit Ceth wollte ich von einer async Replikation zur sync. Replikation kommen, um mehr Sicherheit und geringere Downzeiten zu erreichen, bei gleichbleibender Latenz. Da scheint aber Ceth weniger geeignet zu sein (habe viele VMs mit MSSQL/u.a. DB's), nachdem ich Dank euch hier mehr Infos habe.

Johannes schreibt "Naja für solche kleinen Cluster ist ja eher der gängige Ansatz, das über eine NAS/SAS abzufackeln". Wie meint er das, ich stehe auf dem Schlauch.

Wenn du nur 3 Datenkopien hast, darf regulär nur eine Kopie ausfallen. Wenn zwei Kopien offline sind geht das ganze berechtigt in ReadOnly.
Du kannst das entschärfen wenn du für kritische Daten eine 4/2 Regel nutzt, dann können 2 Kopien offline gehen.
Ceph kann man da sehr frei konfigurieren.
Wenn du viele SQL hast, ist das schon wieder deutlich besser als ein dicker SQL. Hast du mal die Performancewerte der SQL gemessen?
Ich habe Kunden mit SQL DBs, welche mehrere TB groß sind und eine Permanentlast von 50k+ I/O und Peaks auf mehrere 100k I/O machen. Die sind nicht Ceph geeignet, aber da hinterfrage ich auch jedes mal, ob man das wirklich virtualisieren muss.
P.S. dieses Setup läuft derzeit klassisch auf einem Propoeritären SAN-Storage, was man natürlich auch an PVE anbinden kann.

 

[crmspezi]

Dass man eine NAS oder ein per FibreChannel angebunden StorageArray hat und dieses über ISCSI oder NFS an diese PVE-Hosts anbindet

Danke, das habe ich und bin mit Latenz sehr zufrieden. Repliziere über zrep (async) zu einer weiteren NAS alle 5 min. Ich wollte aber mehr Sicherheit (also sync). Kann ich bestimmt mit drb machen, aber ceph hatte mich auch gereizt.