NAS UGreen DXP4800 Plus

[DeuSimon]

Hab gerade gelesen, dass es Immich als TrueNAS-App gibt.

Das ist eine Community-App, nicht "offiziell" von TruNAS.
Ist das gleiche als wenn Du Immich im LXC Container von Communityskripts installierst.
Dazu fühlt sich niemand verantwortlich ausser denen, die das so anbieten.
Immich empfiehlt VM.
Proxmox empfiehlt keine Docker in Docker (LXC).

Es muss ja nicht zwingend in die Hose gehen... doch wenn ich an mein kleines Paperless denke, oder an mein Immich, was darin steckt, da würde ich doch lieber den offiziellen Empfehlungen folgen.
Ja, man bekommt halt viel erzählt, LXC sind toll und sparsam. Das ist halt so ein doofes geschwätz was sich einfach so verbreitet, obwohl Proxmox es mit Docker in LXC nicht empfehlen tut. Aber trotzdem ist es so stark verbreitet. Da schreibt jmd ne Anleitung oder macht ein Video und ein nächster übernimmt es.
Als VM sinds halt, je nach dem, 2 Watt mehr Verbrauch.
Bin halt ein "LXC macht alles besser - Opfer" und Community Skripts sind super einfach.

Schaue lieber genau beim Thema Immich und TrueNAS, was da bei Fehlerfällen Sache ist.


//Hm ja, bei mir läuft Immich noch im LXC, bis es das nächste mal wieder nicht geht... D:


Edit: Ich bin Beginner. Damit hochprozentig wahrscheinlich falsche Angaben gemacht zu haben.

 

[IsThisThingOn]

da würde ich doch lieber den offiziellen Empfehlungen folgen.

Ist generell auch bei nicht so wichtigen Diensten eigentlich immer eine gute Sache. Hilft auch enorm beim troubleshooten.

Das ist halt so ein doofes geschwätz was sich einfach so verbreitet

Der ganz grosse Vorteil von LXC ist die Nutzung von files anstelle von blockstorage. Das ist eine kompliziertes Thema und schwer zu erklären für newcomers und gleichzeitig kann blockstorage ganz schön in die Hose gehen. Verstehe darum schon, warum per default einfach LXC empfohlen wird.

Ich hingegen bin der Meinung ,als newcomer sollte hypervisor und storage gar nicht erst kombiniert werden und wenn ZFS dann nur im mirror. Das klingt erst mal nach gatekeeping, verhindert aber IMHO viel Schmerzen.

Als VM sinds halt, je nach dem, 2 Watt mehr Verbrauch.

Wie kommst du darauf? Wüsste jetzt nicht warum eine VM für mehr Stromverbrauch denn eine LXC sorgen sollte. Wegen den Updates?

 

[Johannes S]

Als VM sinds halt, je nach dem, 2 Watt mehr Verbrauch.

Naja, das Argument mit den Ressourcen bezieht sich ja nicht so sehr auf den Stromverbrauch (wäre auch echt albern) sondern den RAM. Der einer VM zugewiesene RAM kann halt nicht anders genutzt werden, da sind lxcs tatsächlich flexibler. Nur bin ich bei sowas ja so gemein zu finden, dass dieses "Problem" keins ist, wenn man halt nicht für jeden Dienst eine eigene VM mit docker laufen lässt, sondern mehrere docker-container in einer VM laufen lässt (also z.B. eine VM für Tests und eine für Produktion). Ein anderes Ding ist, das wer gerne die iGPU nutzen möchte um darüber Transcoding (für Plex, jellyfin, immich etc) bei einer VM das Problem hat, dass er sie durchreichen muss und dann auch für nichts anderes zur Verfügung steht. Bei einer dezidierten Grafikkarte kein Problem, bei einer iGPU führt das dann aber dazu, dass man nicht mehr die Konsole direkt am Rechner (etwa für Debuggen bei einen Netzwerkproblem) nutzen kann.

Im Grunde kann man das ganze Problem halt darauf runterbrechen, dass wer seinen ersten Heimserver mit einen gebrauchten Mini-PC aufsetzt mit den dort üblichen Ressourcen (nur iGPU, envtl. nur 8-16 GB RAM) schnell nach Möglichkeiten zur Optimierung sucht. Dagegen spricht auch gar nichts, sofern man sich der Grenzen und möglichen Probleme bewusst ist. Mein Eindruck ist aber, dass ein Großteil der Leute, die die Helferskripte nutzt und empfiehlt, das eben nicht tut.

 

[proxmrmomba]

Ich hatte mit der letzten TrueNAS-Scale Version, das Problem, dass ich die in Proxmox nicht mehr nutzen konnte.
Frische Installation, beim einrichten eines ZRaids kommt die Meldung, dass die vDisks keine eindeutige Seriennummer haben und hat damit die Installation Einrichtung des Raid-Z abgebrochen wurde.
Müsste jetzt genau schauen, welche Version das wäre.
...
Nur so für den Hinterkopf.

 

[uwka77]

Ich denke, die Entscheidung ist gefallen - TrueNAS nativ auf der UGreen. TrueNAS ist schon eine andere Hausnummer als UGOS, habe es mal in einer VM angetestet. Werde aber die Boot-SSD wechseln, sicher ist sicher.

Von UGOS wollte ich gerade mal die Einstellungen speichern, hab da keine Funktion für gefunden. Ein Grund mehr zu wechseln.

 

[uwka77]

Ich hatte mit der letzten TrueNAS-Scale Version, das Problem, dass ich die in Proxmox nicht mehr nutzen konnte.

Das Problem hatte ich mit meiner TrueNAS-Installation unter VMware Workstation auch, das war aber nur eine Warnung, die man wegklicken konnte.

 

[proxmrmomba]

Setzt

Das Problem hatte ich mit meiner TrueNAS-Installation unter VMware Workstation auch, das war aber nur eine Warnung, die man wegklicken konnte.

Das ist interessant.
Ich konnte die Warnung wegklicken und war (meine ich) auch direkt aus dem Assistenten geflogen? Oder es ging nicht mehr weiter? Selbst unterschiedlich große HDDs konnnte er nicht zuordnen :-D

 

[uwka77]

Hallo,

wollte mich noch mal melden: TrueNAS Scale ist jetzt nativ auf der UGreen installiert.

Auf den ersten Blick sieht auch alles gut aus (bis auf die sinnlose LED-Laufzeile am Gehäuse, wo bei UGOS der Status der Festplatten angezeigt wird). Allerdings gibt ein großes ABER: TrueNAS Scale hat große Probleme mit NFS! Der Zugriff auf eine NFS-Share ist um den Faktor 10 (!) langsamer als bei Samba oder iSCSI, Deduplizierung spielt dabei keine große Rolle. Ich habe auch Sync deaktiviert, das bringt leider nicht viel. Getestet habe ich das mit einer Windows 10-VM, die ich auf meinem Haupt-PC mit VMware Workstation von den verschiedenen Shares starte und dann den Passmark Performance-Test ausführe. Beim Disk-Test ist der Zugriff auf die NFS-Share von TrueNAS mit 2x2 TB NVMe (Mirror) noch langsamer als der Zugriff auf die NFS-Share der Synology mit 2x8 TB HDDs (RAID1). Unglaublich!

Der einzige Ausweg ist der Einsatz von iSCSI statt NFS. Hat aber aus meiner Sicht ein paar Nachteile:
- Auf ein iSCSI-Laufwerk kann nur ein Client zugreifen. Da ich in meinem Homelab mehrere Server habe (Windows, ESXi, Proxmox), müsste ich für jeden ein extra iSCSI-Laufwerk anlegen.
- Und, das ist m. E. ein entscheidender Nachteil, man muss den iSCSI-Laufwerken eine Größe zuweisen. Und 2 TB sind da nicht sehr viel, wenn man die auf mehrere Volumes aufteilen muss. Zum Glück gibt es Thin Provisioning, da könnte man diesen Nachteil etwas abmildern. Aber elegant ist das alles nicht.
Bei NFS würde ich dafür eine Freigabe benutzen und dort dann Ordner einrichten und könnte besser mit dem Speicherplatz jonglieren.
- NFS ist einfacher einzurichten.

Tja. Zurück auf UGOS?

Viele Grüße
Uwe Herrmann

 

[IsThisThingOn]

Der Zugriff auf eine NFS-Share ist um den Faktor 10 (!) langsamer als bei Samba oder iSCSI

Das ist definitiv seltsam uns sollte nicht sein. Von welchem Client aus ist das?

Deduplizierung spielt dabei keine große Rolle.

Du hast aber hoffentlich nicht dedup am laufen?

Ich habe auch Sync deaktiviert, das bringt leider nicht viel.

Klar, sync ausschalten macht auch nur sync writes schneller, weil du den client belügst. Lass besser die Finger davon, ausser du weisst, was du tust.

Der einzige Ausweg ist der Einsatz von iSCSI statt NFS. Hat aber aus meiner Sicht ein paar Nachteile:

Der IMHO grösste Nachteil ist, iSCSI ist blockstorage also zvol und kein Dataset. Das bringt massivste Nachteile mit sich.

Leider können wir dir aber so nicht weiterhelfen, dazu ist dein Setup und deine Testweise viel zu undurchsichtig.
Erstelle mal ganz einfach ein Dataset, mit den defaults oder mit 1M recordsize und greife mit einem bare metal Linux per NFS und als Vergleich dazu mit SMB darauf zu.

 

[Falk R.]

Hallo,

wollte mich noch mal melden: TrueNAS Scale ist jetzt nativ auf der UGreen installiert.

Auf den ersten Blick sieht auch alles gut aus (bis auf die sinnlose LED-Laufzeile am Gehäuse, wo bei UGOS der Status der Festplatten angezeigt wird). Allerdings gibt ein großes ABER: TrueNAS Scale hat große Probleme mit NFS! Der Zugriff auf eine NFS-Share ist um den Faktor 10 (!) langsamer als bei Samba oder iSCSI, Deduplizierung spielt dabei keine große Rolle. Ich habe auch Sync deaktiviert, das bringt leider nicht viel. Getestet habe ich das mit einer Windows 10-VM, die ich auf meinem Haupt-PC mit VMware Workstation von den verschiedenen Shares starte und dann den Passmark Performance-Test ausführe. Beim Disk-Test ist der Zugriff auf die NFS-Share von TrueNAS mit 2x2 TB NVMe (Mirror) noch langsamer als der Zugriff auf die NFS-Share der Synology mit 2x8 TB HDDs (RAID1). Unglaublich!

Der einzige Ausweg ist der Einsatz von iSCSI statt NFS. Hat aber aus meiner Sicht ein paar Nachteile:
- Auf ein iSCSI-Laufwerk kann nur ein Client zugreifen. Da ich in meinem Homelab mehrere Server habe (Windows, ESXi, Proxmox), müsste ich für jeden ein extra iSCSI-Laufwerk anlegen.
- Und, das ist m. E. ein entscheidender Nachteil, man muss den iSCSI-Laufwerken eine Größe zuweisen. Und 2 TB sind da nicht sehr viel, wenn man die auf mehrere Volumes aufteilen muss. Zum Glück gibt es Thin Provisioning, da könnte man diesen Nachteil etwas abmildern. Aber elegant ist das alles nicht.
Bei NFS würde ich dafür eine Freigabe benutzen und dort dann Ordner einrichten und könnte besser mit dem Speicherplatz jonglieren.
- NFS ist einfacher einzurichten.

Tja. Zurück auf UGOS?

Viele Grüße
Uwe Herrmann

Wenn ich das richtig verstehe, greifst du mit Windows per NFS zu. Das ist immer langsam, da der Windows NFS Client nicht so doll ist.
Bitte mal mit Linux oder direkt mit Proxmox testen.

 

[uwka77]

Ich gebe zu, dass ich sehr viel und scheinbar intransparent getestet habe. Ich habe einfach mehrere Shares unter verschiedenen Konstellationen mit TrueNAS angelegt, dort dann eine VMware-VM abgelegt und diese über VMware Workstation gestartet. Und ja, eine Share davon ist auch mit Deduplizierung.

Das komische ist, dass man beim Kopieren der VM auf die NFS-Share noch nicht merkt, dass es langsamer als SMB oder iSCSI ist - die angezeigten Kopiergeschwindigkeiten differieren wenig. Erst man Starten der VM von der NFS-Share wird offensichtlich, dass das "eine lahme Kiste" ist. Und beim "Passmark Performance Test" bricht der Disk-Benchmark komplett ein.

Hier mal ein paar Ergebnisse des Disk-Benchmarks-Tests in einer Windows 10 VM. Ablegt ist die VM auf:
- einer NVEMe-Partition auf meinem PC : 7.600
- einer SATA-SSD-Partition auf meinem PC : 3.400
- einer HDD-NFS-Share auf der Synology : 1.280
- einer NVMe-NFS-Share auf der TrueNAS UGreen: 835 ohne Dedup
- einer NVMe-NFS-Share auf der TrueNAS UGreen: 745 mit Dedup
- einer NVMe-SMB-Share auf der TrueNAS UGreen: 6.700 mit Dedup
- einem NVMe-iSCSI-Drive auf der TrueNAS UGreen: 6.500 mit Dedup

Ich habe auch gelesen, dass man die Finger von Deduplizierung lassen sollte. Aber bei meiner Konstellation, identische VMs auf verschiedenen Virtualisierungsplattformen zu testen, mehr als verlockend.

Der IMHO grösste Nachteil ist, iSCSI ist blockstorage also zvol und kein Dataset. Das bringt massivste Nachteile mit sich.

Dazu kann ich leider nichts sagen.

 

[uwka77]

Ja, ich muss das mal mit meinem ESXi-Server oder Proxmox testen, da habt ihr recht.

Wenn ich das richtig verstehe, greifst du mit Windows per NFS zu.

Korrekt, ich mounte das mit dem Windows NFS-Client ohne angepasste Optionen. Leider kann ich die NFS-Version beim Mounten nicht beeinflussen, sonst hätte ich es mal mit NFS v3 versucht.

 

[Falk R.]

Nicht vergessen, bei einem Netzwerkshare kannst du mit verschiedenen Protokollen auf den gleichen Share zugreifen. Bei Windows SMB und Linux mit NFS.

 

[Bu66as]

Hallo @Falk R.,

da hast du absolut recht. Der NFS-Client von Windows ist leider notorisch ineffizient (u. a. wegen der Implementierung von Sync-Writes und Locking) und eignet sich überhaupt nicht als Referenz für die Performance, die man später unter einem Linux-basierten System wie Proxmox erwarten kann.

@uwka77 Die von dir gemessenen Einbrüche liegen mit sehr hoher Wahrscheinlichkeit rein am Windows-Client. Wenn du die VMs später auf einem Proxmox- oder ESXi-Host betreibst, wird NFS dort die gewohnte Leistung bringen. Für den Test unter Windows/VMware Workstation ist SMB (oder iSCSI) tatsächlich der korrekte Weg. Deine Sorge, dass das NAS per se langsam ist, ist also unbegründet.

 

[Johannes S]

Das ist definitiv seltsam uns sollte nicht sein. Von welchem Client aus ist das?

Interessant wäre auch, welche NFS Version (NFS3 oder NFS4? NFS4 sollte flotter sein, wenn ich mich richtig erinnere) auf server- und clientseite konfiguriert ist.

 

[IsThisThingOn]

Ich habe einfach mehrere Shares unter verschiedenen Konstellationen mit TrueNAS angelegt, dort dann eine VMware-VM abgelegt

Ich kenne mich null aus mit VMWare. Aber verstehe ich das richtig, dass du unter VMware eine disk ähnlich wie QEMU2 inter Proxmox erstellst und diese dann auf den NFS share von TrueNAS schiebst?

Das kann fast nur in die Hose gehen. Ausser du verstehst zu 100% was du tust. CoW on Cow ist ganz mies, dann noch volblocksize oder recordsize in Kombination mit der Blocksize der VM disk usw.

Dazu kann ich leider nichts sagen.

Dann hast du mich falsch verstanden, das war eine Warnung an dich gerichtet

KISS. Keep it simple stupid.

- VMs auf Proxmox.
- Proxmox hat SSD mirrors. Kein RAIDZ
- Daten liegen nicht in VMs! Also zum Beispiel, die Nextcloud VM hat nicht die userdaten auf der VM disk gespeichert. Sondern die sind auf einem NFS share ausgelagert, das auf deinem ZFS dataset liegt.
- ZFS datasets dürfen, wenn sie nur grössere Dateien beinhalten auch ein RAIDZ2 mit HDDs sein.

Wenn du dich an diese Punkte haltest wirst du ein simples und stabiles Setup haben ohne ZFS Schmerzen.
Ansonsten musst du schon zu 100% wissen, was du tust.

 

[Bu66as]

@IsThisThingOn,

du triffst den Nagel auf den Kopf. Das ist der klassische "Perfect Storm": Der Windows-NFS-Client ist per se ineffizient (Locking/Sync), und das dann kombiniert mit VM-Disk-Images auf einem ZFS-Dataset (CoW-on-CoW) potenziert die Latenzen massiv.

@uwka77 misst hier effektiv nur den Flaschenhals seines Testaufbaus, nicht die tatsächliche Leistung des NAS. Dein Rat zu "KISS" (VMs auf lokalen SSDs, Daten auf dem Share) ist der einzig sinnvolle Weg aus dieser Sackgasse.

 

[Browbeat]

Tja. Zurück auf UGOS?

Falls noch nicht bekannt:

https://www.youtube.com/watch?v=CR-0buRzYxE

Wäre ggf. auch ein Einsatzzweck für mein DXP4800

 

[moonsorrox]

Ich besitze auch ein Ugreen und habe auf dem DXP 6800 Pro Proxmox installiert.
Bei mir läuft bisher eine einzige VM mit TrueNAS Scale, da ich ein NAS System nutzen wollte. Ich habe 4 Festplatten in einem Pool welcher sich Datenpool nennt.
Hier kommen dann meine ganzen NAS Dateien die ich von meiner Synology runter genommen habe.
Die 4 Festplatten mit 8 TB die ich an TrueNAS durchgereicht habe sind in Proxmox nicht mehr zu sehen da sie komplett von TrueNAS genutzt werden.
Deswieteren habe ich auf der eingebauten NvMe das System drauf auf zwei weiteren NvMe jeweils mit 4TB kommen die ganzen VM und LXC drauf die noch kommen.

Da ich absolut kein TrueNAS Kenner bin habe ich es aber trotzdem gewagt weil ich das System einfach gut finde.
Dei erste Hürde habe ich auch schon genommen. Was die Rechte betrifft ist das alles etwas schieriger zu verstehen unter TrueNAS.
Ich habe eine SMB Freigabe und zusätzlich eine NFS Freigabe auf einem Ordner der sich bei mir Musik nennt.

Auf einem anderen Proxmox habe ich einen LXC am laufen mit dem neuesten LyrionMusicServer womit ich meine älteren Logitech Squeezeboxen betreiben kann.
Die Musik Dateien liegen auf den TrueNAS, da immer wieder welche dazu kommen kann ich die von Windows auf drauf kopieren und der Lyrion LXC kann sie nutzen.
Bisher bin ich noch am Anfang mit dem Ugreen aber sehr zufrieden.
Zwei weitere HDDs jeweils mit 3 TB weiß ich noch nicht wie und mit was ich sie nutze sind jeweils eigene ZFS Pools.

TrueNAS ist bei mir nur ein NAS hatte auch schon OMV das wäre auch gegangen. Kann ich ja immer nochmal ausprobieren.
Ansonsten werde ich auf dem TrueNAS keine VM oder Container einrichten das bleibt was es ist ein NAS.
Dafür habe ich ja dann Proxmox und hier kann ich ja LXCs und VMs ohne Ende installieren. Bisher haeb ich noch 3 weitere Proxmox die ich alle ablösen oder zumindest zwei davon komplett ausrangiere, dass kommt alles auf das Ugreen.
Dann nehme ich eins der Hardware Geräte welches mein Proxmox PBS ersetzt der ist etwas schwach da kommen dann die Backups drauf davon habe ich einiges auf einer 8TB Platte.

 

[6equj5]

Daher ist es eine UGReen DXP4800 geworden, über die man viel positives liest.

Geht so. Hatte ein paar Wochen die DXP4800+ bis sie mir zu dünn drauf war für Virtualisierung. Bin dann auf das Minisforum N5 gewechselt und das rockt mit dem AMD. Dazu noch USB4, Oculink ... ach ja, 5 bays hat das auch in einem extrem kompakten Gehäuse.

Hatte auch beides ausprobiert, Truenas und PVE. Bei TN ist die Virtualisierung eine Katastrophe, weshalb ich jetzt komplett auf PVE bin. NAS-Funktionen mach ich mit Kernel NFS und Samba direkt auf dem PVE, das geht super. Webmin noch, das ist für viele Sachen übersichtlicher. Z.B. sieht man auch Temperaturen.

TrueNAS Scale hat große Probleme mit NFS! Der Zugriff auf eine NFS-Share ist um den Faktor 10 (!) langsamer als bei Samba oder iSCSI,

Nein, das hatte ich bei TN nicht. Jedenfalls nicht mit async, mit sync schon.

Ich habe auch Sync deaktiviert, das bringt leider nicht viel.

Wo denn? M.W. muß man das beim Client einstellen. Also in Deinem Fall bei Windows etwa so:

• Use the mount command in CMD or PowerShell.
• Add the -o async option for asynchronous writes, but be aware of potential data loss if the server crashes before data is flushed.
• Example: mount -o async <Server>:/ShareName <DriveLetter>:

NFS ist m.E. auf Linuxen der Gold-Standard. Simpel und rasend schnell (also mehr geht halt dann physikalisch net).