[Sammelthread] OpenZFSonWindows: HowTos, Performance, wasauchimmer...

Wenn man den 2.3.1 rc13 Treiber installiert, kann Windows den Pool importieren und im Dateiexplorer anzeigen. Das Slog wird auch benötigt, sonst muss man die Importoption -m (ohne Slog) verwenden.

Das war recht schmerzfrei und hat funktioniert. Bzw. bin gerade am kopieren.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich wage nun seit ca. 2 Wochen ZFSonWindows "produktiv" auf meinem Haupt-Server. Irgendjemand muss das ja mal auf Herz und Nieren im Alltag prüfen. :d

Server Stats:
AMD 5600X
MC12-LE0
64GB RAM
Dual 10GBit SFP+ NIC
1x 250GB NVME OS (PCIe3 x1)
2x 2TB NVME Storage (PCIe3 x4)
2x 10TB HDD Backup (nur temporär verbunden)
OS: WinServer 2022
ZFS version: 2.3.1rc14

ZFS Setup:
Haupt-Pool aus den 2x 2TB NVME im mirror.
Backup Pool aus den 2x 10TB HDD ebenfalls im mirror (HDDs werden nur bei Bedarf manuell physisch verbunden).

Haupt-Pool dient als Storage für SMB-Shares im Netzwerk und lokale Hyper-V VMs.
Backup-Pool ist wie der Name schon sagt das Backup vom Haupt-Pool.

Erkenntnisse bis hierher:

1.
Beim Syntax für das Erstellen eines Mirror-Pools muss man genau auf die Reihenfolge achten: :
zpool.exe create [OPTIONS] [POOLNAME] [TYP "mirror"] [DISKS]

Zum Beispiel:
Code:
zpool.exe create  -O casesensitivity=insensitive -O normalization=formD -O compression=lz4 -O atime=off -o ashift=12 tank mirror '\\?\PHYSICALDRIVE0' '\\?\PHYSICALDRIVE1'

2.
Performance (Pool ca. 80% voll, 2 VMs laufen darauf):
1767966340460.png



3. Was funzt (einfach so):
Dedup
Replication

4. Sharing-Besonderheiten
SMB-Freigaben überleben einen Reboot (nur) wenn Freigabe eines ganzen Datasets erfolgt, Freigabe eines Unterordnen in einem Dataset ist nach Reboot weg. Keine Ahnung warum.

