Windows Offloaded Data Transfer

ODX (Offloaded Data Transfer) ist ein Feature, das das Kopieren und Verschieben von Servern beschleunigt. Dieses Feature ist ab Windows Server 2012 verfügbar und wird auf NTFS-Volumes unterstützt. Diese Seite beschreibt ODX aus Dateisystem- und Minifilterperspektive. Informationen zu Speichergeräten finden Sie unter Windows Storage Offloaded Data Transfers.

Das Übertragen von Daten zwischen Computern oder innerhalb desselben Computers ist eine häufige Dateisystemaktivität. Die Verwendung der standardmäßigen Funktionen ReadFile und WriteFilefunktioniert aus funktionaler Sicht gut, erfordert jedoch eine starke Datenverschiebung über alle Systemebenen und potenziell über ein Netzwerk hinweg. Diese Komplexität kann sich auf die Verfügbarkeit der Systeme auswirken, die an der Übertragung beteiligt sind, und das Netzwerk, das die Systeme verbindet. Die erweiterten Funktionen vieler Speichersubsysteme ermöglichen eine effizientere Durchführung der komplexen Aufgabe der Datenverschiebung.

Anwendungen können diese Funktionen nutzen, um den Prozess der Datenverschiebung in das Speichersubsystem zu entladen. Dateisystemfilter können diese Aktionen normalerweise überwachen, indem Lese- und Schreibanforderungen auf ein Volume abgefangen werden. Weitere Aktionen sind erforderlich, damit Filter ODXs kennen.

Typische Datenübertragungen

Das Verschieben von Daten in einem Anwendungsszenario ist heute einfacher. Es umfasst das Lesen der Daten in den lokalen Speicher und das erneute Schreiben an einen neuen Speicherort. Das folgende Diagramm veranschaulicht dieses Szenario.

In diesem Szenario wird eine Datei zwischen zwei Speicherorten auf zwei verschiedenen Dateiservern kopiert, wobei jeweils ein eigener virtueller Datenträger über ein Intelligent Storage Array (ISA) verfügbar gemacht wird. Das initiierende System muss zuerst die Daten vom virtuellen Quelldatenträger in einen lokalen Puffer lesen. Anschließend werden die Daten über einige Transport- und Protokolldaten (z. B. SMB über 1 GbE) an das zweite System verpackt und übertragen. Das zweite System empfängt dann die Daten und gibt sie in einen lokalen Puffer aus. Anschließend schreibt das Zielsystem die Daten auf den virtuellen Zieldatenträger. In diesem Szenario wird eine typische Read/Write-Methode der Datenübertragung beschrieben, die täglich von vielen verschiedenen Anwendungen mehrmals durchgeführt wird.

Standardlese- und Schreibvorgänge funktionieren zwar in den meisten Szenarien gut, die daten, die kopiert werden sollen, befinden sich möglicherweise auf virtuellen Datenträgern, die von demselben intelligenten Speicherarray verwaltet werden. Dies bedeutet, dass die Daten aus dem Array, auf einen Server, über einen Netzwerktransport, auf einen anderen Server und wieder in dasselbe Array verschoben werden. Das Verschieben von Daten innerhalb eines Servers und über einen Netzwerktransport kann sich erheblich auf die Verfügbarkeit dieser Systeme auswirken. Darüber hinaus ist der Durchsatz der Datenverschiebung durch den Durchsatz und die Verfügbarkeit des Netzwerks begrenzt.

Ausgelagerte Datenübertragungen (ODX)

Auslagern der Datenübertragung

In Windows 8 wurden zwei FSCTLs eingeführt, die eine Methode zum Entladen der Datenübertragung erleichtern. Durch diese Entlastung wird die Last der Bitbewegung von Servern auf Bit-Bewegungen verschoben, die intelligent innerhalb der Speichersubsysteme auftreten. Die beste Möglichkeit zum Visualisieren der Befehlssemantik besteht darin, sie als analog zu einem ungepufferten Lesen und einem ungepufferten Schreibvorgang zu betrachten.

