Alternative für GlusterFS?

[floh8]

Ich kann es nur immer wieder erwähnen, das ich gern mal gewusst hätte, warum GLusterFS v. Proxmox so sträflich behandelt wird. Wenn man den posts dazu folgt, findet man Aussagen vom STAFF wie "würde ich max. mit 4 Nodes machen und danach ceph", "bis zu 10 Nodes funktioniert dies". Man findet auch Kritik zur Recovery-Performance bei Ausfällen. Diese sei sehr schlecht mit Glusterfs. Andere senken ihre Ansprüche und können an ihrem NFS-Export von GLusterFS nix aussetzen. Jetzt liest man natürlich in den Vergleichstests, dass man viel optimieren kann - dies allerdings im Internet nicht hier.
Ich finds schade. Darum habe ich mal recherchiert nach einem Clusterfilesystem mit den gleichen Möglichkeiten wie GlusterFS, aber mit Subvolume+Snapshot-Funktionalität.
Warum das Ganze. Ich hätte gern ein clusterFS, das ich für Container einsetzen kann, wo das Backup via snapshot einen konsistenten Zustand sichern kann und was recht fix geht, wenn ich DBs oder fileserver drin laufen lasse.
Ich habe leider kein freies Opensource-System gefunden. Die meisten sind für riesige Umgebungen und Performance gedacht. Features wie Snapshot, Subvolume, Scrubbing fehlen da komplett. Viele sind auch nicht frei und kosten Lizenzen. Trotzdem möchte ich mal eins, zwei zur Sprache bringen, die am ehesten an GlusterFS rankommen und auch sehr ähnlich sind.
Und zwar: BeeGFS. Ist ähnlich, da auf posix-Filesystem basierend und sehr felxibel skalierbar. Ich kann sogar einen SingleHost installieren und es drauf laufen lassen, was natürlich wenig sinnvoll wäre. Für alle, die mit GlusterFS so ihre Problemchen haben, empfehle ich zu nächst die Doku von RedHat. Ansonsten könnt ihr natürlich BeeGFS eine Chance geben. Es wird zwar nicht direkt von Proxmox unterstützt, aber das wird ja GlusterFS auch nicht. Die Einrichtung kannst du auch in die fstab machen und dann ein Dir-Storage erstellen. Hast du die selben funktionen wie mit GlusterFS. Ein Performance-Vergleich findet man hier. Ich will mal einen Vergleich hier publizieren.

Cluster FS	GlusterFS​	BeeGFS​	SeaweedFS​	DRBD​	Ceph​
Komprimierung	ja, via VDO or ZFS	ja, via VDO or ZFS	ja, via VDO or ZFS	ja, via VDO or ZFS	ja
Deduplizierung	ja, via VDO or ZFS	ja, via VDO or ZFS	ja, via VDO or ZFS	ja, via VDO or ZFS	nein
Snapshot	ja, nicht in Proxmox	nein	nein	nein	ja
Subvolumes	nein	nein	nein	nein	ja
High Availibility	ja	ja, als Mirror	ja	ja	ja
CIFS-Config integriert	ja	nein, separat	nein, separat	nein, separat	ja
NFS-Config integriert	ja	nein, separat	nein, separat	nein, separat	ja
Bit-Rotate-Schutz	ja	nein, mit zfs	nein, mit zfs	nein, mit zfs	ja
Belastbarkeit	ja	nur in Enterprise	ja	ja	ja
RDMA	ja	ja	nein	ja	ja
Quota/Acl	ja	nur in Enterprise	nein	ja	ja
Geo Replication	ja	nein	ja	ja	ja
Tiering	ja	nein	ja	nein	Cache tiering
iSCSI	ja	nein, separat	nein, separat	nein, separat	ja
use case	HCI, more	HCI, more	HCI, more	Backup, HCI, more	HCI, more

Bei ceph hab ich nicht mehr alles im Kopf. Wenn was falsch ist, dann schreibt mal. Leider habe ich erst spät gesehen, das BeeGFS vermarktet wird, deshalb reicht die Community-Version für den produktiven Einsatz vermutlich nicht aus. Is ja trotzdem ganz nett zu wissen. ;-) DRBD ist ja wieder im Kommen. Bei SeaweedFS fand ich das Tiering recht interessant, was anscheinend besser ist, als das von GlusterFS.

Fazit:
Eine Alternative mit Subvolumes findet man für GlusterFS nicht, da mind. der Bit Rotate Schutz fehlt. ZFS als Raid darunter zu nutzen, um dies auszugleichen, finde ich bei einem HCI als Ressourcenverschwendung. Um Container funktional auf einem ClusterFS zu nutzen, benötigt man nun mal Subvolumes und Snapshot, damit man nicht zusätzliche Layer wie eine Imagedatei (Qcow) nutzen muss. Es wäre natürlich mal interessant einen Container auf Basis einer QCow2-Datei mit einer VM bezügl. Performance zu vergleichen. Die Proxmox-Entwickler haben sich bereits negativ über einen zusätzlichen Layer geäußert und deshalb wird sich in diese Richtung wohl leider nichts passieren. Container im Cluster-Umfeld bleiben also Ceph vorbehalten. Wer Deduplizierung auf seinem Cluster-Storage bevorzugt wie ich, der muss also bei VMs bleiben und kann die schöne Containerfunktion von Proxmox nicht auskosten.

 

[floh8]

Ich denke, ich habe mir die Frage, warum Proxmox überhaupt keine Container-Tag für GlusterFS anbietet, nun selbst beantwortet. Ob GlusterFS snapshots bei GlusterFS unterstützt ist irreleavant, wenn GlusterFS keine Subvolumes unterstützt. Was der Fall ist.
Man kann volumes auf dem selben Blockdevice anlegen, dazu muss man aber erst einen neuen Ordner auf dem Device erstellen, was nicht über einen gluster-Befehl funktioniert, da glusterfs nur die darüber liegende Ebene verwaltet.

Wenn man doch nur qcow2-Files als Container-Images nehmen könnte. Dann wäre es so schön einfach. Verdammt, das ist sogar möglich. Proxmox staff - habt ihr freie Ressourcen? Look here.

 

[Falk R.]

Hallo Floh,

du hast dich ja schon viel mit den Themen auseinander gesetzt. Hast du auch Erfahrung mit RDMA in dem Umfeld? Wie gut funktioniert RDMA mit Ceph und geht das auch in Proxmox? Ich habe RDMA bei Microsoft S2D lieben gelernt (Spart viele Ressourcen und macht das Storage richtig schnell)

Viele Grüße,
Falk

 

[floh8]

hallo falk,

Erfahrung habe ich leider nicht. Meine Recherchen dazu sind schon eine Weile her, aber ich denke, da hat sich nicht viel geändert. Der Linux-Kernel unterstützt nur die Variante RoCE für RDMA. Reicht aber auch. Leider ist bei Linux die Kompatibilität immer so ein Problem, deshalb muss man für andere Varianten professionellen Support einkaufen. Generell ist sowieso ein Anbieter zu nutzen, der Support anbietet und eine gute Community bietet wie Mellanox. Ceph unterstützt es siehe oben. Proxmox ist es egal, da Proxmox ja das Storgesystem anspricht.

 

[Falk R.]

Also wenn man RDMA vernünftig nutzen möchte kommt man um RoCEv2 und Mellanox nicht drum herum. Mit Broadcom Nics geht das auch, aber eher nur zum testen. iWarp fällt für mich sowieso aus. Hast du eventuell einen link mit aktuellen Infos zu Ceph mit RDMA. Ich finde im Netz immer recht alte Beiträge und ganz oft "experimental".

 

[floh8]

