Neuaufbau Homelab

takt3r

Neuling
Thread Starter
Mitglied seit
18.11.2024
Beiträge
4
Hallo zusammen,
ich bin gerade dabei, mein Homelab aufzuräumen.

Derzeit betreibe ich einen Unraid-Server:
Gigabyte MC12-LE0
AMD Ryzen 7 5700x
64 GB ECC-RAM
4x 1TB NVME in einer ASUS Hyper M.2 x16 Gen 4-Karte
3x 4TB HDD
Dieser Server wird für Docker-Container, VMs und ein paar Netzlaufwerke verwendet. Zusätzlich habe ich noch ein Synology DS215j im Einsatz, das ebenfalls einige Netzlaufwerke bereitstellt. Eigentlich möchte ich das DS215j in Rente schicken.

Ich möchte von Unraid weg und auf Proxmox umsteigen. Proxmox soll auf dem aktuellen Server installiert werden und wieder Docker-Container, virtuelle Maschinen und Netzlaufwerke bereitstellen. Macht es Sinn, für die Netzlaufwerke TrueNAS zu installieren und dafür den onboard SATA-Controller durchzureichen, oder sollte ich die Netzlaufwerke eher auf Basis von Cockpit realisieren? Die NVMEs sollen für Docker und VMs genutzt werden.
Weiterhin möchte ich ein "Offsite"-Backup in meiner Garage einrichten. Diese ist 70m vom Haus entfernt und per LAN angebunden. Dort möchte ich meine Netzlaufwerke, virtuellen Maschinen und Container sichern, vielleicht später auch als externes Backup für die Familie. Meine Idee war, etwas auf Basis eines Gigabyte MJ11-EC1 mit 32GB RAM und 3x 16TB als Backup-Appliance aufzubauen. Was sollte ich dort installieren? TrueNAS Scale Bare Metal?

Wie würdet ihr den Storage (HDD) für die Netzlaufwerke (Server und Backup) umsetzen? ZFS?

Vielen Dank im Voraus für eure Meinungen :)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Storage VM vs ZFS web-gui add on auf Proxmox
Proxmox ist Debian mit ZFS. TrueNAS ist ebenfalls Debian mit ZFS. Eine Full Size Debian Storage VM bringt daher nur Komfort, keine essentiellen Extras, kostet dafür viel CPU und RAM. Um Proxmox direkt als Filer zu nutzen muss man lediglich Kernel-NFS und -ksmbd (schneller) oder SAMBA (mehr Funktionen) aktivieren. Die web-gui von Proxmox ist stark auf VMs optimiert. Für ZFS und Share Management gibts add-ons wie Cockpit oder mein napp-it. Sowas spart enorm Resourcen.

ZFS ist das nonplusultra lokaler Dateisysteme. Ich würde mit den Platten ein Z1 machen und die NVMe als zwei special vdev Mirror dazupacken um kleine Dateien, Metadaten oder die VM ZFS Dateisysteme darauf zu legen. Eventuell 2 x 10GB von zwei der NVMe abtrennen um ein Slog zu haben (Absicherung des RAM Schreibcaches mit aktiviertem sync write, macht bei VMs Sinn)

Alternativ einen zweiten NVME Pool als Z1 mit aktiviertem Sync für die VMs
 
Macht doch aus P/L und Verbrauchs Sicht beides überhaupt keinen Sinn...
Die 4TB HDDs und die 1TB NVMEs sind jetzt schon im Server verbaut und laufen schon eine Weile. Ich bin gern offen für Vorschläge ;)
Beitrag automatisch zusammengeführt:

Storage VM vs ZFS web-gui add on auf Proxmox
Proxmox ist Debian mit ZFS. TrueNAS ist ebenfalls Debian mit ZFS. Eine Full Size Debian Storage VM bringt daher nur Komfort, keine essentiellen Extras, kostet dafür viel CPU und RAM. Um Proxmox direkt als Filer zu nutzen muss man lediglich Kernel-NFS und -ksmbd (schneller) oder SAMBA (mehr Funktionen) aktivieren. Die web-gui von Proxmox ist stark auf VMs optimiert. Für ZFS und Share Management gibts add-ons wie Cockpit oder mein napp-it. Sowas spart enorm Resourcen.

ZFS ist das nonplusultra lokaler Dateisysteme. Ich würde mit den Platten ein Z1 machen und die NVMe als zwei special vdev Mirror dazupacken um kleine Dateien, Metadaten oder die VM ZFS Dateisysteme darauf zu legen. Eventuell 2 x 10GB von zwei der NVMe abtrennen um ein Slog zu haben (Absicherung des RAM Schreibcaches mit aktiviertem sync write, macht bei VMs Sinn)

Alternativ einen zweiten NVME Pool als Z1 mit aktiviertem Sync für die VMs
OK, danke für deine ausführliche Antwort. Wie kann ich denn die Netzlaufwerke dann auf das Backup-System sichern? Gibt es da auch ein Addon oder geht das mit dem PBS?
 
Ich bin gern offen für Vorschläge ;)
Na wenn sie schon da sind, kann man das ja machen, und bei Bedarf einfach größere einsetzen - den folgenden Absatz kannst daher eigentlich ignorieren, ich führe allerdings zum Verständnis gern aus:

Nachdem die Anzahl der Schnittstellen auf der kleinen Hardware massiv begrenzt ist, würde ich immer zu maximal großen Datenträgern tendieren, bei halbwegs annäherendem €/TB.

So ist z.B. ein 2x 18-20TB HDD Mirror imho p/l mäßig viel besser als jedes Raid-Z darunter, außer natürlich, man hat die Hardware schon daheim. Auch vom Stromverbrauch her usw... Die Toshiba 20tb Heliumplatte bekommst für ~330€ (mein Letztstand im Kopf), macht 660€ für 20tb gespiegelt. Wennst dir jetzt ein 15-20tb RaidZ aus mehreren kleineren Platten baust, wirst immer teurer sein, höher im Verbrauch, lauter, viel mehr Slots belegen.
Bei den M.2 genau so, ein Z1 damit macht ja überhaupt keinen Sinn, die Latenzen werden ja nicht unbedingt besser und die PCIe 4.0 Leistung/Durchsatz von guten PCIe 4.0 TLC DRAM SSDs (2-4tb Modelle) sollte ja massiv ausreichend sein.


Wie gea schon sagt, sowas wie ein SLOG macht vllt. Sinn...
Was ich mich gerade frage, wenn man ein SLOG mit PLP verwendet, kann man dann den Rest mit gutem Gewissen ohne PLP ausführen?

Ist halt... weil die PLP PCIe (also M.2 und U.2) SSDs richtig Strom brauchen im vgl. zuden Non-PLP, mit paar nicht wirklich erhältlichen Alternativen wie der Samsung PM, die da besser als die Micron sein dürfte... und Preise, die jenseits von gut und böse sind momentan...
Beitrag automatisch zusammengeführt:

oder geht das mit dem PBS?
... der PBS dürfte ganz gut sein. Habs mir selber aber noch nicht angesehen. Ich denke, es lohnt sich, sich in diesem Thema zu vertiefen.
 
OK, danke für deine ausführliche Antwort. Wie kann ich denn die Netzlaufwerke dann auf das Backup-System sichern? Gibt es da auch ein Addon oder geht das mit dem PBS?

Die schnellste Methode ZFS Datasets (Dateisysteme und Volumes) zu sichern ist ZFS Replikation auf Basis von ZFS Snaps. Das sichert auch offene Dateien im aktuellen Zustand und ist ideal für einen Fileserver. Für VM Dateisysteme ist es nicht so optimal weil ein ZFS Snap deren Konsistenz nur garantieren kann wenn die VM down ist, ansonst da ist ein Proxmox Backupserver sicherer (dafür viel langsamer).

Das Backupsystem würde ich auch mit Proxmox und identisch machen. Dann hat man volle Redundanz bei Problemen. Eventuell ein zusätzliches offline Backup auf USB Platten überlegen oder das System in der Garage so konzipieren dass ein Blitz nicht NAS und Backup zerstört (normalerweise nicht am Netz, Fiber etc).