• FSCTL_OFFLOAD_READ

  Diese Steuerelementanforderung verwendet einen Offset innerhalb der Datei, um gelesen zu werden und eine gewünschte Länge in der FSCTL_OFFLOAD_READ_INPUT-Struktur. Wenn unterstützt, empfängt das Speichersubsystem, in dem die Datei gehostet wird, den zugeordneten Lesespeicherbefehl. Anschließend wird ein Token generiert, bei dem es sich um eine logische Darstellung der Daten handelt, die zum Zeitpunkt des Offload-Lesebefehls gelesen werden sollen. Diese Tokenzeichenfolge wird an den Aufrufer in der FSCTL_OFFLOAD_READ_OUTPUT-Struktur zurückgegeben.

• FSCTL_OFFLOAD_WRITE

  Diese Steuerelementanforderung verwendet einen Offset innerhalb der Datei, in die geschrieben werden soll, die gewünschte Länge des Schreibvorgangs und das Token, das eine logische Darstellung der zu schreibenden Daten ist. Wenn dies unterstützt wird, erhält das Speichersubsystem, das die zu schreibende Datei hostet, den zugeordneten Offload-Speicherbefehl. Es versucht zunächst, das angegebene Token zu erkennen, und führt den Schreibvorgang nach Möglichkeit aus. Der Schreibvorgang wird unter Windows abgeschlossen, weshalb Komponenten im Dateisystem und Speicherstapel die Datenverschiebung nicht sehen. Sobald die Datenverschiebung abgeschlossen ist, wird die Anzahl der geschriebenen Bytes an den Aufrufer zurückgegeben.

Ähnlich wie im ersten Diagramm zeigt das folgende Diagramm eine einfache Dateikopie zwischen zwei virtuellen Datenträgern auf zwei verschiedenen Servern.

Anstatt jedoch normale Lese- und Schreibvorgänge durchzuführen, verlagern wir die schwere Arbeit der Bitbewegung auf das Speicherarray. Das erste System gibt den Lesevorgang aus, der das Array anfordert, ein Token zu generieren, das eine Punkt-in-Time-Ansicht der Daten darstellt, die innerhalb des Bereichs des ersten virtuellen Datenträgers gelesen werden sollen. Das erste System überträgt dann das Token an das zweite System, wodurch wiederum ein Offload-Schreibvorgang auf den zweiten virtuellen Datenträger mit dem Token ausgibt. Das Array interpretiert dann das Token und versucht, die Datenverschiebung zwischen den virtuellen Datenträgern durchzuführen. Die tatsächliche Datenübertragung erfolgt innerhalb des intelligenten Speicherarrays und nicht zwischen den beiden Hosts. Dieses Design verbessert die Verfügbarkeit der beiden Systeme erheblich, während der Netzwerkdatenverkehr zwischen den Systemen praktisch eliminiert wird.

Integration mit dem Kopiermodul

Das Hauptkopiemodul in Windows wird von CopyFile und verwandten Funktionen verwendet. Ab Windows 8 versucht das Kopiermodul transparent, ODX vor dem herkömmlichen Dateicodepfad zu verwenden. Die Kopier-APIs werden von den meisten Anwendungen, Hilfsprogrammen und der Shell verwendet. Diese Aufrufer können ODX-Funktionen standardmäßig mit wenig, falls vorhanden, Codeänderung oder Benutzereingriff verwenden.

Die folgenden Schritte fassen zusammen, wie das Kopiermodul ein ODX versucht:

1. Das Kopiermodul gibt eine FSCTL_OFFLOAD_READ in der Quelldatei aus, um ein Lesetoken abzurufen.
2. Wenn beim Abrufen des Lesetokens ein Fehler aufgetreten ist, greift das Kopiermodul auf herkömmliche Lese- und Schreibvorgänge zurück (der herkömmliche Dateicodepfad). Wenn der Fehler angibt, dass das Quellvolume das Entladen nicht unterstützt, markiert das Kopiermodul auch das Volume in einem Prozesscache. Das Kopiermodul versucht nicht mehr, die Volumes im Cache pro Prozess auszuladen.
3. Wenn das Token erfolgreich abgerufen wurde, versucht die Kopier-Engine, FSCTL_OFFLOAD_WRITE-Befehle in großen Blöcken für die Zieldatei auszugeben, bis alle durch das Token logisch dargestellten Daten ausgeladen und geschrieben sind.
4. Alle Fehler beim Ausführen des Offload-Lese-/Schreibvorgangs führen dazu, dass das Kopiermodul auf den herkömmlichen Lese-/Schreibcodepfad zurückfällt. Dieser Fallback beginnt ab dem Ort, an dem der Offload-Codepfad beendet wurde (wobei der Lese- oder Schreibzugriff abgeschnitten wurde). Das Kopiermodul aktualisiert den gleichen Cache pro Prozess, sodass es nicht versuchen wird, diese Volumes zu entladen, wenn eine der folgenden Bedingungen zutrifft. Dieser Prozesscache wird in regelmäßigen Abständen zurückgesetzt.

