[SOLVED] Home Server // Machbarkeitsprüfung

[jaysn8]

Hallo Community,

ich bin neu im Thema Proxmox und habe bis auf einen virtuellen Versuch bisher noch keine Erfahrung gesammelt. Ich möchte dennoch gerne meine Home Server auf Basis eines Dell Poweredge T30 gerne virtualisieren und stelle mir das wie folgt vor:

2x250GB Samsung EVO 850 SSD als Mirrored ZFS Raid (RAID1), darauf Proxmox installieren. Auf dem selben Volume sollen dann die VM und Container laufen (min. FreeNAS, EMBY, eine Win10VM und vllt eine Ubuntu VM zum testen).

2x2TB WD Red als Mirrored ZFS Raid (RAID1) für sensible Daten. Dieses Volume möchte ich auch auf Proxmox-Ebene erstellen und darauf aus einer FreeNAS-VM darauf zugreifen. Ist das möglich und wenn ja wie?

1x8TB WD Red alleine für weniger wichtige Daten, wie Filmsicherungen etc auch auf Proxmox-Ebene. Darauf möchte ich per VM oder Container (Emby und FreeNAS) zugreifen? Ist das auch möglich und wenn ja wie?

Die sensiblen Daten sichere darüber hinaus wöchentlich auf ein Synology.

Was haltet ihr davon? Mir ist klar, dass ich einiges an RAM brauche für die ZFS Volumes, besorgemir zur Not noch mehr! Auf eine Cache-SSD möchte ich zunächst verzichten, kann aber ja noch nachkommen, falls ich möchte.

Kurz zur Hardware:

• Intel Xeon E3-1225 v5
• Chipsatz: Intel C236
• 16 GB ECC Ram

Ich freue mich sehr über euer Feedback und danke!

 

[Deleted member 34654]

16 gab zuwenig bitte auch an den Stromverbrauch denken

 

[LnxBil]

16 gab zuwenig bitte auch an den Stromverbrauch denken

So direkt würde ich das nicht abschmieren. Ich hab schon ZFS auf einem Raspberry PI betrieben und ja, es war nicht schnell aber es hat funktioniert.

Was haltet ihr davon?

Kann man so machen, Verbesserungen gibt es viele, aber die gehen schon direkt ins Geld. Für ein Home-Lab reicht das völlig aus und klappt so. Die SSDs sind für Consumer-Bereich geeinget und sind nicht auf viele Schreibvorgänge ausgelegt, hier würde ich den Wearout im Blick behalten. Bei einer 750 EVO habe ich mir bei der Verwendung von PVE in einem Monat über 20% "runtergeschrubbt". Das Problem liegt an den sehr großen, internen Speicherblöcken, die bei jedem I/O geschrieben werden müssen.

2x2TB WD Red als Mirrored ZFS Raid (RAID1) für sensible Daten. Dieses Volume möchte ich auch auf Proxmox-Ebene erstellen und darauf aus einer FreeNAS-VM darauf zugreifen. Ist das möglich und wenn ja wie?

Wenn es wirklich ein Volume ist, also ein ZVOL, dann ja. Das ist dann aber nur in der VM erreichbar. Zugriff über den "normalen" ZFS Weg von PVE, einfach einen zweiten ZFS-Eintrag an der Installation über die GUI anlegen.

1x8TB WD Red alleine für weniger wichtige Daten, wie Filmsicherungen etc auch auf Proxmox-Ebene. Darauf möchte ich per VM oder Container (Emby und FreeNAS) zugreifen? Ist das auch möglich und wenn ja wie?

Entweder über LVM oder auch gleich ZFS verwenden und wie die "normalen" Festplatten durchreichen.

 

[jaysn8]

Danke für deinen Input.

Die SSDs sind für Consumer-Bereich geeinget und sind nicht auf viele Schreibvorgänge ausgelegt, hier würde ich den Wearout im Blick behalten.

Hast du einen Vorschlag, wie ich das langlebiger gestalten kann, ohne extrem tief in die Tasche greifen zu müssen? Wie gesagt reicht mir eine "Home-Performance" aus.

EDIT: Ich könnte doch Proxmox und die VMs auch auf einer einzelnen SSD laufen lassen und die VMs bzw. auch Container einfach täglich/wöchentlich auf den ZFS Mirror sichern, oder? Damit müsste ich bei Ausfall der SSD nur eine neue SSD einbauen, Proxmox aufsetzen und die VMs aus dem Backup starten. Würde dies so funktionieren?

