ZFS - Probleme mit Lese-Performance

[tcg]

Hi,

ich habe ein Problem zu verstehen was mit meinem NAS los ist.
Im Prinzip ist das was ich zusammen gebaut habe genau das was ich eigentlich will...
HW: HP Microserver G8 mit E3-1240-v2 und 16GB RAM, 970-EVO(NVMe), 4*HD204UI(AHCI) (bewusst kein HW Raid Controller !)

Ich hab das hier mal beschrieben: https://www.hardwareluxx.de/community/f101/hp-proliant-g8-g1610t-g2020t-i3-3240-e3-1220lv2-microserver-963207-523.html#post26404426

Konfiguration:
16 GB USB Stick: ESXi 6.7 (non HP iso)
250 GB 970-EVO (NVMe): 3 virtuelle Platten für ESXi: 8GB FreeNAS-boot, 64GB ZIL, 64GB L2ARC
4*2 TB HD204UI (AHCI): zusammen mit dem Controller an FreeNAS durchrereicht, Z1 pool (dann mit je 64GB ZIL und ARC auf NVMe)
Die FreeNAS VM hat: 4 Cores, 10GB RAM, 4*reale 2TB-HD im Z1 und 2*virtuelle 64GB-HD

Der ESXi Server bootet vom USB Stick, hat ein ZFS basiertes FreeNAS "obendrauf" (auf dem NVMe Datastore) der dann den Haupt-Datastore per NFS breitstellt.
Also ein NAS mit Bit-Rot-Protection (ZFS), transparentem Cache (ZIL&L2ARC auf NVMe), Compression (LZ4), dedup (ZFS), keine Boot-Order Probleme (ESXi), viel Platz für weitere VMs, also einfach richtig gut !
Ein Problem ist noch: da alle VMs (bis auf FreeNAS) auf dem NFS-Datastore liegen, kann ich die nicht als Autostart markieren, ich muss die per Hand starten...

Tests mit einer Windows-VM direkt auf der NVMe HW zeigen dass diese wirklich sauschnell ist !!
In der VM zeigt Crystal-Disk-Mark hier 3.3GB/s lesen, 1.5GB/s schreiben, das erwarte ich dann auch für ZIL und L2ARC.

Zu meinem Problem:
direkt nach der Installation der VM auf dem NFS Pool hat Crystal-Disk-Mark gesagt: Lesen=1200MB/s, Schreiben=200MB/s (auch nach reboots)
Am nächsten Tag (nach Reboot) auf einmal nur noch Lesen=40MB/s, Schreiben bleibt immer gleich.
Auch nach vielen Reboots, Konfig-Changes, mit ZFS-Cache und ohne, ...
Dann, nach vielem Spielen, auf einmal Lesen=400MB/s, Schreiben bleibt immer noch ungefähr gleich.
Ich kapier nicht was da schief gelaufen ist, ich verstehe den ZFS-ZIL-ZIP-ZAP-ZUP Kremprel irgendwie nicht.
Alles läuft Rock-Stable, nur das Lesen bricht irgendwie ein... Momentan stabil bei ~400MB/s, aber keine Ahnung wie lange.
Also ob da was parallel läuft und rein grätscht, aber Scrub und Dedup sollten nicht den ganzen Tag aktiv sein, das Z1 ist fast nicht voll (<<5% momentan)

Was könnte ich denn bei so einem System erwarten ? 400MB und 200MB sind erst mal ok für mich...
Was könnte ich denn Testen ?
Was könnte ich denn neu Konfigurieren ?

 

[Trambahner]

NIEMALS dedup verwenden. Unter keinen Umständen, das frisst RAM und jede Menge Performance und erhältst fast keinen Gegenwert.
BTW, einfach abschalten ist nicht, einmal an bleiben Immer Reste. Du darfst da den Pool neu aufsetzen.
Als Slog brauchst Du ein Device, das permanente Writes erträgt, wenn Sync nicht ausgeschaltet und NFS. Die kleine 970 wird da schnell im Sättigungsmodus sein und ggf. auch schnell hin sein. Erst recht Wenn du da Virtual Disks draus machst und in die VM gibst.
Slog: Go for Optane 900P oder Datacenter-SSD (letztere direkt/passthrough in der VM).

 

[tcg]

Mist, hab eben den Server neu gestartet um zu schauen wie schnell er heute ist...
Jetzt ist der NFS Pool in ESXi verschwunden ?!? FreeNAS läuft, NFS ist exportiert, nur ESXi sieht das auf einmal nicht mehr ?!?
ich nehme das "Rock Stable" zurück !
nochmal rebootet: NFS ist echt weg ?!?
und nochmal: wieder da ?!?!?

