[Sammelthread] ZFS Stammtisch

Eine Frage hätte ich noch.
Was ist den mit sehr guten Enterprise NVMe SSDs vorausgesetzt bei einem ZFS-Mirror oder Stripe realistisch als maximale Schreib und Lese-Performance für MB/s und IOPs bei sequenziell bzw. random 4k?
Nur, dass ich ein Gefühl für meine Werte bekommen kann! ;)

So ist die Performance meines aktuellen Mirrors:
mb_sync.JPG
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Solange ZFS an sich überlebt ist alles gut.

Genau darum gehts ja.
Auch ZFS kann durch Probleme beschädigt werden, die außerhalb seiner Kontrolle liegen wie RAM Fehler ohne ECC oder fehlende PLP bei SSD.

Dateisysteme ohne Copy on Write und Prüfsummen sind durch Abstürze beim Schreiben generell gefärdeter. Man kann zwar argumentieren dass es meist gut geht. Im Fall der Fälle gibt es aber mangels Prüfsummen auf Daten/Metadaten keine Möglichkeit festzustellen ob z. B. ext4 oder ntfs Fehler haben. Ein fschk oder chkdsk prüft nur die Stimmigkeit der Metadaten. Ein Journal kann helfen aber nur wenn die letzten bestätigten Schreibvorgänge auf Platte sind. Eine "Reparatur" kann strukturelle Metadatenfehler beseitigen oder "Daten Rührei" hervorrufen. Reparaturen im Datenbereich ist da generell nicht möglich da derartige Fehler nicht erkannt werden können.

Daten-Rührei hatte ich schonmal bei meinem Mailserver bevor ich von ntfs zu ZFS gewechselt habe.
Beitrag automatisch zusammengeführt:

Eine Frage hätte ich noch.
Was ist den mit sehr guten Enterprise NVMe SSDs vorausgesetzt bei einem ZFS-Mirror oder Stripe realistisch als maximale Schreib und Lese-Performance für MB/s und IOPs bei sequenziell bzw. random 4k?
Nur, dass ich ein Gefühl für meine Werte bekommen kann! ;)

Ich habe mal ein paar Performancetest gemacht

Man muß aber immer unterscheiden
- reine Poolperformance
- was geht übers Netz
- was kosten Sharing Dienste wie FC/iSCSI, NFS oder SMB
 
Ich habe mal ein paar Performancetest gemacht
Wow, die Werte bei dir sind ja der Hammer! :)
Da sind meine Werte bei den sync-writes mit nur um die 50 MB/s eine echte "Katastrophe". Selbs, wenn hier NFS-Sharing noch ein wenig Performance kostet. - Wobei sich die VMs gar nicht so langsam anfühlen.
Übrigens hat eine Veränderung der Record-Size die Performance wie von dir schon vorhergesagt eher verschlechtert oder wenn nur in kleinen Teilbereichen minimal verbessert. Ich werde hier bei 128 KiB bleiben!

Hätte ggf. jemand Empfehlungen für M2.PCIe SSDs (Formfaktor 2280) die wesentlich besser mit sync-writes umgehen können?
 
Hätte ggf. jemand Empfehlungen für M2.PCIe SSDs (Formfaktor 2280) die wesentlich besser mit sync-writes umgehen können?
Intel Optane, z.B. Intel Optane SSD P1600X oder 4801X (oder 90x allerdings ohne garantierte PLP)
Sind bis auf DRAM basierte Laufwerke absolut die schnellsten,

ps.
Man kann auch PCIe oder U.2 NVMe nehmen. Da ist die Auswahl größer.
Man kann die per PCIe oder M.2->U.2 Kabel anschließen.
 
Man kann die per PCIe oder M.2->U.2 Kabel anschließen.
Danke für den Hinweis. Das wäre dann die einzige Möglichkeit bei mir.
PCIe ist leider alles bereits voll.

Gibt es aus euerer Erfahrung raus ggf. noch besonders gute Consumer SSDs für M2280 die schnell sind bei sync-writes und "nur" keine PLP haben?
Ich könnte dafür den SSD Pool regelmäßig per Replication auf einen anderen Z-Pool klonen, falls mal ein Fehler wegen Stromausfall auftritt!
 
Gibt es aus euerer Erfahrung raus ggf. noch besonders gute Consumer SSDs für M2280 die schnell sind bei sync-writes und "nur" keine PLP haben?
Das schließt sich mE aus.

1. Ein sync write wartet auf Bestätigung der SSD/HDD, dass er "on disk" geschrieben wurde.
2. Die SSD kann einen sync write nur bestätigen, wenn dieser (a) auf den flash geschrieben wurde (langsam) oder (b) sofort, wenn er im PLP-gesicherten RAM-cache liegt.
3. Ohne PLP also keine schnelle Bestätigung und damit keine schnellen sync-writes.
 
Also ich fand die "Kingston DC1500M Data Center Series Mixed-Use SSD - 960GB, U.2" eigentlich recht gut, sind allerdings doch etwas teurer...
(In dem Thread gibt es dann auch Infos zum Thema Adaption von U2 auf M2)
 
Das schließt sich mE aus.

1. Ein sync write wartet auf Bestätigung der SSD/HDD, dass er "on disk" geschrieben wurde.
2. Die SSD kann einen sync write nur bestätigen, wenn dieser (a) auf den flash geschrieben wurde (langsam) oder (b) sofort, wenn er im PLP-gesicherten RAM-cache liegt.
3. Ohne PLP also keine schnelle Bestätigung und damit keine schnellen sync-writes.
OK, das was du hier schreibst klingt für mich absolut plausibel.
Danke für die Aufklärung.

Somit scheint es aber glücklicherweise wohl so, dass billige SSDs wenigstens wirklich im sync-Modus arbeiten, wenn es gefordert ist und nicht noch einen Haufen Daten in einem flüchtigen Speicher sammeln!
 
Also ich fand die "Kingston DC1500M Data Center Series Mixed-Use SSD - 960GB, U.2" eigentlich recht gut, sind allerdings doch etwas teurer...
Nein wirklich billig sind die leider nicht mehr, aber was ich aktuell habe ist aus Performance Sicht auch eine "Kathastrophe".

Wenn ich nur eine SSD 1TB in einem ZFS-Strip anstatt eines ZFS-Mirrors verwende und den Pool per Replikation auf einen Z2-Pool täglich sicherer, dann hätte ich doch bis auf die automatische bit-rot Erkennung weiterhin alle ZFS-Vorteile und könnte eine SSD einsparen?
Oder wäre es besser auf zwei 512 GB SSDs in einem Stripe zu setzten und diesen dann per Replikation zu spiegeln? - Dann hätte ich auch die automatische bit-rot Korrektor?
 
Bit-Rot sollte ZFS ja weiterhin erkennen. Du hast ja weiterhin die Prüfsummen.

Wenn ich das Richtig gesehen habe:

1 Disks --> Fehler Erkennung
2 Disks ---> Fehler Korrektur (Mirror) Fehler Erkennung (mirror degraded)
3 Disks ---> Fehler Korrektur (Raid Z1) Fehler Erkennung (Raid Z1 degraded)
4 Disks ---> Fehler Korrektur (Raid Z2) Fehler Korrektur (RAID Z2 degraded -1 disk) Fehler Erkennung (RAID Z2 degraded -2 disks)

Solltest du natürlich bei RAID Z1 / Z2 Kleine Dateien dabei haben, dann kann es weiterhin sein, dass die Korrektur auch für diese Funktioniert.
 
1 Disks --> Fehler Erkennung
2 Disks ---> Fehler Korrektur (Mirror) Fehler Erkennung (mirror degraded)
Danke für die Aufklärung. Das heißt bei einer Disk ist dann eigentlich nur der Nachteil, dass ich die fehlerhafte Datei manuell tauschen muss.

Trifft die Aussage von dir für 2 Disks nur für den Mirror oder auch für den Stripe zu, was die Fehler Korrektur betrifft? - Klar ist, wenn eine Disk ausfällt, dann ist der ganze Pool weg!
 
Du brauchst ja Parität + Daten um den Fehler zu korrigieren.
Du hast z.b. bei einem Z1:
Block 1 Block 2 Parität
Prüfsumme Block 1 defekt --> du kannst aus Block 2 und Parität den Block 1 berechnen.

bei einem Mirror:
Block 1 Block 2
Block 1 Prüfsumme falsch ---> Block 2 sind die richtigen Daten

bei einem Stripe kannst du auch nur erkennen ....
leider hilft in einem solchen Fall auch kein Snapshot. ...
natürlich kannst du auch Copys = 2 fahren ...
 
Checksums - also bit rot Erkennung - hast Du auf jedem ZFS System.

Automatische Korrektur)Reparatur von Bit rot benötigt Redundanz, also mirror- oder RAIDZ-vdevs.

Wieviele vdevs Du nun in einem zpool "Stripe"st, hat darauf keinen Einfluss. Ein vdev weg = Pool weg.
 
bei einem Stripe kannst du auch nur erkennen ....
leider hilft in einem solchen Fall auch kein Snapshot. ...
natürlich kannst du auch Copys = 2 fahren ...
Das heißt auf den Snapshot vor dem Fehler zurückzuspringen wäre nicht möglich?
Dann muss ich wohl mindestens zwei Laufwerke kaufen. Danke für die Aufklärung und das Bewahren vor dem nächsten Fehler! :)
 
Das heißt auf den Snapshot vor dem Fehler zurückzuspringen wäre nicht möglich?
Nein, das ist grds. nicht möglich.

Der snapshot ist ja gerade keine Kopie.

Wenn der relevante Teil der Datei lange unverändert war, dann beziehen sich alle snapshots ja auf die gleichen Bits auf der Platte. Wenn so ein Bit kippt, "kippen" alle snapshots mit.

Wenn Du natürlich häufig Änderungen machst, dann hast Du aufgrund COW viele Dateiversionen gespeichert und dann kann ein älterer snapshot schon helfen.
 
Zuletzt bearbeitet:
Ich bin gerade am Konzept für meinen Backup Server und nehme nur Teile, die ich schon hier habe. Daraus ergibt sich, dass ich 6x 14TB und 4x 12TB HDDs verwenden werde.
Ein Z2 über alle 10 Platten ist am effizientesten trotz des Verlustes von 6x 2TB "Überhang". Kann ich über diese Restkapazität noch ein Z2 legen?
Wenn ihr einen ganz anderen Vorschlag habt, gerne raus damit.

1650208519568.png
 
Zuletzt bearbeitet:
Was dagegen spricht: KISS, Keep it simple, stupid. Wenns mal Probleme gibt hat man Stress und dann ist es nicht gut wenn man Spezialfälle beachten muss. ZFS Raid finde ich zwar um Größenordnungen übersichtlicher als manche Hardwareraid die ich schon hatte. Wenn dann aber mal mehrere Platten spordisch ausfallen muss man auch bei ZFS dreimal hinschauen um zu sehen was los ist. Wegen der extra 8 TB würde ich mir den Stress nicht geben. Wenns wichtig ist dann eher eine weitere Platte kaufen.

Wenns aber sein soll, dann die 14TB Platten partitionieren (12+2). Dann kann man auf den 2TB einen weiteren Pool aufsetzen.
 
Zuletzt bearbeitet:
Moin, ich mal wieder.

Ich hab aktuell das Phänomen, dass Solaris (11.4) beim Booten reproduzierbar abschmiert, wenn ich mehr als eine NVME per passthrough in die Solaris-VM (Esxi 7) durchreiche. Nehme ich eine von zweien, klappt's, und zwar mit beiden (egal welche, solange halt einzeln). Es handelt sich um 2x um die gleiche SSD (Samsung PM9A1). Komischerweise erkennt Solaris die durchaus unterschiedlich, einmal als c15t1d0, einmal als c14t1d0 (nur halt dummerweise nicht gleichzeitig).

Hat jemand eine Idee? Kann ich evtl. Solaris irgendwie dazu zwingen, auch bei den NVMEs die Disks über die Seriennummer / WWN zu identifizieren?

Randnotiz: lustigerweise wirft nvmeadm einen Error, dass die Platform nicht supported sei...
 
bin etwas weiter: scheint entweder an den spezifischen SSDs oder am Steckplatz zu liegen. Habe aktuell 4 980 Pro per passthrough durchgereicht. Auch 4 ADATA NVME gingen. Die steckten dann alle über solche Hyper-Karten in echten PCIEslots (der CPU) und nicht in m.2 Slots des Mainboards (wobei die angeblich laut Blockdiagramm auch an der CPU hängen).

Aktuell ärgere ich mich mal wieder mit dem 9305-24i (SAS3224) herum: der erzeugt im Passthrough laut iostat kontinuierlich soft-errors gleichmäßig über sämtliche an ihn angeschlossenen (SATA) SSDs... ich habe keinen Schimmer, wieso. Werde ggf. nachher nochmal mit dem Onboard HBA 3008 gegentesten. Schon sehr sonderbar:

iostat_errors.jpg


EDIT: habe mich daran erinnert, dass schon früher mal der Aufruf der smartmontools den Counter erhöht hatte. Bin auf den Eintrag von @gea hier gestoßen und versuche aktuell mal mein Glück mit acc --> smart "disabled"

EDIT2: die oben im EDIT genannte Einstellung hat geholfen. Nach einem Reboot der VM war der Counter 0 und bleibt da auch.
 
Zuletzt bearbeitet:
NVMe Passthrough vor allem mit mehreren NVMe ist häufig ein Problem, entweder mit der aktuellen Umgebung oder plötzlich nach einem ESXi oder OS Update. Für "Produktivumgebungen" nicht zu empfehlen. Ist auch nicht nur bei Solaris der Fall.

Workaround:
- Eine NVMe geht meist, teilweise nach Anpassung der passthrough.map
- Wenn es vor allem um Slog geht, ist es meist zuverlässiger ein ESXi datastore auf der NVMe anzulegen und darauf eine vdisk als Slog.
- Wenn man Performance und Kapazität braucht, ist SAS 12G (oder neu 24G) fast so schnell wie NVMe vor allem mit Multipath io und 2x12/24G, aber um Welten problemfreier. Die richtig schnellen SAS SSD (WD SS530/SS540 oder Seagate Nytro) sind aber derzeit kaum zu bekommen.

vgl https://www.servethehome.com/what-i...ata-center-kioxia-seagate-broadcom-microchip/
 
Ich bin mal gespannt: aktuell gehts mit den 4 Samsung, die 4 ADATA allein gingen auch. Der Test mit allen 8 gleichzeitig steht allerdings noch aus. Wenn das geht, würde ich darauf wetten dass die 2 aktuell in den beiden m.2 Slots auch funktionieren, wenn man sie über einen Adapter in einen PCIE-Slot steckt.

Geht zwar aus dem Blockdiagramm vom Mainboard für mich nicht eindeutig hervor, aber vermutlich ist die Verdrahtung/Beschaltung da geringfügig anders, was die VM dann aus dem Tritt bringt. Mit dem anderen Brett war es allerdings wirklich OS-abhängig. Solaris mit exakt identischen Settings bootete nicht, TrueNAS (Core) dagegen problemlos (auch im weiteren Betrieb).
 
Hi

Beim Kumpel steht ein ESXi AiO mit napp-it. napp-it und der Host befinden sich im management Netz/VLAN. Ans napp-it ist ein LSI 2008 durchgereicht, dort dran hängen eine SM883 sowie 2 WD Gold. Ausserdem ist beiden WD Gold je ein SLOG angehängt, welche als vmdk direkt auf dem Storage des ESXi liegen. Auf einer NVMe Optane 800P.

Auf den WD Gold hat es je ein "Haupt-" ZFS Filesystem. Da drauf habe ich ein weiteres ZFS Filesystem eingeschachtelt, wo ich per SMB aus einem anderen VLAN (DMZ) zugreife. Etwas unglücklich, von der DMZ ins Storage zu beregeln, ich weiss. Lässt sich aber nicht anders lösen für den Moment.

Nun habe ich das Problem, wenn ich da von der DMZ auf den SMB Share etwas kopiere, ist das schnarchlangsam. Weiss nicht liegt es an der FW oder an dem Storage. Aber wenn ich da per SMB kopiere, müsste das von der SM883 auf die Optane doch pfeilschnell gehen, irre ich mich da? Es geht um einige minecraft Verzeichnisse, das kopiert da gerade mal mit 8-10 MByte/s.

Firewall ist eine Zywall USG 200, da dran hängt ein 10 Gbit Switch. Die DMZ und das management Netz sind aber nur per 1 Gbit/s verbunden. Die Firewall sollte so um die 1.5 GBit/s Durchsatz machen, wenn ich das richtig in Erinnerung habe. Kein IDS/Snort oder sowas aktiv, das Chischtli macht nur das Routing.

Gruss und danke
 
Wenn Du vom DMZ in ein anderes Netz gehst, werden die Netze wohl per VLAN getrennt. Dann läuft der Verkehr ja durch Deinen Layer 3 router - typischerweise die Firewall, wenn Du nicht einen L3 fähigen switch oder eine routing VM zwischenschaltest.

Dort würde ich das performance bottleneck vermuten. Wobei die Geschwindigkeit doch sehr grottig ist.

Andere Möglichkeit: viele kleine Files = langsam, da viel Overhead und die Dateien sequentiell übertragen werden. Daran kannst Du nicht viel ändern.

Teste Mal einen "großen" Dateitransfer / iperf.
 
Hi

Das Management Netz ist ein VLAN und über den Switch angebunden. Die DMZ ist ein normales Gateway, das hängt direkt am Server von der FW aus. Die USG 200 routet das.

Werde mal eine 4GB ISO oder so kopieren, wenn ich wieder Zugriff auf das System habe.

Es sind kleine Files, ja. Aber die müssten gelesen von einer SM 883 schreibend auf eine Optane ja zügig durch gehen. Ich vermute da ein Problem mit dem SLOG. Wenn ich intern auf dem napp-it kopiere, ist es super schnell. Schneller als von der SM 883 gelessen werden kann. Da wird der RAM noch mit rein spielen.
 
Kleine Files über Netzwerk = langsam.

Bottleneck ist da (1) der storage (hier nicht) aber auch (2) die Netzwerk Übertragung (hier vermutlich mit schuld).

Du kopierst ja nicht von A nach B, sondern liest von A, schickst es an den Router, der schickt es weiter und dann wird auf B geschrieben.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh