Meinung zu sehr kompaktem Selbstbau-NAS

djdf

Cadet 4th Year
Registriert
Juli 2017
Beiträge
83
Hallo zusammen,

darf man hier auch unvernünftige Dinge besprechen? Was jetzt kommt, ist nämlich nicht gerade ökonomisch. Aber ich hab Spaß daran und gebe mein Geld eher für solche Dinge aus.

Seit knapp 6 Jahren betreibe ich ein Selbstbau-NAS auf Basis von OMV und das ist grundsätzlich schon sehr potent. Ich möchte und muss mein Heimnetz bisschen anders strukturieren und da ich das bestehende NAS derzeit nicht außer Betrieb nehmen kann, überlege ich, parallel ein zweites aufzubauen und wenn alles läuft, das alte NAS zu veräußern. Das ist zumindest der mittelfristige Plan, von dem ich zwar gerade sehr angetan bin, aber noch nicht weiß, ob er gut ist.

Ein großes Problem an der Sache: Platzmangel (max. 30cm in der Höhe und weniger als 30cm in der Tiefe). Da ich noch ein U-NAS NSC-410 herumstehen habe, soll das als Basis für das neue NAS dienen, außer es ergeben sich noch Vorschläge. Damit ergeben sich natürlich ein paar Einschränkungen bzgl. der techn. Ausstattung, weil ich an Mini-ITX gebunden bin.

Was soll auf dem neuen NAS laufen? Es dient als:
  • Datengrab für Fotos, geschäftl. Dokumente etc.
  • Film-Archiv (aber kein Transcoding, ich nutze Kodi an den Endgeräten und spiele nur hausintern die Filme ab)
  • DVR mit TVheadend
  • Videoüberwachung (voraussichtl. BlueIris) und
  • ich möchte das NAS zum Router/Firewall machen und damit meinen Ubiquiti-Router rausschmeißen.
Da ich hier ein paar Sicherheitsbedenken beim Einsatz von opnSense innerhalb von OMV habe, ist die Überlegung Promox als Basis einzusetzen und darin neben opnSense und BlueIris auch OMV als eigenständige VM zu betreiben. Das ganze System wird vollverschlüsselt laufen. Zudem werde ich das Film-Archiv, derzeit in h264, in h265 konvertieren - das sollten heute alle Endgeräte können, um so massiv Platz zu sparen (derzeit verbraucht mein DVR ca. 3 TB und das Filmarchiv ca. 12 TB, erste Tests zeigen, dass sich das auf ein Viertel reduzieren lässt). Die Kameras werden mittelfristig durch 4K Modelle ersetzt (möglicherweise auch eine Erweiterung auf bis zu 7 Kameras). Es laufen noch ein paar andere kleine Docker-Container. Das Backup wird zukünftig verschlüsselt und inkrementell in die Cloud ausgelagert.

Was soll an HW rein?
  • ASRock Rack E3C256D2I
  • Intel Xeon E-2336
  • 2x32GB DDR4 ECC (ECC ist ein Muss)
  • 4x Samsung SSD 870 EVO 4TB als RAID-Z1 (also ZFS)
  • 1x Samsung SSD 980 500GB, M.2 als OS-Disk
  • und natürlich die DigitalDevices Max S8

Passt irgendwas gar nicht in dem Setup? Vom Gefühl her, wird es sicher überdimensioniert sein, aber ich würde da jetzt nicht rumschrauben, nur um 50 EUR zu sparen. Wenn es natürlich sinnvolle Einsparungen sind, die dann eine dreistellige Ersparnis bringen, bin ich offen für Vorschläge. Weniger Strom als vorher sollte es trotzdem verbrauchen. Ich hätte mich dabei auch gern über 2x 2.5G LAN gefreut, aber das gibt es nicht im Mini-ITX soweit ich sehen konnte und der einzige Slot ist durch die DVB-Karte belegt. Persönlich fühle ich mich mit den SSDs - die machen es halt so teuer - bzgl. Ausfallsicherheit sicherer als mit HDDs, insb. weil ein Rebuild schneller von statten geht.

Ich freue mich auch über Vorschläge bzw. Alternativen zur Software (insb. Proxmox, OMV und BlueIris).

VG
 
Über die 1GB/s-LANschnittstelle bekommst du nicht im Ansatz die Geschwindigkeit der SSD's übertragen, hier würde ich eher auf HDD setzen. Ich habe bisher in >4 Jahren Betriebszeit einen RAID-Rebuild benötigt und das war vor der Anschaffung einer passenden USV.
 
  • Gefällt mir
Reaktionen: polyphase
@djdf Hast du einen 3D Drucker?
 
Zuletzt bearbeitet:
In der Tat eine tolle Option, wenn ich ein reines NAS suchen würde. Erfüllt aber zwei Anforderungen nicht, ECC und PCIe Slot für die TV-Karte. Danke trotzdem!
 
Das mit dem router/FW sehe ich kritisch. Das geht schief und ist vor allem auch ein echtes Sicherheitsproblem.