Zugriff über den "normalen" ZFS Weg von PVE, einfach einen zweiten ZFS-Eintrag an der Installation über die GUI anlegen.

Das wäre mir lieber, wenn ich da flexibel von mehreren VMs aus drauf zugreifen kann. Wenn ich den "normalen" ZFS Weg von PVE über einen zweiten Eintrag gehe, kann ich auch aus einer anderen VM auf das RAID zugreifen?

 

[LnxBil]

EDIT: Ich könnte doch Proxmox und die VMs auch auf einer einzelnen SSD laufen lassen und die VMs bzw. auch Container einfach täglich/wöchentlich auf den ZFS Mirror sichern, oder? Damit müsste ich bei Ausfall der SSD nur eine neue SSD einbauen, Proxmox aufsetzen und die VMs aus dem Backup starten. Würde dies so funktionieren?

Ja, funktioniert. Ich würde das nur automatisieren, dass du es nicht mal vergisst. Die Automatisierung bitte auch entsprechend überwachen. Die Snapshot-Namen würde ich mit dem Datum verstehen, dann kannst du schnell automatisch prüfen, ob diese auf der "anderen Seite" aktuell sind.

Das wäre mir lieber, wenn ich da flexibel von mehreren VMs aus drauf zugreifen kann. Wenn ich den "normalen" ZFS Weg von PVE über einen zweiten Eintrag gehe, kann ich auch aus einer anderen VM auf das RAID zugreifen?

Ob RAID oder nicht ist "dir" as VM egal. Du bekommst speicher und wo der herkommt ist erstmal egal. Ich habe in meinem kleinen Heimsystem auf einem schon in die Jahre gekommen Laptop (wegen geringem Stromverbrauch) auch eine SSD und eine SHDD drin, jeweils ein einzelner Pool und verteile die Daten darauf. Synchronisiert wird das Ganze dann aufs NAS (wenn das an ist) - also ein ähnliches System wie du.

 

[jaysn8]

Vielen Dank für deine Antwort! Damit ist mein Konzept zu 99% fertig und ich kann mit der Umsetzung starten.

Eine letzte Frage bleibt für mich noch offen: Kann ich auf das Storage von mehreren Containern / VMs aus zugreifen?

Ganz konkret: Ich möchte zum Beispiel Videos auf das Storage packen. Zum einen möchte dann mit einem Turnkey-Container auf das Storage zugreifen, aber auch mit einem Emby-Container und wsl. sogar einem ownCloud-Container. Läuft das so wie ich mir das vorstelle?

 

[LnxBil]

Ganz konkret: Ich möchte zum Beispiel Videos auf das Storage packen. Zum einen möchte dann mit einem Turnkey-Container auf das Storage zugreifen, aber auch mit einem Emby-Container und wsl. sogar einem ownCloud-Container. Läuft das so wie ich mir das vorstelle?

Technisch ist das machbar mit Containern mittels Bind-mount über die GUI, damit ist das System aber nicht mehr snapshotbar. Alternativ kannst du es über eine Netzwerkfreigabe machen, dann haben alle Zugriff und es würde auch mit KVM-VMs funktionieren. Fraglich ist, warum du bei gleichen Daten dennoch das Zugriffssystem (ownCloud, etc.) autark halten möchtest. Ich würde die Daten und alle Dienste in einen Container packen um das folgende Problem zu umgehen:
Generell hat man beim Zugriff auf die gleichen Dateien immer ein Locking-Problem, d. h. im ungünstigsten Fall bekommst du Datenkorruption, wenn zwei Prozesse gleichzeitig auf die gleiche Datei schreibend zugreifen. Bei NFS und Samba/Cifs gibts dafür locking, bei einem Bind-Mount ist das aber nicht der Fall. Falls das in deinem Fall nicht gegeben ist, hast du kein Problem damit.

 

[jaysn8]

Alternativ kannst du es über eine Netzwerkfreigabe machen, dann haben alle Zugriff und es würde auch mit KVM-VMs funktionieren.

Das klingt nach der besten Lösung! Kann ich die Freigaben direkt unter Proxmox erstellen oder muss ich das dann z.B. über Turnkey machen?

Lieber wäre mir auf Proxmox-Ebene, aber könnte mir notfalls damit anfreunden über Turnkey freizugeben.

Vielen Dank für deine Hilfe LnxBil!

 

[LnxBil]

Das klingt nach der besten Lösung! Kann ich die Freigaben direkt unter Proxmox erstellen oder muss ich das dann z.B. über Turnkey machen?

Freigabe musst du auf dem Gast machen. Zu Turnkey kann ich nichts sagen, hab ich noch nie verwendet.

 

[jaysn8]

Okay. Welchen Fileserver verwendest du? Möglicherweise ist das noch eine Alternative zu Turnkey für mich.

 

[LnxBil]

Okay. Welchen Fileserver verwendest du? Möglicherweise ist das noch eine Alternative zu Turnkey für mich.

Turnkey bietet dir ja Appliances an, mit denen du schnell an dein Ziel kommst.

Ich verwende für alles Debian als Betriebssystem und dann je nach Client entweder NFS, Samba/Cifs oder Netatalk/AFS. Damit hab ioch dann 99,99% aller möglichen Betriebssysteme abgedeckt.

 

[jaysn8]

Okay vielen Dank. Ich überlege mir noch, ob ich Turnkey verwende oder mich etwas flexibler mit einem Debian aufstelle.

Vorerst letzte Frage: Die SSD auf der ich dann Proxmox und die Container / VM drauf laufen lasse, lasse ich auch mit dem ZFS Dateisystem formatieren / laufen, oder spricht da etwas gegen?

 

[LnxBil]

Überall ZFS, ja.

 

[jaysn8]

Alles klar, wird gemacht ;-)

Vielen Dank dir nochmal!

 

[Vitamin[X]]

Ich geb jetzt einfach mal meinen Senf dazu.

In meinem fall habe ich das Raid einfach im Linux erstellt und reiche diese Ortner jetzt via MountPoints zu den Containern weiter, wodurch ich mir das Netwerk in dieser Geschichte spare und somit die Laufwerke immer aktiv sind auch beim Netzwerk ausfall oder neustarten des netzwerk laufwerks dinststes.

Zusätzlich denken die Container es wäre eine interne festplatte und nichts entferntes, somit kannst du daraus sogar booten, und wenn du dies machst brauchst du nicht immer den ganzen container backuppen sondern nur die geänderten daten, je nach dem wie du deinen Rhythmus machst kannst du das sogar synchron halten.

 

[jaysn8]

Danke für deinen Kommentar!

@LnxBil : Das System läuft jetzt wie wir oben diskutiert haben, die Konfiguration ist abgeschlossen. Nachfolgend ein Screenshot von den Storages, die ich eingerichtet habe:



zu 1 + 2: selbsterklärend, läuft soweit

zu 3: hier möchte ich Backups / Snapshots der VM und Container ablegen
zu 4: hier möchte ich die sensiblen Dateien speichern
zu 5: hier möchte ich unsensible Daten speichern

Kannst du mir sagen, wie ich nun aus meiner Debian-KVM oder aus meinem Debian-CT (habe mich noch nicht entschieden, was besser für mich ist) auf 4 + 5 zugreife, um das Debian dann als Fileserver mit NFS- und CIFS-Freigaben zu verwenden, wie oben besprochen?

Wie gesagt, möchte ich die KVM oder CT snapshoten, damit ich einfach die System SSD tauschen kann, wenn sie kaputt geht und dann direkt wieder Zugriff auf mein Storage auf dem ZFS Mirror haben.

Vielen Dank!

 

[LnxBil]

zu 3: hier möchte ich Backups / Snapshots der VM und Container ablegen

Snapshots werden im Dataset gespeichert, also im ZFS, man kann die Speicherstätte nicht beeinflussen. Ich persönlich mache keine Backups von VMs, wenn ich eh alles auf ZFS habe. Das wird gesnapshottet und dann mittels send/receive übertragen auf eine andere Platte.

Kannst du mir sagen, wie ich nun aus meiner Debian-KVM oder aus meinem Debian-CT (habe mich noch nicht entschieden, was besser für mich ist) auf 4 + 5 zugreife, um das Debian dann als Fileserver mit NFS- und CIFS-Freigaben zu verwenden, wie oben besprochen?

Legst dir auf jedem Storage eine neue, virtuelle Disk an und hast dann bei 3 versch. Storages 3 Disks in deiner VM oder Container. Geht alles über Hardware oder Resources-Tab in PVE.

