Windows Storage Offloaded Data Transfer

Windows Offloaded Data Transfer (ODX) ist ein Feature, das das Kopieren und Verschieben von Servern beschleunigt. Es ist ab Windows Server 2012 verfügbar und wird auf NTFS-Volumes unterstützt.

In diesem Artikel wird ODX aus Speichergerätperspektive beschrieben. Informationen zu Dateisystemen und Minifiltern finden Sie unter Ausgelagerte Datenübertragungen.

Übersicht

Anstatt bei Dateiübertragungen große Datenmengen zu kopieren, führte Windows ODX einen tokenisierten Vorgang zum Verschieben von Daten auf Speichergeräten ein. Die Quelldatei und eine Zieldatei können sich an einem der folgenden Speicherorte befinden:

• Auf demselben Volume.
• Auf zwei verschiedenen Volumes, die auf demselben Computer gehostet werden.
• Auf einem lokalen Volume und einem Remotevolume über Server Message Block (SMB2 oder SMB3).
• Auf zwei Volumes auf zwei verschiedenen Computern über SMB2 oder SMB3.

Der Prozess eines Offload-Kopiervorgangs auf ODX-fähigen Speichergeräten wird im folgenden Diagramm gezeigt.

1. Die Kopieranwendung sendet eine Offload-Leseanforderung an den Kopier-Manager des Quellspeichergeräts.
2. Der Quellkopie-Manager gibt ein Token zurück. Das Token ist eine Repräsentation (ROD) der zu kopierenden Daten.
3. Die Anwendung sendet eine Offload-Schreibanforderung mit Token an den Kopier-Manager des Zielspeichergeräts.
4. Der Speicherarray-Kopier-Manager verschiebt die Daten vom Quellgerät auf das Zielgerät und gibt das Ergebnis des Offload-Schreibvorgangs an die Anwendung zurück.

Identifizieren einer ODX-fähigen Quelle und eines Ziels

Zur Unterstützung von ODX müssen Speicherarrays die zugehörigen T10-Standardspezifikationen für ODX-fähige Speicherarrays implementieren, einschließlich Offload-Lese- und Schreibvorgängen mit Token. Während der LUN-Geräte-Enumeration (Systemstart oder Plug-and-Play-Ereignis) erfasst oder aktualisiert Windows die ODX-Funktionsinformationen des Speicherzielgeräts mithilfe der folgenden Schritte.

1. Abfrage der Kopieabladungsfähigkeit.
2. Erfassen der erforderlichen Parameter für Kopieabladungsvorgänge und Einschränkungen.

Standardmäßig versucht Windows es zuerst mit dem ODX-Pfad für einen Kopiervorgang, wenn sowohl die Quell- als auch die Ziel-LUNs ODX-fähig sind. Wenn die ursprüngliche ODX-Anforderung des Speichergeräts fehlschlägt, kennzeichnet Windows die Kombination der Quell- und Ziel-LUN als „nicht ODX-fähigen“ Pfad und folgt dem älteren Dateicodepfad für die Kopie.

ODX-Lese-/Schreibvorgänge

Synchrone Befehlsannahme und APIs

Eine große Offload-Schreibanforderung wird mithilfe des folgenden Algorithmus aufgeteilt, um einen robusten synchronen Offload-Schreibvorgang sicherzustellen.

• Wenn das Zielspeichergerät keine optimale Übertragungsgröße bereitstellt, legen Sie die optimale Übertragungsgröße auf 64 MB fest.
• Wenn die vom Zielgerät festgelegte optimale Übertragungsgröße größer als 256 MB ist, legen Sie die optimale Übertragungsgröße auf 256 MB fest.
• Die vom Speicherzielgerät angegebene optimale Übertragungsgröße ist größer als Null und kleiner als 256 MB.

Synchrones Offload-SCSI-Befehle zum Lesen und Schreiben reduzieren die Komplexität von MPIO- und Clusterfailover-Szenarien. Windows erwartet, dass der Kopier-Manager die synchronen Lese-/Schreibzugriffsbefehle innerhalb von vier Sekunden abschließt.

Anwendungen können die APIs FSCTL, DSM IOCTL oder SCSI_PASS_THROUGH verwenden, um mit Speicherarrays zu interagieren und Kopieabladungsvorgänge durchzuführen. Um Datenbeschädigungen oder Systeminstabilität zu vermeiden, schränkt Windows das direkte Schreiben von Anwendungen auf ein vom Dateisystem bereitgestelltes Volume, ohne zuerst exklusiven Zugriff auf das Volume zu erhalten, ein. Diese Einschränkung ist aufgrund der Möglichkeit erforderlich, dass ein Schreibzugriff auf das Volume möglicherweise mit dem Dateisystem-Schreibvorgang kollidiert. Wenn solche Kollisionen auftreten, kann der Inhalt des Volumes in einem inkonsistenten Zustand verbleiben.

