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.
Please also mark the comments that contributed to the solution of the article
Content-ID: 561913
Url: https://administrator.de/contentid/561913
Printed on: October 11, 2024 at 15:10 o'clock
17 Comments
Latest comment
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
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...
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.
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.
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