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

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich bin noch immer am Sammeln von Konzepten wie man Windows mit seinen Besonderheiten und ZFS so kombiniert, dass etwas ganz Besonderes dabei herauskommt. Nach bisherigem Sachstand scheint es so zu sein, dass SMB direkt auf ReFS Partitionen das Optimum darstellt was man performancetechnisch mit einem NAS und neuen Copy on Write Dateisystemen hinbekommen kann. ZFS ist langsamer, kann allerdings deutlich mehr als ReFS, z.B. Replikation, Snapshots, Verschlüssellung, Compress, Echtzeit Dedup, sync write, Hybrid Pools für small io und viel einfacheres Handling um nur ein paar Vorteile zu nennen. Man kann jetzt natürlich einen kleinen High Peformance Windows NVMe Pool mit einem großen High Feature ZFS Pool kombinieren. Soweit so gut.

Microsoft bewirbt gerne S2D als ultimative Storagelösung. Das sind Clusterlösungen für einen virtuellen Speicherpool über mehrere Rechner um Redundanz, High Performance und Hochverfügbarkeit zu gewährleisten. Cluster Storage wäre daher etwas wovon auch ZFS profitieren könnte und zwar mit einem Ultra Light/ Ultra Easy Ansatz. Ich stelle mit folgendes Konzept vor:

Man nehme einen Master Rechner der Storage z.B. per SMB (direkt) freigibt, z.B. ein Windows 11 Rechner. Dazu ein oder mehrere weitere Windows 11 Rechner die per SMB direkt verbunden sind. Netzwerk jeweils 10-100 Gb. Auf dem Master und diesen Rechnern liegt jeweils eine .vhdx Datei die als virtuelle Platte bereitgestellt wird (per Storage Spaces, Größe=Storage Pool, thick prov, 256k Blöcke, mit oder ohne Redundanz). Diese virtuellen Platten werden jetzt benutzt um einen ZFS Pool zu erstellen, bei Master mit einem Node ein Mirror, bei mehreren Nodes ein Raid-Z.

Ein Ausfall einer Platte auf einem Node kann durch Storage Space Redundanz gehandhabt werden, muss aber nicht. Es darf ein kompletter Node ausfallen da wir ein ZFS Raid über die Nodes haben. Fällt der Master Rechner aus, können die Shares mit den virtuellen Platten auf einem anderen Windows 11 Rechner gemountet und bereitgestellt werden und der ZFS Pool importiert werden. Komplexität nahe Null wenn man ZFS und Windows Basics kann.

Neben HA und Hochverfügbarkeit könnte der Ansatz auch die ZFS Performance deutlich verbessern. Vor allem wäre das Clustermanagement trivial und die Netz Connectivity mit SMB direkt richtig schnell und resourcenschonend vermutlich wesentlich effektiver als per FC/iSCSI als Cluster Alternative.

@besterino
Wäre der Ansatz sinnvoll?
 
Puh… das übersteigt meinen Erfahrungshorizont. Und meine letzten Spielereien mit Windows Clustern liegen auch schon lange zurück. Allerdings: Smb direct als „Server“ geht leider schon nicht mit einem Windows Client, sondern du brauchst dafür schon eine Server-Version.

Windows 10 and Windows 11 family are restricted to client-only and can't act as an SMB Direct server.

Quelle: https://learn.microsoft.com/en-us/windows-server/storage/file-server/smb-direct?tabs=disable
 
Immer diese künstlichen Windows Client Restriktionen.
Also Windows 11 das einen ZFS Cluster aus .vhdx Dateien normal über SMB3, eventuell mit Multipath bereitstellt oder Windows Server wenn man schnelleres SMB direkt möchte. Mit Server 2019 immerhin noch kostenlos möglich?

Ansonst kann man das ganze Cluster Gedöns vom MS ignorieren, man braucht ja nur SMB Shares mit einer .vhdx darauf um den ZFS Cluster zu machen.
 
Zuletzt bearbeitet:
Der Hyper-V Server 2019 ist gratis, kann clustern und kann SMB Direct
Leider ein Ende in Sicht bei den Gratissachen von Microsoft :-(
 
Sicherheitsupdates für Server 2019 soll es bis Anfang 2027 geben. Man hat also noch etwas Zeit. Vielleicht ist bis dahin SMB direkt/RDMA auch im Client Windows enthalten. Ansonst ist SMB3/ Multichannel auch nicht so langsam. Hauptnachteil dürfte neben der geringeren Performance eine deutlich höhere CPU Last sein.

Das Konzept mit virtuellen Diskimages auf SMB mit (ZFS) Pools darauf wird mir immer klarer um damit einen sehr schnellen Storage Cluster zu bauen der einfach zu verstehen und einzurichten ist. Mit iSCSI ist ein Network Mirror oder Raid-Z deutlich aufwändiger. Ein Ceph Cluster mit wenigen Nodes wird sicher sehr viel langsamer sein und ungleich komplizierter. Ganz zu schweigen vom Verlust der Windows SMB Features rund um ACL. Es braucht eine gewisse Zeit bis man das Zusammenspiel der Teile unter Windows versteht und Komplexität vermeidet. Mit etwas Powershell und GUI Unterstützung kann das was richtig tolles werden.

Konzeptionell plane ich folgendes:
- Ein SMB Cluster wird über die Server aufgebaut deren Membername mit cs_ beginnt
(Idealerweise Windows aber SAMBA (BSD,Linux,OSX)/ Solaris SMB sollte auch gehen

- jeder SMB Server hat ein Share "vhdx" mit einem vhdx Diskimage cs_image.vhdx

Dadurch wird es möglich, die virtuellen Platten ohne weitere Konfiguration bereitzustellen um einen ZFS Cluster-Pool darauf zu importieren (natürlich auch ein Storage Space, aber ich glaube an ZFS unter Windows). Auch beim Ausfall der Master Servers ist so ein Cluster schnell auf eine anderen Server übertragen.

Ein ZFS Netzwerk Mirror sieht dann so aus
Ein (Windows) Rechner als Storage Node mit Image auf Freigabe \\ip\cs_image.vhdx

Ein Windows Rechner als Storage Master mit Image auf Freigabe \\localhost\cs_image.vhdx
- Die Images als virtual disk bereitstellen (Diskmanager)
- Auf den beiden virtuellen Platten einen ZFS Mirror erstellen (importieren)
- Auf dem Pool ein Dateosystem erstellen und per NFS/SMB freigeben.

Der Ausfall des Node bedeutet keinen Storageausfall
Der Node kann schnell Master werden
Performance skaliert mit Anzahl der Nodes und Raid Level
 
Zuletzt bearbeitet:
Open-ZFS 2.2.6 rc4 mit Fast Dedup ist da
 
Da ich großer ZFS-Fan bin, gleichzeitig aber auch ein gewisser Windows-Jünger wäre eine taugliche Kombination beider Welten natürlich ein persönlich wahr gewordener Traum.
Irgendwie klingt das trotzdem ziemlich befremdlich... Ich bin eigentlich auch ein (NOCH) Windows-Jünger, aber jetzt auf die Idee kommen, OPNsense könnte auch mal unter Windows laufen, ist auf die gleiche Art befremdlich. Für mich, imho und so :hust:
 
Jedes System hat so seine Killerfeatures.

Bei Windows ist es vor allem der SMB Server mit überragender SMB direct/RDMA Performance, die ACL Rechteverwaltung und Hyper-V samt virtuelle vhdx Disks die man auch remote auf SMB halten kann (Netzwerk Cluster). Storage Spaces mit unterschiedlichen Plattentypen oder Größen und Data Tiering ist ein nettes add-on. Letztlich hat und kennt jeder Windows.
 
Zuletzt bearbeitet:
ZFS ist schon genial einfach. Man hat Dateisysteme und Mountpoints, das wars schon.
Unter Winwows hat man Laufwerksbuchstaben, Dateisysteme, Volumes und Partitionen, je nach Tool mit abweichenden Angaben.

Gar nicht so einfach da den Überblich zu behalten (vor allem mit Storage Spaces aber auch ZFS unter Windows muss sich da einfügen)

volumes.png
 
ich scheitere unter Windows ja schon an den basics (oder die Doku ist Grütze)
Platten suchen:
wmic diskdrive list brief

INTEL SSDSC2BB160G4 \\.\PHYSICALDRIVE0 INTEL SSDSC2BB160G4 1 160039272960
INTEL SSDSC2BB160G4 \\.\PHYSICALDRIVE1 INTEL SSDSC2BB160G4 1 160039272960

Pool anlegen:

zpool create tank mirror PHYSICALDRIVE0 PHYSICALDRIVE1
Expanded path to '\\?\PHYSICALDRIVE0'
Expanded path to '\\?\PHYSICALDRIVE1'
working on dev '#1048576#160031571968#\\?\PHYSICALDRIVE0'
setting path here '/dev/physicaldrive0'
setting physpath here '#1048576#160031571968#\\?\PHYSICALDRIVE0'
working on dev '#1048576#160031571968#\\?\PHYSICALDRIVE1'
setting path here '/dev/physicaldrive1'
setting physpath here '#1048576#160031571968#\\?\PHYSICALDRIVE1'
cannot create 'tank': no such pool or dataset

hm?
 
Ist PHYSICALDRIVE0 sicher nicht die Windows Bootplatte.
Geht denn
Code:
zpool create tank PHYSICALDRIVE1
 
Ich würde folgendes versuchen

1. ein oder zwei virtual hardisks >10GB anlegen (.vhdx), auch thin provisioned möglich
geht in der Datenträgerverwaltung. Darauf einen Pool anlegen.
(Falls das Problem irgendwie mit den Intel SSD zusammenhängt, da bei mir die gleiche Aktion kein Problem macht)

2. Falls das Problem weiterbesteht:
https://github.com/openzfsonwindows/openzfs/issues oder

Jorgen Lundman wird sich dann wohl melden und um ein Log bitten (cbuf.txt)
 
diskpart

create vdisk file=C:\temp\disk1.vhdx maximum=25600 type=fixed

100 Prozent bearbeitet

DiskPart hat die Datei für virtuelle Datenträger erfolgreich erstellt.


zpool.exe create tank \\?\C:\temp\disk1.vhdx
cannot create 'tank': no such pool or dataset
 
diskpart

create vdisk file=C:\temp\disk1.vhdx maximum=25600 type=fixed

100 Prozent bearbeitet

DiskPart hat die Datei für virtuelle Datenträger erfolgreich erstellt.


zpool.exe create tank \\?\C:\temp\disk1.vhdx
cannot create 'tank': no such pool or dataset
Entweder in der Datenträgerverwaltung oder mittels Powershell (mount-vhd) die vhdx als Festplatte mounten, dann kannst du sie dem zpool hinzufügen. Wäre mir neu wenn das direkt mit vhdx Dateien geht.
 
PS C:\Program Files\OpenZFS On Windows> wmic diskdrive list brief
Caption DeviceID Model Partitions Size
SAMSUNG MZVL21T0HCLR-00B00 \\.\PHYSICALDRIVE2 SAMSUNG MZVL21T0HCLR-00B00 4 1024203640320
INTEL SSDSC2BB160G4 \\.\PHYSICALDRIVE1 INTEL SSDSC2BB160G4 2 160039272960
INTEL SSDSC2BB160G4 \\.\PHYSICALDRIVE0 INTEL SSDSC2BB160G4 2 160039272960
Microsoft Virtual Disk \\.\PHYSICALDRIVE3 Microsoft Virtual Disk 0 26839088640

PS C:\Program Files\OpenZFS On Windows> zpool create tank PHYSICALDRIVE3
Expanded path to '\\?\PHYSICALDRIVE3'
working on dev '#1048576#26833059840#\\?\PHYSICALDRIVE3'
setting path here '/dev/physicaldrive3'
setting physpath here '#1048576#26833059840#\\?\PHYSICALDRIVE3'
cannot create 'tank': no such pool or dataset
 
Hmm.
Das Problem hatte ich noch nicht.

ps
Zum Anlegen, Mounten und Dismounten von virtuellen Harddisks (lokal oder in SMB Shares für einen Cluster) habe ich in napp-it ein Extra Menü
Da Powershell dazu Hyper-V und dessen Powershell Erweiterung benötigt, diese beiden in der Systemsteuerung (appwiz.cpl) vorher aktivieren und neu starten.
dazu noch c:\vhdx oder v:\vhdx anlegen weil die vhdx da abgelegt werden.

1726511101237.png
 
@ludwinator
Ich sehe dass du das Problem in openzfsonwindows > discussion eingestellt hast.
Jorgen Lundman hat ja auch gleich reagiert. Mit den entsprechenden Logs wie cbuf wird er hoffentlich schnell die Ursache finden und in einer rc5 beheben.

Das zeigt aber wie wichtig es ist dass viele ZFS on Windows testen und Probleme rückmelden. ZFS selber ist ja ziemlich allerneuestes originales Open-ZFS 2.2.6 mit ein paar Anpassungen wie driveletter support oder nfs4 ACL wie bei Solaris Unix für volle Kompatibiität mit ntfs ACL im Dateisystem. Dafür dass gerade soviel neue Probleme rund um mount/unmount drin sind, bin wohl ich verantwortlich. Bei mir ist aufgefallen dass der ufs Treiber Probleme mit Aomei Backup macht. Jorgen hat zwei Wochen lang vergeblich versucht das zu beheben. Im Ergebnis hat er den gesamten Mount Bereich neu geschrieben mit aktuell einigen neuen Bugs. Wenn es aber geht, dann viel flüssiger z.B. viele Aktionen ohne extra mount/unmount.

Also breit testen und berichten entweder in discussion oder im issue tracker
 
Ich habe mal rumgefragt, welche nic man in einen Windows Server und in einen Windows 10/11 client einbauen sollte wenn man ultraschnelles und günstiges SMB direct/RDMA möchte und habe mehrfach die Antwort erhalten: Mellanox CX-4

Ist das Konsens?
Besser Nic-Nic verkabeln bzw gibt es günstige Switche?
 
Zuletzt bearbeitet:
Relativ günstige Switches hatte @java4ever immer mal im 100Gbit&Co.-Thread. Ich hab aber meinen immer noch nicht testen können auf RDMA.

Ansonsten ist nic-nic in der Tat die günstigste und m.E. auch einfachste Variante, um RDMA mal schnell zu testen.

Zur Hardware: ich hab bisher zu 100Gbit nur Mellanox NICs gehabt… ab und an gibts Schnäppchen bei Ebay. 350 Euro für 2 ConnectX-5 VPI Dual-Port fand ich seinerzeit z.B. sehr ok.
 
Muss man bei den Karten etwas beachten wenn man SMB direct/RDMA machen möchte statt IB?
Muss man immer crossflashen ib/ip?

Bei früheren 40G Versuchen hatte ich DAC Kabel mit eingebautem Glasfaserwandler für längere Kabel bis 100m, Geht sowas ?
Wäre dann die einfachste Option. Bei den Kabeln bin ich echt unsicher ob QSFP 28 oder 56.

Wenn man SMB direct z.B. für 4/8K Video braucht, so sind das nur einzelne Arbeitsplätze.
Ein oder mehrere Dualport Netzwerkkarten im Server sind wohl die einfachste Lösung und spart den teuren, lauten Switch .
Gibts denn auch Breakout Kabel wie bei 200G ->
Normales 1G/10G ip LAN kann man ja zusätzlich machen.

Grundsätzliches steht ja in
Ist dennoch nicht so einfach wenn es einfach nur tun soll ohne viel Bastelei und Versuche.
 
Zuletzt bearbeitet:
Muss man bei den Karten etwas beachten wenn man SMB direct/RDMA machen möchte statt IB?
Muss man immer crossflashen ib/ip?

Die Modellbezeichnungen sind etwas ätzend. Gibt halt z.B. ConnectX-4 die gar keine 100Gbit können. 100Gbit gibt's bei den ConnectX-4 nur mit den Modellen MCX455A-ECAT (single port) und MCX456A-ECAT (dual port):


Die, sowie ConnectX-5 und aufwärts können aber sowohl IB als auch Ethernet. Das stellst Du einfach per firmware-tool ein (kein crossflash nötig bei den original Mellanox).

Eine Vergleichstabelle gibt's hier:

Noch eine (bessere) Übersicht hier:

ACHTUNG: Wenn Du eine "branded" Karte nimmst, kann das alles mögliche sein. ConnectX-4 ließen sich noch crossflashen, ab ConnectX-5 hat Mellanox/Nvidia aber fröhliche Sicherheitsfeatures (verschlüsselte Bereiche der Firmware) eingeführt, die das verhindern können. Ich hab z.B. zuletzt HP-branded ConnectX-5 erwischt. Crossflash auf original Nvidia-/Mellanoxfirmware ging nicht, aber mit etwas Fluch... .äh... Sucherei hab ich die aktuelle HP-Firmware gefunden und problemlos flashen können.

Bei früheren 40G Versuchen hatte ich DAC Kabel mit eingebautem Glasfaserwandler für längere Kabel bis 100m, Geht sowas ?
https://www.fs.com/de/products/1548...MI35OWh4PMiAMVN5GDBx0WaST9EAAYASAAEgJxgvD_BwE
Wäre dann die einfachste Option. Bei den Kabeln bin ich echt unsicher ob QSFP 28 oder 56.

Keine Ahnung zu DACs. QSFP56 gibt's aber wohl erst ab ConnectX-6... Könnte schwierig sein, die schon gebraucht als Schnapper zu finden. Wenn Du hingegen neu kaufen kannst/darfst, why not (oder gleich ConnectX-7?)... ;)

Wenn man SMB direct z.B. für 4/8K Video braucht, so sind das nur einzelne Arbeitsplätze.
Ein oder mehrere Dualport Netzwerkkarten im Server sind wohl die einfachste Lösung und spart den teuren, lauten Switch .
Gibts denn auch Breakout Kabel wie bei 200G ->
Normales 1G/10G ip LAN kann man ja zusätzlich machen.

Ist halt in der (dann im Zweifel manuellen) Verwaltung im Host ggf. etwas blöd mit den Netzwerken / IP-Adressen. Wenn ich mich richtig erinnere, gab es auch Problemchen mit meinem Hypervisor, bei dem 100Gbit NICs / Ports per PCIE-Passthrough an VMs durchgereicht waren: Wenn zu einem bestimmten Zeitpunkt beim Booten die Gegenstelle (also der Client) nicht online war (oder auch später offline gegangen ist), kam die NIC im Server nicht wieder hoch, bis die VM neu gestartet wurde (möglicherweise musste der ganze Host neu gebootet werden). Ich meine, das war im Zusammenhang mit einer Solaris 11.4 VM mit nem zugewiesenen ConnectX-4 Port. Genau deshalb hab ich dann doch irgendwann einen 100gbit Switch angeschafft, damit der relevante Port im Server eben immer eine aktive Gegenstelle hatte. Ist aber schon eine Weile her, meine Erinnerung kann trügen und/oder sich Software/Treiber/etc. weiterentwickelt haben.

Breakoutkabel funktionieren meines Wissens (!) NUR auf der Switchseite. Du kannst also am Switch einen 100Gbit-Port in 4x25Gbit aufteilen; die NICs können das hingegen NICHT.

Du kannst aber an einem 100gbit-QSFP28-Port an der NIC durchaus eine geringere Speed fahren, z.B. auch per QSFP28/SFP+ Adapter einen SFP+ 10Gbit Transceiver bestücken und den dann ganz normal mit einem vorhandenen 10Gbit SFP+ Switch verbinden. Das mache ich tatsächlich häufiger: normales Mainboard nur mit 1Gbit Ports, Dual-Port-ConnectX dazu und ein Port für "normales" 10Gbit Netz, der zweite Port für 100Gbit. Spart halt für mich eine (10Gbit) NIC und entsprechenden PCIe-Slot.

Alternativ statt "Vergeudung" eines 100Gbit-Ports für lumpige 10Gbit kannst Du aber natürlich auch die beiden Ports einer Dual-Port-NIC z.B. per PCIe-Passthrough UNTERSCHIEDLICHEN VMs zuweisen oder eben auch nur stumpf 2 Rechner per 100Gbit verbinden.

Wegen der deutlich höheren Flexibilität habe ich bisher immer nur Dual-Port NICs gekauft.

Grundsätzliches steht ja in
Ist dennoch nicht so einfach wenn es einfach nur tun soll ohne viel Bastelei und Versuche.

Ich übernehme keine Garantie für irgendwas. Ich mach das alles nur aus Spaß anner Freud' als bestenfalls (!) "halbwegs informierter Laie mit gefährlichem Halbwissen" ohne jegliche Form von professionellem Anspruch. :d Ich hab aber immerhin schon einige Bastelei und Versuche hinter mir. ;)
 
  • Danke
Reaktionen: gea
Also am Besten wenn SMB direkt ohne viel Versuche tun soll:

Original Mellanox bevorzugen
Mellanox X5 wegen mehr Features
Mellanox X4 muss man auf das Modell achten, anderes Brand möglich aber kann in Bastelei ausarten
25G statt 100G ist deutlich günstiger und reicht eigentlich für Server-Client komplett aus (3GB/s)

Hat jemand Active Dac Kabel QSFP28 getestet (max 100m). Kupfer Dac gehen ja nur bis 5m.
 
Mellanox X5 wegen mehr Features
@gea, ZFSonWindows hätte ich ja für einen Witz gehalten, aber wenn du dich damit beschäftigst muss ich mir das auch mal anschauen.
Bei der CX-5 würde ich empfehlen die MCX516ACDAT zu nehmen, die kann schon PCIe4, falls auf einer Seite ein Desktop Board benutzt wird, spart das PCIe Lanes.
Wenn du einen Switch benötigst, könnte der CRS504 von Mikrotik für dich interessant sein.
Der kann leider kein RoCE v2, dann wär das die Empfehlung für ein Homelab, aber für SMB Direct ist der gut.
 
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