speedy-it
Goto Top

64 KB Clustergröße und UseLargeFRS bei Cluster Shared Volume mit NTFS optimal ?

Ich grüße Euch.

Könnte Ihr mir bitte behilflich sein, ich bin seit Tagen beschäftigt die endgültigen "optimalen / empfohlenen Einstellungen" für ein Cluster Shared Volume zu finden.

Erst hatte ich ReFS doch dann stellte sich raus, es läuft im „File System Redirected mode“ ...
Der Beitrag von Warum ihr keine ReFS Formatierung für CSVs verwenden solltet, die von einem SAN bereitgestellt werden machte ich auch auf das Problem aufmerksam.
Doch dort wird 4K Clustergröße empfohlen, da die VMs selbst (sowie der Host) auch mit 4 KB arbeiten.

Jetzt wurde es deshalb auf NTFS mit 4K Cluster umgestellt, doch dann fand ich das hier:
https://techcommunity.microsoft.com/t5/storage-at-microsoft/cluster-size ...
(man beachte dort den letzten Satz gaaanz unten: "While a 4K cluster size is the default setting for NTFS, there are many scenarios where 64K cluster sizes make sense, such as: Hyper-V, SQL, deduplication, or when most of the files on a volume are large.")

und https://learn.microsoft.com/de-de/windows-server/storage/file-server/ntf ...

Dort der Absatz:
Es gibt neue Empfehlungen für das Formatieren von Volumes, um eine ordnungsgemäße Erweiterung von großen VHDX-Dateien zuzulassen. Wenn Sie Volumes formatieren, die Sie mit Datendeduplizierung verwenden oder die sehr großer Dateien hosten, z. B. VHDX-Dateien, die größer als 1 TB sind, verwenden Sie das Cmdlet Format-Volume in Windows PowerShell mit den folgenden Parametern.
-AllocationUnitSize 64KB ...
-UseLargeFRS ...

Letzterer Link geht noch mehr ins Details und beschreibt nun bei VMs > 1 TB (ich habe 150, 350 GB als zwei VMs mit Windows Server 2022 für DC01 und WaWi und 2 TB Virtual Disk zu der 150 GB VM als sozusagen Datenlaufwerk D).


Meine Frage wäre, ob 64 KB Clustergröße bei NTFS für Cluster Shared Volume und "UseLargeFRS" alles ist was ich beachten muss oder mir noch eine Info fehlt, damit ich das CSV nicht noch einmal löschen / formatieren muss und ein drittes Mal von Vorne anfange, weil man eine ggf. noch in einer Doku auftauchende Einstellung nicht mehr im Nachhinein geändert bekommt.

Es gibt ja auch noch alle möglichen Wechselwirkungen mit Backup-Software wie Veeam, was ich so gelesen habe - was sind also die optimalen Einstellungen ?


Die StripSize vom RAID Controller ist 256 KB bei 4 Festplatten (SSD) im RAID 10, also 4x 64 KB - wäre dann doch auch stimmig mit 64 KB Clustergröße bei NTFS oder ?


Vielen Dank für Euren Rat

Content-ID: 93971884715

Url: https://administrator.de/forum/64-kb-clustergroesse-und-uselargefrs-bei-cluster-shared-volume-mit-ntfs-optimal-93971884715.html

Ausgedruckt am: 27.12.2024 um 12:12 Uhr

erikro
erikro 13.09.2023 um 17:29:09 Uhr
Goto Top
Moin,

ein paar Worte dazu, was das mit den Clustern auf sich hat. Ich erkläre das anhand des alten FAT, da es einfacher zu verstehen ist und die Zahlen kleiner sind.

FAT16 heißt deshalb so, weil der Adressraum 2^16 groß ist. Das heißt, man kann 2^16 Cluster adressieren. Nehme ich eine Clustergröße von 4KB, dann kann ich also maximal 265MB adressieren (2^32*4/1024 MB). Bei einer Clustergröße von 32KB, werden daraus 2GB.

Allerdings belegt jede Datei mit 1KB einen Cluster. Bei 4KB großen Clustern verliere ich also nur 3KB. Bei 32KB großen entsprechend 31KB. Das nennt man den Clusterverschnitt. Der Vorteil kleiner Cluster liegt also im kleineren Clusterverschnitt.

Auf der anderen Seite hat eine Datei, die 1MB groß ist, bei einer Clustergröße von 4KB 256 Adressen im Dateisystem. Sind die Cluster 32kb groß, sind es nur noch 32 und bei 64KB nur 16. Das ist der Vorteil von großen Clustern. Es werden weniger Adressen pro Datei gebraucht und somit kann der Zugriff schneller erfolgen.

Daraus ergibt sich die Faustregel: Erwarte ich kleine Dateien, mache ich kleine Cluster. Erwarte ich große Dateien, dann mache ich die Cluster so groß wie möglich.

hth

Erik
Speedy-IT
Speedy-IT 13.09.2023 um 18:25:55 Uhr
Goto Top
Vielen Dank Erik für deine Mühe und die sehr verständliche Zusammenfassung.
Mir ist das aber grundsätzlich klar, es geht mir um die "Systemvoraussetzungen / Best Practice" - wie richte ich es für den Cluster / VMs bei Hyper-V optimal ein, um so wenig Leistung wie möglich zu verschwenden, die ggf. zu späteren Zeit einmal fehlt. Jetzt sind SSDs im System im RAID 10 und diese will ich nicht wegen falscher Konfiguration um die mögliche Leistung bringen.

Die Clustergrößen sind ja schon einmal unterschiedlich zu wählen, je nachdem ob man NTFS oder ReFS einsetzt (will NTFS), aber auch Exchange / SQL oder Veeam macht da was ich bis jetzt gelesen habe "Vorschriften".
Gut Exchange habe ich nicht lokal, liegt in der Cloud.

Wieviel Speicherkapazität bei welcher Clustergröße möglich ist beschreibt auch mein obiger Link:
https://learn.microsoft.com/de-de/windows-server/storage/file-server/ntf ...
Aber es steht dort eben bei VHDX > 1 TB soll man das in meinem Fall Cluster Shared Volume mit 64 KB Clustern und zusätzlich UseLargeFRS formatieren.

Was also ist der Idealzustand ? Mich interessieren da Eure Erfahrungenswerte.


Ich habe es jetzt mit 64 KB für das Cluster Shared Volume getestet, doch die Geschwindigkeit bricht dann im Benchmark (CrystalDiskMark) mit 8 GB Datei um schwankend etwa 10-15% ein.
Als grobe Einordnung:
bei 64 KB habe ich schwankend zwischen 1557 und 1758 MB/s lesend und 781-891 MB/s schreibend
bei 4 KB habe ich schwankend zwischen 1865 und 2068 MB/s lesend und 868-964 MB/s schreibend

Alles mit 4 KB Cluster eingerichtet (Host, CSV, VM) ist also grundsätzlich zumindest bei dem Testfall schneller.
Ich kann aber jetzt nicht alles testen, habe den Benchmark mit einer 8 GB Datei gemacht und kann nicht eine 100 GB oder gar 1000 GB Datei benchmarken - dann kann ich die SSDs wegwerfen.
In den 2 TB die ich als Virtual Disk habe liegen halt die Files vom Fileserver (also alle Freigaben) - ansonsten habe ich keine großen Datenbanken.
Die vorhandenen Firebird Datenbanken sind unter 50 GB und in der 350 GB VM, die WaWi scheint da aus mehreren zu bestehen - aber das ist nicht so richtig mein Thema / Bereich (sehe halt die Größe der Datensicherungen, die ggf. komprimiert ist, weiß ich nicht, daher gebe ich mal 50 GB an).

Wenn ich dann z.B. noch
https://backupchain.com/i/hyper-v-block-size-for-ntfs-whats-recommended

oder folgendes lese
https://learn.microsoft.com/de-de/windows-server/administration/performa ...

scheint es doch am besten zu sein, wenn mein Cluster Shared Volume mit 4 KB ist, da die VMs ja auch 4 KB sind. Man kann bei der Windows-Installation die Clustergröße nicht auswählen, es nimmt immer 4 KB.
Der Link von Bachupchain sprechen z.B. von 10% Leistungseinbuße, wenn es sozusagen zwischen 64 KB (CSV) und 4 KB (VM) "übersetzen" muss.

Darum geht es mir auf welcher Basis habe ich die besten Leistungswerte, ohne meine Hardware unnötig per Software zu drosseln.
Warum empfiehlt Microsoft 64 KB Cluster, wenn das doch augenscheinlich deutlich langsamer ist.
Was übersehe ich ?

Das 64 KB mehr Speicherplatz verschwendet wird, wenn man überwiegend kleine Dateien hat, ist klar - doch da innerhalb der VM zwangsweise mit 4 KB gespeichert ist (zumindest die Systempartition) ist die Verschwendung eventuell nicht so groß, da die VM selbst ja als große Datei im CSV mit 64 KB liegen würde. Im CSV liegen also nur wenige kleine Dateien, sondern nur die VMs, die kleinen Dateien sind innerhalb der VM mit den 4 KB Cluster "verpackt".
Legt man eine zweite Festplatte (Virtual Disk) für z.B. die Daten an hätte man die Auswahl etwas anderes als 4 KB zu nehmen, aber nicht fürs System selbst. Das sieht die Windows-Installation nicht vor.

Soll ich das CSV mit 64 KB betreiben, obwohl die VMs dann zwangsweise 4 KB Cluster haben ?
Oder ist es doch der beste Weg generell mit 4 KB - obwohl Microsoft was anderes empfiehlt bzw. Microsoft versteht die Empfehlung eher für größere Umgebungen als meine. Auch wenn 1 von 3 VMs > 1 TB wäre (die Daten, also aller Kleinkram von Excel bis zu Fotos und PDFs).


Empfehlungen / Erfahrungen bitte nur bezüglich NTFS - ReFS möchte ich nicht, ist auch für CSV nicht supported.
Siehe z.B. https://www.hyper-v-server.de/hypervisor/performance-probleme-hyper-v-cl ...

ReFS hat auch den Nachteil, dass man da nichts reparieren kann. Gibt es Probleme oder Bugs ist halt alles weg und die Daten im RAW-Modus komplett unerreichbar.
Bei NTFS sind halt manche Dateien Schrott, aber nicht gleich die ganze VM.
Siehe z.B. https://www.borncity.com/blog/2022/02/08/microsoft-wird-refs-bug-in-wind ...
Zusätzlich verhindert ReFS den "Direkt-Mode" und es läuft immer im langsamsten "File System Redirected mode" - das war eigentlich der Beginn dieser ganzen Überlegungen und jetzt "ufert" es langsam aus, da man kaum praktische Erfahrungen von Kollegen findet - was sich wann letztlich bewährt hat.

Ich kann das alles halt später nicht mehr ändern, daher muss ich das jetzt wissen.