OS für All-In-One Server?

Tomson124

Enthusiast
Thread Starter
Mitglied seit
30.07.2013
Beiträge
84
Hatte ja vor paar Monaten ein Thema bzgl. Kaufberatung hier, mittlerweile sind die Komponenten (abgesehen von HDDs und SSD) in dem ein oder anderen Sale zusammengekauft und zusammengebaut.
Bevor ich allerdings jetzt HDDs und SSDs kaufe, schien es mir sinnvoll mir bzgl. dem Betriebssystem Gedanken zu machen, da z.B. TrueNAS bzw. ZFS ja doch etwas "Vorplanung" braucht bzgl. Speichermedien.

Ich wechsel ja von einem QNAP TS-453D welche mit Docker, VM und NAS einfach überfordert ist. In der laufen aktuell 3x 8TB welche ich sehr warscheinlich nicht übernehmen werde in den neuen, sondern entweder das ganze QNAP als Offsite bei meinem Bruder unterbringe oder evtl. als Teil der Backup-Strategie weiternutze.
Aktuell hatte ich für den neuen Server an 2x 20TB im Mirror (sollte vorerst locker reichen und spart etwas Strom im Vergleich zu 3x HDDs, grade weil die 2,5Gbit LAN auch mit der Leistung einer HDD schon gedeckt sein dürften), ne einzelne HDD für Plex/Jellyfin (Größe weiß ich noch nicht, evtl. eine der 8TB) und eine 2TB NVMe für Docker und VMs.

Die Frage die sich mir jetzt stellt ist gehe ich mit Proxmox, Proxmox+TrueNAS, TrueNAS oder Unraid...
Prinzipiell ist die Data-Resilience bei ZFS besser (wobei Unraid mittlerweile ja auch ZFS kann), was man so hört aber Docker/Kubernetes bei TrueNAS ein vielfaches umständlicher als bei Unraid. Dafür wiederrum sind Berechtigungen und Freigaben feiner machbar in TrueNAS.
Bei Proxmox bin ich mir noch sehr unsicher, hatte mich damit einmal auf einem Mini-PC etwas gespielt, wirkt mir aber nach "etwas zu viel des guten", ich bastel zwar gern, aber zumindest die NAS-Funktionalität soll eigentlich möglichst einfach und stabil funktionieren (so wie es mit dem QNAP auch der Fall war, auch wenn man mal mit den Docker-Containern oder so was verbockt hat :d )

Prinzipiell hätte Unraid auch den Vorteil die HDDs in den SpinDown schicken zu können, was aber warscheinlich selten bis gar nicht vorkommt wegen Überwachungskameras.

Bin da auf Erfahrungsberichte bzw. Empfehlungen gespannt. :)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
All in One bedeutet dass man einen Server hat der die beiden Hauptfunktionen Virtualisierung und NAS abdeckt. Als Virtualisierungsplattform war bis vor Kurzem ESXi die Nummer 1. Ist immer noch die resourcensparendste und für mich vom Handling angenehmste Option und hat für Windows Gäste die beste Performance. Wegen der Politik von BroadCom ist das aber mehr und mehr keine so interessante Option für Home & Lab, auch wenn ESXi8 wieder frei ist.

Neben Windows Hyper-V ist vor allem Proxmox die aktuelle Hauptalternative zu ESXi vor allem weil ZFS immer dabei ist, es exzellente VM Optionen hat und das mit einer Web-GUI auch komfortabel nutzbar ist. Für mich ist Proxmox damit die eierlegende Wollmilchsau unter Linux.

Für den NAS Part bietet die Proxmox GUI zu wenig. Da ist man schnell auf der Console oder man ergänzt die Proxmox GUI mit Cockpit oder napp-it cs um Storage Management. Man kann auch ein Storage OS virtualisieren (*Linux, OmniOS, TrueNAS, Windows). Das ist aber OS Vollvirtualisierung und kostet damit erheblich Resourcen und selbst für ein einfaches SMB Share muss man erst ein vollwertiges OS hochfahren.

Spindown würde ich ignorieren. Für VMs oder Videoüberwachung nicht tauglich, auch ansonst dauert es immer sehr lange bis Platten aufwachen. Setup von ProxMox AiO mit oder ohner Storage-web-gui: www.napp-it.org/doc/downloads/proxmox-aio.pdf
 
