[Projekt] Selbstbau-NAS mit ZFS - auf Proxmox Basis?

Badrig

Nostalgiker
Thread Starter
Mitglied seit
28.01.2006
Beiträge
8.726
Ort
Nürnberg
Hey zusammen, bei mir steht in näherer Zukunft ein größerer Umbau an. Durch mein Workstation Upgrade wurde folgende Hardware frei:
  • Xeon E-2176G
  • WS C246M PRO
  • 64GB DDR4 ECC
  • WD Black SN750 1TB
  • ASUS XG-C100C 10G NIC
Auf dieser Basis will ich ein neues NAS bauen, das mein QNAP ablösen soll. Erste Ausbaustufe sollen 54TB netto werden, ich denke an 4x 18 TB (Z1). In einer zweiten Stufe könnten weitere 4 HDDs@Z1 dazu kommen.
Meine erste Idee war Proxmox zu verwenden, weil ich damit aktuell gute Erfahrungen mache, darauf dann nur einen kleinen Dateiserver virtualisieren und evtl noch ein paar andere kleine VMs laufen zu lassen.
Wichtig sind vor allem Sicherheit und auch Geschwindigkeit.

Konkrete Fragen:
  • Ist es clever das ZFS direkt in Proxmox anzulegen?
  • Welche VM oder LXC wären geeignet für einen kleinen SMB-Dateiserver?
  • Gibts an der Hardware etwas auszusetzen? (außer dass ich ohne IPMI auskommen muss)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Bei der Festplattengröße und Kriterium "Sicherheit" verbietet sich eigentlich ein Z1 ...

Proxmox ZFS: Geht; Vorteil: Du musst keine HBA/Disks durchreichen an VMs; Nachteil: keine GUI / nette Verwaltungstools.
VM/LXC: Das übliche - OmniOS+napp-it, TrueNAS, XigmaNAS, OMV, ...
Hardware: Die consumer nvme scheint mir eher überflüssig.
 
Danke. Ich muss noch dazu sagen, dass es das komplette NAS regelmäßig gebackupt wird auf einen zweiten Server. Was wäre die Alternative zu Z1? Z2 bei größeren vdevs?
Die Sache mit der GUI wäre tatsächlich nett, aber der zusätzliche Aufwand macht es irgendwie wieder unattraktiver als das, was die GUI an Vorteilen bringt.

Die genannten Beispiele für VM/LXC schau ich mir mal an, danke!

Die SSD liegt einfach noch rum, ich würde jetzt nicht extra eine neue kaufen 🤷‍♀️
 
Wird eigentlich eine Storage-VM benötigt wenn einfach auf Proxmox Ebene ZFS verwendet wird? Als Alternative könntest du dir ggf. TrueNAS Scale ebenfalls auf Debian 11 Basis anschauen. Es werden Docker und virtuelle Maschinen (KVM) OOTB unterstützt.
 
Danke. Ich muss noch dazu sagen, dass es das komplette NAS regelmäßig gebackupt wird auf einen zweiten Server. Was wäre die Alternative zu Z1? Z2 bei größeren vdevs?
Bei wirklich regelmäßigen Backups könnte Z1 durchaus OK sein - Du musst nur damit leben können, dass ggfs beim resilver eine zweite Platte und damit der Pool Hops geht (und Du dann die 54TB aus dem Backup wieder einspielen musst). Du musst also eine lange downtime in Kauf nehmen können.
 
Ich habe bei mir etwas ähnliches laufen, allerdings mit itx Board.
Ansonsten habe ich es so gemacht, dass ich auf die nvme proxmox und meine vms packe und den kompletten SATA Controller an eine Truenas VM durchreiche.
Vorteil für mich ist, dass ich wie auf meinen anderen Kisten auch, erstmal proxmox als Basis habe, trotzdem aber die zfs Verwaltung über truenas mache.

Wenn im worst case die nvme abraucht, stelle ich einfach eins der täglichen Backups her und gut ist.
 
Ich hab nur gelesen, dass die Performance bei einem virtualisierten FreeNAS/TrueNAS nicht der Hit sein soll. Sonst wäre das natürlich auch eine Option. Und überhaupt, wie schneidet ZFS eigentlich performancemäßig ab (Z1 vs Hardware-Raid5)?
 
Wenn Du die SSD/HDD per Passthrough über einen Hostbusadapter in die VM durchreichst, und dieser hinreichend Ram zuweist, hast du annähernd native Performance wie direkt am Blech.
Zumindest bei ESXI ist das der Fall. Bei Proxmox kann ichs mangels Erfahrung damit nicht einschätzen.

ZFS-Vorteile: Massiv Prüfsummen, copy-on-write Dateisystem (=>kein Write-Hole). ZFS integriert Volume-Manager und Dateisystem in eins, so dass es im Gegensatz zu einem Raidcontroller jederzeit weiss,
wo welche Datenblöcke und deren Redundanz sind.
=> Generell mehr Verwaltungsbedarf als bei einem einfachen Dateisystem auf nem Hw Raid5, da ZFS in erster Linie auf Datenintegrität ausgelegt ist. Wird aber in der Regel kompensiert durch den großen Ram-Cache (ARC) und die Schreibstrategie, so dass ZFS bei ordentlicher Ausstattung sehr performant sein kann. Insbesondere Random Schreibvorgänge werden nach Möglichkeit durch den Ram-Cache serialisiert.

Bei 18TB-Platten würde ich aber wie Asche77 von Raid5/Z1 abraten und zu Raid6/Z2 raten.

Die Aquantia 10G-NIC, wenn sie läuft mit dem OS/Hypervisor der Wahl, fein. Aber, ich formulier es mal so: wäre nicht meine Wahl.
 
Zuletzt bearbeitet:
Wird eigentlich eine Storage-VM benötigt wenn einfach auf Proxmox Ebene ZFS verwendet wird? Als Alternative könntest du dir ggf. TrueNAS Scale ebenfalls auf Debian 11 Basis anschauen. Es werden Docker und virtuelle Maschinen (KVM) OOTB unterstützt.
Hmmm....
Proxmox basiert auf Debian, TrueNAS Scale ebenfalls
Könnte man da nicht beides kombinieren?
Oder bringt TrueNAS Scale eventuell sogar die gleiche Virtualisierung von Proxmox schon mit?
Soweit ich das sehe haben beide KVM für VMs
Nur bei den Containern gibt es unterschiede - LXC vs Docker - wobei Docker zumindest bei der normalen TrueNAS Version nicht mehr dabei ist bzw. über eine zu installierende Debian VM hinzufügbar ist.

Demanch wäre TrueNAS Scale das "bessere" Proxmox?
(Vermutlich sehe ich das zu einfach)
 
TrueNAS SCALE soll in der Tat ein "besseres" proxmox werden, daher sowohl storage als auch Container als auch VMs unter einem Dach abbilden. (Bei proxmox ist zumindest storage nur rudimentär umgesetzt)

Dafür ist proxmox frei und bewährt, TrueNAS SCALE gerade erst beim ersten Release Candidate.
 
Storage ist immer "mission critical" - sollte immer laufen. Je mehr Funktionen man dazu packt desto mehr gefärdet man dessen Funktionsfähigkeit. Ein Storageserver der weitere Dienste bereitstellen muss ist dann im Fall der Fälle beim kleinsten Problem offline, braucht Wartung oder es stehen kritische Bugfixes an - natürlich mit Reboot und hoffen dass alles nacher wieder läuft..

Sicherheitsbewusste Windows Nutzer werden daher kaum auf >14 Tage uptime kommen.
OmniOS/Openindiana uptime > 1000 Tage z.B ist aber keine Seltenheit und im Vergleich nur ein relativ kleines Sicherheitsproblem.

Wirklich stabiles Storage ist minimalistisches "Storage only" und eher abseits vom Mainstream "unter Dauerfeuer" Linux und Windows.
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: you
Das Projekt lag auf Halde, weil ich umgezogen bin. Nun ist mir auch noch eine HDD abgeraucht und hat dabei mein Raid geschrottet (soviel zu Raid5 verkraftet einen Ausfall 🤡 ). Daher wird das Thema jetzt wieder aktuell.
TrueNAS Scale wird tatsächlich immer interessanter, aber weniger für Virtualisierung als für den klassischen Gebrauch. Tendiere zur oben vorgeschlagenen Variante mit Proxmox, Hostadapter durchreichen und TrueNAS Scale drauf. Dann würde ich meinen Raid-Adapter einfach beibehalten und auf IT-Mode setzen.

Muss mir jetzt noch eine Festplattenorganisation inkl. evtl Neuanschaffungen überlegen und ich suche insbesondere nach einem passenderen Gehäuse. Mein Define R5 ist voll.
 
Warum doppelt gemoppelt mit proxmox und TrueNAS SCALE ??

Das sind doch beides Linux (Debian) KVM virtualisierer mit ZFS.

Da würde ich einfach TrueNAS SCALE verwenden für alles ...
 
Ich hab schon einen Proxmox Server und kann so alles zentral managen/überwachen. Außerdem benutze ich nur LXC Container, weil ich Docker ganz schrecklich finde.
So bleibt jedes OS bei seinem Spezialgebiet.
 
Warum dann nicht einen LXC Fileserver? Oder gibt's da keinen mit netter GUI wie TrueNAS?
 
Was erhoffst du dir von Scale? Ich hätte da jetzt auch ehr Proxmox + TrueNAS genommen und nicht doppelt gemoppelt...
 
Scale nur, wegen Debian. Mit Linux bin ich vertrauter, wenn mal was schieflaufen sollte. Ich glaube, primär ists eine Gefühlssache.
Anderer Punkt dafür: Ich hab hier Aquantia Karten, für die es unter BSD nur einen experimentellen Treiber gibt.
Warum dann nicht gleich Scale als Host? -> Weil ich eine Funktionstrennung haben will - wegen einer schlechten Erfahrung, wo der Host auch direkt NAS war. NAS soll NUR NAS-Dinge tun und VM-Host soll nur Host-Dinge tun. Ist das so abwegig?
 
