17
Best Practice für Fileserver auf Proxmox Cluster
Hallo,
derzeit laufen in einer Firma, dessen Netzwerk ich betreue, zwei Windows Server Hyper-V Hosts, jeweils mit einem recht großem Hardware RAID und mit automatischer Replizierung. Als Fileserver läuft auf einem der Hosts eine Windows VM die ein paar SMB Shares bereitstellt.
Nun bin ich am überlegen, wie man diesen Hyper-V Cluster auf einen Linux-basierten Ansatz wie z.B. Proxmox umziehen könnte um dank ZFS und der Mögichkeit für häufigere Snapshots an Flexibilität und Sicherheit zu gewinnen.
Einen Proxmox-Cluster mit ZoL und Storage Replication aufzusetzen ist an sich auch kein Problem, nur habe ich jetzt noch nicht die optimale Lösung gefunden, wie man nun mit dem Fileserver am Besten weiter verfährt:
Option 1:
Man könnte weiter einen Windows Server virtualisieren, der dann Fileserver spielt. Als VM Disk würde dann ein ZFS Dataset (als Block Device) dienen, von dem Snapshots angelegt werden würden. Der Nachteil hieran ist, dass man, um z.B. eine einzige Datei aus einem Snapshot wiederherstellen zu können, erst die gesamte VM zurücksetzen müsste um diese dann zu starten und die eine Datei zu extrahieren. Sehr umständlich.
Option 2:
Man könnte Freenas statt Windows Server virtualisieren und dann innerhalb der VM ebenfalls ZFS benutzen. Auch wenn das gehen würde, so wird allseits davon abgeraten, ZFS in einer VM auf ZFS einzusetzen und meiner Erfahrung nach leidet darunter auch ziemlich die Performance. Für eine Produktivumgebung, finde ich diese Option ungeeignet.
Option 3:
Da Proxmox letztlich ja auch nur ein Debian ist, könnte man Samba direkt auf dem Host oder in einem LXC installieren und dann alle Daten in ein paar zusätzlichen ZFS Dataset ablegen. Diese Lösung gefällt mir am Besten, da man so auch den .zfs Ordner einbinden könnte um die Snapshots über die "Shadow Copies" Unterstützung von SMB verfügbar zu machen.
Allerdings wüsste ich bei dieser Option jetzt nicht, wie man damit High Availability umsetzen könnte? Man bräuchte dann einen Mechanismus, der die Daten automatisch zum zweiten Host repliziert und dann dort einen Samba-Server unter der gleichen IP startet. Könnte man das mit der Proxmox Storage Replication und LXC vielleicht irgendwie umsetzen? Hat das schonmal jemand gemacht und wie gut funktioniert das?
Das ganze soll natürlich möglichst keine "Frickellösung" werden, also sollte so viel wie möglich auch von Proxmox offiziell supported werden.
Wie würdet ihr sowas umsetzen? Ich wäre für ein paar Ideen und Einschätzungen sehr dankbar.
derzeit laufen in einer Firma, dessen Netzwerk ich betreue, zwei Windows Server Hyper-V Hosts, jeweils mit einem recht großem Hardware RAID und mit automatischer Replizierung. Als Fileserver läuft auf einem der Hosts eine Windows VM die ein paar SMB Shares bereitstellt.
Nun bin ich am überlegen, wie man diesen Hyper-V Cluster auf einen Linux-basierten Ansatz wie z.B. Proxmox umziehen könnte um dank ZFS und der Mögichkeit für häufigere Snapshots an Flexibilität und Sicherheit zu gewinnen.
Einen Proxmox-Cluster mit ZoL und Storage Replication aufzusetzen ist an sich auch kein Problem, nur habe ich jetzt noch nicht die optimale Lösung gefunden, wie man nun mit dem Fileserver am Besten weiter verfährt:
Option 1:
Man könnte weiter einen Windows Server virtualisieren, der dann Fileserver spielt. Als VM Disk würde dann ein ZFS Dataset (als Block Device) dienen, von dem Snapshots angelegt werden würden. Der Nachteil hieran ist, dass man, um z.B. eine einzige Datei aus einem Snapshot wiederherstellen zu können, erst die gesamte VM zurücksetzen müsste um diese dann zu starten und die eine Datei zu extrahieren. Sehr umständlich.
Option 2:
Man könnte Freenas statt Windows Server virtualisieren und dann innerhalb der VM ebenfalls ZFS benutzen. Auch wenn das gehen würde, so wird allseits davon abgeraten, ZFS in einer VM auf ZFS einzusetzen und meiner Erfahrung nach leidet darunter auch ziemlich die Performance. Für eine Produktivumgebung, finde ich diese Option ungeeignet.
Option 3:
Da Proxmox letztlich ja auch nur ein Debian ist, könnte man Samba direkt auf dem Host oder in einem LXC installieren und dann alle Daten in ein paar zusätzlichen ZFS Dataset ablegen. Diese Lösung gefällt mir am Besten, da man so auch den .zfs Ordner einbinden könnte um die Snapshots über die "Shadow Copies" Unterstützung von SMB verfügbar zu machen.
Allerdings wüsste ich bei dieser Option jetzt nicht, wie man damit High Availability umsetzen könnte? Man bräuchte dann einen Mechanismus, der die Daten automatisch zum zweiten Host repliziert und dann dort einen Samba-Server unter der gleichen IP startet. Könnte man das mit der Proxmox Storage Replication und LXC vielleicht irgendwie umsetzen? Hat das schonmal jemand gemacht und wie gut funktioniert das?
Das ganze soll natürlich möglichst keine "Frickellösung" werden, also sollte so viel wie möglich auch von Proxmox offiziell supported werden.
Wie würdet ihr sowas umsetzen? Ich wäre für ein paar Ideen und Einschätzungen sehr dankbar.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 561913
Url: https://administrator.de/contentid/561913
Ausgedruckt am: 24.11.2024 um 04:11 Uhr
17 Kommentare
Neuester Kommentar
Hallo,
das klingt für mich so, als hättest du wenig Ahnung von dem, was du da aufziehen willst - daher die Bitte, entweder du spielst diese Konstellation auf Test-HW bei dir durch oder belässt es beim derzeitigen oder du holst dir jemanden dazu, der weiss, was er tut.
Allerdings ist die Frage, was läuft darunter? Es wird nur durch die Abkehr von MS nicht sicherer oder gar stabiler, wenn man nicht weiss, wie der Hase läuft.
Lösungen und Einschätzungen gibt es auf der Basis nicht, weil man nicht weiss, was darunter laufen soll.
Viele Grüße,
Christian
certifiedit.net
das klingt für mich so, als hättest du wenig Ahnung von dem, was du da aufziehen willst - daher die Bitte, entweder du spielst diese Konstellation auf Test-HW bei dir durch oder belässt es beim derzeitigen oder du holst dir jemanden dazu, der weiss, was er tut.
Allerdings ist die Frage, was läuft darunter? Es wird nur durch die Abkehr von MS nicht sicherer oder gar stabiler, wenn man nicht weiss, wie der Hase läuft.
Lösungen und Einschätzungen gibt es auf der Basis nicht, weil man nicht weiss, was darunter laufen soll.
Viele Grüße,
Christian
certifiedit.net
Danke für deine Antwort.
Ich betreibe bereits mehrere Netzwerke und Proxmox-Cluster. Nur in dieser sezifischen Konstellation konnte ich mich noch nicht für die optimale Lösung entscheiden, weswegen ich hier nach anderen Ideen frage.
Allerdings ist die Frage, was läuft darunter?
Was meinst du mit "was läuft darunter"?
Auf den Fileserver wird ganz normal von mehreren Arbeitsplätzen aus zugegriffen.
Und sonst sollen auf dem VM-Host noch mehrere andere (Windows und Linux) VMs für Mailserver, Datenbanken, Terminalserver etc. laufen. Um die geht es aber in diesem Thread nicht und ob die letztlich auf einem Hyper-V oder KVM laufen ist auch egal.
Hinter dieser Entscheidung stehen selbstverständich auch noch weitere Überlegungen bezüglich Backup-Strategie etc., aber wie gesagt: Daum gehts in diesem Thread ja nicht.
Zitat von @certifiedit.net:
das klingt für mich so, als hättest du wenig Ahnung von dem, was du da aufziehen willst
Wie kommst du darauf? Ich habe die Frage soweit wie möglich auf das Wesentliche runtergebrochen, damit die nicht zu lang wird.das klingt für mich so, als hättest du wenig Ahnung von dem, was du da aufziehen willst
Ich betreibe bereits mehrere Netzwerke und Proxmox-Cluster. Nur in dieser sezifischen Konstellation konnte ich mich noch nicht für die optimale Lösung entscheiden, weswegen ich hier nach anderen Ideen frage.
- daher die Bitte, entweder du spielst diese Konstellation auf Test-HW bei dir durch oder belässt es beim derzeitigen oder du holst dir jemanden dazu, der weiss, was er tut.
Selbstverständlich baut man sowas vorher in einer Testumgebung oder in VMs auf, bevor man es umsetzt.Allerdings ist die Frage, was läuft darunter?
Auf den Fileserver wird ganz normal von mehreren Arbeitsplätzen aus zugegriffen.
Und sonst sollen auf dem VM-Host noch mehrere andere (Windows und Linux) VMs für Mailserver, Datenbanken, Terminalserver etc. laufen. Um die geht es aber in diesem Thread nicht und ob die letztlich auf einem Hyper-V oder KVM laufen ist auch egal.
Es wird nur durch die Abkehr von MS nicht sicherer oder gar stabiler, wenn man nicht weiss, wie der Hase läuft.
Es geht bei der Abkehr von MS nicht um die typische Windows vs. Linux Diskussion sondern um eine Überlegung, wie man den Storage robuster umsetzen kann. Und vorallem angesichts der aktuellen Ransomware-Problematik, ist NTFS mit seiner sehr beschränkten Snapshot-Unterstützung halt echt nicht gut aufgestellt, sodass ein Wechsel auf eine ZFS-basierte Lösung sinnvoll erscheint.Hinter dieser Entscheidung stehen selbstverständich auch noch weitere Überlegungen bezüglich Backup-Strategie etc., aber wie gesagt: Daum gehts in diesem Thread ja nicht.
Moin,
dein Konzept als Backup für ein Desaster-Recovery könnte schon passen. Für alles Andere würde ich eher auf Veeam setzen. Da geht die Wiederherstellung einzelner Dateien recht einfach und flott...
VG
dein Konzept als Backup für ein Desaster-Recovery könnte schon passen. Für alles Andere würde ich eher auf Veeam setzen. Da geht die Wiederherstellung einzelner Dateien recht einfach und flott...
VG
Seh ich ähnlich. Du versuchst hier nicht dass Problem zu reduzieren, sondern versuchst die Auswirkung zu reduzieren.
Besser autarkes Backup. Dann kannst das bestehende Setup auch belassen. Sicherung per Veeam. Kannst ja auch öfter bis stündlich machen.
Aber ohne den Hintergrund helfen Ideen nicht.
Besser autarkes Backup. Dann kannst das bestehende Setup auch belassen. Sicherung per Veeam. Kannst ja auch öfter bis stündlich machen.
Aber ohne den Hintergrund helfen Ideen nicht.
Würde an Deiner Stelle auch nicht auf Dateisystem-Snapshots als Backup setzen.
Da Proxmox eine integrierte Backup-Möglichkeit besitzt würde ich diese verwenden und an ein externes Ziel sichern. Somit besteht keinerlei Bedarf für eine Backup-Software ähnl. VEEAM...
Da Proxmox eine integrierte Backup-Möglichkeit besitzt würde ich diese verwenden und an ein externes Ziel sichern. Somit besteht keinerlei Bedarf für eine Backup-Software ähnl. VEEAM...
2
Zitat von @Ad39min:
Würde an Deiner Stelle auch nicht auf Dateisystem-Snapshots als Backup setzen.
Da Proxmox eine integrierte Backup-Möglichkeit besitzt würde ich diese verwenden und an ein externes Ziel sichern. Somit besteht keinerlei Bedarf für eine Backup-Software ähnl. VEEAM...
Zumal sich alles sehr bequem, übersichtlich und zuverlässig in Proxmox einstellen lässt.Würde an Deiner Stelle auch nicht auf Dateisystem-Snapshots als Backup setzen.
Da Proxmox eine integrierte Backup-Möglichkeit besitzt würde ich diese verwenden und an ein externes Ziel sichern. Somit besteht keinerlei Bedarf für eine Backup-Software ähnl. VEEAM...
Das sowieso. Der Plan ist autoamtisiert regelmäßig Snapshots zu erstellen und diese dann auf einen Backup-NAS (offsite) sowie täglich gewechselte USB-Festplatten zu replizieren (pve-zsync).
Das lässt sich mit Proxmox in der Tat sehr gut umsetzen und man kann in Fall von Ransomware o.ä. zu jedem beliebigen Zeitpunkt zurück und bekommt gleich auch noch sehr schnelle inkrementelle Backups dazu.
Das gehört zu den genannten weiteren Gründen, warum Proxmox präferiert wird. Aber darum ging es in meiner Frage nicht. ;)
Das lässt sich mit Proxmox in der Tat sehr gut umsetzen und man kann in Fall von Ransomware o.ä. zu jedem beliebigen Zeitpunkt zurück und bekommt gleich auch noch sehr schnelle inkrementelle Backups dazu.
Das gehört zu den genannten weiteren Gründen, warum Proxmox präferiert wird. Aber darum ging es in meiner Frage nicht. ;)
Wenn es darum geht, einzelne Dateien wiederherzustellen, die ggf. versehentlich gelöscht oder überschrieben wurden, dann helfen Snapshots nur wenig, bzw. machen es recht kompliziert.
Bei einem Konzept mit einer Sicherung des Fileservers zusätzlich mit Veeam o.Ä. hast du es da deutlich einfacher.
Bei einem Konzept mit einer Sicherung des Fileservers zusätzlich mit Veeam o.Ä. hast du es da deutlich einfacher.
Zitat von @BirdyB:
Wenn es darum geht, einzelne Dateien wiederherzustellen, die ggf. versehentlich gelöscht oder überschrieben wurden, dann helfen Snapshots nur wenig, bzw. machen es recht kompliziert.
Bei einem Konzept mit einer Sicherung des Fileservers zusätzlich mit Veeam o.Ä. hast du es da deutlich einfacher.
Könntest du bitte meine Frage lesen? Wenn es darum geht, einzelne Dateien wiederherzustellen, die ggf. versehentlich gelöscht oder überschrieben wurden, dann helfen Snapshots nur wenig, bzw. machen es recht kompliziert.
Bei einem Konzept mit einer Sicherung des Fileservers zusätzlich mit Veeam o.Ä. hast du es da deutlich einfacher.
Genau um diese Abwägung geht es in diesem Thread, wie man damit am Besten umgeht. Nur leider hat das bislang jeder ignoriert. :/
Am Sinnvollsten erscheint mir aktuell Option 3 mit Storage Replication und einem Samba-Server in einem LXC Container. Einzelne Dateien wiederherzustellen ist dann auch kein Problem.
Moin,
da scheinbar die Antwortenden entweder ihre eigenen Dienstleistungen verkaufen wollen oder auf Veeam schwören:
Hallo,
Da du von Hardware RAID sprichst würde ich erstmal prüfen, ob die Hardware Vorraussetzungen für ZFS überhaupt bestehen. Unterstützt die RAID Karte den HBA Modus?
Windows Fileserver mit entsprechenden vollständigen Block Level Snapshots hat die entsprechenden von dir genannten Nachteile. Gerade wenn man einzelne Dateien extrahieren will, wenn z.B. ein Nutzer die wichtigen Daten in einem Ordner der letzten Tage gelöscht hat, wird das sehr schnell sehr hampelig. Klar mit Veeam könntest du, wie von den anderen gesagt, zusätzlich zu den Snapshots noch die Dateien seperat backupen, aber hier muss man auch schauen wie Veeam mit Dateiversionen umgeht und wie viel Speicherplatz das vorhalten von mehreren Monaten braucht. In Veeam bin ich aber kein Experte und kann dementsprechend nichts dazu sagen.
Wieso willst du FreeNas virtualisieren? Soll das für ein Samba Fileserver genutzt werden? Meiner Erfahrung nach ist ZFS in ZFS wirklich sehr langsam. Es geht, ja, aber Spaß macht das nicht. Zumal dann einige ZFS Funktionen ggf. nicht korrekt funktionieren, weshalb davon im Allgemeinen abgeraten wird.
Ohne dein genaues Einsatzszenario zu kennen, würde ich auch Option 3 präferieren. Du könntest mit Proxmox ein ZFS Storage anlegen und das zwischen deinen Nodes z.B. alle 5 Minuten replizieren, wie das z.B. auch HyperV im Cluster Modus macht. Mit dem entsprechenden Qemu Guest Agent kann Proxmox dann auch sicherstellen, das vor den Snapshot sämtliche Änderungen des Gastsystems geflusht werden und die VM im Notfall im konsistenten Zustand ist. Gleiches kannst du auch für das Datasets des LXC Container machen, in dem der Samba Fileserver läuft. Im Notfall fehlen dir dann 5 Minuten an Daten, wenn ein Server ausfällt. Gleichzeitig hat man aber eben den Vorteil, dass man z.B. mehrere Monate an Snapshots vorhalten kann (natürlich entsprechend mit der Zeit ausdünnen) und diese mit dem vfs_shadow_copy Modul von Samba einbinden kann. Dann können die Nutzer sogar selbstständig mit dem Versionsverlauf auf ältere Versionen oder gelöschte Dateien zugreifen und wiederherstellen. Habe ich mal mit rumgespielt und funktioniert echt einwandfrei. Leider ist das mit einem Windows Fileserver doch relativ hampelig dieses Snapshot System umzusetzen, da NTFS dafür schlicht nicht gebaut wurde, sodass ZFS + Samba schon einige Vorteile besitzt.
Diese Snapshots die du sowieso für die Replizierung anlegst kannst du auch mit pve-zsync direkt auf ein ZFS fähiges NAS (z.B. FreeNas) rüber schieben, sodass man die VMs notfalls auch wiederherstellen kann, wenn die RAIDs beider Nodes den Geist aufgeben, auch wenn das schon sehr unwahrscheinlich ist ;).
Vorsichtig muss man nur bei entsprechenden Datenbankanwendungen sein, wenn man Block Level Snapshots macht. Diese reagieren ggf. nicht immer auf das Flush vom Qemu Guest Agent. Hier bietet sich dann ggf. wirklich noch eine Veeam Instanz in der VM selber an z.B. bei einem SQL Server, die das dann auf ein entsprechendes Backup NAS oder ähnliches schiebt.
Kleiner Tipp:
Bei Samba empfiehlt sich der Einsatz von NTACLs statt Posix ACLs, wenn es sich um komplexere Berechtigungsstrukturen handeln sollte (Default). Ggf. musst du in ZFS die xattr aktivieren, damit diese ordnungsgemäß gespeichert werden. Sonst gibt es hier eventuell Probleme. Diese NTACLs können allerdings ausschließlich von einem Windows Computer verwaltet werden.
Ich würde dir ansonsten einmal raten für die genaueren technischen Details wie Proxmox das genau löst in deren offiziellem Forum nachzufragen, da gibt es vielleicht auch mehr Linux Fileserver Enthusiasten ;).
da scheinbar die Antwortenden entweder ihre eigenen Dienstleistungen verkaufen wollen oder auf Veeam schwören:
Hallo,
derzeit laufen in einer Firma, dessen Netzwerk ich betreue, zwei Windows Server Hyper-V Hosts, jeweils mit einem recht großem Hardware RAID und mit automatischer Replizierung. Als Fileserver läuft auf einem der Hosts eine Windows VM die ein paar SMB Shares bereitstellt.
Nun bin ich am überlegen, wie man diesen Hyper-V Cluster auf einen Linux-basierten Ansatz wie z.B. Proxmox umziehen könnte um dank ZFS und der Mögichkeit für häufigere Snapshots an Flexibilität und Sicherheit zu gewinnen.
Nun bin ich am überlegen, wie man diesen Hyper-V Cluster auf einen Linux-basierten Ansatz wie z.B. Proxmox umziehen könnte um dank ZFS und der Mögichkeit für häufigere Snapshots an Flexibilität und Sicherheit zu gewinnen.
Da du von Hardware RAID sprichst würde ich erstmal prüfen, ob die Hardware Vorraussetzungen für ZFS überhaupt bestehen. Unterstützt die RAID Karte den HBA Modus?
Einen Proxmox-Cluster mit ZoL und Storage Replication aufzusetzen ist an sich auch kein Problem, nur habe ich jetzt noch nicht die optimale Lösung gefunden, wie man nun mit dem Fileserver am Besten weiter verfährt:
Option 1:
Man könnte weiter einen Windows Server virtualisieren, der dann Fileserver spielt. Als VM Disk würde dann ein ZFS Dataset (als Block Device) dienen, von dem Snapshots angelegt werden würden. Der Nachteil hieran ist, dass man, um z.B. eine einzige Datei aus einem Snapshot wiederherstellen zu können, erst die gesamte VM zurücksetzen müsste um diese dann zu starten und die eine Datei zu extrahieren. Sehr umständlich.
Option 1:
Man könnte weiter einen Windows Server virtualisieren, der dann Fileserver spielt. Als VM Disk würde dann ein ZFS Dataset (als Block Device) dienen, von dem Snapshots angelegt werden würden. Der Nachteil hieran ist, dass man, um z.B. eine einzige Datei aus einem Snapshot wiederherstellen zu können, erst die gesamte VM zurücksetzen müsste um diese dann zu starten und die eine Datei zu extrahieren. Sehr umständlich.
Option 2:
Man könnte Freenas statt Windows Server virtualisieren und dann innerhalb der VM ebenfalls ZFS benutzen. Auch wenn das gehen würde, so wird allseits davon abgeraten, ZFS in einer VM auf ZFS einzusetzen und meiner Erfahrung nach leidet darunter auch ziemlich die Performance. Für eine Produktivumgebung, finde ich diese Option ungeeignet.
Option 3:
Da Proxmox letztlich ja auch nur ein Debian ist, könnte man Samba direkt auf dem Host oder in einem LXC installieren und dann alle Daten in ein paar zusätzlichen ZFS Dataset ablegen. Diese Lösung gefällt mir am Besten, da man so auch den .zfs Ordner einbinden könnte um die Snapshots über die "Shadow Copies" Unterstützung von SMB verfügbar zu machen.
Allerdings wüsste ich bei dieser Option jetzt nicht, wie man damit High Availability umsetzen könnte? Man bräuchte dann einen Mechanismus, der die Daten automatisch zum zweiten Host repliziert und dann dort einen Samba-Server unter der gleichen IP startet. Könnte man das mit der Proxmox Storage Replication und LXC vielleicht irgendwie umsetzen? Hat das schonmal jemand gemacht und wie gut funktioniert das?
Man könnte Freenas statt Windows Server virtualisieren und dann innerhalb der VM ebenfalls ZFS benutzen. Auch wenn das gehen würde, so wird allseits davon abgeraten, ZFS in einer VM auf ZFS einzusetzen und meiner Erfahrung nach leidet darunter auch ziemlich die Performance. Für eine Produktivumgebung, finde ich diese Option ungeeignet.
Option 3:
Da Proxmox letztlich ja auch nur ein Debian ist, könnte man Samba direkt auf dem Host oder in einem LXC installieren und dann alle Daten in ein paar zusätzlichen ZFS Dataset ablegen. Diese Lösung gefällt mir am Besten, da man so auch den .zfs Ordner einbinden könnte um die Snapshots über die "Shadow Copies" Unterstützung von SMB verfügbar zu machen.
Allerdings wüsste ich bei dieser Option jetzt nicht, wie man damit High Availability umsetzen könnte? Man bräuchte dann einen Mechanismus, der die Daten automatisch zum zweiten Host repliziert und dann dort einen Samba-Server unter der gleichen IP startet. Könnte man das mit der Proxmox Storage Replication und LXC vielleicht irgendwie umsetzen? Hat das schonmal jemand gemacht und wie gut funktioniert das?
Windows Fileserver mit entsprechenden vollständigen Block Level Snapshots hat die entsprechenden von dir genannten Nachteile. Gerade wenn man einzelne Dateien extrahieren will, wenn z.B. ein Nutzer die wichtigen Daten in einem Ordner der letzten Tage gelöscht hat, wird das sehr schnell sehr hampelig. Klar mit Veeam könntest du, wie von den anderen gesagt, zusätzlich zu den Snapshots noch die Dateien seperat backupen, aber hier muss man auch schauen wie Veeam mit Dateiversionen umgeht und wie viel Speicherplatz das vorhalten von mehreren Monaten braucht. In Veeam bin ich aber kein Experte und kann dementsprechend nichts dazu sagen.
Wieso willst du FreeNas virtualisieren? Soll das für ein Samba Fileserver genutzt werden? Meiner Erfahrung nach ist ZFS in ZFS wirklich sehr langsam. Es geht, ja, aber Spaß macht das nicht. Zumal dann einige ZFS Funktionen ggf. nicht korrekt funktionieren, weshalb davon im Allgemeinen abgeraten wird.
Ohne dein genaues Einsatzszenario zu kennen, würde ich auch Option 3 präferieren. Du könntest mit Proxmox ein ZFS Storage anlegen und das zwischen deinen Nodes z.B. alle 5 Minuten replizieren, wie das z.B. auch HyperV im Cluster Modus macht. Mit dem entsprechenden Qemu Guest Agent kann Proxmox dann auch sicherstellen, das vor den Snapshot sämtliche Änderungen des Gastsystems geflusht werden und die VM im Notfall im konsistenten Zustand ist. Gleiches kannst du auch für das Datasets des LXC Container machen, in dem der Samba Fileserver läuft. Im Notfall fehlen dir dann 5 Minuten an Daten, wenn ein Server ausfällt. Gleichzeitig hat man aber eben den Vorteil, dass man z.B. mehrere Monate an Snapshots vorhalten kann (natürlich entsprechend mit der Zeit ausdünnen) und diese mit dem vfs_shadow_copy Modul von Samba einbinden kann. Dann können die Nutzer sogar selbstständig mit dem Versionsverlauf auf ältere Versionen oder gelöschte Dateien zugreifen und wiederherstellen. Habe ich mal mit rumgespielt und funktioniert echt einwandfrei. Leider ist das mit einem Windows Fileserver doch relativ hampelig dieses Snapshot System umzusetzen, da NTFS dafür schlicht nicht gebaut wurde, sodass ZFS + Samba schon einige Vorteile besitzt.
Diese Snapshots die du sowieso für die Replizierung anlegst kannst du auch mit pve-zsync direkt auf ein ZFS fähiges NAS (z.B. FreeNas) rüber schieben, sodass man die VMs notfalls auch wiederherstellen kann, wenn die RAIDs beider Nodes den Geist aufgeben, auch wenn das schon sehr unwahrscheinlich ist ;).
Vorsichtig muss man nur bei entsprechenden Datenbankanwendungen sein, wenn man Block Level Snapshots macht. Diese reagieren ggf. nicht immer auf das Flush vom Qemu Guest Agent. Hier bietet sich dann ggf. wirklich noch eine Veeam Instanz in der VM selber an z.B. bei einem SQL Server, die das dann auf ein entsprechendes Backup NAS oder ähnliches schiebt.
Kleiner Tipp:
Bei Samba empfiehlt sich der Einsatz von NTACLs statt Posix ACLs, wenn es sich um komplexere Berechtigungsstrukturen handeln sollte (Default). Ggf. musst du in ZFS die xattr aktivieren, damit diese ordnungsgemäß gespeichert werden. Sonst gibt es hier eventuell Probleme. Diese NTACLs können allerdings ausschließlich von einem Windows Computer verwaltet werden.
Ich würde dir ansonsten einmal raten für die genaueren technischen Details wie Proxmox das genau löst in deren offiziellem Forum nachzufragen, da gibt es vielleicht auch mehr Linux Fileserver Enthusiasten ;).
@BirdyB
Naja, schau bei ZFS mal in den .zfs Ordner der sich im Root jeden Mountpoints eines Datasets befindet. Einfacher kann man nicht auf seine Dateien zugreifen. Wenn man die dann über Samba mit dem entsprechenden shadow copy Module freigibt hat man für die Endnutzer viel gewonnen.
Im .zfs Ordner wird jeder Snapshot als Ordner abgebildet in dem man hinein navigieren kann und sich die Dateien im aktuellen Zustand des Snapshots anschauen kann ;).
Naja, schau bei ZFS mal in den .zfs Ordner der sich im Root jeden Mountpoints eines Datasets befindet. Einfacher kann man nicht auf seine Dateien zugreifen. Wenn man die dann über Samba mit dem entsprechenden shadow copy Module freigibt hat man für die Endnutzer viel gewonnen.
Im .zfs Ordner wird jeder Snapshot als Ordner abgebildet in dem man hinein navigieren kann und sich die Dateien im aktuellen Zustand des Snapshots anschauen kann ;).
Hat weder was von auf Veeam schwören, noch mit eigenen Dienstleistungen zu tun.
Er will eine praktikable nicht frickelige Lösung aber offensichtlich geht es alles in die Richtung. Zu dem muss er so dann wieder schauen wie er die Basis, die Samba Shakes und die Probleme mit dem Unbekannten VM Konstellation unter den Hut bringt.
Hier sehe ich die beste Lösung mit einem beibehalt des Clusters (oder neudesigns) und der Höherfrequenten Sicherung per Veeam. Das geht auch multilevel.
Aber wenn er das abweichen von der Idee als nichtlesen interpretiert, dann soll er das machen. Seh da aber mittlerweile das Festhalten an einer fixen Idee.
Da muss er dann aber durch, wenn er keine anderen Meinungen (auch du) hören will soll er besser anderweitig Rat holen, den er ggf. Besser Steuern kann. ;)
Er will eine praktikable nicht frickelige Lösung aber offensichtlich geht es alles in die Richtung. Zu dem muss er so dann wieder schauen wie er die Basis, die Samba Shakes und die Probleme mit dem Unbekannten VM Konstellation unter den Hut bringt.
Hier sehe ich die beste Lösung mit einem beibehalt des Clusters (oder neudesigns) und der Höherfrequenten Sicherung per Veeam. Das geht auch multilevel.
Aber wenn er das abweichen von der Idee als nichtlesen interpretiert, dann soll er das machen. Seh da aber mittlerweile das Festhalten an einer fixen Idee.
Da muss er dann aber durch, wenn er keine anderen Meinungen (auch du) hören will soll er besser anderweitig Rat holen, den er ggf. Besser Steuern kann. ;)
Guten Abend,
hältst du es vielleicht als Option aus der Hardware eine Hyperconverged Umgebung zu bauen?
Sprich du nimmst den Hypervisor deiner Wahl und ebenfalls ein Storage virtualisierer deiner Wahl (Datacore, Open-E etc.) welcher deine nötigen Funktionen zur Verfügung stellt und baust den per RAW Device Mapping ein. Dann stellst du für die VM Umgebung ein NFS oder ISCSI Share zur Verfügung und für Files SMB mit Snapshots. Klar bissle teurer aber dann hast auch einen ordentlicher Sync.
hältst du es vielleicht als Option aus der Hardware eine Hyperconverged Umgebung zu bauen?
Sprich du nimmst den Hypervisor deiner Wahl und ebenfalls ein Storage virtualisierer deiner Wahl (Datacore, Open-E etc.) welcher deine nötigen Funktionen zur Verfügung stellt und baust den per RAW Device Mapping ein. Dann stellst du für die VM Umgebung ein NFS oder ISCSI Share zur Verfügung und für Files SMB mit Snapshots. Klar bissle teurer aber dann hast auch einen ordentlicher Sync.
@Waishon Danke für deine Einschätzung, genau darauf wollte ich mit meiner Frage hinaus. Deine Beschreibung einer möglichen Umsetzung passt ziemlich genau zu dem, was ich vorhatte, das werte ich mal als Bestätigung für Option 3. 
Wie das mit der Verfügbarkeit des Samba LXC in der Praxis funktioniert, und ob Proxmox den Container bei einem Ausfall direkt auf einem anderen Host wieder startet, muss ich wohl einfach mal testen. Wenn das so klappt, dann ist das ja wirklich eine sehr saubere und einfache Lösung. Eine LDAP-Integration bringt Proxmox ja sogar schon mit. Die muss man dann allerdings auch in den LXC reinbringen und auf das korrekte Mapping der Permissions achten, wie du meintest.
@certifiedit.net Auch, wenn es bei meiner Frage ursprünglich darum ging, wie ich am geschicktesten einen Fileserver mit der geplanten Infrastruktur betreiben kann, bin ich selbstverständlich auch offen für Alternativvorschläge für andere Technologien, die Proxmox/ZFS überlegen sind. Ich weiß nicht, ob du bereits Erfahrungen mit dem praktischen Einsatz von ZFS sammeln durftest, aber meiner Ansicht nach, ist Veeam bei weitem keine vergleichbare Alternative, da es, auch wenn es eine sehr gute Software ist, in Hinsicht auf Snapshots zwangsläufig unter den gleichen Einschränkungen leidet, wie NTFS auch.
Sicher kann man da auch irgendwie was mit Veeam hinbiegen, das von der Funktionalität her an ZFS rankommt, das erscheint mir dann aber eher wie eine Frickellösung, die das nachahmen soll, was man mit ZFS von Haus aus auch in sauber und robust bekommt.
Dennoch danke für deinen Vorschlag. Veeam haben wir aktuell schon im Einsatz, und ich werde nochmal erörtern, inwiefern wir die aktuelle Konfiguration optimieren können, sodass vielleicht zumindest kurzfristig keine Umstellung nötig ist. Aber davon, Proxmox mit ZFS als langfristig bessere Alternative in Betracht zu ziehen, bringt mich das nicht ab.
NTFS ist halt einfach in der Zeit stehen geblieben, und auch wenn Microsoft sich größte Mühe gegeben hat, da noch neue Funktionen wie Shadow Copies einzubauen, so ist und bleibt es halt immernoch die gleiche alte Architektur. Daran kann auch Veeam nichts ändern. Da ist ZFS, als komplett neuer Ansatz zu allem, was bis dahin verbreitet war, nunmal die wesentlich fortschrittlichere und flexibere Alternative. Aber wer weiß, vielleicht wagt sich Microsoft da ja nochmal an einen Neuanfang, wie es mit APFS ja sogar Apple gewagt hat (wenn auch mit einigen Problemen, aber anderes Thema :D), aber bis dahin fährt man wohl mit OpenZFS am Besten.
@Fabezz Vielen Dank für diesen Vorschlag. Tatsächlich hatte ich über soetwas ähnliches auch schon nachgedacht, in meinem Fall dann mit einer FreeNAS/TrueNAS Box für Storage, die direkt die SMB Shares bereitstellt und dann den Speicher für den Proxmox-Cluster über iSCSI oder Ceph bereitstellt. Das wäre vermutlich die schönste Lösung, aber wie du schon angemerkt hattest, dafür braucht man dann mehr und ggf. andere Hardware. Vorallem wenn man sowohl Storage als auch VM-Hosts redundant auslegen will. Das ist aktuell leider nicht drin.
Ich denke ich werde diesen Thread jetzt erstmal als Gelöst markieren. Es sieht aber so aus, als wäre Option 3 wohl tatsächlich die vernünftigste Lösung für so ein Einsatzszenario mit der bestehenden Hardware. Ich werde das mal evaluieren, wie gut das funktioniert und mich bei konkreten Fragen zu Proxmox wohl besser an geeigneterer Stelle wenden.
Ich danke euch für eure Vorschläge!
Wie das mit der Verfügbarkeit des Samba LXC in der Praxis funktioniert, und ob Proxmox den Container bei einem Ausfall direkt auf einem anderen Host wieder startet, muss ich wohl einfach mal testen. Wenn das so klappt, dann ist das ja wirklich eine sehr saubere und einfache Lösung. Eine LDAP-Integration bringt Proxmox ja sogar schon mit. Die muss man dann allerdings auch in den LXC reinbringen und auf das korrekte Mapping der Permissions achten, wie du meintest.
@certifiedit.net Auch, wenn es bei meiner Frage ursprünglich darum ging, wie ich am geschicktesten einen Fileserver mit der geplanten Infrastruktur betreiben kann, bin ich selbstverständlich auch offen für Alternativvorschläge für andere Technologien, die Proxmox/ZFS überlegen sind. Ich weiß nicht, ob du bereits Erfahrungen mit dem praktischen Einsatz von ZFS sammeln durftest, aber meiner Ansicht nach, ist Veeam bei weitem keine vergleichbare Alternative, da es, auch wenn es eine sehr gute Software ist, in Hinsicht auf Snapshots zwangsläufig unter den gleichen Einschränkungen leidet, wie NTFS auch.
Sicher kann man da auch irgendwie was mit Veeam hinbiegen, das von der Funktionalität her an ZFS rankommt, das erscheint mir dann aber eher wie eine Frickellösung, die das nachahmen soll, was man mit ZFS von Haus aus auch in sauber und robust bekommt.
Dennoch danke für deinen Vorschlag. Veeam haben wir aktuell schon im Einsatz, und ich werde nochmal erörtern, inwiefern wir die aktuelle Konfiguration optimieren können, sodass vielleicht zumindest kurzfristig keine Umstellung nötig ist. Aber davon, Proxmox mit ZFS als langfristig bessere Alternative in Betracht zu ziehen, bringt mich das nicht ab.
NTFS ist halt einfach in der Zeit stehen geblieben, und auch wenn Microsoft sich größte Mühe gegeben hat, da noch neue Funktionen wie Shadow Copies einzubauen, so ist und bleibt es halt immernoch die gleiche alte Architektur. Daran kann auch Veeam nichts ändern. Da ist ZFS, als komplett neuer Ansatz zu allem, was bis dahin verbreitet war, nunmal die wesentlich fortschrittlichere und flexibere Alternative. Aber wer weiß, vielleicht wagt sich Microsoft da ja nochmal an einen Neuanfang, wie es mit APFS ja sogar Apple gewagt hat (wenn auch mit einigen Problemen, aber anderes Thema :D), aber bis dahin fährt man wohl mit OpenZFS am Besten.
@Fabezz Vielen Dank für diesen Vorschlag. Tatsächlich hatte ich über soetwas ähnliches auch schon nachgedacht, in meinem Fall dann mit einer FreeNAS/TrueNAS Box für Storage, die direkt die SMB Shares bereitstellt und dann den Speicher für den Proxmox-Cluster über iSCSI oder Ceph bereitstellt. Das wäre vermutlich die schönste Lösung, aber wie du schon angemerkt hattest, dafür braucht man dann mehr und ggf. andere Hardware. Vorallem wenn man sowohl Storage als auch VM-Hosts redundant auslegen will. Das ist aktuell leider nicht drin.
Ich denke ich werde diesen Thread jetzt erstmal als Gelöst markieren. Es sieht aber so aus, als wäre Option 3 wohl tatsächlich die vernünftigste Lösung für so ein Einsatzszenario mit der bestehenden Hardware. Ich werde das mal evaluieren, wie gut das funktioniert und mich bei konkreten Fragen zu Proxmox wohl besser an geeigneterer Stelle wenden.
Ich danke euch für eure Vorschläge!
Hallo maichelmann,
ich verstehe deine Aussage gerade nicht. Wenn du eh alles auf den zweiten Host replizierst dann sollte doch die Hardware bereits für "virtuellen Storage Cluster im Bauch" ausreichen.
Klar ist dass du kein Ceph nehmen kannst da hier Erasure coding n+1 nicht aufgeht und somit der Zustand von Ceph nicht hergestellt werden kann. Deshalb einen anderen vstorage Hersteller welcher nicht 3 Nodes benötigt.
Somit kannst du eine saubere Lösung mit Replikation bzw. Aktiv/Aktiv hochziehen und hättest alle Funktionen die du willst. Ob dies Freenas unterstützt kann ich nicht sagen da ich es nicht kenne.
ich verstehe deine Aussage gerade nicht. Wenn du eh alles auf den zweiten Host replizierst dann sollte doch die Hardware bereits für "virtuellen Storage Cluster im Bauch" ausreichen.
Klar ist dass du kein Ceph nehmen kannst da hier Erasure coding n+1 nicht aufgeht und somit der Zustand von Ceph nicht hergestellt werden kann. Deshalb einen anderen vstorage Hersteller welcher nicht 3 Nodes benötigt.
Somit kannst du eine saubere Lösung mit Replikation bzw. Aktiv/Aktiv hochziehen und hättest alle Funktionen die du willst. Ob dies Freenas unterstützt kann ich nicht sagen da ich es nicht kenne.
@Fabezz
Ah, da hatte ich dich wohl falsch verstanden. Proxmox untertützt dieses Konzept letztlich auch schon, sodass ich auch das einfach mit ZFS nutzen könnte, um so eine HCI aufzuziehen. Mit einem Samba für SMB obendrauf, läufts dann auf genau das hinaus, was ich auch unter "Option 3" schon beschrieben hatte.
Das ist mit ZFS an sich dann zwar nicht wirklich ein Storage Cluster, aber zusammen mit Storage Replication reicht das trotzdem schon für diesen Anwendungsfall.
Ah, da hatte ich dich wohl falsch verstanden. Proxmox untertützt dieses Konzept letztlich auch schon, sodass ich auch das einfach mit ZFS nutzen könnte, um so eine HCI aufzuziehen. Mit einem Samba für SMB obendrauf, läufts dann auf genau das hinaus, was ich auch unter "Option 3" schon beschrieben hatte.
Das ist mit ZFS an sich dann zwar nicht wirklich ein Storage Cluster, aber zusammen mit Storage Replication reicht das trotzdem schon für diesen Anwendungsfall.
Zitat von @Waishon:
Windows Fileserver mit entsprechenden vollständigen Block Level Snapshots hat die entsprechenden von dir genannten Nachteile. Gerade wenn man einzelne Dateien extrahieren will, wenn z.B. ein Nutzer die wichtigen Daten in einem Ordner der letzten Tage gelöscht hat, wird das sehr schnell sehr hampelig. Klar mit Veeam könntest du, wie von den anderen gesagt, zusätzlich zu den Snapshots noch die Dateien seperat backupen, aber hier muss man auch schauen wie Veeam mit Dateiversionen umgeht und wie viel Speicherplatz das vorhalten von mehreren Monaten braucht. In Veeam bin ich aber kein Experte und kann dementsprechend nichts dazu sagen.
Windows Fileserver mit entsprechenden vollständigen Block Level Snapshots hat die entsprechenden von dir genannten Nachteile. Gerade wenn man einzelne Dateien extrahieren will, wenn z.B. ein Nutzer die wichtigen Daten in einem Ordner der letzten Tage gelöscht hat, wird das sehr schnell sehr hampelig. Klar mit Veeam könntest du, wie von den anderen gesagt, zusätzlich zu den Snapshots noch die Dateien seperat backupen, aber hier muss man auch schauen wie Veeam mit Dateiversionen umgeht und wie viel Speicherplatz das vorhalten von mehreren Monaten braucht. In Veeam bin ich aber kein Experte und kann dementsprechend nichts dazu sagen.
Moin,
Mit VSS ist das wiederherstellen einzelner Dateien doch geradezu trivial, keine Ahnung warum man das alles jetzt unnötig kompliziert machen will.
/Thomas