Will man besonders hohe Sicherheit im Backupsystem, da entweder OpenZFS mit OmniOS nehmen (Solaris Fork) oder einen Linux OpenZFS Pool mit deaktivierten Features machen. Es gibt doch immer wieder unschöne Bugs in Linux ZFS die man in OmniOS so nicht sieht.
 
Zuletzt bearbeitet:
Ich hatte auch schon nach neuen Platten geschaut. Derzeit sind die Preise wie folgt:
Toshiba Cloud-Scale Capacity MG10ACA 20TB: 313€ (15,63€/TB)
Seagate Exos X - X16 16TB: 236€ (14,78€/TB)

Aufgrund des €/TB und des Gesamtpreises hatte ich an die Seagate gedacht. Oder was haltet ihr von Recertified Platten -> Seagate HDD Exos X - X16 | 16TB Festplatte | ST16000NM001G bei ebay für 166€

Also das Backup System als Proxmox Cluster aufbauen? Vor dem Backup-System in der Garage ist auch eine USV, welche sowohl Strom als auch Netzwerk trennen soll ;)

Meine Überlegung bzgl. TrueNAS Scale als Backup-System war der Einsatz von MinIO um einen S3 Objektspeicher bereitstellen und testen zu können.

PLP SSDs wollte ich aufgrund des Preises nicht unbedingt anschaffen, kann ich den SLOG mit non-PLP SSDs/NVMEs realisieren?
 
Aufgrund des €/TB und des Gesamtpreises hatte ich an die Seagate gedacht.
Imho nicht schlau, die €/TB sind fast gleich, da würd ich immer das größere Modell nehmen. Aber ist wohl Geschmacksache. Wenn du nur wenig Speicher brauchst, und dir ein 16er Mirror lange ausreichen wird, reicht das natürlich. Wenn man allerdings (so wie ich) ohnehin ~50 TB will, ist das mit den größeren Drives immer schlauer.
Oder was haltet ihr von Recertified Platten -
Kann man auch machen, wenns billig sind. Kann man halt auch über ein Z2 nachdenken, dann ist man auf der sicheren Seite und kann nüchtern betrachtet sorglos fast jeden "Mist" reinstecken (solang man nicht vorsätzlich defekte Drives verwendet).
Meine Überlegung bzgl. TrueNAS Scale als Backup-System war der Einsatz von MinIO um einen S3 Objektspeicher bereitstellen und testen zu können.
Das sagt mir nix, aber wenn du nen "Testserver" willst kannst dir ja noch extra irgend einen gebrauchten Thin-Client hinstellen oder so ein N100 (ähnliches) System, da kannst frickeln bis der Arzt kommt. Vielleicht versteh ich das aber auch ganz falsch.
PLP SSDs wollte ich aufgrund des Preises nicht unbedingt anschaffen, kann ich den SLOG mit non-PLP SSDs/NVMEs realisieren?
Klar, die Frage ist aber, wie sinnvoll der SLOG dann noch ist. Er nimmt etwas TBW von den Drives, denen er zugewiesen ist... aber zusätzliche Sicherheit bietet er halt nicht so wirklich.
Deshalb meine Frage, ob es evtl. sinnvoll wäre nur den SLOG mit PLP auszurüsten.
Per Shell (TrueNAS GUI kanns nicht) kann man ja eine SSD partitionieren und diese einzlenen Partitionen als SLOG/ZIL unterschiedlichen ZFS Pools zuordnen, hab ich schon so gemacht.

Jetzt denke ich mir, dass man ja theoretisch mit einer PLP SSD (da würde ja auch >250gb reichen, größer hat halt mehr TBW und ist meist etwas schneller in der Größenordnung) sogar mehrere non-PLP pools per SLOG/ZIL "bedienen" könnte - irre ich mich da, oder kann man das machen? Jetzt mal "High-Performance" Anwendung mit Optane-Mirror und so Spaß außen vor, "home-tauglich" eben.
=> Ist das eine Schnapsidee oder kann man das machen?
 
Ich hatte an folgende Recertified Platte gedacht:
Screenshot 2024-11-18 121159.png


Davon 3 Stück als Z1 oder zwei als Mirror oder 4 als Z2?
 
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