Wie gesagt, möchte ich die KVM oder CT snapshoten, damit ich einfach die System SSD tauschen kann, wenn sie kaputt geht und dann direkt wieder Zugriff auf mein Storage auf dem ZFS Mirror haben.

Die Konfiguration der PVE-Maschinen liegt im Betriebssystem und wenn die Disks die Krätsche machen, ist auch die Konfiguration weg. Am besten synchronisierst du deine Root-Partition immer auf ein ZFS-Dataset, sodass du noch an die Daten ran kommst.


Mach mal bitte noch ein zpool status -v, dass wir auch den Aufbau der Pools sehen.

 

[jaysn8]

Danke für deine Antwort!

Snapshots werden im Dataset gespeichert, also im ZFS, man kann die Speicherstätte nicht beeinflussen. Ich persönlich mache keine Backups von VMs, wenn ich eh alles auf ZFS habe. Das wird gesnapshottet und dann mittels send/receive übertragen auf eine andere Platte.

Verstehe. Ich fürchte ich habe es noch nicht vollständig begriffen: Snapshots werden im Dataset gespeichert und diese muss ich manuell heruakopieren, um sie woanders abzuspeichern?

Was macht dann die Backup-Funktion? Würde die dann die komplette VM inkl. virtuellen Disks backuppen?

Legst dir auf jedem Storage eine neue, virtuelle Disk an und hast dann bei 3 versch. Storages 3 Disks in deiner VM oder Container. Geht alles über Hardware oder Resources-Tab in PVE.

Okay begriffen und unter Ressourcen für eine VM auch gefunden! Im selben Menü eines CT kann ich nur einen Mount Point hinzufügen, was ich ja nicht möchte. Wie kann ich die virtuelle Disk in CT-Fall erstellen?

Die Konfiguration der PVE-Maschinen liegt im Betriebssystem und wenn die Disks die Krätsche machen, ist auch die Konfiguration weg. Am besten synchronisierst du deine Root-Partition immer auf ein ZFS-Dataset, sodass du noch an die Daten ran kommst.

Leider habe ich offenbar auch diesen Punkt noch nicht komplett begriffen: Mein Plan war PVE, Images und Container auf der einzelnen SSD laufen zu lassen. Datenspeicher wie oben beschrieben nutzen und dann die VM und CT snapshotten und diesen auf dem Mirror ablegen, damit ich diese wiederherstellen kann, wenn die SSD die Grätsche macht und ich so sofort wieder ein laufendes System habe. Wenn ich die Root-Partition synce würde das so klappen? Oder hast du einen Vorschlag, wie das komfortabler funktioniert mit meiner Hardware?

Im Anhang der output von zpool status -v

 

[LnxBil]

Verstehe. Ich fürchte ich habe es noch nicht vollständig begriffen: Snapshots werden im Dataset gespeichert und diese muss ich manuell heruakopieren, um sie woanders abzuspeichern?

Das Ziel sollte ein ZFS sein, dann kannst du einfach mittels send/receive die Snapshots dorthin übertragen. Kann auch eine externe Platte sein, denn externe Backups sollte man immer haben.

Was macht dann die Backup-Funktion? Würde die dann die komplette VM inkl. virtuellen Disks backuppen?

Ja, das ist aber unabhängig von einem Snapshot. Der PVE Backupprozess nimmt den aktuellen Zustand on komprimiert alle nicht-leeren Blöcke und speichert die Daten inkl. der Konfiguration in einer VMA-Datei ab. Diese kannst du dann in einem anderen PVE einfach importieren und die VM läuft dann mit den alten Einstellungen.

Okay begriffen und unter Ressourcen für eine VM auch gefunden! Im selben Menü eines CT kann ich nur einen Mount Point hinzufügen, was ich ja nicht möchte. Wie kann ich die virtuelle Disk in CT-Fall erstellen?

Wenn dein Container auf ZFS liegt hast du keine "virtuelle Disk". Die Daten liegen ja als Dateien im ZFS (im Gegensatz zu ZVOL bei KVM). Es gibt zwei Arten von Mount Punkten bei Containern, der eine verwendet ein Verzeichnis und somit bekommst du alle möglichen Verzeichnisse da mittels bind-Mount rein, der andere legt ein neues dataset (hier dateisystem) im ZFS an, dass ähnlich wie das root eingebunden wird. Letzteres ist nach wie vor snapshotfähig, falls das dein Problem mit dem Begriff ist.

Leider habe ich offenbar auch diesen Punkt noch nicht komplett begriffen: Mein Plan war PVE, Images und Container auf der einzelnen SSD laufen zu lassen. Datenspeicher wie oben beschrieben nutzen und dann die VM und CT snapshotten und diesen auf dem Mirror ablegen, damit ich diese wiederherstellen kann, wenn die SSD die Grätsche macht und ich so sofort wieder ein laufendes System habe. Wenn ich die Root-Partition synce würde das so klappen? Oder hast du einen Vorschlag, wie das komfortabler funktioniert mit meiner Hardware?

Keinen SPOF (Single-Point-of-Failure) einbauen, denn ohne die VM-Konfigurationsdateien hast du halt nur 99,999% der Datenmenge aber ohne Konfiguration startet nichts. Ich würde dann eher das OS auf dem ZFS Mirror installieren, denn dann hast du die Konfigurationsdaten noch und die PVE Installation ist klein und benötigt nicht viel I/O. Du kannst dennoch deine "schnellen" Daten auf die SSD legen, hierfür würde ich dann aber Replikation auf einen anderen ZFS pool einrichten, dass die auch kaputt gehen kann, du aber die Daten noch hast. Somit verringerst du die Time-to-Recovery erhebtlich, da PVE immer bootet wenn "nur" eine der beiden Platten kaputt ist und du über das BIOS die andere Platte als Bootplatte auswählst. Ich verwende ein ähnliches Setup mit einer SSD und einer SSHD (SSD auf SSHD replizieren) und alles wird auf externen ZFS-Pool nochmal gesynct bzw. send/receive.

Dein aktuelles Setup mittels 3 unterschiedlichen Pools macht das alles nicht unbedingt leicher. Besser wäre z.B. 4 gleiche Platten für raid-z1 gewesen, aber oft "wächst" so ein System ja und man kann nur mit dem Arbeiten was man hat.

 

[jaysn8]

Vielen Dank für deine ausführliche Antwort!

Dein aktuelles Setup mittels 3 unterschiedlichen Pools macht das alles nicht unbedingt leicher. Besser wäre z.B. 4 gleiche Platten für raid-z1 gewesen, aber oft "wächst" so ein System ja und man kann nur mit dem Arbeiten was man hat.

Genau, es ist ein gewachsenes System und bei den nächsten Anschaffungen werde ich besser planen

Okay, wenn ich deine Infos für mich zusammenfasse, ergibt sich folgendes Fazit:

PVE auf den ZFS Mirror aus den 2x2TB WD Reds (ein zpool mit den Mountpunkten, die PVE selber anlegt plus einen "storage" Mountpunkt, worauf ich die tatsächlichen Daten speichere und einen "backup" Mountpunkt, worauf ich PVE Backups (=VMA) ablegen lasse.

Die SSD nehme ich dann als ZFS Device mit einem zpool und zwei ZFS Einträgen (einer für Images und einer für Container), d.h. darauf können dann die VM und CT laufen und werden von dort regelmäßig auf dem Mirror gesichert.

Meine einzelne 8 TB Platte wird dann einfach ein ZFS mit zwei Mountpunkten "storage" und auch vllt nochmal "backup" (kann die VMA ja einfach monatlich nochmal dorthin kopieren).

Macht dies so Sinn oder kann ich noch weiter vereinfachen?

Habe ich so dann die Time-To-Recovery erheblich verringert?

Für mein Verständnis ja, aber eine Bestätigung bringt mir tatsächliche Sicherheit.

Es gibt zwei Arten von Mount Punkten bei Containern, der eine verwendet ein Verzeichnis und somit bekommst du alle möglichen Verzeichnisse da mittels bind-Mount rein, der andere legt ein neues dataset (hier dateisystem) im ZFS an, dass ähnlich wie das root eingebunden wird. Letzteres ist nach wie vor snapshotfähig, falls das dein Problem mit dem Begriff ist.

Falls ich so fortfahre wie oben: Wie erreiche ich, dass ich ein solchen Mount Punkt in einen Container bekomme, wie du vorschlägst? Online finde ich ausschließlich Anleitungen, wie über die PVE GUI über Ressourcen ein Bind Mount eingebunden wird, was ich ja nicht möchte, sondern deinen zweiten Weg gehen möchte.