Offload-Lesevorgänge

Die Offload-Leseanforderung einer Anwendung kann die Tokenlebensdauer (Inaktivitätstimeout) angeben. Wenn die Anwendung die Tokenlebensdauer auf Null festlegt, wird der Standardzeitgeber für Inaktivität als Tokenlebensdauer verwendet. Der Kopier-Manager des Speicherarrays verwaltet und überprüft das Token entsprechend dem Inaktivitätstimeoutwert und den Anmeldeinformationen. Der Windows-Host beschränkt auch die Anzahl der Dateifragmente auf 64. Wenn die Offload-Leseanforderung aus mehr als 64 Fragmenten besteht, schlägt die Anforderung zum Kopieren von Windows fehl, und es wird auf den herkömmlichen Kopiervorgang zurückgegriffen.

Nach Abschluss der Offload-Leseanforderung bereitet der Kopier-Manager ein Datenrepräsentationstoken (ROD) für den Befehl zum Empfangen des Lesevorgangs vor. Das ROD-Token-Feld gibt die Zeitpunkt-Repräsentation von Benutzerdaten und Schutzinformationen an. Die ROD kann Benutzerdaten im Format „Exklusiv öffnen“ oder „Mit Freigabe öffnen“ repräsentieren. Der Kopier-Manager kann das Token gemäß seiner ROD-Richtlinieneinstellung ungültig machen. Wenn der ROD-Wert für einen Kopieabladungsvorgang „Exklusiv öffnen“ ist, kann das ROD-Token ungültig werden, wenn die ROD geändert oder verschoben wird. Wenn die ROD das Format „Mit Freigabe öffnen“ hat, bleibt das ROD-Token gültig, wenn die ROD geändert wird. Ein ROD-Token hat 512 Byte mit dem folgenden Format:

Größe (Bytes)	Tokeninhalte
4	ROD-Token-Typ
508	ROD-Token-ID

Da das ROD-Token nur vom Speicherarray gewährt und genutzt wird, ist das Format nicht transparent, eindeutig und äußerst sicher. Wenn das Token geändert wurde, nicht validiert oder abgelaufen ist, kann der Kopier-Manager das Token während des Offload-Schreibvorgangs ungültig machen. Das zurückgegebene ROD-Token aus dem Offload-Lesevorgang weist einen Inaktiv-Timeoutwert auf, der die Anzahl von Sekunden angibt, für die der Kopier-Manager das Token für die nächste Verwendung von „Mit Token schreiben“ gültig halten muss.

Offload-Schreibvorgänge

Nachdem die Anwendung das ROD-Token vom Kopier-Manager erhalten hat, sendet sie die Offload-Schreibanforderung mit dem ROD-Token an den Kopier-Manager des Speicherarrays. Wenn ein synchroner Offload-Schreibbefehl an das Zielgerät gesendet wird, erwartet Windows, dass der Kopier-Manager den Befehl innerhalb von vier Sekunden abschließt. Wenn der Befehl aufgrund einer Zeitüberschreitung oder anderer Fehlerbedingungen beendet wird, lässt Windows den Befehl fehlschlagen. Die Anwendung greift entsprechend dem zurückgegebenen Statuscode auf den herkömmlichen Kopiervorgang zurück.

Die Offload-Schreibanforderung kann mit einem oder mehreren „Receive Offload Write Result“-Befehl(en) abgeschlossen werden. Wenn der Offload-Schreibvorgang teilweise abgeschlossen ist, gibt der Kopier-Manager die geschätzte Verzögerung und die Anzahl der Übertragungsvorgänge zurück, um den Kopierfortschritt anzugeben. Die Anzahl der Übertragungsvorgänge gibt die Anzahl zusammenhängender logischer Blöcke an, die ohne Fehler von der Quelle auf das Zielmedium geschrieben wurden. Der Kopier-Manager kann Offload-Schreibvorgänge in einem sequenziellen oder einem Scatter/Gather-Muster ausführen.

Wenn ein Schreibfehler auftritt, zählt der Kopierfortschritt zusammenhängende logische Blöcke vom ersten logischen Block bis zum Block mit dem Fehler. Die Clientanwendung oder das Kopiermodul setzt den Offload-Schreibvorgang aus dem Block mit dem Schreibfehler fort. Nach Abschluss des Offload-Schreibvorgangs schließt der Kopier-Manager den Befehl „Receive ROD Token Information“ ab mit:

• Die geschätzte Statusaktualisierungsverzögerung ist auf Null gesetzt.
• Der Fortschritt der Datenübertragung zeigt 100 Prozent an.

Wenn das Ergebnis des Empfangs des Offload-Schreibvorgangs den gleichen Fortschritt bei der Anzahl der Datenübertragungen zurückgibt, lässt Windows den Kopiervorgang nach vier Wiederholungen scheitern und gibt ihn wieder an die Anwendung zurück.

Eine Clientanwendung kann den Offload-Schreibvorgang auch mit einem bekannten ROD-Token ausführen, bei dem es sich um ein vordefiniertes ROD-Token mit einem bekannten Datenmuster und Tokenformat handelt. Eine gängige Implementierung wird als Zero-Token bezeichnet. Eine Clientanwendung kann ein Zero-Token verwenden, um einen oder mehrere Bereiche logischer Blöcke mit Nullen auszufüllen. Wenn das bekannte Token nicht unterstützt oder erkennbar ist, lässt der Kopier-Manager die Offload-Schreibanforderung mit „Invalid Token“ fehlschlagen. Ein bekanntes ROD-Token hat 512 Byte mit dem folgenden Format:

Größe (Bytes)	Tokeninhalte
4	ROD-Token-Typ
2	Bekanntes Muster
506	ROD-Token-ID

In einem Offload-Schreibvorgang mit einem bekannten ROD-Token kann eine Clientanwendung keinen Offload-Lesevorgang verwenden, um ein bekanntes Token anzufordern. Der Kopier-Manager überprüft und verwaltet die bekannten ROD-Token gemäß seiner eigenen Richtlinie.

Leistungsoptimierungsparameter der ODX-Implementierung

Die Leistung von ODX hängt nicht von den Transportverbindungsgeschwindigkeiten des Clientserver-Netzwerks oder des Storage Area-Netzwerks (SAN) zwischen dem Server und dem Speicherarray ab. Der Kopier-Manager und die Geräteserver des Speicherarrays verschieben die Daten.

Nicht jeder Kopieabladungsvorgang profitiert von der ODX-Technologie. Beispielsweise könnte der Kopier-Manager eines 1-Gbit-iSCSI-Speicherarrays eine 3-GB-Dateikopie innerhalb von 10 Sekunden abschließen, wobei die Datenübertragungsrate mehr als 300 MB pro Sekunde beträgt. Die Datenübertragungsrate übertrifft bereits die maximale theoretische Übertragungsgeschwindigkeit der 1-Gbit-Ethernet-Schnittstelle.

Darüber hinaus ist es möglich, dass die Kopierleistung für Dateien einer bestimmten Größe möglicherweise nicht von der ODX-Technologie profitiert. Um die Leistung zu optimieren, kann die Verwendung von ODX auf eine zulässige Mindestdateigröße und maximale Kopierlängen beschränkt werden. Hinweis:

• Windows legt eine Mindestanforderung für die Dateigröße für Kopieabladungsvorgänge von 256 KB im Kopiermodul fest. Wenn eine Datei kleiner als 256 KB ist, greift das Kopiermodul auf den herkömmlichen Kopiervorgang zurück.

• Der Windows-Host verwendet eine maximale Tokenübertragungsgröße und eine optimale Anzahl von Übertragungsvorgängen, um die optimale Übertragungsgröße eines Offload-SCSI-Lese- oder Schreibbefehls vorzubereiten. Die Gesamtübertragungsgröße (als Anzahl der Blöcke) darf die maximale Tokenübertragungsgröße nicht überschreiten. Wenn das Speicherarray keine optimale Anzahl von Übertragungsvorgängen meldet, verwendet Windows 64 MB als Standard.

Die Parameter für die optimale und maximale Übertragungslänge geben die optimale und die maximale Anzahl von Blöcken in einem Bereichsdeskriptor an. Kopieabladungsanwendungen können diese Parameter berücksichtigen, um eine optimale Leistung bei der Dateiübertragung zu erreichen.

ODX-Fehlerbehandlung und Unterstützung für hohe Verfügbarkeit

Wenn ein ODX-Vorgang eine Dateikopieanforderung fehlschlagen lässt, greifen das Kopiermodul und das Windows-Dateisystem (NTFS) auf den herkömmlichen Kopiervorgang zurück. Wenn der Kopieabladungsvorgang während des Offload-Schreibvorgangs fehlschlägt, fahren das Kopiermodul und das NTFS mit dem herkömmlichen Kopiervorgang vom ersten Fehlerpunkt im Offload-Schreibvorgang fort.

ODX-Fehlerbehandlung

ODX verwendet einen robusten Fehlerbehandlungsalgorithmus gemäß den Features des Speicherarrays. Wenn der Kopieabladungsvorgang in einem ODX-fähigen Pfad fehlschlägt, erwartet der Windows-Host, dass die Anwendung auf den herkömmlichen Kopiervorgang zurückgreift. An diesem Punkt hat das Windows-Kopiermodul bereits den Mechanismus „Fallback zu herkömmlichem Kopiervorgang“ implementiert. Nachdem der Kopieabladungsfehler aufgetreten ist, kennzeichnet NTFS die Quell- und Ziel-LUN für drei Minuten als nicht ODX-fähig. Nach Ablauf dieser Zeit versucht das Windows-Kopiermodul den ODX-Vorgang erneut. Ein Speicherarray könnte dieses Feature verwenden, um die ODX-Unterstützung vorübergehend in einigen Pfaden in Situationen mit sehr hoher Last zu deaktivieren.

ODX-Failover in MPIO- und Clusterserverkonfigurationen

Offload-Lese- und Schreibvorgänge müssen von demselben Speicherlink (I_T Nexus) abgeschlossen oder abgebrochen werden.

Wenn ein MPIO- oder Clusterserver-Failover während eines synchronen Lese- oder Schreibvorgangs auftritt, geht Windows wie folgt damit um:

• Wenn ein MPIO-Pfad-Failover auftritt, ruft Windows den fehlgeschlagenen ODX-Befehl erneut auf. Wenn der Befehl erneut fehlschlägt, unternimmt Windows Folgendes:

  • Initiierung eines Clusterserverknoten-Failovers, wenn es um einen Teil eines Clusterservers geht.
  • Ausgabe eines LUN-Resets zum Speichergerät und Rückgabe eines E/A-Fehlerstatus an die Anwendung, wenn Clusterserver-Failover nicht möglich ist.

• In einer Clusterserverkonfiguration wird für den Clusterspeicherdienst ein Failover zum nächsten bevorzugten Clusterknoten durchgeführt und dann der Clusterspeicherdienst fortgesetzt. Die Offload-Anwendung muss clusterfähig sein, um den Lese-/Schreibzugriffsbefehl nach dem Clusterspeicherdienst-Failover erneut versuchen zu können.

Wenn der Offload-Lese- oder Schreibbefehl nach dem MPIO-Pfad- und Clusterknoten-Failover fehlgeschlagen ist, gibt Windows nach dem Failover eine LUN-Zurücksetzung auf das Speichergerät aus. Das Speichergerät beendet alle ausstehenden Befehle und Vorgänge im LUN.

Derzeit gibt Windows keine asynchronen Offload-Lese- oder Schreibzugriffsbefehle aus dem Speicherstapel aus.

ODX-Nutzungsmodelle

ODX auf physischem Datenträger, virtueller Festplatte und freigegebenem SMB-Datenträger

Zum Ausführen von ODX-Vorgängen muss der Anwendungsserver Zugriff auf Quell-LUN und Ziel-LUN mit Lese-/Schreibberechtigungen haben. Die Kopieabladungsanwendung gibt eine Offload-Leseanforderung an die Quell-LUN aus und empfängt ein Token vom Kopier-Manager der Quell-LUN. Die Kopieabladungsanwendungen verwenden das Token, um eine Offload-Schreibanforderung an die Ziel-LUN auszugeben. Der Kopier-Manager verschiebt dann die Daten aus der Quell-LUN in die Ziel-LUN über das Speichernetzwerk. Das folgende Diagramm veranschaulicht die grundlegenden unterstützten Quellen und Ziele für Datenübertragungen mit Offload.

ODX-Vorgang mit einem Server

In einer Konfiguration mit einem einzelnen Server gibt die Kopieabladungsanwendung Lese- und Schreibanforderungen von demselben Serversystem aus.

Der Quellserver (oder die Quell-VM) hat Zugriff auf die Quell-LUN (VHD oder physische Festplatte) und die Ziel-LUN (VHD oder physische Festplatte). Die Kopieabladungsanwendung gibt eine Offload-Leseanforderung an die Quell-LUN aus und empfängt das Token von der Quell-LUN. Die Kopieabladungsanwendung verwendet dann das Token, um eine Offload-Schreibanforderung an die Ziel-LUN auszugeben. Der Kopier-Manager verschiebt die Daten aus der Quell-LUN in die Ziel-LUN innerhalb desselben Speicherarrays.

ODX-Vorgang mit zwei Servern

In einer Konfiguration mit zwei Servern gibt es zwei Server und mehrere Speicherarrays, die vom selben Kopier-Manager verwaltet werden.

• Ein Server (oder eine VM) ist der Host der Quell-LUN, und der andere Server (oder VM) ist der Host der Ziel-LUN. Der Quellserver teilt die Quell-LUN mit dem Anwendungsclient über das SMB-Protokoll, und der Zielserver teilt ebenfalls die Ziel-LUN mit dem Anwendungsclient über das SMB-Protokoll. Der Anwendungsclient hat somit Zugriff auf die Quell-LUN und die Ziel-LUN.
• Die Quell- und Ziel-Speicherarrays werden von demselben Kopier-Manager in einer SAN-Konfiguration verwaltet.
• Vom Anwendungsclientsystem aus gibt die Kopieabladungsanwendung eine Offload-Leseanforderung an die Quell-LUN aus, empfängt das Token aus der Quell-LUN und gibt dann eine Offload-Schreibanforderung mit dem Token an die Ziel-LUN aus. Der Kopier-Manager verschiebt die Daten aus der Quell-LUN in die Ziel-LUN über zwei verschiedene Speicherarrays an zwei verschiedenen Speicherorten.

Massive Datenmigration

Die massive Datenmigration ist der Import einer großen Menge von Daten wie Datenbankdatensätzen, Tabellenkalkulationen, Textdateien, gescannten Dokumenten und Bildern in ein neues System. Eine Datenmigration kann durch ein Speichersystemupgrade, ein neues Datenbankmodul oder Änderungen an Anwendungen oder Geschäftsprozessen verursacht werden. ODX kann verwendet werden, um Daten von einem älteren zu einem neuen Speichersystem zu migrieren, wenn der Kopier-Manager des neuen Systems auch das ältere System verwalten kann.

• Ein Server ist der Host des älteren Speichersystems, und der andere Server ist der Host des neuen Speichersystems. Der Quellserver teilt die Quell-LUN als Datenmigrationsanwendungsclient über das SMB-Protokoll, und der Zielserver teilt die Ziel-LUN als Datenmigrationsanwendungsclient über das SMB-Protokoll. Der Anwendungsclient hat somit Zugriff auf die Quell- und die Ziel-LUN.
• Das ältere Speichersystem und das neue Speichersystem werden von demselben Kopier-Manager in einer SAN-Konfiguration verwaltet.
• Vom Clientsystem der Datenmigrationsanwendung gibt die Kopieabladungsanwendung eine Offload-Leseanforderung an die Quell-LUN aus und empfängt das Token aus der Quell-LUN. Die Anwendung gibt dann eine Offload-Schreibanforderung mit dem Token an die Ziel-LUN aus. Der Kopier-Manager verschiebt die Daten aus der Quell-LUN in die Ziel-LUN über zwei verschiedene Speichersysteme an zwei verschiedenen Speicherorten.
• Eine massive Datenmigration kann auch mit einem einzelnen Server an demselben Standort durchgeführt werden.

Hostgesteuerte Datenübertragung innerhalb eines mehrstufigen Speichergeräts

Ein mehrstufiges Speichergerät kategorisiert Daten in verschiedene Arten von Speichermedien, um Kosten zu senken, die Leistung zu erhöhen und Kapazitätsprobleme zu beheben. Kategorien können auf den erforderlichen Schutzstufen, Leistungsanforderungen, der Nutzungshäufigkeit und anderen Überlegungen basieren.

Die Datenmigrationsstrategie spielt eine wichtige Rolle für das Endergebnis einer mehrstufigen Speicherstrategie. ODX ermöglicht die hostgesteuerte Datenmigration innerhalb des mehrstufigen Speichergeräts. Das folgende Beispiel beschreibt ODX in einem zweistufigen Speichergerät:

• Der Server ist der Host des mehrstufigen Speichersystems. Die Quell-LUN ist das Tier1-Speichergerät, und die Ziel-LUN ist das Tier2-Speichergerät.
• Derselbe Kopier-Manager verwaltet alle mehrstufigen Speichergeräte.
• Vom Serversystem aus gibt die Datenmigrationsanwendung eine Offload-Leseanforderung an die Quell-LUN aus und empfängt das Token aus der Quell-LUN. Diese Anwendung gibt dann eine Offload-Schreibanforderung mit dem Token an die Ziel-LUN aus. Der Kopier-Manager verschiebt die Daten aus der Quell-LUN in die Ziel-LUN über zwei verschiedene Stufenspeichergeräte.
• Nach Abschluss der Datenmigration löscht die Anwendung die Daten vom Tier1-Speichergerät und gibt den Speicherplatz wieder frei.