- - - Updated - - -

NIEMALS dedup verwenden

Ich habe gesehen dass die Kompression mit LZ4 schon recht viel bringt... Dann werde ich dedup mal abschalten bzw den Datapool in FreeNAS neu aufsetzen.
thx...

edit:
wobei ich 4 Xeon Kerne und 10GB zugewiesen habe, das sollte reichen. Schade... Aber nicht so wichtig, ist noch ein Bastelsystem...
Das mit "970 schnell kaputt" muss ich nochmal überdenken...

 

[Trambahner]

Mehr als 2 Kerne brauchst Du da nicht zuweisen. Wichtig ist, dass VMs immer bedarfsgerecht mit Ressourcen versorgt wird, ansonsten erzeugt man nur unnötig Overhead da der ESXI-Scheduler sinnlos CPU-Cycles verwalten und verteilen muss. Selbst wenn die Leistung innerhalb der VM brach liegt. Überversorgung blockiert unnötig Leistung.
Dein Ram ist recht knapp, 10GB bei FreeNAS 11 ist eher schon wenig, da dieses selbst schon einiges verschlingen kann. Evtl. Xigmanas (ehemals Nas4free) anschauen, das ist genügsamer. Somit hast Du mehr frei für den ARC (=Cache von ZFS).

L2ARC nur 5-10* des für den ARC verfügbaren Rams setzen. Jeder L2ARC-Block braucht im Ram Platz für die Verwaltung. Bei so knappen Speicher für ZFS belegst Du damit noch viel für den L2ARC. L2ARC musst Du eh austesten, ob und wieviel der bei Deinem Nutzungsprofil bringt.

ZIL/SLOG: Wichtig! Das ist kein Schreibcache im klassischen Sinne, sondern ein Speicherplatz auf den synchron angefordertes Schreiben sofort ausgeführt wird und auch erst nach Erfolg als erfolgt zurückgemeldet wird. Auf den eigentlichen Speicherplatz werden die Daten dann asynchron später geschrieben. Im Falle eines Systemausfalls kann damit aus dem Slog rekonstruiert werden, was von den synchronen Anforderungen commited war und auf die Platten "nachgeschrieben" werden muss. Sprich, für asynchrone Anforderungen bringt es gar nichts. SMB/CIFS (also Windows-Freigaben) sind typischerweise asynchron, NFS sind in aller Regel Synchron-Anforderungen. Kann man am Pool overriden, in dem man den Sync-Eigenschaft des Pools von "Standard" auf "disabled" oder "always" setzt.
Da bei NFS und Sync=Standard alle I/Os von ESXI-Datastores, die per NFS dran hängen, als synchron behandelt werden, macht ein extra ZIL/SLOG-Device durchaus Sinn. Sonst wirds beim Schreiben ganz schnell ganz langsam. Aber! Da eben alles von den ESXI-NFS-Datastores "draufdonnert", müssen solche Devices ggf. sehr viel permantes Schreibvolumen aushalten. Consumer-SSDs und erst recht welche mit TLC-Flash (mit ihrem begrenztem SLC-artigen Puffer) wie die EVOs sind da in aller Regel ungeeignet. Auch 850pro haben manche User hier schon performancetechnisch schnell in die Knie gezwungen! Ferner muss die Reaktionszeit der SSDs konstant sehr kurz sein, sonst gehts schnell nach unten mit der Performance.
Consumer-SSDs schauen oft toll aus in ihren Datenblättern und Benchmarks, nur sind diese Werte nur für kurze Zeit verfügabar. Daher sind Datacenter-SSDs und erst Recht die (gscheiten) Intel-Optanes (900p/905p/P4800X) gefragt. Eine 970 Evo, nochdazu in der kleinsten Größe und dem kleinsten Pseudo-SLC-Puffer, kann da ggf. nicht lange standhalten.
=> Es kommt halt immer drauf an, wie viel man Schreibaufkommen von den VMs auf die NFS-Datastores hat.

Btw, ESXI braucht manchmal etwas, bis es nach nem Boot den NFS-Datastore gemounted hat.

Die HD204UI: Ganz schlechte Wahl für reale Daten. Sehr alt, wahre Methusalems schon. Nicht dauerlauffähig wenn Du 24/7 haben willst und ihre konzipierte Einsatzzeit ist schon lange überschritten. Damit steigende Gefahr für Ausfälle. Nur fürs Rumspielen/Lernen einsetzen, keine echten Daten mehr drauf bitte.

 

[Holt]

Die HD204UI dürfte schon über die 5 Jahre Nutzungsdauer hinaus sein die Samsung damals dafür geplant hatte und außerdem haben die ggf. einen FW Bug der zu Datenkorruption führen kann.

 

[gea]

War das nicht einer der unsäglichen 4k Platten der ersten Stunde die sich mit physical sectorsize=512B meldeten (und damit über ihren Aufbau logen)?

Die wollten dann unbedingt in ZFS fälschlicherweise ein vdev mir ashift=9 (512B) haben, außer man erzwingt ein vdev mit ashift=12 (4k). Nur in letzterem Fall läuft die mit voller Performance (naja für damalige Verhältnisse)

 

[Morpheus2200]

Ich würde dir raten mit so wenig Ram auf dedup zu verzichten. Evtl. bei dem Setup auch auf L2Arc.
L2Arc und Zil auf das gleiche (consumer) device zu legen halte ich für keine gute Idee.
Wenn du noch Platz für ein weiteres NVME device hast würde ich evtl. eine von den kleinen Optane 16/32/58/118 GB als ZIL verwenden. Dann kannst du die andere SSD weiter als L2Arc verwenden.
64GB ZIL ist oversized für dein Setup.

 

[tcg]

Danke für die vielen Infos !

Ja, die HD204ui ist echt etwas älter ;-)
Da hatte ich mal ein NAS am Laufen mit 9 davon (4 im NAS, 5 per eSata), da sind auch schon ein paar gestorben, 5 sind noch da zum Basteln und Testen.

Die 970 war halt günstig und ist an sich super schnell... Das ist ne ESXi-VM auf der 970:

Schade, will ich aber nicht riskieren...
Dann kommt die Windows VM halt wieder da drauf.

Ich habe mal weiter gespielt.
Wenn ich nun log&cache abschalte (ZFS ist schon echt nett, einfach per ssh ein "zpool remove data cache" und die laufende VM merkt nix davon) bricht alle Performance komplett ein:


Irgendwie bin ich überfordert (leider halt auch zeitlich) mich da tiefer mit zu beschäftigen.
Auch meine Versuche mit Storage-Spaces (und SSD Cache) habe ich inzwischen abgebrochen, auch zu komplex ums mal nebenher zu machen.
Ich glaube ich bleibe erstmal bei meinem alten Ansatz/NAS: mit P420+SmartCache -> super trivial, super schnell, halt leider kein ZFS...
Da ich bei meinen alten Videos tatsächlich immer mehr Bitkipper (wie ich vermute) sehe würde ich gerne irgendwas mit Bit-Rot Erkennung haben.

 

[gea]

Ist doch ganz einfach

ESXi über NFS wünscht syncrones, sicheres Schreiben (ohne Schreibcache). Macht ja auch Sinn damit bei einem Stromausfall der Inhalt des Schreibcaches nicht verloren geht. Syncrones Schreiben ist allerdings nicht nur sicher sondern leider auch langsam. Hat zunächst nichts mit ZFS zu tun. Für das Dilemma gibt es nun zwei Auswege. Entweder man möchte weiterhin sicheres aber schnelles asyncrones Schreiben mit Schreibcache (ist bei ZFS im RAM). Dann muss man aber den Inhalt des Schreibcaches sichern. Dazu kann man entweder einen Hardware-Raidcontroller mit Cache und Batterie/Flashsicherung nutzen oder im Falle von ZFS stattdessen den Schreibcache mittels eines Slog (schneller SSD, idealerweise Intel Optane) sichern.

Oder aber man verzichtet auf diese Extra-Sicherung. Im Falle von ZFS setzt man einfach sync=disable für das mit NFS freigegebene Dateisystem. Damit erhält man maximale NFS Schreib-Performance.


Wichtig:
Ein normaler Controller mit SSD Schtreibcache kann zwar Schreiben beschleunigen (ist meist aber langsamer als ZFS Ram Schreib/Lesecache), bietet aber keine Absicherung des Schreibcaches bei Stromausfall. Ist also nichts gewonnen, ganz im Gegenteil. Im Falle eines Crashes ist das VM Dateiesystem im Zweifel kaputt. Von ZFS Extras wie Absicherung gegen Datenkorruption oder Vermeiden des Raid Write-Hole-Problems mal ganz zu schweigen. Die gibts halt nur mit ZFS.

Das betrifft die Schreibperformance. Für die Leseperformance ist vor allem RAM entscheidend (als Lesecache) sowie die Raid-Konfiguration. Da ist ein Multi-Raid-10 das beste und viel schneller als ein Raid Z. Für ein AiO System würde ich aber eh immer einen Pool ais SSDs (z.B. Mirror, mit guten SSDs ohne Slog) und einen zweiten Pool aus Platten (Raid-Z) für Filer und Backup machen.

Ansonsten
dedup ist fast immer ein NoGo (eventuell mal Oracle Solaris mit dedup2 außen vor)
10GB RAM ist mit FreeNAS echt knapp. Wenn man bei Free-BSD bleiben möchte eher den Nas4Free Nachfolger XigmaNAS oder ein Solarish nehmen. Da kommt ZFS (und NFS) her und die sind etwas genügsamer und haben die bessere Integration von ZFS in OS und Sharing Dienste wie iSCSI, NFS und SMB.

 

[Bccc1]

Die anderen haben ja schon geschrieben das dein ZIL unnötig groß ist, aber es fehlt noch die Info was angemessen wäre:
Bei FreeNAS wird der ZIL alle 5s geleert. D.h. das ZIL muss nicht größer sein, als in 5s Daten darauf landen können. Normalerweise würde man jetzt von der Netzwerkgeschwindigkeit ausgehend rechnen, bei 1 x 10 GBit/s müsste das ZIL 6,25GiB groß sein. Da bei dir der Zugriff über das ESXi Netzwerk läuft, ist da ja keine Limitierung auf NIC Geschwindigkeiten drauf, also gehen wir mal von der NVMe Schreibgeschwindigkeit aus. Laut deinem Bench sind das 1540 MiB/s. In 5s kommen so 7700 MiB zusammen. Bei realistischer Last eher viel weniger. Selbst wenn du da jetzt noch ein Puffer draufpackst, macht mehr als 10 GiB meiner Meinung nach kein Sinn.

 

[gea]

Das beste Slog vor den Intel Optane war ein ZeusRam. Das ist Dram basiert und hat 8GB. Viel mehr ist auch nicht nötig. Aktuell ist eine Intel Optane ab 800P das Maß der Dinge.

btw
Oracle Solaris und OpenSolaris haben einen 5s Schreibcache Puffer. Delphix hat das für Illumos und OpenZFS auf einen dynamischen Puffer geändert bei dem nicht die Zeit sondern der Speicher festgelegt wird (default 10% RAM, max 4GB)

Tuning the OpenZFS write throttle | Delphix

 

[Holt]

gea, was ist an den Platten mit physikalischen 4k Sektoren und 512 Byte Emulation (512E) unsäglichen? Außer ein paar 4kn Platten sind fast alle HDDs heutzutage so und die lügen auch nicht über ihren Aufbau, sondern geben sehr wohl auch die physikalischen Sektorgröße korrekt mit 4k und die logische Sektorgröße mit 512 Byte an. Dies ist auch kein Problem, auch nicht bei der Performance solange das Alignment stimmt und wenn nicht, denn leidet vor allem die Schreib- aber nicht die Leseperformance darunter und dies auch nur bei kurzen zufälligen Zugriffen. Hier ist aber vor allem die schwache seq. Leseperformance das Problem: "Am nächsten Tag (nach Reboot) auf einmal nur noch Lesen=40MB/s, Schreiben bleibt immer gleich."

 

[gea]

Diese Platten, meist aus 2010/11 waren intern zwar bereits 4k, meldeten sich aber mit physical sectorsize 512B. Es gab damals wohl noch Kompatibilitätsprobleme mit Alt-Windows. ZFS liest diese physical sectorsize aus und erstellt entsprechend sein vdev. Mit diesen Platten dann fälschlicherweise ashift=9 mit deutlichen Performanceeinbrüchen und man kann diese dann auch nicht mit aktuellen 4k Platten ersetzen.

z.B.
WD HDD lying about 4K sectors - excess.org

Aktuelle 4kn oder 512e Platten betrifft das nicht mehr.

 

[Holt]

Die sollten den logical sektorsize mit 512 Byte und den physical sectorsize mit 4096 Byte melden, aber ich habe keine hier um dies zu testen und selbst wenn es falsch ist und daher das Alignment nicht stimmt, so wäre dies bei den 4k Werten zu sehen, vor allem bei 4k schreibend, aber nicht bei seq. lesend. Das Problem warum man die 512e eingeführt hat, ist auch nicht nur Windows sondern auch das BIOS.