Neuaufbau Homelab

takt3r

Neuling
Thread Starter
Mitglied seit
18.11.2024
Beiträge
6
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?
 
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
muss kein Cluster sein, einfach ein kleines Zweitsystem so wie das Erstsystem
;)

Meine Überlegung bzgl. TrueNAS Scale als Backup-System war der Einsatz von MinIO um einen S3 Objektspeicher bereitstellen und testen zu können.
zum Testen kann man das auch unter Proxmox realisieren. Als Backup für ZFS oder Proxmox ist S3 eher weniger geeignet.
PLP SSDs wollte ich aufgrund des Preises nicht unbedingt anschaffen, kann ich den SLOG mit non-PLP SSDs/NVMEs realisieren?
Ist eine Risikoabschätzung. Ohne PLP besteht ein deutlich höheres Risiko eines Datenverlustes/ korrupte VM wenn das System beim Schreiben abstürzt. Wenn man noch eine 64/128 GB Optane findet so wäre das günstig und perfekt für ein Slog. Mirror muss nicht sein.
 
Macht die Überlegung nun Sinn, ein SLOG mit PLP für die Pools die selbst kein PLP haben?

Die Wahrscheinlichkeit dass in einem ZFS Pool mit Flash ohne plp ein Datenfehler nicht nur entdeckt sondern aus Redundanz auch behoben werden kann ist sehr sehr hoch. PLP ist daher bei einem Pool schön aber nicht so essentiell wie bei einem Slog.

Ist das Slog ein Mirror so erfolgt das Schreiben da auch nacheinander mit dem Ergebnis dass eine der beiden Mirrors wahrscheinlich valide Datenblöcke hat, daher ist ja ein ZFS SSD Pool mit aktiviertem sync auch ohne plp ganz ok.
 
Ich bin mit den Details ein wenig Lost…
Ich versuche mal zusammenzufassen:
Hauptserver
Proxmox
2x 1TB NVME Mirror
Aus den 3x 4TB Platten mache ich ein RAID-Z1 (wobei die Platten auch schon 5 Jahre alt sind…)
Für die Netzlaufwerke nutze ich Kernel NFS und Cockpit für die GUI.

Backup-System
Proxmox
2x16 bzw 20TB neu als Mirror oder 4x16TB Recertified als RAID-Z2

Ich hätte noch eine Intel SSD 750 mit 400GB und PLP da, welche ich verwenden könnte. Was mache ich mit der Intel SSD mit dem PLP? In den Hauptserver?

Wie richte ich die Datensicherung zwischen den beiden Proxmox-Systemen ein? Geht das per GUI oder mit einem PBS als VM?
 
Ich hätte noch eine Intel SSD 750 mit 400GB und PLP da, welche ich verwenden könnte. Was mache ich mit der Intel SSD mit dem PLP? In den Hauptserver?
mit einer SSD geht nur L2Arc Lesecache oder Slog (da brauchts nur 10GB).
Mit einer zweiten als Mirror ginge special vdev, SSD Pool und daneben eine kleine 10GB Slog Partition

Wie richte ich die Datensicherung zwischen den beiden Proxmox-Systemen ein? Geht das per GUI oder mit einem PBS als VM?

PBS dient in erster Linie dazu VMs zu sichern. Ganze ZFS Dateisysteme syncronisiert man fortlaufend mit ZFS Replikation. Jede ZFS Web-Gui sollte das anbieten.
 
Hab’s ausgefüllt, hast ja recht. Oder eben 3x recertified als Z1 oder ist das zu riskant?
Der Vergleich hinkt.
4x 166€ = 4x 16TB ergibt 32TB nutzbar
2x 236€ = 2x 16TB ergibt 16TB nutzbar

Richtig wäre:
4x 166€ für 32TB nutzbares Z2
3x 236€ für 32TB nutzbares Z1
... hier sind die 4 ein klein wenig billiger, aber kaum...
 
Mathematisch schon.
Praktisch nicht.
Sein Ziel war ein Mirror 16TB als Backup.
Das 4x Raid-z2 war nur wegen der Anfälligkeit von recertified platten. Die 32TB Storage sind ein Nebenerscheinung.

Die frage ist halt... Benötigt man so viel speicher?
Will man so viel Geld ausgeben?
Und sind die 50-150€ unterschied den wirklich so wichtig das man die Sicherheit aufs Spiel setzen will?
Ist es denn überhaupt ein Sicherheitrisiko? Wie großes ist die Chance das beim Ausfall einer platte die zweite beim wiederherstellen auch ausfällt?
Und selbst WENN alle platten im Backup System ausfallen? Wie tragisch ist das? Wie gross ist die Chance das genau in dem Moment das komplette Haupt System unwiderruflich ausfällt?
Hat man nicht genau für diese Situation ein 3-2-1 System mit einer Offline platte iwo?
 
Das 4x Raid-z2 war nur wegen der Anfälligkeit von recertified platten. Die 32TB Storage sind ein Nebenerscheinung.
Ja dann machs nen 3-fach Mirror, dann bist wiederum ca. auf gleich.
Meingott.

Wsl. wäre ein normaler Mirror mit den Recs. okay genug, würde ich mal meinen. Die Chance dass eine ausfällt ist ja schon eher klein.
 
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