AliManali
cpt sunday flyer
Ich habe jetzt die zwei Platten, und werde die dann halt an das bestehende napp-it ins Management vLAN klemmen, und SMB dort hin beregeln. So weit, so gut.
NFS habe ich theoretisch schon in der Firewall nur der ESXi vmKernel IP selber freigegeben bzw. beregelt. Nun möchte ich aber im napp-it zusätzlich NFS nochmals nur am Host selber zulassen. Wie mache ich das nochmals? Unter Dienste NFS, oder unter ZFS Dateisysteme? Finde die betreffende Option irgendwie gerade nicht.
NFS habe ich theoretisch schon in der Firewall nur der ESXi vmKernel IP selber freigegeben bzw. beregelt. Nun möchte ich aber im napp-it zusätzlich NFS nochmals nur am Host selber zulassen. Wie mache ich das nochmals? Unter Dienste NFS, oder unter ZFS Dateisysteme? Finde die betreffende Option irgendwie gerade nicht.
martingo
Experte
- Mitglied seit
- 17.01.2017
- Beiträge
- 1.300
Für den ZFS Dataset NFS deaktivieren und wieder aktivieren.
Bei der Aktivierung gibt es eine Eingabezeile und dort könntest Du reinschreiben:
rw=10.1.8.11/32
Was Schreibzugriff von dieser IP zulässt und sonst keine Zugriffe. Steht aber auch etwas ausführlicher im Kommentar unter der Eingabezeile, denke ich.
Bei der Aktivierung gibt es eine Eingabezeile und dort könntest Du reinschreiben:
rw=10.1.8.11/32
Was Schreibzugriff von dieser IP zulässt und sonst keine Zugriffe. Steht aber auch etwas ausführlicher im Kommentar unter der Eingabezeile, denke ich.
Ich habe erst heute gelernt, dass HW Raid Schnee von gestern und ZFS der neue heiße Scheiß ist.
Nun überlege ich, ob es Sinn macht meinen Server umzustellen und wie viel Aufwand damit verbunden wäre.
Sehe ich es richtig, dass ...
1. ... ich meinen Controller auf IT Mode flashen müsste oder die Platten direkt an den onboard Controller hängen müsste?
2. ... ich nicht weiterhin Windows Server als Basis (mit Hyper-V VMs) benutzen kann?
3. ... ich trotz ZFS keine unterschiedlich großen HDDs zusammen in einen Pool werfen kann?
4. ... 48GB ECC UDIMM knapp wäre für insgesamt 56TB Plattenkapazität?
5. ... der Umzug aktuell (bei laufendem System ohne HW-Umbaupläne) mehr Aufwand als Nutzen brächte?
Danke
Nun überlege ich, ob es Sinn macht meinen Server umzustellen und wie viel Aufwand damit verbunden wäre.
Sehe ich es richtig, dass ...
1. ... ich meinen Controller auf IT Mode flashen müsste oder die Platten direkt an den onboard Controller hängen müsste?
2. ... ich nicht weiterhin Windows Server als Basis (mit Hyper-V VMs) benutzen kann?
3. ... ich trotz ZFS keine unterschiedlich großen HDDs zusammen in einen Pool werfen kann?
4. ... 48GB ECC UDIMM knapp wäre für insgesamt 56TB Plattenkapazität?
5. ... der Umzug aktuell (bei laufendem System ohne HW-Umbaupläne) mehr Aufwand als Nutzen brächte?
Danke
Zuletzt bearbeitet:
Trambahner
Urgestein
zu 1: Ja
zu 2: Nein. Die ZFS-Filer-VM kann Shares ja als SMB oder ISCSI an den Windows-Server exportieren. Hyper-V kann SMB z.B. zur Ablage von HDD-Images nutzen, wie es ESXI mit NFS kann.
=> Ein Hyper-V-Server kann eine Storage-VM haben (Platten können vom Hyper-V durchgereicht werden ) und die Storage VM exportiert den Speicher wieder an den gleichen Hyper-V Server.
Funktioniert mit aktuellem Hyper-V und passendem Storage-OS wie bei ESXI. Mit FreeBSD/Xigmanas und Server 2019 Eval hab ich das getestet, bin aber noch nicht happy mit dem Durchsatz (bis jetzt nur max ~550 MB/s sequentiell erreicht, obwohl der Testpool etwa das doppelte könnte). Die ESXI-AIO-Lösung scheint da performanter zu sein.
Mit Hyper-V und ZFS hab ich vor Kurzem experimentiert, weil ich gerne eine AIO Windows-Workstation hätte, die aber ZFS drunter hat statt NTFS. Aber wie gesagt, mir gefällt der I/O-Durchsatz (noch) nicht. Andersrum, Windows-VM @ Bhyve, fand ich, vorsichtig gesagt, nicht....gut bzgl. Verhalten.
zu 3: Jein. Die kleinste HDD eines Pools mit Redundanz gibt halt den Ton an.
zu 4: Nein. Kommt immer auf die Nutzungmuster an. Ich habe eine ZFS-Filer-VM mit 6x14TB Raidz2 und 3*2*960GB SSD striped Mirror Pool; läuft wunderbarst mit 16 GB.
zu 5: musst Du für Dich beantworten.
zu 2: Nein. Die ZFS-Filer-VM kann Shares ja als SMB oder ISCSI an den Windows-Server exportieren. Hyper-V kann SMB z.B. zur Ablage von HDD-Images nutzen, wie es ESXI mit NFS kann.
=> Ein Hyper-V-Server kann eine Storage-VM haben (Platten können vom Hyper-V durchgereicht werden ) und die Storage VM exportiert den Speicher wieder an den gleichen Hyper-V Server.
Funktioniert mit aktuellem Hyper-V und passendem Storage-OS wie bei ESXI. Mit FreeBSD/Xigmanas und Server 2019 Eval hab ich das getestet, bin aber noch nicht happy mit dem Durchsatz (bis jetzt nur max ~550 MB/s sequentiell erreicht, obwohl der Testpool etwa das doppelte könnte). Die ESXI-AIO-Lösung scheint da performanter zu sein.
Mit Hyper-V und ZFS hab ich vor Kurzem experimentiert, weil ich gerne eine AIO Windows-Workstation hätte, die aber ZFS drunter hat statt NTFS. Aber wie gesagt, mir gefällt der I/O-Durchsatz (noch) nicht. Andersrum, Windows-VM @ Bhyve, fand ich, vorsichtig gesagt, nicht....gut bzgl. Verhalten.
zu 3: Jein. Die kleinste HDD eines Pools mit Redundanz gibt halt den Ton an.
zu 4: Nein. Kommt immer auf die Nutzungmuster an. Ich habe eine ZFS-Filer-VM mit 6x14TB Raidz2 und 3*2*960GB SSD striped Mirror Pool; läuft wunderbarst mit 16 GB.
zu 5: musst Du für Dich beantworten.
Zuletzt bearbeitet:
ZFS braucht RAM vor allem für den Schreib-Lesecache und für Dedup. Als Faustregel:
2 GB für ein 64bit OS (egal ob BSD, OSX, Linux, Solarish oder Windows)
1 GB extra falls BSD oder Linux (ZFS Ramverwaltung ist intern noch immer weitgehends Solaris, dafür wurde ZFS ja entwickelt)
2 GB optional für den Virtualisierer z.B. ESXi (All in One)
x GB für VMs (optional, All in One)
0,5 (napp-it) bis 2 GB (geschätzt FreeNAS) für Management Tool
Falls man Platten wie Intel Optane ohne Dedup einsetzt, bringt mehr RAM nicht soviel, unabhängig von der Poolgröße. Für ein NAS unter Solarish ist man also mit 4GB, mit FreeNAS eher bei 8GB Minimum.
Dazu kommt der RAM der Performance bringt. Der rambasierte Schreibcache nutzt per default 10%RAM/max 4GB. Der rambasierte Lesecache dynamisch bis ca 80% vom Rest. Je nach Performanceanforderung und Nutzerverhalten kommt man auch auf 8-64GB RAM für einen normalen Filer. Bei vielen Nutzern und kleinen Dateien (Mailserver) auch mehr (64-256 GB RAM).
Aktiviert man Echtzeit-Dedup kommen dazu bis zu 5 GB RAM je TB deduplizierte Daten - sofern man keine special vdev für dedup nutzt und daher keinen RAM für die dedup Tabelle braucht.
2 GB für ein 64bit OS (egal ob BSD, OSX, Linux, Solarish oder Windows)
1 GB extra falls BSD oder Linux (ZFS Ramverwaltung ist intern noch immer weitgehends Solaris, dafür wurde ZFS ja entwickelt)
2 GB optional für den Virtualisierer z.B. ESXi (All in One)
x GB für VMs (optional, All in One)
0,5 (napp-it) bis 2 GB (geschätzt FreeNAS) für Management Tool
Falls man Platten wie Intel Optane ohne Dedup einsetzt, bringt mehr RAM nicht soviel, unabhängig von der Poolgröße. Für ein NAS unter Solarish ist man also mit 4GB, mit FreeNAS eher bei 8GB Minimum.
Dazu kommt der RAM der Performance bringt. Der rambasierte Schreibcache nutzt per default 10%RAM/max 4GB. Der rambasierte Lesecache dynamisch bis ca 80% vom Rest. Je nach Performanceanforderung und Nutzerverhalten kommt man auch auf 8-64GB RAM für einen normalen Filer. Bei vielen Nutzern und kleinen Dateien (Mailserver) auch mehr (64-256 GB RAM).
Aktiviert man Echtzeit-Dedup kommen dazu bis zu 5 GB RAM je TB deduplizierte Daten - sofern man keine special vdev für dedup nutzt und daher keinen RAM für die dedup Tabelle braucht.
hast du dazu mal etwas mehr info / einen Link zum schlau machen ?
Meine Kiste hat 16GB RAM und recht viel HD space, das würde nicht passen, aber ich könnte von einer NVME "Platte" noch ein paar 100 GB opfern...
Wenn man nach "ZFS special vdev" googelt, findet man noch nicht allzuviel Information. Dieses Open-ZFS Feature gibt es ja auch erst seit ein paar Monaten unter Illumos/OmniOS und ZoL.
Prinzipiell nutzt man ein "special vdev" um Daten anhand bestimmter Markmale ausschließlich auf diesem (schnelleren) vdev zu speichern. Als Merkmal kann man neben der Dedup Tabelle auch Metadaten oder small io nutzen oder einzelne Dateisysteme anhand der recsize auf ein derartiges vdev zwingen. Special vdevs sollten 2/3 way mirrors sein da ein vdev Ausfall den Pool schrottet. Ein special vdev kann man aber wieder entfernen - sofern es die gleiche ashift wie der Pool hat, https://www.illumos.org/issues/11840
Prinzipiell nutzt man ein "special vdev" um Daten anhand bestimmter Markmale ausschließlich auf diesem (schnelleren) vdev zu speichern. Als Merkmal kann man neben der Dedup Tabelle auch Metadaten oder small io nutzen oder einzelne Dateisysteme anhand der recsize auf ein derartiges vdev zwingen. Special vdevs sollten 2/3 way mirrors sein da ein vdev Ausfall den Pool schrottet. Ein special vdev kann man aber wieder entfernen - sofern es die gleiche ashift wie der Pool hat, https://www.illumos.org/issues/11840
G
Gelöschtes Mitglied 304674
Guest
Hi,
ich habe bisher noch nie mit ZFS gearbeitet, aber möchte es aus Gründen der Datensicherheit gerne für meinen kommenden Homeserver einsetzen.
Dazu habe ich mal dieses Dokument von der napp-it Website herangezogen und bin gerade dabei dieses vollständig durchzulesen.
Einige Dinge sind mir noch nicht ganz klar...
Ich bin zwar noch nicht komplett durch, aber ich dachte mir ich frage diesbezüglich trotzdem schon mal in die Runde:
1.
Wenn ich das richtig verstanden habe, dann sammelt ZFS kleinere Datenmengen in einem "writecache" im RAM, bevor diese gemeinsam als größere Datenmenge auf die Platten geschrieben werden. Sollte dabei z.B. der Fall eines Stromausfalls eintreten, ist der Cache verloren.
Was passiert wenn der writecache verloren geht? Ist das schlimm? Sollte mich das interessieren?
Das könnte man mit einem "SLOG" verhindern?
Dadurch hätte ich allerdings einen allgemeinen Performance Verlust, selbst wenn dafür eine Intel Optane 800P 58GB verwende?
Habe ich das richtig verstanden? Wie kommt der Performance Verlust zustande?
Ist so ein SLOG jetzt für einen eher kleinen Heimserver (für NAS & einige VMs) interessant oder eher weniger?
2.
Ich dachte man unterscheided bei ZFS grunsätzlich zwischen Pools und Mirrors, aber nachdem ich das PDF gelesen habe verstehe ich es eher folgendermaßen:
Man hat IMMER Pools, z.B. je nach Anwendungsfall:
pool-1 für redundaten HDD Storage
pool-2 für nicht redundanten HDD Storage
pool-3 für performance auf SSDs
In diesen Pools erstellt man dann IMMER vdevs, also z.B.:
pool1-vdev-1: 2x 6TB HDD als Mirror
pool1-vdev-2: 2x 2TB HDD als Mirror
ein Pool wäre dann ganz einfach und sehr flexibel erweiterbar durch hinzufügen eines weiteren vdevs.
In dem Fall wieder ein Mirror aus zwei beliebig großen Platten.
Das wäre ja absolut mega geil... genau sowas möchte ich eigentlich erreichen.
Allerdings steht da auch, dass sich die vdevs wie ein RAID-0 verhalten... also habe ich es doch falsch verstanden?
ich habe bisher noch nie mit ZFS gearbeitet, aber möchte es aus Gründen der Datensicherheit gerne für meinen kommenden Homeserver einsetzen.
Dazu habe ich mal dieses Dokument von der napp-it Website herangezogen und bin gerade dabei dieses vollständig durchzulesen.
Einige Dinge sind mir noch nicht ganz klar...
Ich bin zwar noch nicht komplett durch, aber ich dachte mir ich frage diesbezüglich trotzdem schon mal in die Runde:
1.
Wenn ich das richtig verstanden habe, dann sammelt ZFS kleinere Datenmengen in einem "writecache" im RAM, bevor diese gemeinsam als größere Datenmenge auf die Platten geschrieben werden. Sollte dabei z.B. der Fall eines Stromausfalls eintreten, ist der Cache verloren.
Was passiert wenn der writecache verloren geht? Ist das schlimm? Sollte mich das interessieren?
Das könnte man mit einem "SLOG" verhindern?
Dadurch hätte ich allerdings einen allgemeinen Performance Verlust, selbst wenn dafür eine Intel Optane 800P 58GB verwende?
Habe ich das richtig verstanden? Wie kommt der Performance Verlust zustande?
Ist so ein SLOG jetzt für einen eher kleinen Heimserver (für NAS & einige VMs) interessant oder eher weniger?
2.
Ich dachte man unterscheided bei ZFS grunsätzlich zwischen Pools und Mirrors, aber nachdem ich das PDF gelesen habe verstehe ich es eher folgendermaßen:
Man hat IMMER Pools, z.B. je nach Anwendungsfall:
pool-1 für redundaten HDD Storage
pool-2 für nicht redundanten HDD Storage
pool-3 für performance auf SSDs
In diesen Pools erstellt man dann IMMER vdevs, also z.B.:
pool1-vdev-1: 2x 6TB HDD als Mirror
pool1-vdev-2: 2x 2TB HDD als Mirror
ein Pool wäre dann ganz einfach und sehr flexibel erweiterbar durch hinzufügen eines weiteren vdevs.
In dem Fall wieder ein Mirror aus zwei beliebig großen Platten.
Das wäre ja absolut mega geil... genau sowas möchte ich eigentlich erreichen.
Allerdings steht da auch, dass sich die vdevs wie ein RAID-0 verhalten... also habe ich es doch falsch verstanden?
Dann sind die Daten im write cache weg. Dein Dateisystem ist aber nicht kaputt ("atomic writes"), es wurde nur eben die letzte Änderung nicht gespeichert.
Nicht anders als beim Arbeiten unter Windows oder Linux (dort gibt's m.W. ebenfalls ein RAM-caching der writes).
Nein.
Relevant nur bei Sync writes: ZIL (ZFS Intention Log) oder separates device als ZIL = SLOG stellt sicher, dass zunächst alles im log notiert wird, was ZFS auf Platte schreiben will, und dann erst auf Platte geschrieben wird, und wenn das auch erfolgreich war, dann erst wird der write als bestätigt gemeldet (solange "hängt" uU der schreibende Prozess). Schützt davor, dass nur ein Teil auf Platte geschrieben wird und dann der storage abstürzt (bei Absturz kann dann das ZIL / SLOG neu gelesen und neu auf Platte geschrieben werden).
Ja. Selbst mit SLOG sind sync writes langsamer als async writes. Nur eben nicht sooo viel langsamer als ohne SLOG.
Umgekehrt -- Du erstellst vdevs und fügst sie zu einem Pool zusammen (oder dazu).
Ja.
Ein Pool mit 2 mirror-vdevs funktioniert in etwa wie ein RAID 10: mirror ~ RAID1, 2 vdevs in einem Pool ~ RAID0. Denn die Writes werden innerhalb eines pools (mehr oder weniger) gleichmäßig auf die vorhandenen vdevs verteilt.
zu Pools
Wenn man einen neuen Pool anlegen möchte (zpool create), so muss man auf jeden Fall dabei ein erstes vdev angeben (Basic, Mirror, RaidZn). Später kann man weitere vdevs hinzufügen um den Pool größer/schneller zu machen.
Ramcache
Der kann mehrere GB groß sein. Bei einem Absturz sind die weg. Wenn es sich dabei um ein großes Dokument handelt, ist das eh kaputt, es sei denn es war bereits komplett im Cache. Einen Datenverlust kann da nur ein schreibendes Programm (z.B. Word) durch eigene tmp-Files verhindern. Anders sieht es aus wenn man mit Transaktionen arbeitet, z.B. ein Buchhaltungsprogramm bucht etwas von einem Konto um es nach weiteren Bearbeitungsschritten auf ein anderes Konto zu buchen. Da könnte es passieren dass es die Abbuchung auf Platte schafft, nicht aber die folgende Aufbuchung. Auch VMs mit fremden Dateisystemen sind extrem kritisch. Da könnte es eine Datenänderung auf Platte schaffen, nicht aber das auch nötige Update der Metadaten. Das Dateisystem ist dann korrupt.
Für ZFS selber ist das kein Problem, da es atomare Schreibvorgänge (z.B. Daten + Metadaten) immer komplett neu schreibt oder eben komplett verwirft (Copy on Write).
Aktiviert man sync write, so wird jeder bestätigte Schreibvorgang im ZIL/Slog protokolliert um ihn beim Crash nach dem nächsten reboot nachträglich auf Platte zu bringen. Anschließend gehen die Daten in den Schreibcache. Da man damit alle Daten zweimal schreiben muss, ist sync auch mit dem schnellsten Slog der Welt deutlich langsamer als Schreiben ohne sync Absicherung.
Wenn man einen neuen Pool anlegen möchte (zpool create), so muss man auf jeden Fall dabei ein erstes vdev angeben (Basic, Mirror, RaidZn). Später kann man weitere vdevs hinzufügen um den Pool größer/schneller zu machen.
Ramcache
Der kann mehrere GB groß sein. Bei einem Absturz sind die weg. Wenn es sich dabei um ein großes Dokument handelt, ist das eh kaputt, es sei denn es war bereits komplett im Cache. Einen Datenverlust kann da nur ein schreibendes Programm (z.B. Word) durch eigene tmp-Files verhindern. Anders sieht es aus wenn man mit Transaktionen arbeitet, z.B. ein Buchhaltungsprogramm bucht etwas von einem Konto um es nach weiteren Bearbeitungsschritten auf ein anderes Konto zu buchen. Da könnte es passieren dass es die Abbuchung auf Platte schafft, nicht aber die folgende Aufbuchung. Auch VMs mit fremden Dateisystemen sind extrem kritisch. Da könnte es eine Datenänderung auf Platte schaffen, nicht aber das auch nötige Update der Metadaten. Das Dateisystem ist dann korrupt.
Für ZFS selber ist das kein Problem, da es atomare Schreibvorgänge (z.B. Daten + Metadaten) immer komplett neu schreibt oder eben komplett verwirft (Copy on Write).
Aktiviert man sync write, so wird jeder bestätigte Schreibvorgang im ZIL/Slog protokolliert um ihn beim Crash nach dem nächsten reboot nachträglich auf Platte zu bringen. Anschließend gehen die Daten in den Schreibcache. Da man damit alle Daten zweimal schreiben muss, ist sync auch mit dem schnellsten Slog der Welt deutlich langsamer als Schreiben ohne sync Absicherung.
G
Gelöschtes Mitglied 304674
Guest
Vielen Dank euch beiden für die schnelle Rückmeldung.
Also nur dann wenn die anderen vdevs bereits fast voll sind.
In dem Fall würde einfach einer nach dem anderen voll gemacht werden, oder?
Aus dem SLOG und Sync/Async werde ich noch nicht ganz schlau.
Wie macht sich dieser Performanceverlust denn bemerkbar, bzw. wie stark ist dieser?
In welchem Szenario würde man denn Sync oder Async einsetzen und wann einen SLOG verwenden?
Ich kann das aktuell sehr schlecht einschätzen.
Ich hätte folgende Pools (eigentlich wie oben beschrieben) geplant:
Pool für redundanten HDD Storage (vdevs aus 2er Mirror SATA Platten)
Wird als normales NAS benutzt und für Nutzdaten der VMs (z.B. Dateien der Nextcloud)
Darauf sind Bilder, Musik, Office Dateien etc. - Alles mögliche Querbeet
Sind Sync Writes hier sinnvoll? Ich würde das wahrscheinlich abhängig vom Performanceverlust entscheiden?
Pool für nicht redundanten HDD Storage (vdevs aus einzelnen SATA Platten)
Hauptsächlich Filme, also große Dateien zwischen ca. 3-20GB oder mehr.
Ich gehe davon aus hier eher Async Writes?
Pool für VM Storage (und evtl. Proxmox Hypervisor OS?) (vdevs aus 2er Mirror M.2 NVMe PCIe SSDs)
Für verschiedene VMs, hauptsächlich Linux/BSD aber auch Windows.
Hierfür ist mir noch nicht klar ob ich SSDs mit PowerLoss-Protection verwenden soll, oder "normale"?
Hier wäre demnach Sync Writes und SLOG sinnvoll, um die Gast Dateisysteme nicht zu beschädigen?
Trifft das auch zu wenn man SSDs mit PowerLoss-Protection verwendet?
Wäre ein SLOG hier irgendwo zu gebrauchen bzw. sinnvoll?
Wie würdet ihr obrige Pools aufbauen? Bzw. mit welchen Optionen/Extras?
Hmm... aber eigentlich würde ich neue vdevs nur hinzufügen, um die Speicherkapazität zu erweitern.
Also nur dann wenn die anderen vdevs bereits fast voll sind.
In dem Fall würde einfach einer nach dem anderen voll gemacht werden, oder?
Aus dem SLOG und Sync/Async werde ich noch nicht ganz schlau.
Wie macht sich dieser Performanceverlust denn bemerkbar, bzw. wie stark ist dieser?
In welchem Szenario würde man denn Sync oder Async einsetzen und wann einen SLOG verwenden?
Ich kann das aktuell sehr schlecht einschätzen.
Ich hätte folgende Pools (eigentlich wie oben beschrieben) geplant:
Pool für redundanten HDD Storage (vdevs aus 2er Mirror SATA Platten)
Wird als normales NAS benutzt und für Nutzdaten der VMs (z.B. Dateien der Nextcloud)
Darauf sind Bilder, Musik, Office Dateien etc. - Alles mögliche Querbeet
Sind Sync Writes hier sinnvoll? Ich würde das wahrscheinlich abhängig vom Performanceverlust entscheiden?
Pool für nicht redundanten HDD Storage (vdevs aus einzelnen SATA Platten)
Hauptsächlich Filme, also große Dateien zwischen ca. 3-20GB oder mehr.
Ich gehe davon aus hier eher Async Writes?
Pool für VM Storage (und evtl. Proxmox Hypervisor OS?) (vdevs aus 2er Mirror M.2 NVMe PCIe SSDs)
Für verschiedene VMs, hauptsächlich Linux/BSD aber auch Windows.
Hierfür ist mir noch nicht klar ob ich SSDs mit PowerLoss-Protection verwenden soll, oder "normale"?
Hier wäre demnach Sync Writes und SLOG sinnvoll, um die Gast Dateisysteme nicht zu beschädigen?
Trifft das auch zu wenn man SSDs mit PowerLoss-Protection verwendet?
Wäre ein SLOG hier irgendwo zu gebrauchen bzw. sinnvoll?
Wie würdet ihr obrige Pools aufbauen? Bzw. mit welchen Optionen/Extras?
Sync nur für VMs oder Datenbanken.
Bei leichter VM Belastung und SSD Pool würde ich zunächst ohne SLOG starten und dann schauen.
SSD möglichst Enterprise/Datacenter mit PLP (bei SATA; bei nvme vermutlich auch).
Nicht redundanten HDD Speicher mit mehreren HDD(!) würde ich nicht machen. Lieber einen redundanten Pool mit RAIDZ2 und einzelnen Filesystems, ggfs mit Quota.
Bei leichter VM Belastung und SSD Pool würde ich zunächst ohne SLOG starten und dann schauen.
SSD möglichst Enterprise/Datacenter mit PLP (bei SATA; bei nvme vermutlich auch).
Nicht redundanten HDD Speicher mit mehreren HDD(!) würde ich nicht machen. Lieber einen redundanten Pool mit RAIDZ2 und einzelnen Filesystems, ggfs mit Quota.
G
Gelöschtes Mitglied 304674
Guest
Warum? Wegen fehlender Redundanz oder aus einem anderen Grund?
Die Daten sind mir nunmal nicht die aktuellen Kosten von ~400€ für eine zweite HDD wert.
Den Wert von etwas erkannt man dann meist erst wenn es weg ist....
Ich würde daher zwei Pools, einen aus SSD (Mirror) für VMs und einen aus Plattem (Z1 oderZ2) für Daten und Backup der VMs machen. Ein externes Backup (z.B. USB Disk) der wichtigsten Daten sollte man zusätzlich zu Raid und Snap Versionierung als Disasterbackup mit planen.
Wenn einem die Betriebssicherheit der VMs etwas bedeutet, dann brauchts sync write + powerloss protection (sonst kann man auch auf sync Absicherung der Schreibvorgänge pfeiffen). Bei einem SSD Pool braucht man ein Slog meist nicht, da der Pool schnell genug ist, vgl Punkt 8. in https://napp-it.org/manuals/index.html
Da sieht man auch dass ein Plattenpool mit 500 MB/s Schreibperformance mit aktiviertem sync gerne mal auf 40MB/s einbricht.
G
Gelöschtes Mitglied 304674
Guest
Sync könnte ich ja nachträglich immernoch zu Async ändern, oder?
Ich möchte an dieser Stelle mal die folgenden Blog Posts in den Raum werfen.
Die haben mir beim Verständnis enorm geholfen.
Kann ich wirklich jedem ZFS-Neuling ans Herz legen.
Dort existieren noch mehr Beiträge zu ZFS, kann man sich auch anschauen.
Dort steht dass man ashift manuell bei vdev Erstellung festlegen sollte. Anschließend ist das Ändern nicht mehr möglich.
Wie finde ich denn heraus, welche "physical block size" meine HDD, bzw. SSD hat?
Im Datenblatt der WD Red habe ich zumindest nichts derartiges gefunden.
Ich möchte an dieser Stelle mal die folgenden Blog Posts in den Raum werfen.
Die haben mir beim Verständnis enorm geholfen.
Kann ich wirklich jedem ZFS-Neuling ans Herz legen.
Dort existieren noch mehr Beiträge zu ZFS, kann man sich auch anschauen.
Dort steht dass man ashift manuell bei vdev Erstellung festlegen sollte. Anschließend ist das Ändern nicht mehr möglich.
Wie finde ich denn heraus, welche "physical block size" meine HDD, bzw. SSD hat?
Im Datenblatt der WD Red habe ich zumindest nichts derartiges gefunden.
Trambahner
Urgestein
In >99% der Fälle bist Du mit Ashift=12 (also 4k block size) gut. Denn die übliche Sektorgröße, egal ob emuliert oder physikalisch, ist 4k. Und bei echten 512Byte-HDDs verlierst Du nix dabei.
Echte 512er HDD sind eh absolut untypisch bei den aktuellen Consumer-Multi-TB-Laufwerken. Normal sind das alles 512er-Emulationen mit 4k phys. Blocksize.
512native findest Du eigentlich nur noch bei bestimmten Datacenter-Laufwerken; und da stehts bei den entsprechenden Laufwerken in den Specs.
Echte 512er HDD sind eh absolut untypisch bei den aktuellen Consumer-Multi-TB-Laufwerken. Normal sind das alles 512er-Emulationen mit 4k phys. Blocksize.
512native findest Du eigentlich nur noch bei bestimmten Datacenter-Laufwerken; und da stehts bei den entsprechenden Laufwerken in den Specs.
Zuletzt bearbeitet:
G
Gelöschtes Mitglied 304674
Guest
Wenn ich für meinen VM Storage einen ZFS Mirror mit Sync Writes verwende und darauf eine FreeNAS VM anlege, dann hätte ich ZFS auf zwei Ebenen...
Das möchte man mit Sicherheit nicht, oder?
Dann hätte man die Performance Einbußen x2 und auch die IOPS Belastung x2?
Das möchte man mit Sicherheit nicht, oder?
Dann hätte man die Performance Einbußen x2 und auch die IOPS Belastung x2?
G
Gelöschtes Mitglied 304674
Guest
Ich habe da hauptsächlich an Logs gedacht.
Trambahner
Urgestein
T51b: deine Beschreibung der beabsichtigten VM-Architektur verwirrt mich. Auf eine Storage-VM (die ja einen Hypervisor darunter braucht) und die ZFS bereitstellt nochmal FreeNas installieren ? Versteh ich nicht.
oder meinst Du Iscsi-Speicher von einem getrennten ZFS-Filer per Netzwerk bereitstellen und dadrauf dann wieder FreeNas? Macht auch keinen Sinn.
oder meinst Du Iscsi-Speicher von einem getrennten ZFS-Filer per Netzwerk bereitstellen und dadrauf dann wieder FreeNas? Macht auch keinen Sinn.
G
Gelöschtes Mitglied 304674
Guest
Nein, ich will keine FreeNAS VM in einer Storage VM installieren.
Ich meinte einfach nur eine FreeNAS VM auf dem Hypervisor (Proxmox).
Trambahner
Urgestein
Das macht aber auch keinen Sinn, weil Proxmox sowohl Hypervisor ist als auch ZFS bereitstellt.
G
Gelöschtes Mitglied 304674
Guest
Ich habe schon soo viel gutes über FreeNAS gehört, daher wollte ich es einfach mal ausprobieren.
Und auch genau von dieser Konstellation aus Hypervisor + FreeNAS VM + HBA Passtrough habe ich schon unzählige male gelesen.
Wenn es dann mal darum geht, die gesamten NAS Funktionalitäten direkt über Proxmox zu regeln, wird meist davon abgeraten.
Meist aus Gründen mangelnder Flexibilität.
Ich sehe eigentlich keinen Nachteil darin, es über eine VM zu lösen?
Siehe z.B. hier: https://www.hardwareluxx.de/communi...-zfs-als-ersatz-für-esxi-hba-freenas.1223557/
Aber an dem Thread warst du ja auch schon beteiligt, wie ich sehe.
Und auch genau von dieser Konstellation aus Hypervisor + FreeNAS VM + HBA Passtrough habe ich schon unzählige male gelesen.
Wenn es dann mal darum geht, die gesamten NAS Funktionalitäten direkt über Proxmox zu regeln, wird meist davon abgeraten.
Meist aus Gründen mangelnder Flexibilität.
Ich sehe eigentlich keinen Nachteil darin, es über eine VM zu lösen?
Siehe z.B. hier: https://www.hardwareluxx.de/communi...-zfs-als-ersatz-für-esxi-hba-freenas.1223557/
Aber an dem Thread warst du ja auch schon beteiligt, wie ich sehe.
Trambahner
Urgestein
Meine Antwort und Ansicht ist die gleiche wie vor einem Jahr: dann gleich ESXI nehmen,ne Storage-VM nach Wahl rein, HBA durchreichen und VM-Space via NFS bereitstellen und alles andere bzgl. VM-Betrieb dem ESXI machen lassen.
Performant, einfach zu warten und backuppen.
ESXI kann kein ZFS, Proxmox aber schon; das ist der Unterschied. Und ESXI hat einen extrem kleinen Footprint, kleiner als Proxmox Für ESXI reicht ein kleiner USB-Stick.
ich sehe keinen Sinn, einem ZFS-fähigen Hypervisor nochmal eine ZFS-Appliance zu spendieren. Nochdazu so eine aufgespeckte wie FreeNas.
Macht es unnötig kompliziert, langsamer und wiederspricht in meinen Augen dem KISS-Prinzip.
Gea‘s ESXI AIO-Konzept funktioniert tadellos und bewährt sich. Bei mir seit 2013.
(Ich würde mich sehr über ein ESXI/vsphere mit integriertem ZFS statt Vmfs freuen; das wird aber nicht eintreten da es nicht in Vmwares Konzeption passt und sich vmtl.auch lizenztechnisch beißt.)
Performant, einfach zu warten und backuppen.
ESXI kann kein ZFS, Proxmox aber schon; das ist der Unterschied. Und ESXI hat einen extrem kleinen Footprint, kleiner als Proxmox Für ESXI reicht ein kleiner USB-Stick.
ich sehe keinen Sinn, einem ZFS-fähigen Hypervisor nochmal eine ZFS-Appliance zu spendieren. Nochdazu so eine aufgespeckte wie FreeNas.
Macht es unnötig kompliziert, langsamer und wiederspricht in meinen Augen dem KISS-Prinzip.
Gea‘s ESXI AIO-Konzept funktioniert tadellos und bewährt sich. Bei mir seit 2013.
(Ich würde mich sehr über ein ESXI/vsphere mit integriertem ZFS statt Vmfs freuen; das wird aber nicht eintreten da es nicht in Vmwares Konzeption passt und sich vmtl.auch lizenztechnisch beißt.)
Zuletzt bearbeitet:
maxpowers
Experte
- Mitglied seit
- 13.08.2016
- Beiträge
- 657
Nicht genau umgekehrt? Du hast einen Hypervisor und knallst noch dein NAS drauf, das widerspricht ja auch irgendwo dem KISS-Prinzip.
Stattdessen hast du mit einer extra VM dafür alles schön aufgeteilt, genau das was man eben mit Virtualisierung erreichen will.
Ich glaube das ist halt einfach Ansichtssache.. was man eben bevorzugt
Hatte auch lange mein NAS auf meinem Proxmox Host direkt laufen, mittlerweile gibts dafür eine extra VM bei mir.Ein Type-1 Hypervisor wie ESXi ist ein extrem minimalistisches System. Das kann nur virtualisieren und sonst nichts. Ist kaum mehr als eine Firmware. Darauf virtualisiert man alles, egal ob Storage mit Pass-through oder eine andere Serverinstallation.
Bei Proxmox (oder auch wenn man auf dem NAS virtualisiert, egal ob Free-BSD/OmniOS mit Bhyve/KVM oder OmniOS mit Solaris/LX Zonen) dient immer ein komplettes Full-Feature OS als Unterbau für die Virtualisierung.
Ein ZFS NAS auf ProxMox zu virtualisieren sehe ich auch als nicht so toll an, da hat man 2 x fettes OS. Macht man eigentlich ja nur weil es unter Linux keine vernünftige freie ZFS Storage Appliance Software gibt. Das ist bisher alles eher Unix. Mal sehen was passiert wenn FreeNAS unter Debian kommt (würde immer noch Unix bevorzugen)
Bei Proxmox (oder auch wenn man auf dem NAS virtualisiert, egal ob Free-BSD/OmniOS mit Bhyve/KVM oder OmniOS mit Solaris/LX Zonen) dient immer ein komplettes Full-Feature OS als Unterbau für die Virtualisierung.
Ein ZFS NAS auf ProxMox zu virtualisieren sehe ich auch als nicht so toll an, da hat man 2 x fettes OS. Macht man eigentlich ja nur weil es unter Linux keine vernünftige freie ZFS Storage Appliance Software gibt. Das ist bisher alles eher Unix. Mal sehen was passiert wenn FreeNAS unter Debian kommt (würde immer noch Unix bevorzugen)
G
Gelöschtes Mitglied 304674
Guest
An ESXi stört mich dass es nicht Open Source ist.
Free hin oder her.
Free hin oder her.
Happy Hepo
Experte
- Mitglied seit
- 16.01.2017
- Beiträge
- 225
Aktuell habe ich 2 Crucial MX500 gemirrored als VM-Platten, die werden mir aber zu klein. Als ich mich nach neuen SSDs umgewsehen habe, ist mir aufgefallen, dass die günstigen (readoptimierten) Datacenter-SSDs verglichen mit den günstigen Consumer SSDs sehr geringe RandomWrite IOPS ausgewiesen haben.
Ist das realistisch, dass beispielsweise meine Crucials (90k) RandomWrite die dreifache Performance haben wie Kingston DC500R (28k)? Auch und gerade bei vollerem Pool.
Mit 2x schon komplett vollgelaufenem Pool und aktuell 3/4 voll mit einigen VMs aktiv haben die Crucials folgende Write-Werte im Nappit Benchmark:
Fb3 randomwrite.f sync=always sync=disabled
1997 ops 10504 ops
399.371 ops/s 2100.325 ops/s
3910us cpu/op 2046us cpu/op
2.5ms latency 0.5ms latency
3.0 MB/s 16.4 MB/s
Fb4 singlestreamwrite.f sync=always sync=disabled
430 ops 2105 ops
85.998 ops/s 420.991 ops/s
15785us cpu/op 7924us cpu/op
11.5ms latency 2.4ms latency
85.8 MB/s 420.8 MB/s
dd results sync=always sync=disabled
data 5GB 5GB
dd sequential 187MB/sec) Bytes/s 223MB/sec) Bytes/s
Hat jemand schon Erfahrungen gesdammelt, wie sich Read-optimierte Datacenter-SSD dazu vergleichen lassen? 400 IOPS sync sind schon eine ganz andere Hausnummer als die beworbenen 90k, ich habe die Hoffnung, dass bei Datacenter-Platten der Unterschied nicht so hoch ist.
Ist das realistisch, dass beispielsweise meine Crucials (90k) RandomWrite die dreifache Performance haben wie Kingston DC500R (28k)? Auch und gerade bei vollerem Pool.
Mit 2x schon komplett vollgelaufenem Pool und aktuell 3/4 voll mit einigen VMs aktiv haben die Crucials folgende Write-Werte im Nappit Benchmark:
Fb3 randomwrite.f sync=always sync=disabled
1997 ops 10504 ops
399.371 ops/s 2100.325 ops/s
3910us cpu/op 2046us cpu/op
2.5ms latency 0.5ms latency
3.0 MB/s 16.4 MB/s
Fb4 singlestreamwrite.f sync=always sync=disabled
430 ops 2105 ops
85.998 ops/s 420.991 ops/s
15785us cpu/op 7924us cpu/op
11.5ms latency 2.4ms latency
85.8 MB/s 420.8 MB/s
dd results sync=always sync=disabled
data 5GB 5GB
dd sequential 187MB/sec) Bytes/s 223MB/sec) Bytes/s
Hat jemand schon Erfahrungen gesdammelt, wie sich Read-optimierte Datacenter-SSD dazu vergleichen lassen? 400 IOPS sync sind schon eine ganz andere Hausnummer als die beworbenen 90k, ich habe die Hoffnung, dass bei Datacenter-Platten der Unterschied nicht so hoch ist.
