ReFS - Nachfolger für NTFS?

Daten auf Massenspeichern werden in einem Dateisystem gespeichert. FAT, FAT32, ExtFAT, NTFS sind hinlänglich bekannt aber mit ReFS gibt es ein neues System, welche von Exchange sogar als "preferred" angegeben wird. HIer schildere ich meine Erfahrungen und Eindrücke

Abgrenzung zu NTFS

Die verschiedenen Geschmacksrichtungen von FAT haben nur noch auf USB-Speicher zum Datenaustausch eine Bedeutung. Schon länger nutze ich NTFS auf Clients und Servern und bislang habe ich einen Wechsel zu ReFS noch gar nicht in Betracht gezogen. Es fehlen noch einige Funktionen, die NTFS noch besser macht aber ReFS wird aber als "Robuster" ausgegeben, weil es z.B.: Prüfsummen auf Dateien und Metadaten nutzen kann und so Korruptionen erkennt. Die Details dazu finden Sie bei Microsoft besser beschrieben.

Ich setze ReFS aktuell aber aus verschiedenen Gründen noch nicht aktiv ein:

  • Nicht Bootfähig
    Von ReFS kann man nicht booten. Das Betriebssystem muss also immer noch auf NTFS installiert sein und auf einem Client mit einer Disk möchte ich diese nicht durch Partitionierung stückeln. Auf Servern kann es anders aussehen.
  • 16TB Limit bei 4k Blocksize: Aber 64k mit Exchange geht bis 256TB Limit
    Aber selbst 16TB sind sehr große Partitionen und selbst "große" Exchange Datenbanken sind meist kleiner als 2TB. Für Exchange sind sowieso 64k Blöcke statt der 4 Blocksize empfohlen.
  • 3r Party Tools
    Es hat einige Zeit gedauert, bis "Recoverytools" damals NTFS verstanden habe aber mittlerweile gibt es Werkzeuge, um im Desasterfall vielleicht doch noch Daten von einer Festplatte zu laden. Wie gut solche Programme mit ReFS funktionieren, kann ich noch nicht sagen.

Insofern ist aus meiner Sicht NTFS noch lange nicht am Ende, auch wenn die Festplatten und Datenmengen natürlich weiter ansteigen werden.

Warum ReFS mit eingebauter Resilienz?

Dennoch gib es Vorteile von ReFS durch die eingebaute "Robustheit", indem es Daten selbst an verschiedene Stellen kopiert. Bislang war die Welt einfach:

  • Single Disk
    Eine einzelnen Festplatte hat Daten gespeichert und konnte natürlich defekt werden. Ein Defekt könnte sich in einem Komplettausfall oder durch "Lesefehler" auf einzelnen Sektoren zeigen. Die Daten sind weg, wenn Sie nicht vorgesorgt haben.
  • RAID
    Die logische Antwort darauf sind redundante Speicher durch die Kombination mehrerer Festplatten zu einem RAID. Per Software oder durch einen Hardwarecontroller werden die Daten nun mehrfach (RAID1/RAID10) oder mit Paritätsinformationen (RAID5, RAID6 u.a.) geschrieben um den Ausfall einer Festplatte zu kompensieren.

Leider ist es in beiden Fällen immer mal wieder passiert, dass Daten dennoch korrupt waren und die Ursache ist nicht immer genau zu ermitteln. Es muss also immer noch ein Problem dazwischen geben. Oft war es dann der Controller-Treiber oder der Controller selbst, der ein böses Spiel gespielt hat. NTFS selbst hat keine eingebauten Prüfsummen und kann solche Softwarefehler daher nicht erkennen.

Damit besteht natürlich ein großes Risiko je mehr Dateien und Daten auf den immer größeren Massenspeichern abgelegt werden. Hier kommt die Funktion von ReFS zugute, die nach Aktivierung nicht nur Prüfsummen erstellt und Kopien verteilt sondern auch regelmäßig diese Dateien wieder liest und damit verifiziert. Für einfache Dateiserver oder andere Systeme ohne eigene Datenverifikation sind das wichtige Argumente.

Exchange und ReFS

Mit Exchange 2013 und Windows 2012 hat Microsoft auch den Dateisystem-Support um ReFS erweitert und auf der Ignite 2015 wurde mit Exchange 2016 das erste mal die "preferred Architecture" für Exchange 2016 auf ReFS geändert. Mit Exchange 2019 wurde der Einsatz von ReFS um MCDB erweitert, d.h. SSD's zum Caching.

Allerdings ist hier gerade die Resilienz aus meiner Sicht nicht ganz so wichtig, wenn ich eh mit einer DAG und zwischen Servern replizierten Datenbanken arbeite. Exchange speichert in seiner EDB-Datenbank die Blöcke zu 64kBytes auch immer mit einer Prüfsumme. Beim erneuten Lesen wurde die Prüfsumme verglichen und bei Unstimmigkeiten die berüchtigten -1018 Fehler im Eventlog generiert. Exchange kann eine defekte Datenbankseite durch ein Reseeding vom anderen Server beziehen. Allerdings könnte der gleiche Fehler natürlich auf beiden Server zuschlagen. Dann wäre ReFS wirklich eine deutliche Verbesserung, zumal Exchange diese Informationen sogar zu nutzen kann.

Allerdings beschreibt Microsoft auch explizit, dass die ReFS-Volumes bitteschön ohne "integrity feature" formatiert werden sollen, da Sie wohl zu viel Performance kosten könnten.

Each disk that houses an Exchange database is formatted with ReFS (with the integrity feature disabled) and the DAG is configured such that AutoReseed formats the disks with ReFS:
Quelle The Exchange 2016 Preferred Architecture https://techcommunity.microsoft.com/t5/exchange-team-blog/the-exchange-2016-preferred-architecture/ba-p/604024

Das lässt sich per Jetstress auch gut erkennen, dass in dem Beispiel die Latenzzeit des ReFS-Volume die Anforderungen nicht erfüllt

Die Verzögerung beim Schreiben ist hier der Aktivierung des Integrity Features geschuldet. Es gibt noch weitere Eckwerte, die sie kennen sollten:

Supported for volumes containing Exchange database files, log files and content indexing files, if the following hotfix is installed: Exchange Server 2013 databases become fragmented in Windows Server 2012.

Not supported for volumes containing Exchange binaries.

Best practice: Data integrity features must be disabled for the Exchange database (.edb) files or the volume that hosts these files. Integrity features can be enabled for volumes containing the content index catalog, if the volume doesn't contain any databases or log files.

Supported: All allocation unit sizes. Best practice: 64 KB for both .edb and log file volumes.

Quelle: https://docs.microsoft.com/en-us/exchange/plan-and-deploy/deployment-ref/storage-configuration?view=exchserver-2019

Insofern können Sie daraus die Empfehlung ableiten:

Speicher Fileystem Blocksize DataIntegrity

Betriebssystem/Bootbereich

NTFS

Default

NA

Exchange Binaries

NTFS

Default

NA

Exchange Database und Logs

ReFS

64KB

Off

Exchange Context Index

ReFS

64KB

Optional

Für die Einrichtung einer neuen Festplatte für Exchange sollten Sie daher diese Option abschalten. Das geht aber nicht per GUI über den Festplattenmanager sondern per PowerShell:

# Anzeige der  vorhandenen Festplatten.
PS C:\> Get-Disk

Number Friendly Name              OperationalStatus   Total Size Partition Style
------ -------------              -----------------   ---------- ---------------
2      Microsoft Virtual Disk     Online                      50 GB GPT
1      Microsoft Virtual Disk     Online                      50 GB RAW
0      Virtual HD ATA Device      Online                     100 GB MBR

# Vorbereiten der "RAW"-Disk 1
Get-Disk 1 `
| Initialize-Disk `
   -PartitionStyle GPT `
   -PassThru `
| New-Partition -UseMaximumSize `
| Format-Volume `
   -FileSystem REFS `
   -AllocationUnitSize 65536 `
   -NewFileSystemLabel EXDB01 `
   -SetIntegrityStreams $false `
   -confirm:$false

Dieses Volume müssen Sie nun natürlich noch als Laufwerk bekannt machen oder über einen Mountpoint einhängen. So können Sie alle neuen Festplatten vor der Installation von Exchange schon vorbereiten. Wen Sie später eine DAG mit "Autoreseeding"-Funktion nutzen, dann müssen Sie Exchange auch anweisen, dass er dynamisch neu formatierte Festplatten mit ReFS einrichtet

# DAG auf ReFS als Default einstellen
Set-DatabaseAvailabilityGroup <DAG> -FileSystem ReFS

Etwas inkonsistent ist Microsoft hier schon, dass die Empfehlungen zwar auf ReFS lauten aber der Default in einer DAG auch bei Exchange 2019 noch NTFS ist.

Sie können mit Exchange 2016 und neuer das Dateisystem "ReFS für Datenbanken, Transaktionsprotokoll und Suchindex-Dateien nutzen, wenn Sie sicherstellen, dass das Feature "Integrity" für die Dateien deaktiviert ist. Diese Einstellung macht Exchange normalerweise selbst aber sie können es per PowerShell prüfen bzw. setzen.

# Status einer Datei prüfen
Get-FileIntegrity -Filename c:\db\db1\db1.edb

FileName           Enabled Enforced
--------           ------- --------
c:\db\db1\db1.edb  False True

Set-FileIntegrity-Filename c:\db\db1\db1.edb -enable:$false

Auch mit dem Programm FSUTIL können Sie ermitteln, ob Prüfsummen aktiv sind:

fsutil fsinfo refsinfo f:

Die Ausgabe liefert dann Details zum Dateisystem. Hier ein ReFS-Volume mit und eine ohne

Nach meiner Einschätzung betrifft dies die Integrity Checks für das Dateisystem selbst. Pro Datei gibt es natürlich weitere Einstellungen.

Best practices for Pure Storage® FlashArray with Microsoft Exchange Server 2019.
https://www.purestorage.com/content/dam/pdf/en/white-papers/wp-microsoft-exchange-unleashed.pdf
"Best Practice: Use NTFS with a 64KB allocation unit size with support for large file record segments, even though ReFS is supported. NTFS has an over 26-year history of reliability and compatibility "

Meine Einschätzung zu ReFS

Es ist logisch, dass Microsoft nicht ewig mit NTFS arbeiten kann. Ab 16 TB muss die Blocksize erhöht werden und viele anderen neue Funktionen von ReFS machen Lust auf mehr. Auf der anderen Seiten fehlen ReFS noch einige Funktionen und gerade in der Anfangszeit gibt es schon immer mal wieder Bugs. Exchange 2013 auf Windows 2012 benötigte ein paar Hotfixes. Das ist nun, ca. 8 Jahre später ausgestanden aber wenn Exchange vorgibt, die wesentlichen Integritätschecks auf den Datenbank-Volumes abzuschalten, dann fällt ein wichtiger Vorteil auch noch weg.

ReFS ist sicher das bessere Filesystem für virtuelle Umgebungen, mit Storage Spaces Direct, SANs, iSCSI, weil es durch die Integritätsschecks und Duplizierung von Informationen an mehreren Stellen einfach robuster gegen Störungen ist.

Aber brauche ich das für einen Exchange Server mit lokalen Festplatten in einer DAG? Selbst wenn Exchange virtuell betrieben wir und auch die Disks nur Container sind, dann kann HyperV darunter gerne die VHD/VHDX-Dateien auf einem ReFS-Dateisystem ablegen. Meine Exchange LUN in der VHDX kann ja davon ausgehen, dass die Schicht darunter für eine korrekte Funktion sorgt.

Wenn Sie bislang noch wenig Erfahrungen mit ReFS haben, nicht sicher sind ob ihr Backup und Restore damit umgehen kann und sie ansonsten eher konservativ eingestellt sind, dann sehe ich kein Problem bei der Verwenden von NTFS auch für Datenbanken, Transaktionsprotokollen.

Mit der Veröffentlichung der Seite am 9.7 habe ich eine Umfrage auf Twitter gestartet, die ich ihnen nach 2 Tagen und 56 Antworten nicht vorenthalten will:

Ein viertel des Teilnehmer nutzen tatsächlich ReFS aber die Mehrheit arbeitet noch mit NTFS. Ein Fünftel hat anscheinend noch gar nicht mitbekommen, dass es seit 7 Jahren neben NTFS noch ein anderes Dateisystem gibt. Das ist schade, denn gerade für Dateiserver ist ReFS schon ein Gewinn.

Weitere Links