Die Registry des Hosts greift bei Windows Containern. Problem erkannt und das Thema hatte sich für mich erledigt. 
Alternative für GlusterFS?
- Thread starter floh8
- Start date
Nicht umsonst hat Microsoft ein eigenes Linux Derivat was auf Containerisierung getrimmt ist und portiert immer mehr Dienste wie zuletzt SQL auf Linux.
Das ist eigentlich kein Geheimnis, derzeit bringt MS mehr in Open Source ein als z.B. RedHat. In Azure läuft schon eine ganze Menge Open Source.
zu HCI mit GlusterFS+Dedplizierung siehe https://forum.proxmox.com/threads/kernelmodul-kvdo-fehlt.107179/
Last edited:
Mittlerweile supportet Redhat RDMA für GlusterFS nicht mehr. GlusterFS ist dadurch für mich uninteressant geworden, da RDMA im Storagebereich im Kommen ist und bald zum Standard gehört. Ich weiß nicht, was sich Redhat dabei denkt, aber GlusterFS war eine gute Alternative zu Ceph, auch wenn man mehr Gehirnschmalz in eine multifunktionale Lösung stecken musste. Um Deduplizierung zu haben, sollte man bald StorageSpaces in die engere Auswahl nehmen, da Windows alles mitbringt, was man sich wünscht, wie z.B. Autotiering. Leider fehlt noch der Support für SMB direct im Linuxumfeld. Man muss natürlich mit den Macken von Windows klar kommen.
Hi,
da muss ich dir widersprechen. Im Enterprise Umfeld geht RDMA wieder zurück, da man z.B. lieber NVMe over TCP macht, statt NVMe over RoCE.
Das Problem bei RDMA ist das sehr Komplexe Netzwerksetup mit DCB und PFC.
TCP ist da deutlich robuster, warum auch Redhat jetzt diesen Weg geht.
P.S. Dedup bei S2D möchtest du nicht, das ist reines Post Dedup und kein inline Dedup.
da muss ich dir widersprechen. Im Enterprise Umfeld geht RDMA wieder zurück, da man z.B. lieber NVMe over TCP macht, statt NVMe over RoCE.
Das Problem bei RDMA ist das sehr Komplexe Netzwerksetup mit DCB und PFC.
TCP ist da deutlich robuster, warum auch Redhat jetzt diesen Weg geht.
P.S. Dedup bei S2D möchtest du nicht, das ist reines Post Dedup und kein inline Dedup.
Hallo Falk, du bist ja in Rechenzentren schon gut rumgekommen, aber deine Aussagen sind nicht logisch.
Generell:
Mit NVME-oF habe ich mich noch gar nicht so vertraut gemacht, weil es doch noch eher was für die RZ ist, aber es wird sicherlich mehr werden. Das NVMe Protokoll wird definitiv auch das Standardprotokoll für Festplatten werden. Für Proxmox ist es gar nicht mal so uninteressant, da es iSCSI outperfomed. Man muss aber immer bedenken, dass es ein Blockdevice-Protokoll ist. Wenn man nicht gerade Ceph oder [zfs over nvme]
einsetzt, benötigt man immer noch ein Clusterfilesystem zusätzlich obendrauf. Man bedenke, wenn ich ein Blockraiddevice freigebe, habe ich immer noch keine Zusatz-Funktionen dabei, es sei denn, ich habe sowas wie zfs drunter.
NVMe over TCP ist sicherlich kostensparend, wenn man noch alte Hardware hat, keine Frage, aber dennoch werden Neuanschaffungen RDMA konform sein und auch bei NVMe-Anwendungen wird sich RDMA durchsetzen. Warum? Na, weil es einfach viel mehr Performance bietet als über TCP. Zum Beispiel ist die Latenz doppelt so hoch bei NVMe-oT als over RDMA. Siehe hier: https://nvmexpress.org/wp-content/u...-You-Need-to-Know-About-the-Specification.pdf. Was gerade für HCI-Umgebungen wichtig ist, dass RDMA-Karten die CPU voll entlasten, da die Daten eben nicht durch den TCP Stack müssen. Wenn wir uns andere Protokolle anschauen, die man auf RDMA aufsetzen kann, sehen wir die Überlegenheit von RDMA von um das 2-3fache z.B: bei den IOPS oder der Bandbreite. Siehe hier: https://developer.nvidia.com/blog/d...tem-performance-with-rdma-enabled-networking/
Ich habe mich bereits mit der Einrichtung vertraut gemacht und kann auch das widerlegen. Wenn du Lossless Ethernet-Konfigurationen nutzt, musst du 2 Parameter für das Netzwerk einstellen, nämlich entweder GPFC und PFC oder DSCP und PFC. siehe hier: https://docs.vmware.com/en/VMware-v...UID-B764140D-BCF3-4C99-8169-E5B058757518.html Das sollte jeder normale Admin schaffen. Es setzt natürlich die HW voraus. Das ist klar.
Nein, RDMA ist auch robust, kann routen und ist lange auf dem Markt. Redhat will einfach nur GlusterFS einstampfen, um vermutlich Ressourcen zu schonen. Es hat sich halt nicht so durchgesetzt.
Wie kommst du denn darauf? Nein, um Himmelswillen kein inline Dedup, da geht ja die Performance krachen. Darum setzt es ja keiner bei zfs ein. Wenn dann immer offline Dedup. Darum hat ja BTRFS auch noch seine Daseinsberechtigung. Ich denke aber irgendwann wird zfs offline Deduplication einführen und dann werden die Fanboys von zfs noch mehr schwärmen.
Generell:
Mit NVME-oF habe ich mich noch gar nicht so vertraut gemacht, weil es doch noch eher was für die RZ ist, aber es wird sicherlich mehr werden. Das NVMe Protokoll wird definitiv auch das Standardprotokoll für Festplatten werden. Für Proxmox ist es gar nicht mal so uninteressant, da es iSCSI outperfomed. Man muss aber immer bedenken, dass es ein Blockdevice-Protokoll ist. Wenn man nicht gerade Ceph oder [zfs over nvme]
einsetzt, benötigt man immer noch ein Clusterfilesystem zusätzlich obendrauf. Man bedenke, wenn ich ein Blockraiddevice freigebe, habe ich immer noch keine Zusatz-Funktionen dabei, es sei denn, ich habe sowas wie zfs drunter.
Egal ob Logisch, das ist einfach Erfahrung aus dem Real Life.
Im Real Life sind die Performanceunterschiede nicht so groß. Die extrem niedrigen Latenzen brauchst du eh oft nur bei HPC.
Jetzt guck dir mal die großen Storagehersteller an, viele Supporten nur NVMe over TCP und alle anderen, welche bisher RoCE unterstützt haben, haben jetzt den TCP Support dazu eingebaut. Das einzige wo ich noch viel ROCE nutze, sind die S2D / ASHCI Cluster.
Ist alles auch eine Frage der Einrichtung und auch die Frage ob du die Switches nur für Storage oder auch für normales Netzwerk nutzt.
Inline Dedup muss nicht langsam sein, auch bei ZFS kannst du mit inline Dedup gute Performance erreichen, Alles nur eine Frage der Konfiguration und Abstmmung. Auch wenn S2D das Dedup nur nachgelagert macht, ist es nicht so effektiv, als wenn ich die gleiche Engine in meinem Windows Fileserver nutze und bei S2D ist der Performanceeinbruch auch deutlich spürbar, sogar bei all NVMe.
Bei Proxmox bin ich eh ein Fan von Ceph und wenn Version 18 raus kommt bin ich mal sehr gespannt, Auf der Cephcon wurden einige coole Features und Performanceverbesserungen vorgestellt. Mal gucken was im nächsten Release alles drin ist.Generell:
Mit NVME-oF habe ich mich noch gar nicht so vertraut gemacht, weil es doch noch eher was für die RZ ist, aber es wird sicherlich mehr werden. Das NVMe Protokoll wird definitiv auch das Standardprotokoll für Festplatten werden. Für Proxmox ist es gar nicht mal so uninteressant, da es iSCSI outperfomed. Man muss aber immer bedenken, dass es ein Blockdevice-Protokoll ist. Wenn man nicht gerade Ceph oder [zfs over nvme]
GlusterFS ist für mich keine gute alternative zu Ceph.
Komische Erfahrung, die du so machst.
du meinst, meine Quellen beziehen sich ja nur auf Testumgebungen und deshalb sind sie nicht aussagekräftig. Ich denke schon.
Was ist das wieder für ein Unsinn. Um so geringer meine Latenz ist, desto schneller legt das Paket seinen Weg zurück. Die LAtenz im Netzwerk ist vergleichbar mit der IOPS Zahl bei Speicher. Bandbreite ist nicht immer das Wichtigste. Willst du etwa einen Internetzugang haben mit 1 Gbit/s Bandbreite aber einer Latenz von 1000ms? Jedes Paket, was dein PC wegschickt benötigt 1 Sekunde ehe es ankommt. Na Prost Mahlzeit. Viel Spaß beim Surfen!
Also ich habe mich mal eben bei Fujitsu umgeschaut. Fujitsu ist ja eine Marke, die viele auch im Unternehmensfeld einsetzen. da findest du das Flash-Produkt "Fujitsu Storage ETERNUS AB6100". Und siehe da, es bietet kein NVME over TCP an, dafür aber 2 RDMA Kombinationen. Dass Hersteller NVMe over TCP erst später eingebaut haben, liegt daran, weil die NVME-Spezifikation dazu erst später rauskam als für RDMA. Was für eine unsinnige Argumentation von dir.
Dein normales TCP/IP funktioniert dann trotzdem noch. Das ist dann nicht defekt.
Egal wie gut du es abstimmst, es bleibt langsamer als ohne, denn jede zusätzliche Funktion nutzt die CPU und steigert somit die Latenz.
Keiner hat hier irgendwas über Effizienz geschrieben. Also bleib mal am Ball! Post-Dedup senkt die Latenz natürlich auch, aber ich kann die Einschränkung auf Zeiten planen, wo nicht die Hauptbelastung des Storages ist. Das ist ja grad der Vorteil von Offline-Dedup. Komisch, das ich dir sowas erläutern muss.
Ceph hat aber nun mal kein Dedup und darum geht es mir auch in diesem Thread. Wenn dir dein Ceph wie auch anderen etwas zu langsam ist, dann empfehle ich dir Ceph über RDMA zu aktivieren
Übrigens unterstützt ceph auch NVME-oF. Macht für Proxmox aber weniger Sinn.
Last edited:
Ich hatte mir vor 4 Jahren, als es im Markt losging mit RDMA auch mehr vorgestellt. Aber manchmal kommte es anders als man denkt, vor allem wenn man die technische Brille auf hat. Leider gewinnt oft nicht das technisch bessere Produkt, sondern das mit dem besten Preis/Leistung oder besserem Marketing.
Wenn der Unterschied so groß wäre, dann hätte RDMA längst gewonnen. Durch TCP Offloading der Netzwerkkarten und einiger anderer Features, sind die gemessenen Latenzunterschiede tatsächlich nicht sehr groß, weil wir uns eh in einem Latenzarmen Umfeld bewegen.
Falls due RDMA routen möchtest, machst du auch alle Latenzvorteile wieder kaputt, da das Routing in der Regel mehr bremst.
Fujitsu ist auf dem Storagemarkt ja eher ein kleinerer Player. Guck dir mal die Platzhirsche an. Netapp = nur TCP, DELL (Powerstore) = RoCE angekündigt, aber TCP implementiert, Pure Storage = RoCE im Portfolio, aber die Engineers sagen, nicht kaufen weil es nicht sauber läuft, jetzt TCP implementiert.
Anscheinend ist das auf Storageseite auch nicht ganz unproblematisch zu implementieren. Der einzige Hersteller wo RoCE gut läuft ist Huawei, aber die werden ja von der Politik blokiert. (Ich habe Huawei mit RoCE gern implementiert)
Aber dann musst du beim PFC mehr Hirnschmalz reinstecken, du willst ja mit dem Storage dein Voice nicht abklemmen und auch wegen Voice keine Storagepakete verlieren. Bei dedizierten Storagenetzen ist es tatsächlich relativ einfach, aber viele möchten nicht zwei mal teures Netzwerk kaufen.
Zum Thema Dedup:
Entweder du willst Dedup und planst Ressourcen dafür ein, oder man lässt es komplett. Ich kenne Storagehersteller die im Backend ZFS nutzen, weil die Dedupengine so gut ist. Mit 15-25% Performanceverlust durch Dedup kann man ja leben, wenn der Einspareffekt groß genug ist.
Ich nutze auf den Storages lieber Compression wenn es angeboten wird. Da hast du bis zu 20% bessere Performance und sparst Speicherplatz. Das macht ZFS bei Proxmox per default ja auch.
Leider kann ich keinen Performance-Vergleich im Internet finden. Ich denke, dass RDMA wegen seinem Design trotzdem performanter ist als TOE. RDMA hat allerdings den Nachteil, dass sich die drüberliegenden Programme anpassen müssen, was bei TOE nicht der Fall ist. Das ist aus meiner Sicht die eine Hauptursache für die fehlende Marktdurchdringung und die 2. ist die fehlende Standardisierung. Es gibt halt zu viele Lösungsvarianten, siehe RoCE, iWArp, Infiband.
Richtig, Dell ist zu meiner Verwunderung Spitzenreiter.
Wo hast du die info wieder her. Netapp unterstüzt alle - durch die Bank weg.
Also meine Infrastruktur würde auch den Core Switch für VoIP nutzen. Das muss man natürlich zusätzlich konfigurieren, wenn du VoIP nutzen willst und das machste am Einfachsten mit VLAN Priorisierung. Wie kommste jetzt wieder auf Pakete verlieren? Was für billige Hardware setzt du denn ein? Da verliert doch der Switch keine Pakete.
Oder du verteilst die Last einfach = Perfektionierung der Storageauslastung wie oben beschrieben.
Infiniband = RoCE Protokoll und iWarp nutzt wieder TCP und kein UDP
Ich habe keine Ahnung was NetApp derzeit tatsächlich unterstützt, ich sehe aber nur NVMe over TCP Installationen im Feld. (Hätte ich auch mal nachgucken können)
Egal wie teuer der Switch ist, bei UDP hast du keine Zustellgarantie und wenn ein Uplink dicht ist können UDP Pakete mal hops gehen.Also meine Infrastruktur würde auch den Core Switch für VoIP nutzen. Das muss man natürlich zusätzlich konfigurieren, wenn du VoIP nutzen willst und das machste am Einfachsten mit VLAN Priorisierung. Wie kommste jetzt wieder auf Pakete verlieren? Was für billige Hardware setzt du denn ein? Da verliert doch der Switch keine Pakete.
Da RoCE/Infiniband ihren Performancevorteil herausholen durch die Nutzung von UDP, musst du halt höllisch aufpassen im Design und Monitoring des Netzwerks.
Uplink? Auf dem Core Switch?. Ách den Uplink zum Admin
Dann nimm RoCE V1 da hats kein udp. Clever was?Aber nur weil sie das udp Protokoll an ihre Bedürfnisse anpassen, damit es mit Schaltkreislösungen kompatibel ist.
ja...infiniband war ja mal eigenständig und dann hat es RoCE aufgekauft.
iWarp war schon immer abtrünnig, durch TCP ist es auch tierisch langsam, wenn du es nicht mit TOE kombinierst.
Als verantwortungsvoller Admin solltest du auch mal auf das Nachbarfeld schauen.
ja,ja...Lesen bildet, aber wenn man nur auf dem einen Feld ist, wäre es glatte Zeitverschwendung
Das ist quasi wie mit der Post. Andere Anbieter reihen sich da ja momentan mit ein. Wer weiß, wo es hinführt. Nur noch Hack am Ende der Leitung.
auf jeden....wenn die Dinger richtig heiß werden, haste Fehler ohne Ende auf der Leitung. Ich baue die immer mit 1 HE Abstand ein. Das hilft ungemein. Ich lass mir aber auch sämtliche Temperaturwerte aufs Smartphone senden, damit ich pünktlich mit dem Feuerlöscher zu gegen bin. Deshalb finde ich diese Racks mit Löschanlage 'ne richtig gute Investition.
Hast du schon mal ein größeres RZ gesehen? "Der" Core Switch ist beim kleinen Mittelständler mit einem Serverraum.Uplink? Auf dem Core Switch?. Ách den Uplink zum Admin
In der Regel hast du Uplinks bei kleineren Kunden zu anderen Serverräumen und bei den größeren gehen die Uplinks zu den anderen Rackreihen.
Da wir da in der Regel, im Uplink, nicht mehr als 200-400 GBit haben, kann das schon manchmal Eng werden auf der Leitung.
Zu deinem letzten Post, wenn du immer eine HE frei lässt bei den Switches, arbeitest du auch nicht mit Kalt und Warmgängen. Bei vernünftiger Hardware hast du kein Kühlungsproblem, auch wenn die 100G QSFPs schon ne Menge Wärme erzeugen.
Das sind ja auch Spielerein. Die nutzen wir schon lange nicht mehr. Da ist die Latenz auch viel zu hoch. Wir setzen moderne gebündelte Supraleiter ein. Die bieten auch ne viel höhere Bandbreite. Wenn man Geld hat, baut man redundante Infrastrukturen auf. Dann brauchste auch kein Uplink.
Naja, jetzt fängste an zu spekulieren. Verzettelst du dich da nicht ein wenig.
Naja, man muss sich überlegen, wo man Geld ausgibt. Hightech Switche sind ja unbezahlbar. Wir nehmen lieber KMU-Geräte und pimpen die mit besseren Lüftern und Kühlungspaste. Wenn man sich ein bißchen auskennt, kann man die gut overclocken. Da bekommt man dann bis zu 50 % mehr Durchsatz. Da is mir die Garantie auch egal bei dem Preis/Leistungsverhältnis.
Also Supraleiter hast du bestimmt nicht, wo willst du denn die Kühlung dafür hernehmen? Selbst große RZ arbeiten ganz normal mit Single Mode Glasfaser und da ist derzeit bei 800GBit und 1600GBit (mit Nokia) das Ende der Fahnenstange. Das ist aber noch unbezahlbar.
P.S. lese dich mal in Spine Leaf Architektur ein. Sowas sieht man bei jedem großen Kunden.
Liegt halt nahe, ich mach das schon seit 25 Jahren.
Sowas klingt wieder nach Kleinkrauter (ich weiß, reine Spekulation).
Vernünftige Switches müssen ja nicht so teuer wie Cisco oder HPE sein. Mein Lieblingsswitch für KMU mit 8x100G und 48x25G kostet gerade mal 6k€.
Wenn du einen Switch overclocken willst, kannst du gern bei der CPU machen, aber das interessiert den Switchingchip nicht. Außerdem sind die Switchchips alle so ausgelegt, dass du auf allen Ports Linespeed fahren kannst. Nur beim Routing ist halt irgendwann Ende mit der CPU.
FS Switche sind schon unschlagbar in Preis und Leistung. Zu Beginn dachte ich, die sind eher auf datacenter spezialisiert, aber die bieten ja auch unglaublich günstige Access-Switche an. Sehr geil. Da wird bestimmt irgendwann ein investor kommen und die aufkaufen und dann die Preise Richtung DELL, LEnovo und Co anpassen. Danke nochmal für die Erwähnung von NVME-oF. Das kann man gut in ein individuell konzipiertes Storage integrieren.
NVMEoF ist die Zukunft, nur Microsoft kann das noch nicht.
Naja beim iSCSI Initiator hat sich Microsoft damals auch viel Zeit gelassen. Über welches Protokoll, ist wie immer Geschmackssache, RoCE funktioniert gut wenn du deine Infrastruktur im Griff hast und dann hast du die best-mögliche Performance.