Schreiben auf NAS beschleunigen

Ich baue gerade mein TrueNAS mit Scale auf.

Ich blicke aber nicht so richtig durch, wie ich das ganze jetzt aufbauen soll, um die maximale performance rauszuholen (also vom Prinzip her hab ich schon einen Plan, aber der Teufel steckt im Detail).

Verwendet wird das NAS im Heimgebrauch, in einer hauptsächlichen Windows-Umgebung.
Gespeichert darauf werden tägliche Backups von meinem PC (mit 10Gbit angebunden) & Laptop (mit 2,5Gbit angebunden), die NAS wird verwendet werden als Datenspeicher für ISOs, Dokumente, Treiber.
Und es werden mehrere Videos darauf liegen, die ich per Jellyfin zu meinen Geräten streamen werde.

Mit dem raidz-calculator hab ich mal soweit rumprobiert, und mich dazu entschieden, raidz-1 zu bauen, um eine Mischung aus maximaler kapazität, und etwas Sicherheit zu haben.

Jetzt fehlt halt noch die Geschwindigkeit. laut dem calculator hab ich mit dem raidz1 3fache lese aber nur 1fache schreibgeschwindigkeit.
Ich würde aber auch gerne die schreibgeschwindigkeit erhöhen, logischerweise.

Und da kommt der Punkt, wo ich nicht richtig durchblicke.
Es tauchen immer wieder Begriffe, wie synchrone und asynchrone writes, ZIL, LOG und so weiter auf, in den Beiträgen, die ich bisher gelesen habe, aber weiss nicht so recht was ich da jetzt tun soll.

Da ich hauptsächlich Windows nutze, wird SMB wohl der Übertragungsweg übers Netzwerk sein.

Mein/e Plan/Config sieht so aus:

AMD AMD Ryzen 5 5600G
32GB DDR4
10Gbit NIC

1x 128GB SSD für Boot-Pool
3x 1TB SSD in zraid1 für System-Pool → 2TB brutto nutzbar für VMs & Apps
4x 6TB HDD in zraid1 für Daten-Pool → 18TB brutto nutzbar für Videos, Dokumente, Backups

Jetzt ist meine Idee, da noch 2x 512GB SSD im Mirror als LOG zu dem Daten-Pool hinzuzufügen.
Hab hier auch noch 3x256GB SSD rumfliegen, mit denen ich irgendwas anstellen könnte.
So wie ich das verstanden hab, werden die Daten dann erst in dem SSD-LOG geschrieben, und von dort aus dann auf die HDDs.
Da die HDDs mit einer maximalen schreibgeschwindigkeit von 210MB/s angegeben sind, die SSDs aber mit 500MB/s, sollte das ja dann schneller vorangehen (klar sind nur theoretsiche Werte, aber digital vs mechanisch sollte ja auch schneller sein).

Aber hab leider keinen Plan, ob das überhaupt richtig ist, sinnvoll wäre, oder funktionieren wird.

Auch was das mit asynchron und synchronen writes und SMB auf sich hat hab ich nicht so ganz durchgeblickt, ob das dann da auch funktioniert, etc…

Oder wäre eine andere Umsetzung (ZIL, Cache, whatever) zielführender.
Hab hier auch noch 2x256GB SSDs liegen, dich ich für irgendwas verwenden könnte.

Hoffe, es kann mir da jemand weiterhelfen.

Ein stream à 3MB/s? Sollte selbst eine Kartoffel hinkriegen :slight_smile:

Hast du den Unterschied zwischen sync und async writes denn verstanden?
Wenn ja sollte es eigentlich ziemlich klar sein. :smile:

VMs sind zvols. Zvols ist blockstorage. RAIDZ und blockstorage ist schwierig. Nimm ein 2 oder 3 way mirror anstelle von RAIDZ.

Nee. SLOG ist für sync writes, hat spezielle Hardwareanforderungen.

Starte mal ohne SLOG und L2ARC und schau mal, was du überhaupt brauchst. In 99% der Fälle brauchst du nix davon. Dann würde ich zuerst mal auf 64GB RAM upgraden (bestenfalls anderes Mobo mit ECC), 32 sind schon sehr knapp wenn da noch VMs und Apps drauf laufen sollen.

Nur mal so, warum Scale?

Dies entbehrt ja auch nicht einer gewissen Logik, wobei das mit dem 3-fachen Lesen auch ein eher theoretischer Wert ist.

Dann musst Du schnellere Platten nehmen :slightly_smiling_face:

Hier, hier, hier und hier findest Du solide Erklärungen/Handlungsanweisungen und kurz zusammengefasst - slog könnte Dir helfen, wenn aber, dann mit gepufferten SSDs (bei mir erledigen das Intel dc ssds).

Warum, iSCSI ist unter bestimmten Umständen und Anforderungen n.m.E. besser geeignet.

Ja, ok.

iX-Systems stattet alle seine Kaufkisten mit slog aus. An sonst - siehe die Links oben.

ZFS kennt keinen Cache im Sinne des Wortes und L2ARC vergiss bitte gleich.

Ok, werd ich wohl dann ein mirror machen.

Scale ist ja auf Debian basierend, und mit debian kenn ich mich wenigstens minimal aus, im gegensatz zu freebsd.

Zwar hab ich nicht vor ständig im Terminal rumzusitzen, aber es wird wohl auch irgenwann die Zeit kommen, wann man es muss.

Wäre die Core-Version performanter als Scale?

Ja natürlich, es sind immer alles nur theoretische Werte und Angaben, die meist nichts mit der Realität zu tun haben, das ist mir soweit auch schon bewusst.
Nur als Anhalspunkt kann man das ja schon irgendwie verwenden.

Wenn ich die Platten kaufen würde, wäre das vielleicht ein Thema, aber da ich sie schon hab (waren vorher in meiner alten QNAP), nun ja, werden es wohl die auch bleiben xD

OK, werd ich mir auch mal anschauen, obs vielleicht mehr Sinn macht.

Mit vielem von @bic bin ich nicht 100% einverstanden oder es ist etwas zu kurz gegriffen.
Ein L2ARC kann schon cool sein, kommt halt auf den workload an.

Bevor du jetzt stundenlang dich in SLOG und PLP und volblocksize usw. reinliesst,
schildere doch einfach mal dein workload. Mir ist noch nicht mal klar, ob die VMs auf oder neben dem TrueNAS laufen.

Ich behaupte einfach mal, zu 99% kannst du deinen workload mit einer schlauen pool setup (was du mit der Differenzierung zwischen Media files auf lahmen HDD im RAIDZ und schnellen mirror für VMs bereits erreicht hast) locker abdecken ohne “cache”.

Nun ja, bei mir laufen z.Z. 3 TN, die Notwendigkeit, bei denen etwas per Shell erledigen zu müssen (nicht zu wollen), ergibt sich fast nie. Alles lässt sich bequem über die GUI erledigen.

Sicher nicht, da die Performance von ZFS bestimmt wird, welches ja quasi eine eigenständiges OS darstellt. Core oder Scale sind da praktisch lediglich die “Fernbedienung” und für überflüssigen Spielkram zuständig (Jails, Plugins, etc.) :rofl:
Aber ausgereifter und stabiler sollte Core immer noch sein, zumal es bei Debian zuletzt doch schon zu einigen Problemchen kam (siehe z.B. Kernel-Bug Ende letzten Jahres). Ich bleibe jedenfalls auf unbestimmte Zeit bei Core.