ja, viel machen das nicht, weil es noch zu viele Probleme gibt und die HW ja sehr teuer ist, wenn man niedrige Latenzen haben möchte.
Anscheinend ist ceph auch nicht so ganz egal, wie die Knoten angesprochen werden, sonst gäbe es ja keine unterscheidung in der config. hier findest du paar anhaltspunkte:
https://www.reddit.com/r/ceph/comments/jwra2s/experiences_with_mellanox_infiniband/
https://forums.servethehome.com/ind...-over-rdma-performance-gain.20329/post-310891

ich denke, dass ein professioneller partner wohl unumgänglich ist. Vielleicht wird irgendwann mal Proxmox eine RDMA Empfehlung ausgeben und die auch supporten.

Also, was man rauslesen kann, ist, dass viele Infiband mit Ceph erfolgreich einsetzen.

 

[floh8]

ich stelle immer wieder fest, wie geil eigentlich zfs ist. klar, es kann nicht clustern, aber volumes für container werden halt direkt durchgereicht, nicht wie im vergleich zu allen anderen FS.

 

[Falk R.]

ja, viel machen das nicht, weil es noch zu viele Probleme gibt und die HW ja sehr teuer ist, wenn man niedrige Latenzen haben möchte.
Anscheinend ist ceph auch nicht so ganz egal, wie die Knoten angesprochen werden, sonst gäbe es ja keine unterscheidung in der config. hier findest du paar anhaltspunkte:
https://www.reddit.com/r/ceph/comments/jwra2s/experiences_with_mellanox_infiniband/
https://forums.servethehome.com/ind...-over-rdma-performance-gain.20329/post-310891

ich denke, dass ein professioneller partner wohl unumgänglich ist. Vielleicht wird irgendwann mal Proxmox eine RDMA Empfehlung ausgeben und die auch supporten.

Also, was man rauslesen kann, ist, dass viele Infiband mit Ceph erfolgreich einsetzen.

Hi Floh,

ich habe mich noch etwas schlau gelesen. Ceph ist es quasi egal ob mit oder ohne RDMA. Was leider bei ganz vielen Posts im Netz zu kurz kommt, ist das man nicht nur Latenz und Durchsatz verbessert, sonder man spart auch eine Menge CPU Ressourcen. Gerade bei einem HCI Cluster macht das schon einen großen Unterschied ob ich ein paar VMS mehr mit der gleichen Hardware betreiben kann.
Das mit dem teuer kann ich nicht ganz nachvollziehen. Die Mellanox Karten sind nicht teurer als vergleichbare andere Karten. Im Vergleich zu Intel sogar oft günstiger. Bei den Switches muss man nur auf RDMA Fähigkeit achten, aber teurer werden die nicht dadurch.
Ich habe derzeit ganz viel 25GBit im Einsatz und das ist nur minimal teurer als 10GBit, macht aber viel mehr Spaß.

 

[floh8]

bei den karten geb ich dir recht, aber die "schnellen" Switche kosten halt doch ne menge mehr als so ein standard switch wie man ihn gewohnt ist. und IB ist dann mal richtig teuer. was setzt ihr denn für 25 GBit Switche ein?

 

[Falk R.]

Hi, für NVMeoF oder RoCE nehme ich gern den:
https://www.fs.com/de/products/110479.html
Davon je 2 pro RZ.
Ist eher für die größeren Kunden, gibt auch kleine Switches aber da suche ich immer im Einzelfall das richtige Modell.

 

[floh8]

ja, die scheinen sehr gut zu sein. was mir fehlt, ist die angabe der latenz für 9k frames, denn die würde ich ja als storage switch meist einsetzen oder welche nutzt ihr?
leder habe ich kein vergleichspreis eines arista switches gefunden. eine alternative wäre arista 7280SR3-48YC8 in meinen augen, der ist aber langsamer als der FS Switch. für 5000 € ist der FS auch gar nicht mal so extrem teuer, muss ich zugeben. man muss ja berücksichtigen, dass man 48x 25 GBit mit einer Latenz von ca. 800ns und RDMA-Fähigkeit hat. gute Wahl also!
für eine KMU-Lösung ist der allerdings überdeminsioniert. Kennst du noch einen der nur 24 oder weniger Ports hat mit dieser Spezifikation?

 

[Falk R.]

Hi, mit weniger Ports ist der Mellanox SN2010 fast der einzigste. https://www.mellanox.com/related-docs/prod_eth_switches/PB_SN2010.pdf
Straßenpreis ist da im selben Bereich wie der FS.
Für die ganz kleinen Cluster nehme ich sehr gern den: https://www.fs.com/de/products/108710.html
Der hat nur 4x 25GBit und auch nur 2x 40GBit als Uplink, aber damit geht auch schon was.

 

[Falk R.]

Hi, mit weniger Ports ist der Mellanox SN2010 fast der einzigste. https://www.mellanox.com/related-docs/prod_eth_switches/PB_SN2010.pdf
Straßenpreis ist da im selben Bereich wie der FS. Von DELL gibt es einen ähnlichen, aber der macht Preis/Leistung keinen Sinn.
Für die ganz kleinen Cluster nehme ich sehr gern den: https://www.fs.com/de/products/108710.html
Der hat nur 4x 25GBit und auch nur 2x 40GBit als Uplink, aber damit geht auch schon was.

 

[floh8]

also, FS ist wirklich mit Abstand der günstigste Anbieter solcher Switche. Mir gefällt der kleine FS sehr gut, vor allem wenn du mit nem HCI über 3 Knoten starten willst (Patchfelder zentral), kannst den als Storage + Core + Aggregationsswitch nutzen. Das spart ne Menge Geld. Einfach Klasse. Danke für den Tip.

 

[Falk R.]

SFPs und die Verkabelungskomponenten sind da auch super Preiswert.

 

[floh8]

ich habe immer den fehler gemacht, snapshot-funktionalität mit schnellen backups gleich zu setzen, da ich dachte, wenn snapshots gehen, dann gibt es im filesystem so etwas ähnliches wie dirty bitmaps und das nutzt dann proxmox, um container schnell zu sichern. leider kann ich in meiner testumgebung tests mit großen containern nicht machen, denn das gibt sie leider nicht her. drum habe ich eine alternative gesucht, die ich in einem anderen thread mal darbiete.

 

[Falk R.]

Ich persönlich nutze Container nur um einzelne Dienste zu abstrahieren ohne eigenen Kernel. Nutzdaten wie DBs oder Fileablage mache ich lieber klassisch als VM. Daher habe ich kein Problem mit Backupperformance.
Meine Testumgebung hat nur 4 billige WD Green SSDs pro Host. Da die ohne Cache sind, kann man eigentlich nicht viel erwarten, aber meine Backups laufen trotzdem mit ca. 1GB/s. Mein 40GB Container ist nach 37 Sekunden fertig mit Backup, da ist mir die Dirty Map egal.

 

[floh8]

Was anderes bleibt einem ja nicht übrig. Gerade bei Dateiservern kommt noch das Problem von offenen Dateien hinzu - da is so ein Snapshot von ner qcow natürlich die Rettung. Es ist nur schade, dass man halt so vieles ausschließen muss bei der Containernutzung. Wenn man Windows, was fast jedes KMU hat, bereits nicht im Container nutzen kann, dann wäre ne gewisse Flexibilität bei Linux-Distributionen schon sehr nützlich. Container gibt es ja nicht erst seit gestern.

 

[Falk R.]

Aber Container sind nicht so abstrahiert wie eine VM, was Ressorcenvorteile bringt aber dadurch auch logische Nachteile. Windows Container geht auch, da aber die meisten Applikationen die Registry nutzen sind die nicht Containerfähig. Eventuell wären schnelle Backups möglich, wenn das Host Filesystem die Dirtmap pflegt und man das irgendwie dem Backupprozess beibringt. Kritische Dienste kommen bei mir nie in Container, da kein Livemigration möglich ist.

 

[floh8]

mom..willst du damit sagen, dass windows container auch eingeschränkte Nutzungsfähigkeiten haben, da fast alle Apps registry nutzen, die in Windows containern aber nicht zur Verfügung steht?