Ich würde dass erstmal gar nicht so in einen Topf schmeißen.
Proxmox ist ein Hyperscaler Hypervisor und hat erstmal nichts mit einem NAS zu tun.
TrueNAS Scale, Unraid, OMV, … sind NAS-OS die Funktionen haben um zusätzlich als Hypervisor zu fungieren.
Grundsätzlich kann man natürlich Proxmox Storages direkt auch als NAS nutzen und z.B. über SMB freigeben. Proxmox selbst bietet da halt nur eingeschränkt Komfort auf der Weboberfläche, sprich da ist die Konsole gefragt. Aber auch da gibt es Lösungen WebUIs per Container nachzurüsten.
Ansonsten ginge wie du schon auf der Liste hast z.B. Proxmox als Hypervisor mit einer TrueNAS oder OVM VM. Da musst dann aber wieder schauen wie du den Storage an die VM durchreichst. Das hat auch so seine Tücken.
Kommt also drauf an was du genau möchtest und worauf du Wert legst.

Edit: @gea war etwas schneller ;)
 
Zuletzt bearbeitet:
Ich weiß gar nicht warum Proxmox so oft als "NAS" missbraucht wird. Offiziell, Proxmox ist wie MZuki bereits schreibt ein Hypervisor, OMV, Unraid etc. ein NAS System das eben auch Docker und Co. betreiben können. Proxmox liebe und nutze ich zusätzlich, aber für die meisten zuhause reicht doch ein normales NAS mit Docker. Ich z.B. nutze für den Daily Job meiner Familie und mir nur einen Ubuntu-Server LTS, SMB-Server und Docker mit Portainer und Cockpit-Web gemanagement. Unter cckpit-Web habe ich zudem noch per Qemu eine Maschine virtualisiert laufen. Das Ding benötigt kaum Ressourcen. Bei Proxmox, gerade mit ZFS benötigt wesentlich mehr Hardwarepower (=größeres Loch in der Geldbörse) und vor allem wenn möglich Enterprise SSD für einen zuverlässigen Betrieb. Alles andere geht auch, macht aber bei einem Stromausfall oder Dauerbtrieb z.B. evtl. weniger Spaß. Die Ausfallrate ist dann höher. Zudem ist der administrative Aufwand um ein vielfaches höher. Für alle die als Hobby kein Linux Server verwalten und administrieren wollen ist Unraid, wenn auch Lizenzkosten drauf gehen, die einfachste und sicherste Lösung um Dockerdienste auf normale Hardware laufen zu lassen. OMV oder eben ein reines Ubuntu/Debian-Server machen das auch, erfordern aber auch eben mehr Kenntnisse und wäre kostenlos. Genau das nimmt UNRAID einem ab, dafür eben gegen Geld.
 
Zuletzt bearbeitet:
Für alle die als Hobby kein Linux Server verwalten und administrieren wollen ist Unraid, wenn auch Lizenzkosten drauf gehen, die einfachste und sicherste Lösung um Dockerdienste auf normale Hardware laufen zu lassen.
Das stimmt wahrscheinlich, auch wenn ich UnRAID selbst noch nicht verwendet habe.

Ich wollte ZFS nutzen. Das war früher bei UnRAID entweder nicht möglich oder steckte noch in den Kinderschuhen. Den aktuellen Stand kenne ich nicht. Daher habe ich mich für TrueNAS Scale entschieden (zuvor hatte ich OMV mit ZFS und TrueNAS Core genutzt).

UnRAID scheint darüber hinaus für Home-User interessant zu sein, die extrem viele Daten auf mehreren Festplatten gespeichert haben. Durch seine Kernfunktionalität ermöglicht UnRAID das Energiesparen bei vielen Festplatten, indem es die Möglichkeit bietet, Festplatten gezielt in den Ruhezustand (Spin-Down) zu versetzen, wenn sie nicht gebraucht werden. Dieses UnRAID-Konzept funktioniert aber ggf. nur eingeschränkt mit ZFS und ist für mich auch nicht relevant, da mir ein ZFS-Mirror aus zwei HDDs ausreicht.

Docker scheint in UnRAID problemlos zu laufen. Ich bin jedoch skeptisch, ob es in UnRAID Features wie „hostPathValidation” in TrueNAS Scale gibt. Dieses Feature verhindert, dass ein Dataset gleichzeitig für File-Sharing (z. B. SMB oder NFS) und als HostPath für Apps verwendet wird, wodurch Probleme entstehen könnten.

TrueNAS Scale läuft meiner Erfahrung nach als reines NAS absolut unkompliziert und wartungsarm. Ich nutze es aktuell auch nur als NAS. Früher hatte ich Kubernetes genutzt, bin dann aber auf Docker in Jailmaker umgestiegen, da Kubernetes deutlich mehr Ressourcen zieht (was sich auch am Stromverbrauch des Systems bemerkbar macht) und Features bietet, die für normale Nutzer nicht relevant sind. Glücklicherweise hat man sich bei TrueNAS Scale daraufhin von Kubernetes verabschiedet und setzt auf Docker. Docker soll gut laufen, auch wenn ich das eine oder andere Mal gelesen habe, dass es besser sei, nicht die TrueNAS-eigenen Apps, sondern normale Docker-Container zu nutzen. In diesem Zusammenhang ist vielleicht dieses Video interessant:

TrueNAS Scale ist eine Appliance. Änderungen sollten nur über die UI vorgenommen werden. Dort können auch viele eigene Anpassungen vorgenommen werden, beispielsweise Init-Scripte („powertop --auto-tune” in meinem Fall) oder Auxiliary Parameters für Anpassungen, die über die vorgesehenen Profile bzw. GUI-Optionen hinausgehen. Ärgerlich ist es jedoch, wenn solche Optionen verschwinden, wie es bei den Auxiliary Parametern für SMB geschehen ist. Sie sind wohl noch vorhanden, nur halt nicht mehr in der GUI. Normalerweise braucht man das aber nicht. Ich habe jedoch festgestellt, dass die Profile und Optionen, die für SMB-Shares zur Verfügung stehen, nicht optimal für macOS sind. Das ist mir aufgefallen, als ich mich ein wenig mit der smb.conf (bei TrueNAS smb4.conf) beschäftigt habe. Sie sind in Ordnung, aber es geht anscheinend noch besser. Aber solche Anpassungen sind über die GUI nicht mehr möglich. Das wird aber vielen nicht auffallen und in der Regel sind die vorgesehenen SMB-Profile auch in Ordnung.

Im Bereich der Virtualisierung und Container-Technik gab und gibt es mehrere Umbauten bei TrueNAS Scale. Das sorgt auch für Verunsicherung. In diesem Bereich ist Proxmox einfach besser, ausgereifter und bietet mehr Möglichkeiten. Dort scheint es kein „Hin und Her” zu geben.

Aktuell tendiere ich dazu, die vorgeschlagene Lösung von gea zukünftig einzusetzen – sofern ich die Zeit für eine Umstellung finde –, d. h. Proxmox als NAS in Verbindung mit Napp-IT CS. Ich glaube, dass ich damit unter dem Strich besser fahre und mehr Optionen habe, ohne auf die für mich relevanten Funktionen von TrueNAS Scale verzichten zu müssen. Erfahrungen damit habe ich allerdings noch nicht und es bedeutet sicherlich mehr Aufwand, zumindest initial bei der Einrichtung.
Wenn bei TrueNAS Scale in zukünftigen Versionen allerdings wieder etwas Grundsätzliches bei der Container- und VM-Technologie geändert werden sollte, hat man dann ggf. auch Aufwände.
 
Zuletzt bearbeitet:
Im Prinzip ist es einfach: die Produkte für das verwenden, für das sie primär entwickelt wurden, also...
- z.B. Proxmox als virtualisierer
- TrueNAS, zVault, whatever als Fileserver
- für Docker/APPs keine LXCs verwenden, sondern eigene Debian VMs mit Portainer als Docker
- für umfangreichere/komplexe CT Verbünde oder bei vielen Daten eigene VMs verwenden, (z.B. für Nextcloud etc)
Fertig.

Dann ist alles modular und weitgehend voneinader unabhängig.
 
Hat alles Vor und Nachteile.

Wenn man z.B. Proxmox wegen seiner umfangreichen VM Fähigkeiten, der web-gui für VM handling und dem Proxmox Backupserver möchte und dann eine Storage VM virtualisiert dann hat das auch Nachteile

- Full OS Virtualisierung (mit Linux, OmniOS oder Windows Storage VM kostet ne Menge Resourcen)
- man muss die VM immer hochfahren, selbst für ein simples SMB Share
- schlechtere Performance für VM Storage (mit NFS oder SMB over ip geringer)
- Bugs und Security (Man muss zwei große Betriebssysteme pflegen)

Wenn man schnellen VM Storage lokal unter Proxmox ZFS anlegt und die Storage VM mit ZFS nur für andere Daten und Backup nutzt
- Man braucht RAM für schnelles ZFS zweimal und muss sich zweimal um optimierte ZFS Pools kümmern.

Ich bevorzuge da AiO mit Proxmox als VM Server und Proxmox als Barebone NAS und "sonstiges" als Container oder Vollvirtualisierung.
 
Weils mir beim Lesen weh tut: Ein Hyperscaler ist etwas ganz anderes als ein Hypervisor.
Sorry, der schlaukoter musste raus...
 
- Full OS Virtualisierung (mit Linux, OmniOS oder Windows Storage VM kostet ne Menge Resourcen)
Keine Ahnung was du immer mit deinem "kostet ne Menge Ressourcen" hast? Das kostet ein bisschen RAM, mehr nicht.

- man muss die VM immer hochfahren, selbst für ein simples SMB Share
Man lässt die VM gleich nach dem Systemstart automatisch starten und dann lässt man sie laufen.

- schlechtere Performance für VM Storage (mit NFS oder SMB over ip geringer)
Mag sein, das da ein bisschen Performance verloren geht. Aber immer nur auf Performanceverlusten rumzureiten hilft auch niemandem. Am Ende stellt sich dann raus, das da sowieso nur via 1Gbit Netzwerkverbindung zugegriffen wird...

Sobald man halt auch nur eine "echte" VM braucht, bietet es sich halt an gleich Proxmox untendrunter zu setzen und das NAS-System gleich mitzuvirtualisieren.
 
Weils mir beim Lesen weh tut: Ein Hyperscaler ist etwas ganz anderes als ein Hypervisor.
Sorry, der schlaukoter musste raus...
Hast du absolut recht. Danke fürs korrigieren. Den "Wald vor leuter Bäumen nicht sehen" und so. War kurz durcheinander ;)
 
Keine Ahnung was du immer mit deinem "kostet ne Menge Ressourcen" hast? Das kostet ein bisschen RAM, mehr nicht.
Das bisschen bedeutet RAM und CPU für 1x 64 BIT ZFS OS vs 2x 64 Bit ZFS OS
.. und nicht jeder hat 12Core+ und 128GB+

Man lässt die VM gleich nach dem Systemstart automatisch starten und dann lässt man sie laufen.


Mag sein, das da ein bisschen Performance verloren geht. Aber immer nur auf Performanceverlusten rumzureiten hilft auch niemandem. Am Ende stellt sich dann raus, das da sowieso nur via 1Gbit Netzwerkverbindung zugegriffen wird...

Bei AiO und VMs auf lokaler Storage VM gibts kein physisches LAN.
Da ist es direkter lokaler Proxmox Plattenzugriff (kann ohne Latenz mehrere GByte/s bei NVMe sein) vs NFS/SMB ip traffic über die virtualisierte Nic

Sobald man halt auch nur eine "echte" VM braucht, bietet es sich halt an gleich Proxmox untendrunter zu setzen und das NAS-System gleich mitzuvirtualisieren.

Kann man machen, gibt halt auch einen anderen Ansatz...
 
Zuletzt bearbeitet:
ZFS benötigt, egal ob Proxmox oder nicht generell mehr RAM um performant zu laufen. Außerdem soll man nicht mehr als 80% der Kapazität befüllen. Ich merke von der Performance auf Proxmox keinen wirklichen Nachteil gegenüber meinem Baremetal Ubuntu Server, nur läuft der Proxmox halt mit wesentlich mehr Hardwarereserven gegenüber meinen Baremetal-Server. Mit Proxmox und Co. ist man halt wesentlich flexibler. Alleine ein System mal schnell auf einen anderen Storage zu verschieben oder auomatisiert per PBS die VMs sichern und schnell zurückspielen, da komme ich mit meinem Baremetal-Server nicht mit. Mit TrueScale habe ich keine Erfahrung, ich Schraub noch lieber selbst im System und betreibe meine NAS Funktionalität lieber manuell aka SMB Fileserver etc. klassisch noch per conf Datei. :-)
 
Das bisschen bedeutet RAM und CPU für 2x 64 Bit OS
.. und nicht jeder hat 12Core+ und 128GB+
Eine Gast-VM die nichts tut, braucht auch so gut wie keine CPU-Leistung. RAM brauchts nur soviel wie das nackt gebootete OS eben braucht.
Ein gebootetes Windows 10 braucht bei mir ~1,5GB RAM, ein gebootetes Headless-Linux braucht <500MB RAM... Und dann kommt halt noch das dazu, was als Anwendung darauf laufen soll.
Man braucht dafür also auch bei weitem keine 12 Kerne und/oder 128GB.
Hast du überhaupt schonmal einen Hypervisor mit einem oder mehreren Gästen laufen lassen und geguckt was das wirklich braucht?

Ich hab Proxmox auf einem 4-Kerner mit 64GB RAM, zweitweise mit bis zu 5 VMs gleichzeitig. Ist überhaupt kein Problem und die 64GB RAM hab ich bisher noch nichtmal wirklich gebraucht, 32GB hättens soweit auch getan.
 
Die Frage ist was wann die VMs alles so machen. Meistens langweilen dich die VMs ja, man kommt also auch mit einem 4 Kerner sehr weit. Das langsamere sind zum Schluss die HDDs und wie man diese als Storage nutzt. VMs zum Beispiel sollte man lieber lassen und nir auf ssd/nvmes laufen lassen. Selbst auf meinem N100 hatte ich testweise Proxmox laufen, auch das ging mit einigen VMs. Ich bin aber trotzdem der Meinung, man kann mit sehr wenig Hardwarepower einen Baremetal Server zusammen mit Docker doch sehr viel anstellen. Wer mehr Flexibilität möchte kommt an einen Hypervisor halt nicht vorbei.
 
Ist jetzt bissle abgedriftet aber ich finde die initiale Frage von Tomson ebenfalls immer noch spannend.
Wie macht ihr das denn nun und warum?
ZFS Pools mit z.B. Cockpit oder halt Konsole als NAS Lösung?
Oder habt ihr dedizierte Platten/nen PCI Controller den ihr an z.B. eine TrueNAS VM durchreicht?

Ich überleg auch schon eine Weile von meiner Synology + Deskmini/Proxmox Lösung auf eine All-In-One Lösung mit NVMEs zu gehen weil ich gar nicht so viel Platz brauch.
Bisher hätte ich für den Heimgebrauch zu Unraid + entsprechende Docker für Immich etc. tendiert.
 
Die Frage ist was wann die VMs alles so machen.
Die Frage ist IMMER, was die Anwendungen halt so machen/brauchen. Das OS in einer VM macht ja, wenn sonst nichts drauf läuft erstmal so gut wie überhaupt nichts. Der Overhead einer VM ist also erstmal nur der RAM den das OS in dieser VM braucht um vor sich hinzuidlen.
Container wie Docker fallen da natürlich etwas sparsamer aus, die benötigte CPU-Leistung hängt dort aber genauso davon ab, was in dem Docker halt laufen soll.

Das langsamere sind zum Schluss die HDDs und wie man diese als Storage nutzt. VMs zum Beispiel sollte man lieber lassen und nir auf ssd/nvmes laufen lassen.
Das hat aber jetzt mal überhaupt nichts damit zu tun, ob man auf einen Hypervisor setzt und die NAS-Funktionalität aus einer VM raus zur Verfügung stellt, oder ob man ein NAS-System direkt auf das Baremetal installiert.

Wie macht ihr das denn nun und warum?
Ich brauche kein "NAS", also weder riesige Speichervolumina, noch großartige Benutzerverwaltung, noch Backup, oder sonstwas.
Ich greife lediglich per SSH(FS) direkt auf den Proxmox-Host zu, wenn ich mal schnell irgendwelche Daten im Netzwerk ablegen muss/will.

Oder habt ihr dedizierte Platten/nen PCI Controller den ihr an z.B. eine TrueNAS VM durchreicht?
Wenn ich "komplette" NAS-Funktionalität bräuchte, wäre das eine weitere VM auf meinem Proxmox, weil Proxmox brauche/will ich aus anderen Gründen. Durchreichen würde ich dafür keine Platten, das gibt meine Hardware nicht her, aber klar, wenn man die Möglichkeit hätte, Storage auch durchreichen zu können, könnte man das natürlich auch tun. Vermutlich würde ich es aber nichtmal tun, wenn ich könnte, weil ich keinen Nachteil darin sehe das auch durch die Virtualisierung zu tun. Der limitierende Faktor wäre so oder so die Netzwerkverbindung.
 
Der Schlüsselfaktor ist "use case" und ZFS.
Nutzt man Proxmox als reinen Hypervisor mit lokalem ext4, so sind 4GB RAM für Proxmox + RAM für VMs ok.

Nutzt man Proxmox (oder ein anderes NAS OS mit ZFS) als Hypervisor mit lokalem ZFS, wird man schnell sehen, dass die ZFS Performance (bis auf sehr schnelle NVMe) sehr stark von dem RAM Schreib/Lesecache abhängt. Der ist per default 50% RAM Lesecache und 10% RAM Schreibcache. Will man schnelles lokales ZFS treibt das den RAM Wunsch des Proxmox Nutzers - auch mit jedem anderen OS mit ZFS schnell nach oben.

Nutzt man generell eine VM für ZFS Storage, gilt das nur für die Storage VM bei schlechterer Performance beim "lokalen" Storage Zugriff aus Proxmox über die virtualisierte nic. Nutzt man die Storage VM nur als Filer ohne Proxmox VMs darauf ist das auch kein Thema.
 
Zuletzt bearbeitet:
Wie macht ihr das denn nun und warum?

Nutze auch den AiO Ansatz mit napp-it/Solaris und durchgereichtem HBA, allerdings unter ESXi. Bei vSphere fast ein must-have, da es nur sehr eingeschränkte Storage-Funktionalität gibt. Bei einem Wechsel auf Proxmox würde ich das Konzept aber mitnehmen, das bisschen Overhead vom Filer wär mir egal. Hab ich testweise mal nested mit Openindiana am laufen.

Kommt bald mal ein zweiter Server dazu. Wird dann spannend mit zwei Filern. Echten Storage habe ich (noch) nicht, bislang tuckern vor allem die VMs auf dem Filer. Dann habe ich noch ein kleines Xigmanas mit mehreren Netzwerkschnittstellen, quasi als mehrbesseren USB Stick. Beim zweiten Server gibt es dann einen grösseren Storage. Aber Ziel ist es, den dann alle zwei Wochen mal anzuschmeissen um Daten und VMs zu sichern. Nackte Daten habe ich eh wenig, die liegen überall wild verteilt auf Platten, Grossteil auf der Workstation.
 
Der Schlüsselfaktor ist "use case" und ZFS.
Zusammengefasst: Wenn du ZFS brauchst/willst, brauchst du mehr RAM wegen dieses ZFS.

Spielt also nachwievor keine Rolle ob Proxmox ZFS mit NAS-VM, oder Proxmox mit einer NAS-VM mit ZFS oder ein NAS-OS mit ZFS auf Baremetal. Braucht so oder so mehr RAM weil ZFS halt.
 
Keine Ahnung was du immer mit deinem "kostet ne Menge Ressourcen" hast? Das kostet ein bisschen RAM, mehr nicht.
Das kostet auch CPU, und wenn die OpenZFS Version im Proxmox sowieso mit der in TrueNAS/zVault und wie sie alle heißen identisch ist, was machts für einen Unterschied, dafür nochmal eine unnötige Virtualisierungsschicht mit entsprechenden Nachteilen in Kauf zu nehmen ? Weil man sich ein bissl in die WebUI einfinden muss ?
 
Ich dachte immer, es sei gut Optionen zu haben. Dann schaut man sich an, was einem insgesamt am ehesten zusagt und macht es halt. Für sich. Mh.

Und im übrigen ist nur meine Variante die Richtige :d

Proxmox als Virtualisierer. Darauf VMs für meine in-house/docker services. Kein LXC. Und eine VM mit OmniOS/napp-it und durchgereichtem HBA als NAS.

Warum? Weil ich mich damit wohler fühle ;)

PS: Hier kommt immer wieder durch "bist du dumm? kannst du nicht lesen? was weisst du überhaupt?" ... eigentlich Schade, dass dieses eigentlich spannende Thema und die damit verbundene Diskussion durch persönliche Eitelkeiten schwer genießbar wird.
 
Ich denke man kann nur Empfehlungen geben und eigene Erfahrungen weiter geben. Vieles was hier geschrieben wird ist ja korrekt, nur was für sich einem passt muss man halt ausprobieren. Genau das macht aber Spaß, so viele Möglichkeiten:-)
 
  • Danke
Reaktionen: you
Zusammengefasst: Wenn du ZFS brauchst/willst, brauchst du mehr RAM wegen dieses ZFS.

Spielt also nachwievor keine Rolle ob Proxmox ZFS mit NAS-VM, oder Proxmox mit einer NAS-VM mit ZFS oder ein NAS-OS mit ZFS auf Baremetal. Braucht so oder so mehr RAM weil ZFS halt.

So isses. Nur der Tod ist umsonst und der kostet das Leben..
Dafür haben neuere Dateisysteme wie ZFS massive Vorteile gegenüber ext4 oder ntfs.

- kein defektes Dateisystem oder Raid nach Absturz beim Schreiben (Copy on Write)
- kein bitrot/ silent error Problem mit auto repair erkannter Fehler (mit Redundanz)
- erweiterte Raid Level wie Z3 oder Draid
- schnelles Backup inkl offener Dateien mit ZFS Replikation
- snap versionierung ohne initialen Speicherverbrauch oder Verzögerung
- immer validierte Daten (Prüfsummen auf Daten und Metadaten)
- Hybrid Pools mit special vdev
- transparentes compress, dedup, direct io oder encryption per Dateisystem einstellbar
- sicheres sync write per Software (statt hardware raid+bbu)

Kurzum: heute unverzichtbar, einfach "Stand der Technik"
 
Neuerdings könnte man auch mal TrueNAS als container probieren: https://www.truenas.com/docs/scale/25.04/scaletutorials/containers/
Edit: Hab das wohl missverstanden - hier geht es um Container-Support UNTER TrueNAS, nicht TrueNAS IM Container
Hab ich noch nicht getestet, aber das könnte deutlich resourcenschonender sein, als ne Extra VM und man muss nur noch den Storage-Pool in Proxmox verwalten, wenn man keinen extra controller möchte und diesen dann in den Container durchmounten um einfaches Freigabenmanagement zu haben.

Ich persönlich hab schon viel ausprobiert und bin am Ende auch bei Proxmox gelandet. Storage konfiguriert man üblicherweise nicht so häufig, aber Virtualisierung und Systemmanagement braucht man regelmäßig, daher war mir der Zusatzaufwand für das Storagemanagement auf der Konsole lieber, als jeden Tag mit TrueNAS VM-Gefrickel zu haben.

Dennoch: Proxmox hat ne steile Lernkurve und wenn man schnell fertig werden will, sollte man sich das gut überlegen.
 
Wenn ich "komplette" NAS-Funktionalität bräuchte, wäre das eine weitere VM auf meinem Proxmox, weil Proxmox brauche/will ich aus anderen Gründen. Durchreichen würde ich dafür keine Platten, das gibt meine Hardware nicht her, aber klar, wenn man die Möglichkeit hätte, Storage auch durchreichen zu können, könnte man das natürlich auch tun. Vermutlich würde ich es aber nichtmal tun, wenn ich könnte, weil ich keinen Nachteil darin sehe das auch durch die Virtualisierung zu tun. Der limitierende Faktor wäre so oder so die Netzwerkverbindung.
Wer TrueNAS virtualisiert, sollte die Platten durchreichen. Von allem anderen, insbesondere ZFS auf ZFS, wird abgeraten. Einige User mussten anscheinend schon teueres Lehrgeld zahlen, weil sie es dennoch gemacht haben. Entsprechende Threads dazu sollte man in dem TrueNAS-Forum, Reddit etc. finden.
Es ist natürlich ungünstig, wenn das Durchreichen mit der vorhandenen Hardware nicht möglich ist, die Konfigurationsmöglichkeiten eingeschränkt sind oder ein zusätzlicher Controller gekauft werden muss (insbesondere wenn der Server möglichst wenig Strom verbrauchen soll).
 
Wow, da hab ich mit meiner Frage ja quasi in ein Wespennest gestochen :d
Auf jeden Fall schon mal vielen Dank für die vielen Eindrücke, wenn auch vieles davon glaube ich an meinem Use-Case vorbei geht.

Nachdem ich hauptsächlich Docker Container zusätzlich zum NAS brauche und eine VM wenn überhaupt nur sporadisch mal für einen Gameserver (wenns Windows sein muss) und die Lernkurve bei Proxmox recht steil ist, glaub ich das für meinen Use-Case etwas Overkill...
Platten durch reichen bin ich mir auch nicht sicher ob gut geklappt hätte für ne NAS-VM weil ich aktuell eigentlich nicht geplant habe ne HBA zu verwenden sondern nur die Onboard-Sata-Anschlüsse.
Von daher bleibt dann eigentlich nur BareMetal TrueNAS, OMV oder Unraid. Die Lizenzgebühr für Unraid kann ich in dem Fall vernachlässigen, da ich noch eine Lifetime Lizenz von vor paar Jahren habe :d

Verstehe ich es bei ZFS richtig, dass die ganzen Features wie z.B. Snapshots, Prüfsummen etc. nicht nur bei nem ZFS Raid funktionieren sondern schon generelle Eigenschaften des Filesystems sind, also auch in einem Mirror funktionieren?
Auf spezielle Enterprise Hardware wie PLP SSDs und so würde ich gerne verzichten wegen Kosten und Stromverbrauch, vor allem da eine USV für den Server schon vorhanden ist.

Bzgl. TrueNas lese ich immer davon, dass man es auf einem SSD mirror installiert, ist das eine Notwendigkeit oder eher halt "Best Practice"?
Was mich dann aber schon etwas stört, was ich hier gelesen habe, kann ich unter TrueNas nicht einen SMB Share in einer Docker Container mounten? Das hab ich bei dem ein oder anderen Container (z.B. paperless ingest) aktuell aufm QNAP schon so gemacht... oder verstehe ich da das „hostPathValidation” Thema falsch?
 
Bzgl. TrueNas lese ich immer davon, dass man es auf einem SSD mirror installiert, ist das eine Notwendigkeit oder eher halt "Best Practice"?
Was mich dann aber schon etwas stört, was ich hier gelesen habe, kann ich unter TrueNas nicht einen SMB Share in einer Docker Container mounten? Das hab ich bei dem ein oder anderen Container (z.B. paperless ingest) aktuell aufm QNAP schon so gemacht... oder verstehe ich da das „hostPathValidation” Thema falsch?
Offensichtlich habe ich Unsinn geschrieben. Die Option „hostPathValidation” wurde anscheinend in TrueNAS Scale entfernt. Ich kenne "hostParthValidation" noch aus der Zeit, als Kubernetes genutzt wurde. Docker habe ich unter TrueNAS Scale noch nicht verwendet. Daher auch die falsche Info. Ich hatte nur Docker zu Kubernetes-Zeiten in einem selbst angelegten Container genutzt (Jailmaker).
Dennoch scheint es in aktuellen TrueNAS Scale-Versionen noch zu Warnmeldungen zu kommen, die auf mögliche Konflikte mit bestehenden SMB-Freigaben hinweisen. Was man daraus macht, liegt dann beim User.