• Der Fehler gibt an, dass das Zielvolume das Offload nicht unterstützt.
• Das Quellvolume kann das Zielvolume nicht erreichen.

Folgende Funktionen unterstützen ODXs:

• CopyFile
• CopyFileEx
• MoveFile
• MoveFileEx
• CopyFile2

Folgende Funktionen unterstützen ODXs nicht:

• CopyFileTransacted
• MoveFileTransacted

Unterstützte Offload-Datenübertragungsszenarien

Unterstützung für die Auslagerungsvorgänge wird im Hyper-V-Speicherstapel und im Windows SMB-Dateiserver bereitgestellt. Wenn der zugrunde liegende physische Speicher ODX-Operationen unterstützt, können Anrufer FSCTL_OFFLOAD_READ und FSCTL_OFFLOAD_WRITE an Dateien ausgeben, die auf VHDs oder Remote-Dateifreigaben gespeichert sind, sei es innerhalb einer virtuellen Maschine oder auf physischer Hardware. Das folgende Diagramm veranschaulicht die einfachsten unterstützten Quell- und Zielziele für ODXs.

Dateisystemfilter-Opt-In-Modell und Auswirkungen auf Anwendungen

Ab Windows 8 ermöglicht der Filter-Manager einem Filter die Angabe der Offload-Funktion als unterstütztes Feature. An ein Volume angehängte Dateisystemfilter können gemeinsam bestimmen, ob ein bestimmter ausgelagerter Vorgang unterstützt wird. Wenn er nicht unterstützt wird, schlägt der Vorgang mit einem entsprechenden Fehlercode fehl.

Ein Filter muss angeben, dass er FSCTL_OFFLOAD_READ und FSCTL_OFFLOAD_WRITE unterstützt. Dies geschieht durch einen Registrierungswert DWORD mit dem Namen SupportedFeatures, der sich in der Treiberdienstdefinition in der Registrierung unter HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\filter driver name\ befindet. Dieser Wert enthält Bitfelder, in denen die Bits bestimmen, welche Funktionalität aktiviert ist und während der Filterinstallation festgelegt werden soll.

Derzeit sind die definierten Bits:

Flag	Bedeutung
SUPPORTED_FS_FEATURES_OFFLOAD_READ 0x00000001	Filter unterstützt FSCTL_OFFLOAD_READ
SUPPORTED_FS_FEATURES_OFFLOAD_WRITE 0x00000002	Filter unterstützt FSCTL_OFFLOAD_WRITE

Das Filter-Opt-In-Modell kann basierend auf dem im HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\FilterSupportedFeaturesMode-Registrierungsschlüssel vorhandenen Wert aktiviert oder deaktiviert werden, der die folgenden Werte aufweist:

FilterSupportedFeaturesMode-Wert	Bedeutung
0 (Standard)	Führen Sie die normale Opt-In-Verarbeitung durch.
1	Nie anmelden (entspricht dem Festlegen von SupportedFeatures auf 0 für alle angefügten Filter)

Testen

Verwenden Sie das fltmc-Hilfsprogramm, um die unterstützten Features eines Filters zu überprüfen. Führen Sie fltmc-Instanzen –v [volume]: als Benutzer mit erhöhten Rechten aus, und überprüfen Sie die Spalte "SprtFtrs ":

• Wenn der SprtFtrs-Wert 0x00 ist, bedeutet dies, dass der Filter das Offload auf diesem Volume blockiert. Wenn SprtFtrs auf 0x03 festgelegt ist, werden beide Offloadvorgänge unterstützt.

Überprüfen der Featureunterstützung in der IRP-Verarbeitung

Als Teil der IRP-Verarbeitung ruft die Routine FsRtlGetSupportedFeaturesden aggregierten SupportedFeatures-Status für alle Filter ab, die an den angegebenen Volume-Stapel angeschlossen sind. Komponenten wie E/A-Manager und SRV (SMB) rufen diese Routine auf, um den Status SupportedFeatures für alle Filter im Stapel zu überprüfen. Komponenten, die ihre eigenen Offload-IRPs rollen, sollten diese Funktion aufrufen, um die Opt-In-Unterstützung für diesen Vorgang zu überprüfen.

Überlegungen zu Filtertreibern

ODX ist eine Möglichkeit zum Verschieben von Daten im Rechenzentrum. Aufgrund der Integration von Offloadlogik in das Hauptkopiemodul haben viele Anwendungen standardmäßig die Möglichkeit, geladene Datenverschiebungen durchzuführen, ohne sich explizit zu entscheiden. Daher müssen Filterentwickler verstehen, wie sich diese Vorgänge auf Filter auswirken. Wenn Sie diese Vorgänge nicht vollständig verstehen oder die Änderung des Datenflusses nicht auswerten, kann dies zu Szenarien führen, in denen Daten inkonsistent oder beschädigt werden können. In der folgenden Liste sind einige Aktionspunkte zusammengefasst, die Filterentwickler beim Offload beachten sollten:

• Verstehen Sie diesen Datenfluss, die Auswirkungen auf den Filter und die Fähigkeit des Filters, diese ausgelagerten Vorgänge zu unterstützen.
• Aktualisieren Sie das Filterinstallationsprogramm, um dem Unterschlüssel HKLM\System\CurrentControlSet\Services\[filter] einen REG_DWORD Wert für SupportedFeatures hinzuzufügen. Initialisieren Sie sie, um die Offload-Funktionalität anzugeben.
• Aktualisieren Sie für Filter, die auf Offload-Vorgänge reagieren sollen, die Registrierung auf IRP_MJ_FILE_SYSTEM_CONTROL, um FSCTL_OFFLOAD_READ und FSCTL_OFFLOAD_WRITE zu verarbeiten.
• Geben Sie für Filter, die deaktivierte Vorgänge blockieren müssen, den Statuscode STATUS_NOT_SUPPORTED innerhalb des Filters zurück. Verlassen Sie sich nicht auf den Registrierungswert, um das Blockieren von Offload-Vorgängen zu erzwingen, da Endbenutzer sie ändern können. Ein Filter sollte Offload-Vorgänge explizit zulassen oder verbieten.

Kopieren des Tokens

Bei ausgelagerten Vorgängen werden die Dateidaten vom E/A-Stapel nicht angezeigt. Stattdessen werden die Dateidaten als 512-Byte-Token betrachtet, das der logische Proxy für die Daten ist. Dieses Token ist entweder:

• Eine undurchsichtige und eindeutige Zeichenfolge eines anbieterspezifischen Formats, das vom Speichersubsystem generiert wird.
• Ein bekannter Typ, der ein Datenmuster darstellt (z. B. einen Datenbereich, der logisch null entspricht).

Änderungen an den Daten des Proxytokens führen dazu, dass das Token ungültig wird oder dass das Speichersubsystem die ursprünglichen Daten von einigen anbieterspezifischen Mitteln wie z. B. über einen Snapshotmechanismus beibehalten wird. Nachfolgende Auslagerung von Leseanforderungen an einen angegebenen Bereich in einer Datei führt zu eindeutigen Token.

Es gibt Klassen von Token, die ein Muster von Daten darstellen, das gut definiert ist. Das am häufigsten bekannte Token ist das Nulltoken, das null entspricht. Wenn ein Token als bekanntes Token definiert ist, wird das TokenType-Element in der STORAGE_OFFLOAD_TOKEN Struktur auf STORAGE_OFFLOAD_TOKEN_TYPE_WELL_KNOWN festgelegt. Wenn dieses Feld festgelegt ist, bestimmt das WellKnownPattern-Element, welches Datenmuster das Token ist.

• Wenn das Feld WellKnownPattern auf STORAGE_OFFLOAD_PATTERN_ZERO oder STORAGE_OFFLOAD_PATTERN_ZERO_WITH_PROTECTION_INFORMATION festgelegt ist, gibt es das Nulltoken an. Wenn dieses Token von einem FSCTL_OFFLOAD_READ-Vorgang zurückgegeben wird, gibt es an, dass die im gewünschten Dateibereich enthaltenen Daten logisch null entsprechen. Wenn dieses Token für einen FSCTL_OFFLOAD_WRITE-Vorgang bereitgestellt wird, gibt es an, dass der gewünschte Bereich der zu schreibenden Datei logisch null sein soll.
• Außer dem Nulltoken sind derzeit keine anderen bekannten Tokenmuster definiert. Es wird nicht empfohlen, dass Benutzer ihre eigenen bekannten Tokenmuster definieren.

Abschneiden

Das zugrunde liegende Speichersubsystem, mit dem Windows kommuniziert, kann weniger Daten verarbeiten, die in einem Offload-Vorgang gewünscht wurden. Diese Bedingung wird als Abschneiden bezeichnet. Beim Offload-Lesen stellt das zurückgegebene Token einen Bereich der Daten dar, die kleiner als die angeforderten Daten sind. Das Element TransferLength in der Struktur FSCTL_OFFLOAD_READ_OUTPUT wird verwendet, um diesen Wert anzugeben, der eine Byteanzahl vom Anfang des Bereichs der zu lesenden Datei darstellt. Bei Offload-Schreibvorgängen gibt eine Abkürzung an, dass weniger Daten geschrieben wurden als gewünscht. Das Element LengthWritten in der Struktur FSCTL_OFFLOAD_WRITE_OUTPUT gibt diesen Wert an, der eine Byteanzahl vom Anfang des Bereichs der zu schreibenden Datei ist. Fehler bei der Befehlsverarbeitung oder Einschränkungen innerhalb des Stapels für große Bereiche führen zu einem Abschneiden.

Es gibt zwei Szenarien, in denen NTFS den Bereich abschneidet, der gelesen oder geschrieben werden soll:

1. Der Kopierbereich wird auf gültige Datenlänge (Valid Data Length, VDL) abgeschnitten, wenn VDL vor dem Ende der Datei (EOF) liegt. Diese Aktion setzt voraus, dass VDL an einer logischen Sektorgrenze ausgerichtet ist, andernfalls siehe Szenario.

   

   Während eines FSCTL_OFFLOAD_READ -Vorgangs wird das Flag OFFLOAD_READ_FLAG_ALL_ZERO_BEYOND_CURRENT_RANGE in der Struktur FSCTL_OFFLOAD_READ_OUTPUT gesetzt, um anzuzeigen, dass der Rest der Datei Nullen enthält, und das Element TransferLength gesetzt, um anzuzeigen, dass der Rest der Datei Nullen enthält, und das Elemen

2. Ähnlich wie in Szenario 1, aber wenn VDL nicht an einer logischen Sektorgrenze ausgerichtet ist, schneidet NTFS den gewünschten Bereich auf die nächste logische Sektorgrenze ab.

   

Begrenzungen

• Offload-Vorgänge werden nur auf NTFS-Volumes unterstützt.
• Offload-Vorgänge werden über Remotedateiserver unterstützt, wenn die folgenden Bedingungen erfüllt sind:
  • Die Remotefreigabe ist ein NTFS-Volume.
  • Auf dem Server wird Windows Server 2012 oder höher ausgeführt (vorausgesetzt, der Remotestapel unterstützt auch Offload-Vorgänge).
• NTFS unterstützt das Offload von FSCTLs, die mit Bitlocker- oder NTFS-Verschlüsselung (NTFS Encryption, EFS) verschlüsselt wurden, nicht, deduplizierte Dateien, komprimierte Dateien, residente Dateien, sparse Dateien oder Dateien, die an TxF-Transaktionen teilnehmen.
• NTFS unterstützt das Offload von FSCTLs, die für Dateien innerhalb einer Volsnap-Momentaufnahme ausgeführt werden.
• NTFS schlägt den Offload FSCTL fehl, wenn eine der folgenden Bedingungen zutrifft. Dieser Ansatz folgt der gleichen Semantik wie nicht zwischengespeicherte E/A..
  • Der gewünschte Dateibereich ist auf die Größe des logischen Sektors auf dem Quellgerät nicht ausgerichtet.
  • Der gewünschte Dateibereich ist auf die Größe des logischen Sektors auf dem Zielgerät nicht ausgerichtet.
• Die Zieldatei muss SetEndOfFile und nicht SetAllocation) vor FSCTL_OFFLOAD_WRITE zugewiesen werden.
• Wenn NTFS Lese- und Schreibvorgänge auslagern, ruft sie zuerst CcCoherencyFlushAndPurgeCache auf, um alle geänderten Daten im Systemcache zu übernehmen. Diese Aktion ist die gleiche Semantik wie nicht zwischengespeicherte E/A-Nachrichten.