Bevorzugt: Vorhandenen Router/FW lassen, oder wenn nötig, einkaufen. Kann ja auch sowas wie ein Banana Pi sein. Aber halt ein dediziertes Gerät.

Wenn es absolut was lokales sein muß: Ausreichend viele Netzwerkports (tatsächlich vorhandene, keine virtuellen) und da dann mit SRIOV (wenn VM) bzw passender (dedizierter) Zuweisung (falls nicht) arbeiten.

Firewall auf demselben OS ist per se unsicher, wenn überhaupt dann als VM und dann auch wieder mit ausreichend "echten" Ports, wobei man die dann fürs Routing mitbenutzen kann. Da braucht man dann ein Interface fürs WAN (dediziert für die Firewall-VM) und ausreichend viele Interfaces für den Rest des Netzwerks, mindestens einen wo ein Switch dran kann. Der FW Host kann prinzipiell eine virtuelle Verbindung bekommen von der FW-VM zu deren Host; sollte man nicht tun, aber extra Interface dran und die Daten aus der FW VM zum Switch und von da wieder zurück zum FW Host ist auch nicht soo viel besser.

In jedem Fall, wenn die Möglichkeit besteht: Firewall und Router extra; gerne FW als Router, aber weder FW noch Router auf einem Host, wo Dienste AUSSER FW oder Routing laufen.
 
  • Gefällt mir
Reaktionen: djdf
andy_m4 schrieb:
Warum eigentlich so zwingend ECC? Ich frag nur der Neugier halber.
ZFS ohne ECC kann man machen, ist dann aber halt Sch***e. Außerdem hatte ich vor vielen vielen Jahren mal im privaten Bilderarchiv einige kaputte Dateien. Das war für mich der Auslöser, seither auf Nummer sicher zu gehen und zumindest ECC einzusetzen, wo es geht.
 
andy_m4 schrieb:
Wäre jetzt noch cool zu wissen, ob da AES-NI problemlos läuft. ;)
Hättest du meinen aktuellen Beitrag im Threads zu den ZFS Performance Problemen gelesen, wüsstest du das es funktioniert 👍

Das Problem war TrueNAS Scale, das wohl einen Bug hat, sodass AES-NI nicht richtig funktioniert. Unter TrueNAS Core funktioniert es und die CPU hat quasi keine Auslastung beim ver-/entschlüsseln 🙂
Ergänzung ()

djdf schrieb:
ZFS ohne ECC kann man machen, ist dann aber halt Sch***e.
Das ist ein Mythos der sich bis heute hält 🙈

ZFS ohne ECC hat immer noch eine höhere Datensicherheit als andere Dateisysteme.

Selbst wenn du ZFS mit nur einer Festplatte verwendest, bist du durch die Prüfsumme besser dran, als mit einem Dateisystem ohne Prüfsumme.


Schau dir Mal dieses Video an von der EuroBSDcon, dort wird ab Minute 23:56 mit genau diesen Mythen aufgeräumt 👍

Ergänzung ()

Iqra schrieb:
Das mit dem router/FW sehe ich kritisch. Das geht schief und ist vor allem auch ein echtes Sicherheitsproblem.
Sehe ich überhaupt nicht kritisch, solange man die Netzwerkkarte, welche am Internet hängt (also WAN) komplett per PCIe Passthrough an die Firewall VM durchreicht 😉

Das wird sogar im Enterprise-Bereich so gemacht und läuft bei mir seit Jahren problemlos 👍

Schöner Vorteil ist, man kann von der Firewall VM vor einem großen Update einen Snapshot machen und den notfalls wieder zurückspielen, wenn beim Update etwas schief geht 😎
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: redjack1000 und djdf
Iqra schrieb:
Firewall auf demselben OS ist per se unsicher, wenn überhaupt dann als VM
Das kann man per se nicht so sagen. Kommt halt stark darauf an, was man damit machen und was erreichen will. Wenn das eher so für den internen Gebrauch ist a-la Rechner A soll nicht auf "telemetry.microsoft.com" zugreifen können, dann ist eher problemlos.
Gehts darum das auf dem Firewall-Rechner selbst kein Prozess z.B. nachhause telefonieren können soll, dann ist das natürlich eher ungünstig. Weil was soll den Prozess (der ja offenbar nicht macht was Du willst) jetzt im schlimmsten Fall daran hindern Deine Firewall-Rules zu ändern. Und da schützt auch ne VM nicht vor.

djdf schrieb:
ZFS ohne ECC kann man machen, ist dann aber halt Sch***e.
Sehe ich anders. Also klar. ECC ist natürlich besser. Aber ist jetzt auch nicht so, als wäre es bei ZFS besonders wichtig ECC zu haben. Im Gegenteil. ZFS ist hier tendenziell sogar etwas besser aufgestellt weil die Checksumming (wie bereits schon gesagt) machen.
Mal davon abgesehen hast Du noch viele andere Fehlerquellen als kaputten RAM die teilweise in der Praxis dann eher relevant sind.

DDR4 macht übrigens auch schon ohne ECC schon zumindest einen gewissen Schmalspur-CRC-Check. Das ist natürlich nicht so gut wie ECC aber man steht nicht so "nackig" da wie noch bei DDR3.

Kurzum: Die Entscheidung für ECC kann man machen oder auch nicht, aber es hängt nicht davon ab ob man ZFS einsetzt oder nicht.

polyphase schrieb:
Das Problem war TrueNAS Scale, das wohl einen Bug hat, sodass AES-NI nicht richtig funktioniert.
Ja. Genau darauf hab ich angespielt. :-)

polyphase schrieb:
Schau dir Mal dieses Video an von der EuroBSDcon
Und die FreeBSD-Leute müssen es wissen. Die hatten schließlich schon ZFS im System, da hat das Linux-Lager immer noch an ext4 herum gebastelt. :-)

polyphase schrieb:
Schöner Vorteil ist, man kann von der Firewall VM vor einem großen Update einen Snapshot machen und den notfalls wieder zurückspielen
Dazu braucht man aber nicht zwingend eine VM. Gerade wenn man ZFS einsetzt hat man das Snapshot-Feature ja schon inklusive.
 
  • Gefällt mir
Reaktionen: polyphase
andy_m4 schrieb:
DDR4 macht übrigens auch schon ohne ECC schon zumindest einen gewissen Schmalspur-CRC-Check. Das ist natürlich nicht so gut wie ECC aber man steht nicht so "nackig" da wie noch bei DDR3.
Wieder was gelernt 👍
 
@polyphase
Das ist aber wirklich nur sehr rudimentär. Das stellt lediglich sicher (also im Rahmen dessen was CRC als Fehlererkennung hergibt) das ein geschriebenes Byte auch tatsächlich in der RAM-Zelle so landet wie es halt am Speicherinterface rein kommt.
Und das läuft auch transparent gegenüber dem System ab. Der Fehler wird zwar korrigiert, aber Du kriegst halt nicht mit wenn sowas auftritt.
 
  • Gefällt mir
Reaktionen: Banned
Schützt aber halt nicht gegen Bit Flips im RAM selbst (und das dürfte die häufigere Fehlerquelle gegenüber Fehlern bei der Übertragung dort hin sein, schätze ich).

Bei ECC wird m.W. außerdem auch noch mal nach dem Weg zwischen RAM und CPU beidseitig gecheckt.
 
andy_m4 schrieb:
Kurzum: Die Entscheidung für ECC kann man machen oder auch nicht, aber es hängt nicht davon ab ob man ZFS einsetzt oder nicht.
Mein Fehler, klar, es geht auch ohne, aber es sind halt zwei ganz unterschiedliche Ansätze bzw. Problemlöser, die sich gut ergänzen. Klar gibt es auch viele andere Fehlerquellen, aber ECC ist heutzutage grundsätzlich finanzierbar. Wir hatten im Unternehmensbereich nachweislich schon Bit Flips, die ECC korrigiert hat. Von daher hat ECC bei mir immer Prio.
 
Aber ZFS ohne ECC ist immernoch besser als ext4 ohne ECC, wie z.B. bei einer Synology Diskstation ohne btrfs Support 😉
 
Wenn du ne falsche Prüfsumme durch einen Bit Flip haben solltest, wäre das halt blöd. Wie wahrscheinlich das in der Realität ist, sei mal dahingestellt.

Ich schließe mich deshalb @djdf an: Wenn der Aufpreis überschaubar ist, gibt es mMn keinen rationalen Grund, darauf zu verzichten.
Leider macht es einen Intel durch die Streichung des Supports bei Celeron, Pentium und i3 heute deutlich schwerer. Alte Modelle sind aber noch verfügbar und die PRO-APUs von AMD gibt es auch hin und wieder zu annehmbaren Preisen.
 
Zuletzt bearbeitet:
Jupp, aber wenn man halt schon Hardware hat, welche halt kein ECC unterstützt, dann nutzt man halt diese.

Und besser als die alte Diskstation mit ext4 ist das ZFS ohne ECC allemal 😉
 
@polyphase
Hätte der Odroid H3 genug power um neben TrueNAS noch ein minicube zu betreiben?
Workloads wären ein Passwortmanager, Jellyfish (nur direct play, kein transcoding) und 1-2 webserver mit schlankem Fuss.
 
Sollte reichen.

Das Problem ist aktuell, wenn man Verschlüsselung nutzen möchte, geht das aktuell nur mit TrueNAS Core (FreeBSD). Bei TrueNAS Scale (Linux) funktioniert aktuell die AES Hardwarebeschleunigung nicht.

D.h. auch das man kein Kubernetes direkt auf TrueNAS Core nutzen kann, da nicht Linux basierend.

Wenn du keine Verschlüsselung benötigst, kannst du auch TrueNAS Scale verwenden.

Wobei TrueNAS Core aktuell sowieso performanter läuft, warum auch immer.
 
Zurück
Oben