Du musst TrueNAS Scale nicht auf einem Mirror installieren.
 
Wer TrueNAS virtualisiert, sollte die Platten durchreichen. Von allem anderen, insbesondere ZFS auf ZFS, wird abgeraten.
Man braucht aber nicht zwingend ZFS. Weder auf Proxmox, noch für irgendein NAS-System. Ja, das mag Vorteile haben, vielleicht will man die auch unbedingt haben, aber man braucht sie nicht zwingend. Wenn man ZFS haben will, kann und muss man wohl das darunterliegende System auch entsprechend auslegen.

Nachdem ich hauptsächlich Docker Container zusätzlich zum NAS brauche und eine VM wenn überhaupt nur sporadisch mal für einen Gameserver (wenns Windows sein muss)
Das ich auf meinem "Server" mindestens ein Linux und ein Windows parallel laufen haben will, das Windows jedoch quasi nur für irgendwelche Gameserver die es halt Win-only gibt, war für mich schon der Ausschlag, warum ich einen Hypervisor wollte. Und in dem Fall ist auch das Linux-System (für Gamingserver) eine VM, nicht der Proxmox-Host selbst. Das kommt wiederrum durch den Backupgedanken zustande. Eine VM in Proxmox kann ich eben ganz einfach und komplett backupen.

und die Lernkurve bei Proxmox recht steil ist, glaub ich das für meinen Use-Case etwas Overkill...
Proxmox Lernkurve steil? Wer ein Linux installieren kann, der kann auch Proxmox installieren und dort VMs einrichten. Mir fällt jetzt auf Anhieb nichts ein, wie man es noch einfacher machen könnte.
Abgesehen davon ist Proxmox eigentlich ein ganz normales Linuxsystem, welches einfach nur standardmäßig KVM/QEMU direkt mitinstalliert, die eigentliche Besonderheit ist eigentlich nur das mitgelieferte Webinterface. Die Virtualisierung kannst du dir auf jedem Linux einrichten. Nur so ein "schickes" Webinterface kriegst du nicht so einfach dazu... geschweige denn halt beides einfach mal so out-of-the-box.

Platten durch reichen bin ich mir auch nicht sicher ob gut geklappt hätte für ne NAS-VM weil ich aktuell eigentlich nicht geplant habe ne HBA zu verwenden sondern nur die Onboard-Sata-Anschlüsse.
Je nach Hardware kannst du das Hostsystem auf eine NVMe-SSD installieren und dann den kompletten Onboard-SATA-Controller an eine VM durchreichen. Dann sind halt alle SATA-Platten nur noch in der VM verfügbar. Geht also nicht, wenn du SATA-SSDs für den Host selber brauchst oder auch andere VMs auf SATA-Platten zugreifen sollen. Soll sogar Leute geben die Proxmox von einem USB-Stick booten, um Festplatten durchreichen zu können. ;)
 
Verstehe ich es bei ZFS richtig, dass die ganzen Features wie z.B. Snapshots, Prüfsummen etc. nicht nur bei nem ZFS Raid funktionieren sondern schon generelle Eigenschaften des Filesystems sind, also auch in einem Mirror funktionieren?
Auf spezielle Enterprise Hardware wie PLP SSDs und so würde ich gerne verzichten wegen Kosten und Stromverbrauch, vor allem da eine USV für den Server schon vorhanden ist.

Prüfsummen und Snapshots sind eine Eigenschaft von ZFS und benötigen kein Raid.
Wird beim Lesen allerdings ein Prüfsummenfehler festgestellt und soll der automatisch repariert werden, braucht man Redundanz:

Die Metadaten sind immer doppelt vorhanden, für Daten brauchts irgendein Raid mit Redundanz - Mirror gehört dazu.
 
Und im übrigen ist nur meine Variante die Richtige :d

Ich mach die ganzen Sachen auch, was die Leute hier schreiben. Mir wurde das mit Raspi-Leistung und den fehlenden Hardwareschnittstellen zu blöd, weshalb ich schon länger auf 24/7 PC umgestiegen bin.

@Tomson124 Proxmox hat keine steile Lernkurve. Das bekommst du mit einem (Video-)Turorial sicherlich hin und dauert auch nicht lange. Du kannst auch die KI fragen, die geht mit dir die Installation durch. Wenn du dann beliebige VMs ausführen kannst, würdest du deinen jetzigen Plan vielleicht anders machen, zum Beispiel nur noch ein Proxmox auf dem Belech und alles andere virtuell.
 
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