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