Es klingt abwegig, auf einem linux-zfs-hypervisor eine fette weitere linux-zfs-hypervisor-VM, die als eierlegende wollmilchsau beworben wird, nur für NAS Dienste zu verwenden.

Warum dann nicht zumindest etwas schlankes, das nur NAS macht, zB TrueNAS (ok, auch nicht wirklich schlank), xigmaNAS, OMV, OmniOS+napp-it, ... Oder idealerweise einen LXC container, der via Samba die NAS Dienste bereit stellt?
 
Kritische Sachen will ich nicht als Container laufen lassen.
OMV hat kein ZFS und der Rest ist halt BSD oder sogar Solaris 🤷‍♂️ Also ist eher Ausschlussverfahren.
 
Mal ein Update zu der ganzen Sache, die mittlerweile Form angenommen hat:

Mein NAS habe ich nun doch wieder durch ein QNAP (aber mit ZFS) ersetzt. Das ganze hier wird nun nur mein Backup-Server.
Nach einem Versuch mit Proxmox, der daran scheiterte, dass ich ja keine einzelnen Laufwerke durchschleifen kann (stupid me), landete ich nun doch bei TrueNAS Scale.
Hardware ist nun folgende:
  • Xeon E-2176G
  • WS C246M PRO
  • 64GB DDR4 ECC
  • 2x ADATA SP900 256GB @ Mirror fürs System
  • 2x WD Blue 3D NAND 1TB @ Mirror für VMs (und co)
  • Onboard SATA Controller mit 8 SATA
  • kleiner ASM1061 SATA Controller für die 2 ODDs (zum Durchschleifen an die VM)
  • LSI 9207-8i HBA mit 8 SATA (kommt heute)
  • 10x 12-14TB MG07 Toshiba Enterprise HDDs @ Z2
  • ASUS XG-C100C 10G NIC
  • Fractal Design Define 7 XL (das einzige Gehäuse mit genug HDD-Platz

Aufgesetzt hab ich bisher nur TrueNAS ohne Storage und eine Ubuntu-VM für die ODDs (falls man mal eins braucht).
Einen Ersatz-DNS-Server werde ich wohl in Docker zusammenschustern. Dann folgt noch das Storage, wenn der HBA eingebaut ist, die Freigaben und die Automatisierung der Backups via Rsync.
 
Öh... das heisst Du nutzt nun TrueNAS Scale auf'm Blech quasi nur als Hypervisor und Container-Schleuder - und dadrauf dann noch eine Storage-VM? Die hat als Gast-OS dann was? Nochmal TrueNAS? :confused:

M.E. ist die Grundfrage, wie Du Dein Storage lösen willst. Wenn Du da am Ende bei Linux als OS rauskommst, brauchst Du im Zweifel keine Storage-VM, sondern kannst das dann mit der NAS-Lösung Deiner Wahl (was auch immer) direkt auf'm Blech umsetzen und nimmst halt dafür noch den linux-basierten Hypervisor Deiner Wahl...

Ansonsten: ZFS ist performancemäßig nicht an vorderster Stelle. Das nimmt man aber hin zugunsten all der anderen Vorzüge (zumindest die, die sich dafür entscheiden) und wenn man eine gewisse, definierte Performance anstrebt, wirft man halt im Zweifel das Projekt mit noch mehr/besserer Hardware zu, bis es passt (vor allem mit RAM und schnell(st)en SSDs). :d

Mal über den Daumen: Mit 4 HDDs kommst Du vermutlich so irgendwo bei 350-450MB/s raus - best case (large files, keine sync-writes). 10Gbit sättigst Du damit also nicht.
 
Zuletzt bearbeitet:
Nö, das macht TrueNAS Scale dann natürlich direkt selbst. 10 HDDs mit Z2. Und es sind ja nicht 4 HDDs sondern eben 10. Mein QuTS NAS mit 8 HDDs reizt die 10GBit schon aus, das sollte hier dann auch klappen.
Ich bin nur noch am Überlegen welchen Kompressionsstandard ich nehme. LZ4 oder vielleicht doch ZSTD, wobei ich las, dass ZSTD beim Schreiben auf 1GBit/s limitiert. Vielleicht teste ich das dann einfach erstmal aus.
 
Per default: lz4 am Pool. Macht man nix falsch damit.
Auf Datasets nur für große Medienfiles kann man dann über ausschalten nachdenken, auf cold storage datasets evtl. ZSTD.

Da ich noch FreeBSD 11 einsetze: bei mir immer lz4 oder bei Medienfiles eben ohne Kompression.
 
Zuletzt bearbeitet:
Das ist eben die Frage. Hier wäre es eben nur das Backup, d.h. Geschwindigkeit wäre nicht so kritisch wie am NAS. Wie gesagt, ich werds mal mit Testdaten ausprobieren.
 
Ich habe mich für ZSTD entschieden, es ist nun alles zusammengebaut und aufgesetzt. Nun kopiert der erste Schwung.
Bilder:
oculus1.jpg
oculus2.jpg
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh