NAS UGreen DXP4800 Plus

Wozu überhaupt NFS wenn WindowsClient?
Was sind denn die üblichen Anwendungsszenarien, dass du so viel "Power" brauchst?

Vielleicht nochmal in Ruhe das eigene Vorhaben skizzieren und dann loslegen - nur so ein Tip:)
 
Last edited:
Meine Frage ist: Was mache ich am besten aus meiner neuen UGreen-NAS, die eine ältere Synology ablösen soll. Sie soll in einer nicht produktiven HomeLab-Umgebung zwei Aufgaben erfüllen: Ca. 6 TB Backup-Dateien aufnehmen und als Datastore für verschiedene Virtualisierungslösungen dienen.
Das klingt auch wirklich nicht praxisnah - wenn es nicht produktiv ist, wozu dann Backup?

Außerdem nutzt du ja nun TrueNAS auf dem Ugreen oder? Daher hätte das hier ja nix mehr mit Proxmox zu tun
 
wozu dann Backup
Für den Rest der IT im Haushalt (Daten, Fotos, Videos, MP3s, Veeam Agent Images u.v.a.m.).

Daher hätte das hier ja nix mehr mit Proxmox zu tun
Ja, das ist korrekt. Also danke für jede Antwort. Wobei TrueNAS und Proxmox mit ZFS eine wichtige Gemeinsamkeit haben.
 
  • Like
Reactions: Browbeat
Könnte man theoretisch auch alles auf einem Host laufen lassen ;)
Klar. Aber mein mobo unterstützt kein SR-IOV (oder hat den Intel bug diesbezüglich) und mit vInterfaces auf der Netzwerk Karte habe ich aufgegeben.
Zudem geniesse ich es jetzt, wenn das Internet weiterläuft, auch wenn ich ein Proxmox Neustart mache :)
 
Ich vermute du hast write amplification wie Sau
Wird immer wieder behauptet, Zahlen hab ich noch nie gesehen. Deshalb hab ich's mal selbst gemessen. Ergebnis (Windows VM auf local ZFS 4-disk raidz1): es spielt kaum eine Rolle. Ob nun RAW, VMDK, QCOW2, ZVOL. Tatsächlich ist ZVOL am besten, dann RAW, dann QCOW2, dann VMDK.
Bei ZVOL könnte noch die VolBlockSize 'ne (kleine) Rolle spielen. Ich hab mit 64 KB gemessen und NTFS auch so formatiert.
Via NFS ist es noch egaler. Da fällt halt ZVOL weg. Aber RAW hat keine Snapshots, also ja, da nimmt man dann eben QCOW2.
Nee aber mal ernsthaft, du hast ext4 VMs deren QEMU2 disks auf einen NFS share sind und dieses NFS share nutzt ZFS?
Also nein, NTFS-VMs. Aber sonst ja. Und das ist nur 'ne Test-VM. Eigentlich laufen hier VMs auf zwei PVE local.
... weil richtig geil ist die ausgesuchte Hardware jetzt nicht als Hypervisor ...
Ein Grund, warum ich eben auf das N5 gewechselt bin.
... bei diesem Ugreen ist die QVL wichtig, es läuft nicht jeder beliebige RAM laut Userberichten ...
Ich hatte die von Crucial, die gingen gut (und jetzt sind sie im N5 auch tipptopp).
Die UGreen ist auf 16 GB RAM aufgerüstet (mehr ist im Moment nicht bezahlbar, 64 GB kosten ja mehr als die ganze NAS ohne Platten).
Ja, das ist schon krass. Leider sind 16 GB echt wenig für ZFS und 'n paar Container. Ich hab 80 GB und davon allein gut die Hälfte für den ARC. Ich kann verstehen, wenn man lieber TN hat wegen Storage-Features, aber m.E. ist eben PVE deutlich genügsamer. Ja nu.
Dann wäre interessant, ob mit nfs3 oder nfs4 zugegriffen wird ...
Hat bei meinen Tests keinen Unterschied gezeigt.
 
Wird immer wieder behauptet, Zahlen hab ich noch nie gesehen.
Naja, wenn du ein 4k file in einem 64k volblock änderst, ist die write Amplifikation nun mal 16 fach.
Wenn du ein 64k file in einem einem 64k volblock änderst, hast du gar keine.

Wie NTFS selbst formatiert ist, ist nochmals ein Komplexitätslayer im Test. Der default ist glaube ich für Windows 4k, für ext4 512.

Wer misst, misst Mist.
Ob nun RAW, VMDK, QCOW2, ZVOL. Tatsächlich ist ZVOL am besten, dann RAW, dann QCOW2, dann VMDK.
Was meinst du mit RAW oder ZVOL. RAW kann ja nur in einem ZVOL liegen wenn auf ZFS.
Verstehe darum die Unterscheidung nicht ganz.
Aber RAW hat keine Snapshots,
Ja doch. Sogar die viel schnelleren Snapshots als QCOW2.
 
Leider sind 16 GB echt wenig für ZFS
Ich glaube mittlerweile, dass das mein Hauptproblem ist. Würde gern mit mehr RAM testen, aber der ist im Moment einfach zu teuer. Werde mal OMV ohne ZFS testen. Soll auch einfacher zu administrieren sein.
 
Leider sind 16 GB echt wenig für ZFS und 'n paar Container. Ich hab 80 GB und davon allein gut die Hälfte für den ARC. Ich kann verstehen, wenn man lieber TN hat wegen Storage-Features, aber m.E. ist eben PVE deutlich genügsamer.
Warum sollte PVE genügsamer sein als TrueNAS?
Wer das behauptet, hat ARC nicht verstanden.

ARC ist adaptive replacement cache.
ARC ist read cache.
ARC beinhaltet aber auch einen dirty write cache, die 5s goal async TXGs writes.
Der reach cache kann jederzeit geschrumpft werden. Die dirty writes nicht.

Ich schüttle mir das mal aus dem Ärmel, bitte mit Vorsicht geniessen, ich glaube es kann zu folgenden Situationen kommen:

Du hast ein TrueNAS System mit 64GB RAM:
Davon werden 32GB für VMs und TrueNAS verwendet.
32GB sind für ARC.
Davon sind (10Gbit * 5 Sekunden =6,25) nicht schrumpfbar, weil dirty write data des 10GBit NIC.
Jetzt starten wir eine weitere VM die 8GB konsumiert.
Kein Problem, ARC wird einfach um 8GB geschrumpft.

Du hast ein Proxmox System mit 64GB RAM:
Davon werden 56GB für VMs und Proxmox verwendet.
8GB sind für ARC.
Davon sind (10Gbit * 5 Sekunden =6,25) nicht schrumpfbar, weil dirty write data des 10GBit NIC.
Jetzt starten wir eine weitere VM die 4GB konsumiert.
ARC kann aber nur um ca. 2GB geschrumpft werden.
Wir laufen in eine out of memory Situation.

Das erklärt auch warum unterschiedliche OS, unterschiedliche defaults haben.

TrueNAS hatte früher unter BSD die ARC auf 80% des RAMs limitiert.
Mit TrueNAS SCALE wurde dann der Linux default von max 50% des totalen RAM übernommen.
Weil bei Proxmox der genutzte RAM tendenziell weniger schrumpfbar ist, wurde neu die Limite 10% and max 16GB eingeführt um eine oom Situation zu verhindern. Sehr konservativ.

Das sind aber nur defaults und problemlos anpassbar.
Proxmox nutzt also nicht weniger RAM als TrueNAS. Es hat nur andere Defaults.


TrueNAS empfahl früher min 16GB und 1GB pro TB.
Gab wohl exotische Crashes mit 8GB Systemen und niemand hatte Lust sich diese anzuschauen, weil
"ZFS ist ein Server FS und ein Server hat nicht nur 8GB RAM"
Später korrigierten sie es auf min 8GB, egal wie viel TB.

Proxmox empfiehlt 2GB plus 1GB pro 1TB storage.
Ich glaube das 1GB pro 1TB ist einfach noch ein altes Überbleibsel.

Ich wüsste keinen Grund, warum ich nicht 5TB storage mit 2GB ARC betreiben könnte.
 
Last edited:
  • Like
Reactions: Johannes S
Warum sollte PVE genügsamer sein als TrueNAS?
Wer das behauptet, hat ARC nicht verstanden.

ARC ist adaptive replacement cache.
ARC ist read cache.
ARC beinhaltet aber auch einen dirty write cache, die 5s goal async TXGs writes.
Der reach cache kann jederzeit geschrumpft werden. Die dirty writes nicht.

Ich schüttle mir das mal aus dem Ärmel, bitte mit Vorsicht geniessen, ich glaube es kann zu folgenden Situationen kommen:

Du hast ein TrueNAS System mit 64GB RAM:
Davon werden 32GB für VMs und TrueNAS verwendet.
32GB sind für ARC.
Davon sind (10Gbit * 5 Sekunden =6,25) nicht schrumpfbar, weil dirty write data des 10GBit NIC.
Jetzt starten wir eine weitere VM die 8GB konsumiert.
Kein Problem, ARC wird einfach um 8GB geschrumpft.

Du hast ein Proxmox System mit 64GB RAM:
Davon werden 56GB für VMs und Proxmox verwendet.
8GB sind für ARC.
Davon sind (10Gbit * 5 Sekunden =6,25) nicht schrumpfbar, weil dirty write data des 10GBit NIC.
Jetzt starten wir eine weitere VM die 4GB konsumiert.
ARC kann aber nur um ca. 2GB geschrumpft werden.
Wir laufen in eine out of memory Situation.

Das erklärt auch warum unterschiedliche OS, unterschiedliche defaults haben.

TrueNAS hatte früher unter BSD die ARC auf 80% des RAMs limitiert.
Mit TrueNAS SCALE wurde dann der Linux default von max 50% des totalen RAM übernommen.
Weil bei Proxmox der genutzte RAM tendenziell weniger schrumpfbar ist, wurde neu die Limite 10% and max 16GB eingeführt um eine oom Situation zu verhindern. Sehr konservativ.

Das sind aber nur defaults und problemlos anpassbar.
Proxmox nutzt also nicht weniger RAM als TrueNAS. Es hat nur andere Defaults.


TrueNAS empfahl früher min 16GB und 1GB pro TB.
Gab wohl exotische Crashes mit 8GB Systemen und niemand hatte Lust sich diese anzuschauen, weil
"ZFS ist ein Server FS und ein Server hat nicht nur 8GB RAM"
Später korrigierten sie es auf min 8GB, egal wie viel TB.

Proxmox empfiehlt 2GB plus 1GB pro 1TB storage.
Ich glaube das 1GB pro 1TB ist einfach noch ein altes Überbleibsel.

Ich wüsste keinen Grund, warum ich nicht 5TB storage mit 2GB ARC betreiben könnte.
Man kann den ZFS ARC bei PVE hier anpassen -->
Code:
root@pve03:~# cat /etc/modprobe.d/zfs.conf
options zfs zfs_arc_max=6715080704
--> offizielle Quelle
Ich hab damit ne zeitlang rumexperimentiert, es hat jedoch bei der Performance keinen merklichen Unterschied gemacht. Ich würde es daher auf default lassen.
 
  • Like
Reactions: Johannes S
Mit dem Code alleine ist es nicht getan.
Zumindest laut der offiziellen Doku ist es mit dieser einen Zeile getan, was die maximale Größe des ARC angeht. Falls du da andere Infos hast bitte die entsprechende Quelle nennen. Die Größe des ARC muss ggf. an die jeweilige Anforderungen (Workload) manuell angepasst werden und kann daher nicht pauschal beantwortet werden. Wo man das ändern kann, habe ich geschrieben und dass es in den meisten Fällen auf default passt habe ich ebenfalls geschrieben. Die korrespondierenden Quellen, die meine Argumentation stützen, habe ich genannt.
Performance mag nicht bemerkbar sein, aber empty RAM is wasted RAM
Ich habe in den letzten 30 Jahren immer gerne 20-30% freien RAM gehabt und bin recht gut damit gefahren. Ich mache das aber auch nicht beruflich und bin auch kein Profi ;) Der freie RAM hat sich als recht nützlich erwiesen, wenn ich z.B. mal eben neue SW ausprobieren will. Wenn dann der RAM zu knapp bemessen ist, könnte mein System instabil werden oder sogar komplett abstürzen und das ist immer ein bisschen blöd...finde ich zumindest.

In der alten PVE Version (< 8.1) habe ich genau wegen dem hohen "Verbrauch" den ARC manuell begrenzt. Ich musste zu einem späteren Zeitpunkt PVE (9) komplett neu installieren und habe danach festgestellt, dass der Speicherhunger auf einmal wesentlich niedriger war als in der Vorgängerversion (glaube 8.4.1), weswegen der manuellen Eingriff (s.o.) wegfallen konnte. Scheinbar wurde im Rahmen der Updates (<8.1-->8.4.1) keine automatische Umstellung dieser Obergrenze vorgenommen (evtl nur bei einer Neuinstallation?), weswegen das für einige Leute hier durchaus von Interesse sein könnte, damit sie das selbst nachjustieren können.

Ich bin überhaupt erst auf die Sache aufmerksam geworden, weil die LXCs vor der Umstellung nach längerem Betrieb häufig zu swappen angefangen haben, was ich gerne abstellen wollte. Swappines lässt sich meines Wissens nur Global einstellen und nicht separat für einzelne LXCs, weswegen ich mich mit der Thematik etwas intensiver auseinandergesetzt habe und entsprechend recherchieren musste.

Das beschriebene "oom" Szenario würde, erneut aus meiner Sicht, mehrere virtuelle Instanzen mit mengenmäßig erheblichen Schreibzugriffen voraussetzen, was möglicherweise in deinem persönlichen Usecase der Fall sein mag, aber vermutlich nicht auf die breite Masse zutrifft. Ich finde dazu nichts passendes und Ich meine der Schreibcache wird bei ZFS nicht über ARC, sondern andere Mechanismen gelöst. Gibt es Quellen zu der "dirty writes in ARC" Theorie oder kommt das von irgendeiner fantasierenden KI der nach ner Std Konversation die Tokens ausgegangen sind? Die denken sich dann nämlich irgendwann Sachen einfach aus, was sowohl gefährlich als auch peinlich enden kann.

PVE ist grundsätzlich nicht als Filesever sondern als Hypervisor gedacht. Die Anpassung der Defaultwerte für den ARC könnten daher bei einer Zweckentfremdung als Fileserver durchaus Performancevorteile bringen. Ich habe bei der Verwendung als reiner Hypervisor keine Vorteile feststellen können, daher würde ich anderen raten die Defaultwerte zu lassen, bzw. wenn PVE vor Version 8.1 installiert wurde, die Werte in o.g. Datei entsprechend anzupassen. Die Proxmoxentwickler werden sich vermutlich auch ein paar Gedanken zu dem Thema gemacht haben, bevor sie das geändert haben.

Es wird für den Einsatzzweck ZFS unter PVE einfach nicht soviel RAM für den ARC benötigt, als wie für einen Fileserver mit ZFS. Daher kommen, aus meiner Sicht, eher die Änderungen von 50% --> 10%. Die meisten möchten den RAM bei PVE auch vermutlich lieber den virtuellen Instanzen geben, statt ihn in den ZFS ARC von PVE zu versenken in dem dieses Plus an RAM kaum/keine Vorteile bietet. Gerne lasse ich mich jedoch mit Gegenargumenten die durch verlässliche Quellen belegt sind auch hier vom Gegenteil überzeugen.

Guten Rutsch ;)
 
  • Like
Reactions: Browbeat