NFS-Freigaben funktionieren nur, wenn dem Dataset auf dem die Freigabe erfolgen soll (entweder insgesamt oder in einem Unterordner) ein eigener Laufwerks-Buchstabe zugewiesen wird. Scheint aber ein Windows-Ding zu sein, hat wohl nichts mit ZFS zu tun (gleiches Phänomen, wenn man auf/in einer VHDX eine NFS-Freigabe.

5.
Napp-it fühlt sich irgendwie deutlich zäher an als auf meinem Solaris-Host. Ist allerding kein fairer Vergleich, weil die Solaris-Kiste deutlich potenter ist (mehr RAM, mehr Kerne) und dort auch nicht die cs-Version läuft.
Ein ~1.5TB Replikation-Job ist mir unter Napp-it wiederholt abgestürzt, manuell über die CMD lief der auf Anhieb durch.
Auch konnte ich meinen Pool unter napp-it nicht anlegen, im UI wurde mir zu einer Disk bei "can pool" "no" angezeigt. Über die CMD ging es hingegen.

6.
Wenn sich nach Pool-Erstellung die Windows-Zuordnung "PHYSICALDRIVE#" der Datenträger ändert (was sehr schnell mal passieren kann), also z.B. Datenträger1 nicht mehr PHYSICALDRIVE1 ist, sondern PHYSICALDRIVE2, bekommt ZFS bzw. zpool.exe das nicht mit und zeigt entsprechend falsche (oder nicht mehr existierende) Datenträger an.


Vorläufiges Zwischenfazit: Das Ganze hat noch Kinderkrankheiten, mit denen man aber umgehen kann / für mich keine Dealbreaker.
 
Ich wage nun seit ca. 2 Wochen ZFSonWindows "produktiv" auf meinem Haupt-Server. Irgendjemand muss das ja mal auf Herz und Nieren im Alltag prüfen.
danke!

:d

Erkenntnisse bis hierher:

1.
Beim Syntax für das Erstellen eines Mirror-Pools muss man genau auf die Reihenfolge achten: :
zpool.exe create [OPTIONS] [POOLNAME] [TYP "mirror"] [DISKS]

Zum Beispiel:
Code:
zpool.exe create  -O casesensitivity=insensitive -O normalization=formD -O compression=lz4 -O atime=off -o ashift=12 tank mirror '\\?\PHYSICALDRIVE0' '\\?\PHYSICALDRIVE1'

sollte identisch zu OpenZFS sein

2.
Performance (Pool ca. 80% voll, 2 VMs laufen darauf):
Anhang anzeigen 1174066

sieht ja gut aus

3. Was funzt (einfach so):
Dedup
Replication

Alle OpenZFS 2.3.1 Features sollten funktionieren.

4. Sharing-Besonderheiten
SMB-Freigaben überleben einen Reboot (nur) wenn Freigabe eines ganzen Datasets erfolgt, Freigabe eines Unterordnen in einem Dataset ist nach Reboot weg. Keine Ahnung warum.

Wird das Sharing über Windows konfiguriert?
Unabhängig davon, man sollte ausschließlich ZFS Dateisysteme freigeben und eher keine normalen Unterordner und niemals nested ZFS Dateisysteme weil da kann durch unterschiedliche ZFS Eigenschaften Chaos entstehen.

NFS-Freigaben funktionieren nur, wenn dem Dataset auf dem die Freigabe erfolgen soll (entweder insgesamt oder in einem Unterordner) ein eigener Laufwerks-Buchstabe zugewiesen wird. Scheint aber ein Windows-Ding zu sein, hat wohl nichts mit ZFS zu tun (gleiches Phänomen, wenn man auf/in einer VHDX eine NFS-Freigabe.

Kann man mit leben wenn man NFS braucht, ist ja auch mit ntfs so,
SMB ist wichtiger und leistungsfähiger (ACL, Performance)

5.
Napp-it fühlt sich irgendwie deutlich zäher an als auf meinem Solaris-Host. Ist allerding kein fairer Vergleich, weil die Solaris-Kiste deutlich potenter ist (mehr RAM, mehr Kerne) und dort auch nicht die cs-Version läuft.
Ein ~1.5TB Replikation-Job ist mir unter Napp-it wiederholt abgestürzt, manuell über die CMD lief der auf Anhieb durch.
Auch konnte ich meinen Pool unter napp-it nicht anlegen, im UI wurde mir zu einer Disk bei "can pool" "no" angezeigt. Über die CMD ging es hingegen.

Canpool ist die Meinung von Powershell und bezieht sich zunächst primär auf Storage Spaces. Napp-it möchte hier auch für ZFS canpool=yes haben
War der manauelle Transfer auch mit netcat over lan oder local?.

Ansonst ist napp-it cs unter Windows deutlich langsamer als unter Free-BSD, Linux oder OSX, sowohl via web-gui wie auch mit Powershell auf Console vs Shell cmd. Mit einer der Gründe warum ich Command Caching eingebaut habe um wiederholte Abfragen zu beschleunigen.

Wenn eine Replokation in napp-it gestartet ist, macht sie ein cmd (lokal) oder zwei (netcat) mit send/receive auf.


6.
Wenn sich nach Pool-Erstellung die Windows-Zuordnung "PHYSICALDRIVE#" der Datenträger ändert (was sehr schnell mal passieren kann), also z.B. Datenträger1 nicht mehr PHYSICALDRIVE1 ist, sondern PHYSICALDRIVE2, bekommt ZFS bzw. zpool.exe das nicht mit und zeigt entsprechend falsche (oder nicht mehr existierende) Datenträger an.

Ähnlich wie bei Linux mit sda, sdb werden die Platten beim Booten durchnummeriert. Ändert sich da was bei den Platten, kann sich die Nummerierung ändern. Das Windows Verhalten ist inzwischen deutlich besser geworden, wenn sich Platten ändern. Solaris/Illumos mit WWN Plattennamen ist da natürlich deutlich überlegen. Auch Linux mit by-id Plattennamen bietet einen akzeptables Verhalten. Windows kann hier noch was lernen. Hat aber nichts mit ZFS zu tun.

Zur Not muss man halt den Pool neu importieren wenn sich Platten geändert haben.

Vorläufiges Zwischenfazit: Das Ganze hat noch Kinderkrankheiten, mit denen man aber umgehen kann / für mich keine Dealbreaker.

Mein Eindruck ist, dass OpenZFS unter Windows schon richtig gut ist. Probleme macht das unterschiedliche mount/locking/volume Verhalten von Windows mit einem Unix Dateisystem. Sieht man daran dass manche Programme, vor allem Systemnahe oder Spiele noch Probleme mit ZFS haben können.

Wenn man OpenZFS Issues den Windows Issues gegenüberstellt, meint man schnell dass nacktes OpenZFS on Linux mehr beta ist als mit Windows Dateisystemtreiber zusätzlich.

Entwicklung geht aber rasend schnell mit einem neuen release alle ca 4 Wochen der entdeckte Probleme behebt. Da Windows so viel mehr Variationen als ein normales Linux/Unix System aufweisen kann, sind Tests (und Issue reports) so wichtig.
 
Wird das Sharing über Windows konfiguriert?
Unabhängig davon, man sollte ausschließlich ZFS Dateisysteme freigeben und eher keine normalen Unterordner und niemals nested ZFS Dateisysteme weil da kann durch unterschiedliche ZFS Eigenschaften Chaos entstehen.
Ja SMB-Shares werden wohl immer letztendlich über Windows konfiguriert. Die ZFS smb-share Option called auch nur die entsprechende Windows-Funktion (so Lundman in einem der Posts auf Github). Dementsprechend dürfte es grds. auch nicht die üblichen ZFS-Probleme mit Freigabe in Ordnern / nested Datasets geben, weil ja bei ZFSonWindows das keine entsprechenden ZFS-Eigenschaften sind.

Canpool ist die Meinung von Powershell und bezieht sich zunächst primär auf Storage Spaces. Napp-it möchte hier auch für ZFS canpool=yes haben
In einer früheren Version war es nach meiner Erinnerung auch so, dass es mit canpool=no auch über die Konsole nicht ging. Scheint sich geändert zu haben.


War der manauelle Transfer auch mit netcat over lan oder local?.
Rein local von lokalem Pool1 zu lokalem Pool2.
 
Ja SMB-Shares werden wohl immer letztendlich über Windows konfiguriert. Die ZFS smb-share Option called auch nur die entsprechende Windows-Funktion (so Lundman in einem der Posts auf Github). Dementsprechend dürfte es grds. auch nicht die üblichen ZFS-Probleme mit Freigabe in Ordnern / nested Datasets geben, weil ja bei ZFSonWindows das keine entsprechenden ZFS-Eigenschaften sind.

Im Gegensatz zu Solaris/Illumos wo ein Share eine strikte ZFS Eigenschaft ist, ist bei Linux (SAMBA) oder Windows ein Share ein beliebiger Ordner. Der SMB Server weiß nichts von ZFS und geht deshalb nicht davon aus, dass ein "Unterordner" (ZFS Dateisystem) plötzlich anderes casesensitiviy, locking oder ACL behaviour hat.

In einer früheren Version war es nach meiner Erinnerung auch so, dass es mit canpool=no auch über die Konsole nicht ging. Scheint sich geändert zu haben.

ZFS kann manchmal auch eine Platte nutzen mit canpool=no. Eine Platte mit canpool=yes geht immer.

Rein local von lokalem Pool1 zu lokalem Pool2.

Eine Replikation die in napp-it angestoßen wird macht da auch nur zfs send | zfs receive als Hintergrund Task. "Sollte" sich daher gleich verhalten.
 
Tat es aber in meinem Fall nicht. ;) Ich schau die Tage nach einem Reboot nochmal, ob der Job dann per napp-it durchgeht.

Reboot sollte egal sein. Die Replikation wird als Admin Hintergrundtask im Backend server.pl gestartet.
Kontrollieren kann man Remote Hintergrundprozesse indem man im napp-it cs cmd Feld rl (remotelog) eingibt.

1768047016655.png
 
Windows Server hat ja doch eine ganze Reihe von Vorteilen wie SMB Direkt (für nics > 10G), Active Directory mit weltweit eindeutigen ntfs ACL mit Gruppen in Gruppen, diverse Serverdienste, besseres Storage Spaces Management, Usability und einiges mehr.

Für Soho, Windows Server Essentials ist die bevorzugte Wahl für bis zu 25 user und 50 devices bei max 1 Server je Nutzer
RAM, CPU/Core Anzahl ist auch limitiert, bei 2019/2022/2025 unterschiedlich.

günstiges Angebot z.B.

https://www.trustpilot.com/review/digitlogs.com
https://digitlogs.com/product/windows-server-2019-essentials/

hat jemand Erfahrung mit digitlogs?
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh