Die Vorteile bei der Nutzung von Hyper-V unter Windows Server 2016 und ReFS als Dateisystem | Hyper-V Server Blog

Die Vorteile bei der Nutzung von Hyper-V unter Windows Server 2016 und ReFS als Dateisystem

Mit dem Release von Windows Server 2016 wird Microsoft eine neue Version des Dateisystems “Resilient File System”, kurz ReFS, veröffentlichen. ReFS hat Einzug in den Windows Server unter 2012 gehalten, dort war es in Version 1 verfügbar. Kaum eine Software und kaum ein Hersteller hat das neue Dateisystem vollständig unterstützt; wir bekamen häufig Aussagen wie “Das kann funktionieren, muss aber nicht; probieren Sie es aus.”. Wenn es zum Beispiel darum ging sehr große Volumes anzulegen, wie z.B. für Backup-Speicher. Mit Windows Server 2016 wird sich dies nun ändern, Microsoft hat im Hintergrund viel gearbeitet und die Versionsnummer auf eine 3 heraufgestuft. Mit dieser neuen Version kommen nun etliche Verbesserungen und Neuerungen mit, auf die ich im Laufe des Artikels eingehe und kurz erläutere. Im zweiten Teil zeige ich die Mehrwerte auf, die sich allein durch die Nutzung von dem neuen Dateisystem ergeben.


Verbesserungen und Neuerungen

Bei der Nutzung von ReFS gegenüber NTFS gibt es einige Vorteile. Die folgenden Beschreibungen beziehen sich ausschließlich auf Version 3 von ReFS unter Windows Server 2016, vorherige Versionen werden nicht betrachtet:

Maximalwerte

Ein Volume kann bis zu einem Yottabyte groß werden. Das sind 1 000 000 000 000 000 000 000 000 Bytes oder eine Milliarde Petabytes. Jede Datei auf dem Volume kann bis zu 16 Exabyte groß werden. Diese Speichermenge brauchen wir aktuell jedoch noch nicht, das Dateisystem ist aber schonmal gerüstet.

Die Arbeit mit Metadaten

Viele Datei-Operationen werden nicht mehr direkt ausgeführt (z.B. die Erstellung von einer VHDX mit fester Größe), sondern es wird per Metadaten-Operation gemacht. Dies beschleunigt viele Operationen ungemein.Wo genau diese Funktion Verbesserungen bringt, sehen wir später im zweiten Teil.

Block Cloning

Bei diesem Vorgang kopiert das Dateisystem selbst einen Teil der Daten statt der Applikation selbst. Es gibt bei diesem Vorgang einige Voraussetzungen, z.B. das der geclonte Bereich nicht größer als 4 GB sein darf (Achtung: Nicht die Datei selbst ist hiermit begrenzt, sondern nur der jeweilige Bereich, der geclont wird). Weiterhin müssen die Dateien (Quelle und Ziel) auf dem gleichen Volume liegen, sonst funktioniert der Vorgang nicht. Weitere Informationen sowie eine sehr gute Grafik wie der Cloning-Prozess abläuft, finden sich bei Microsoft selbst: Microsoft MSDN: Block Cloning

Schutz gegenüber logischen Fehlern

Alle Metadaten, die auf dem Volume vorhanden sind, werden mit einer Checksumme belegt, geprüft und bei einem Missmatch automatisch repariert. Dies sorgt dafür, dass nicht separat und manuell ein ChkDsk ausgeführt werden muss. Benutzerdaten können optional ebenfalls mit diesen Prüfsummen vor einem Ausfall geschützt werden, diese Funktion hört auf den Namen Integrity Stream. Der Schutz kann entweder für das gesamte Volume, für einzelne Ordner oder für einzelne Dateien konfiguriert werden. Die Aktivierung dieser Funktion bedingt (vermutlich) Storage Spaces-Technologie im Hintergrund und führt zur einer Reduzierung der Performance.

Funktionen, die (noch) nicht enthalten sind

Da ich einen Teil der Neuerungen aufgeführt habe, hier noch ein paar Worte zu Funktionen, die nicht oder noch nicht in ReFS enthalten sind. Dies kann für gewisse Einsatzzwecke egal sein, für andere sind diese Funktionen allerdings essentiell.

  • Keine Unterstützung von 8+3 Dateinamen ;)
  • Keine NTFS Komprimierung
  • Keine Nutzung von Encrypted File System (EFS)
  • Keine Unterstützung und Nutzung von Quotas
  • Keine Deduplizierung
  • Keine Boot-Möglichkeit von einem ReFS-Volume

Die Mehrwerte bei der Nutzung von ReFS als Ablage für Hyper-V VMs

Wird das lokale Laufwerk oder das Cluster Shared Volume mit ReFS unter Windows Server 2016 formatiert, ergeben sich zahlreiche Vorteile bei dem Betrieb von VMs auf diesem Volume.

[ms_alert icon=”fa-exclamation” background_color=”#f5f5f5″ text_color=”” border_width=”0″ border_radius=”0″ box_shadow=”no” dismissable=”no” class=”” id=””]Die Nutzung von ReFS-formatierten Volumes in einem Failover Cluster als Cluster Shared Volumes führt zu einem umgeleiteten Traffic, da die Daten von jedem Knoten nicht direkt geschrieben werden können, sondern erst zum Besitzer des Datenträgers geschickt werden. Dies führt in einigen Fällen zu nicht gewollten und nicht berücksichtigten Traffic zwischen den Knoten und somit zu einem möglichen Flaschenhals. Wenn jeder Knoten direkt auf seinen Datenträger schreiben soll, muss NTFS als Dateisystem genutzt werden.[/ms_alert]

Die Erstellung von VHD oder VHDX-Dateien

Bei der Erstellung von virtuellen Festplatten-Dateien gibt es unter NTFS immer wieder den Nachteil, dass dieser Vorgang recht lange dauern kann. Werden die Dateien mit einer festen Größe angelegt, wird die Datei nach der Erstellung “durchgenullt”. Hierbei wird der gesamte Speicherplatz mit Nullen geschrieben, dies kann bei mehreren hundert Gigabyte oder teilweise Terabyte schon einige Zeit in Anspruch nehmen. Unter ReFS ist dieser Vorgang eine Metadaten-Operation und dauert ca. eine Sekunde, unabhängig von der Größe der Datei. Das Dateisystem deklariert einen gewissen Bereich als belegt, das war schon alles.

Testen wir das Ganze einmal. Auf einem Windows Server 2016 TP5 habe ich zwei Volumes erstellt, basierend auf zwei SSDs aus unserem Hyper-V Powerkurs. Volume E ist mit NTFS formatiert, Volume F mit ReFS.

ReFS_001

Nun legen wir auf jedem der Volumes nacheinander eine 30 GB große VHDX-Datei an und messen die benötigte Zeit:

ReFS_002

Mit einer 50 GB großen Datei sieht es wie folgt aus:

ReFS_003

Hyper-V Checkpoints (ehemals Snapshots)

Die IO-Belastung bei der Nutzung von Hyper-V Checkpoints wird durch das neue Dateisystem enorm verbessert. Da Checkpoints nicht nur manuell erstellt werden können, sondern auch unter anderem bei der Erstellung von einem Backup zur Anwendung kommen können, werden diese recht häufig genutzt. Ein Checkpoint funktioniert wie folgt:

Eine virtuelle Maschine benutzt eine oder mehrere VHD oder VHDX-Dateien. Diese Dateien werden lesend und schreibend genutzt, vorhandene Daten werden gelesen oder verändert und neue Daten werden geschrieben.

ReFS_004

Wird nun von der VM ein Checkpoint erstellt, werden die aktiv genutzten VHD(X)-Dateien geschlossen, es wird pro Datei eine zugehörige AVHD(X)-Datei erstellt (Hierbei handelt es sich um eine differenzielle Datei, die jeweils auf die ursprüngliche Datei verweist) und diese neue Datei wird nun für neue und geänderte Daten genutzt.

ReFS_005

Solch ein Checkpoint wird seit Windows Server 2012 R2 zum Beispiel bei jedem VM-Backup gemacht, der erstellt wird. Nach dem Backup wird der Checkpoint wieder aufgelöst. Der Auflösungsprozess sieht unter NTFS anders aus als unter ReFS:

Checkpoint auflösen unter NTFS

Unter NTFS müssen die Daten, die in der AVHDX-Datei vorhanden sind, über die Daten in der VHDX geschrieben werden. Dieser Vorgang benötigt den doppelten Speicherplatz der AVHDX-Datei, da dieser Vorgang mit einer Kopie gemacht wird und dadurch abgebrochen bzw. unterbrochen werden könnte. Durch das Kopieren der Daten dauert dieser Vorgang, abhängig von Größe und Performance des Speichers im Hintergrund, mehrere Minuten bis hin zu Stunden. Je länger der Checkpoint vorhanden war, desto größer sind in der Regel die AVHDX-Dateien. Im Hintergrund wird der Speicherort der Dateien auf Blockebene geändert, die geänderten Blöcke der AVHDX-Datei werden auf die veralteten Blöcke der VHDX-Datei kopiert. Der Merge-Vorgang führt zu einem erhöhten IO-Verhalten auf dem Volume, der je nach Storage-System zu einer Beeinträchtigung der aktiven VMs führt.

Checkpoint auflösen unter ReFS

Wenn Sie ReFS einsetzen, gibt es keine wirklichen Bewegungen auf dem Volume. Wird ein vorhandener Checkpoint aufgelöst, werden keine Daten auf dem Volume von Platz A (die Daten in der AVHDX-Datei) an Platz B (die VHDX-Datei) verschoben, sondern es erfolgt eine “Verpointerung” der Daten. Die alten Daten in der VHDX-Datei werden auf dem Dateisystem als ungültig deklariert und die genutzten Daten in der AVHDX-Datei werden als weiterhin gültige Daten einfach weiter benutzt, ohne das der physische Speicherplatz verändert wird. Dies führt dazu, dass das Entfernen von einem Checkpoint innerhalb weniger Sekunden möglich ist, egal wie groß die gemachten Änderungen sind. Da kaum Daten geschrieben werden, gibt es bei diesem Vorgang keinen großen (negativen) Einfluss auf die Performance von dem Volume.

Jan Kappen
 

Jan Kappen ist ausgebildeter Fachinformatiker in der Richtung Systemintegration. Er hat seine Ausbildung im Sommer 2008 abgeschlossen und arbeitete bis August 2018 bei der Rachfahl IT-Solutions GmbH & Co. KG. Seit September 2018 arbeitet er als Senior Netzwerk- und Systemadministrator bei einem großen mittelständischen Unternehmen im schönen Sauerland. Jan Kappen ist unter anderen MCITP Server Administrator, Enterprise Administrator und Enterprise Messaging Administrator 2010 sowie MCTS für System Center Virtual Machine Manager 2008, Windows Server 2008 Active Directory, Windows Server Virtualization und Windows Server 2008 Network Infrastructure. Seit 2015 wird Jan Kappen im Bereich "File System Storage" bzw. "Cloud & Datacenter Management" für seine Expertise und seine Community-Arbeit mit dem MVP Award von Microsoft ausgezeichnet.

  • Sascha Reuter sagt:

    Das Anlegen von großen VHDX Containern in wenigen Sekunden ist auch jetzt schon unter NTFS möglich. Stichworte: VHDXTOOL, SYSTOLA
    Nur so ein Tipp am Rande.

  • Sascha da hast du recht. Allerdings nullt das Program die Daten auf dem Volume nicht aus und ist damit nur bedingt vergleichbar/einsetzbar (siehe Emfehlungen von syslola selber: http://www.systola.com/blog/14.01.2015/VhdTool-Is-Dead-Long-Live-VhdxTool/#.V867BoVOKUk)

    Gruß Carsten

  • Sascha Reuter sagt:

    Hallo Carsten,
    wie funktioniert es denn technisch bei ReFS? Dort wird ja eine sehr große VHDX Datei auch in wenigen Sekunden erstellt. Wird das “nullen” dann im Hintergrund ausgeführt? Also langsam ohne das System zu belasten?

  • Hi Sascha,

    Microsoft sagt das das Nullen eine Metadatenoperation ist und deswegen keine Nullen auf die Sectoren geschrieben werden müssen.

    Gruß Carsten

  • Sascha Reuter sagt:

    Also wenn das Nullen nur eine Metadatenoperation ist, dann wird dem OS ja nur vorgegaukelt, das die physischen Sektoren genullt wären. Ist soweit in Ordnung für die VMs, da wohl dann Nullen gelesen werden, obwohl auf dem eigentlichen Medium ggf. noch alte Daten an gleicher Stelle vorhanden sind. Aber mit entsprechenden Tools/Sektoreditoren würde man alte Daten lesen können.
    Wie immer steckt der Teufel im Detail…

  • Stefan sagt:

    Hi,

    Danke für den guten Artikel. Wird ReFS eigentlich schon von MS generell empfohlen, oder gibt es wie bei 2k12R2 Einschränkungen (kein SQL/AD/whatever). Als Hyper-V-Storage werd ichs auf jeden Fall in Betracht ziehen.

    gruß, stefan

  • Jan Kappen sagt:

    Hallo Stefan,
    aktuell noch nicht, aktuell ist es auch noch Version 1. Bei den Kunden, die es im Einsatz haben, funktioniert es meistens, aber seitens der Hersteller heißt es meist “man kann es nutzen, aber wir können nichts garantieren”. Ab 2016 sollte es erst in der Produktion eingesetzt werden, aktuell nur zu Testzwecken.
    Gruß, Jan

  • Stefan sagt:

    Ah, ok. Danke!

  • Hallo Stefan,

    vielen Dank für den guten Artikel.
    Wir haben zur Zeit eine Migration von einem Windows 2012 R2 Hyper-V Cluster mit CSV nach Windows 2016 Cluster mit einer neuen 3PAR als Storage dahinter.

    Wie ich in einem Workshop über Windows 2016 Server auch gelernt habe, habe ich das CSV mit ReFS formatiert. Nur wie ich jetzt bei der Migration festgestellt habe, wird der CSV Datenträger, wenn der ReFS formatiert ist redirected d.h. Performanceverlust. Weiterhin habe ich festgestellt d.h. die Zugriff auf die LUN ohne CSV ca. einen Durchsatz von 1GB/S (16GB FC-SAN) hat und denn die gleiche LUN als CSV freigegeben ist, hat man nur noch einen Durchsatz von ca. 150-300MB/s … ist dieser Effekt bekannt?

    Vielen Dank und netten Gruß,
    Heinrich Klassen

  • Jan Kappen sagt:

    Hallo Heinrich,
    ich hatte auch ein Projekt mit zwei 3PAR-Systemen, dort haben wir bewusst NTFS genutzt, da bei ReFS die gelöschten Blöcke nicht durchgereicht werden vom Filesystem und der Storage Admin nach Rücksprache mit HP davon abgeraten hat, ReFS zu Nutzen, da in Summe weniger Speicherplatz zur Verfügung steht. Grundsätzlich ist ReFS von der reinen Performance her langsamer als NTFS, vor allem bei Aktivierung der Datenintegrität.
    Gruß, Jan

  • Franz Schenk sagt:

    Was stimmt jetzt? Dieser Blog oder http://windowsitpro.com/windows-server-2016/ntfs-or-refs-cluster-shared-volumes-windows-server-2016 die folgendes schreiben: “A big reason for using NTFS is that when using ReFS for Cluster Shared Volumes it always runs in file system redirection mode which means all I/O is sent over the cluster network to the coordinator node for the volume”

    Es gibt schon einen Kommentar in diesem Blog von Heinrich Klassen zum genau gleichen Thema, der leider nicht beantwortet wurde.

    Eine klare Aussage, ob REFS in Verbindung mit CSV in einem Server 2016 Hyper-V Cluster eingesetzt werden soll oder nicht wäre sehr hilfreich!

  • Jan Kappen sagt:

    Hallo,
    die Aussage auf der windowsitpro-Seite ist korrekt, es erfolgt bei CSV-Datenträgern immer ein Redirect zum Besitzer der Disk. Der Beitrag hier ist schon fast ein halbes Jahr alt, ich werde mal eine Anpassung vornehmen mit dem Hinweis auf der umgeleiteten Modus. Die anfängliche Euphorie über die Mehrwerte und Neuheiten ist ein wenig dem Realismus und den Einschränkungen gewichen, denen man nun im Alltag begegnet. Zu der Frage bzw. Aussage: Weiterhin NTFS nutzen.
    Gruß, Jan

  • >