Windows Offloaded Data Transfers Overview

Applies To: Windows Server 2012 R2, Windows Server 2012

This topic provides an overview of Windows Offloaded Data Transfer (ODX, also known as copy offload) in Windows. ODX enables direct data transfers within or between compatible storage devices without transferring the data through the host computer.

Did you mean…

Feature description

Windows Offloaded Data Transfer (ODX) functionality in Windows maximizes an enterprise’s investment in intelligent storage arrays by enabling the arrays to directly transfer data within or between compatible storage devices, bypassing the host computer.

By offloading the file transfer to the storage array, ODX minimizes latencies, maximizes array throughput, and reduces resource usage such as CPU and network consumption on the host computer. Windows offloads file transfers transparently and automatically when you move or copy files, irrespective of whether you drag-and-drop files through File Explorer or use command-line file copy commands.

Practical applications

Some of the applications of ODX include:

Rapidly import and export Hyper-V virtual machines that are stored on an ODX-capable storage array and accessed via iSCSI, Fibre Channel, or SMB file shares

Transfer large files such as database files or video files with increased speed and decreased CPU and network resource consumption on the host server

Important functionality

In traditional host-based file transfers, the data to be transferred must be:

Read from the storage through the source server

Transferred across the network to the destination server

Written back to the storage through the destination server

To eliminate this inefficiency, ODX uses a token-based mechanism for reading and writing data within or between intelligent storage arrays. Instead of routing the data through the host, a small token is copied between the source server and destination server. The token serves as a point-in-time representation of the data. As an example, when you copy a file or migrate a virtual machine between storage locations (within or between storage arrays), a token representing the virtual machine file is copied, thereby removing the need to copy the underlying data through the servers.

The following figure explains the steps that are involved with a token-based copy operation.

Figure 1В В В Token-based copy operation

This procedure is described in the following steps:

A user copies or moves a file by using Windows Explorer, a command line interface, or as part of a virtual machine migration.

Windows automatically translates this transfer request into an ODX (if supported by the storage array), and it receives a token that represents the data.

The token is copied between the source server and destination server.

The token is delivered to the storage array.

The storage array internally performs the copy or move and provides status information to the user.

In the event of an MPIO path failover, Windows retries the ODX transfer. If this fails, Windows initiates a cluster failover (when part of a failover cluster). In the event of a cluster failover, if the application is cluster aware Windows resumes the ODX transfer after the failover. If Windows cannot resume or restart an ODX transfer after an MPIO path or cluster failover, Windows issues a LUN reset to the storage device, ending all outstanding operations on the LUN. It then returns an IO failure back to the application.

Hardware requirements

To use ODX, your storage arrays must meet the following requirements:

Must be certified compatible with Windows Offloaded Data Transfer (ODX)

To support ODX between storage arrays, the copy manager for the storage arrays must support cross-storage array ODX, and the storage arrays must be from the same vendor

Must be connected by using one of the following protocols:

Fibre Channel over Ethernet

Serial Attached SCSI (SAS)

Must use one of the following configurations:

One server with one storage array

One server with two storage arrays

Two servers with one storage array

Two servers with two storage arrays

Software requirements

To use ODX, your environment must support the following:

The computer initiating the data transfer must be running Windows Server 2012 R2, Windows Server 2012, Windows 8.1, or Windows 8.

File system filter drivers such as antivirus and encryption programs need to opt-in to ODX. ODX is not supported by the following file system filter drivers:

BitLocker Drive Encryption

Files must be on an unencrypted basic partition. Storage Spaces and dynamic volumes are not supported.

Files must be on a volume formatted using NTFS. ReFS and FAT are not supported. Files can be directly transferred to or from this volume, or from one of the following containers:

A Virtual Hard Disk (VHD) that uses the VHD or VHDX formats

A file share that uses the SMB protocol

The files must be 256 KB or larger – smaller files are transferred using a traditional (non-ODX) file transfer.

The application that performs the data transfer must be written to support ODX. The following currently support ODX:

Hyper-V management operations that transfer large amounts of data at a time, such as creating a fixed size virtual hard disk (VHD), merging snapshot or converting virtual hard disks.

Copy commands in Windows PowerShell

Copy commands in Windows command prompt (including Robocopy)

Files should not be highly fragmented. Transfers of highly fragmented files will have reduced performance.

Hyper-V Requirements

To use ODX with virtual machines hosted by Hyper-V, the virtual machines need to access storage from an ODX-capable storage array. You can achieve this by using any of the following approaches.

Store the VHD on an ODX-capable iSCSI LUN

Assign ODX-capable iSCSI LUNs to the virtual machine’s iSCSI initiator

Assign ODX-capable Fibre Channel LUNs to the virtual machine’s virtual Fibre Channel adapter

Connect the host or virtual machine to an SMB file share on another computer that is hosted on an ODX-capable storage array

See also

For more information, see the following resources.

Deploy Windows Offloaded Data Transfers

Applies To: Windows Server 2012 R2, Windows Server 2012

This topic discusses how to deploy Windows Offloaded Data Transfer (ODX) in Windows Server 2012 to directly transfer data within or between compatible storage devices, bypassing the host computer. This topic also discusses hardware requirements, software requirements, and how to verify the performance of ODX after you implement it.

Although no action is required to use ODX with a compatible storage array and compatible applications, there are a number of tasks that you should perform to confirm that your environment is compatible with ODX and to verify that you are receiving the performance benefits of ODX, as discussed in this topic.

In this document

Prerequisites

To use ODX, your environment must meet the following hardware and software requirements.

Hardware requirements

To use ODX, your storage arrays must meet the following requirements:

Be certified as compatible with Windows Offloaded Data Transfer (ODX) on Windows Server 2012

Support cross-storage array ODX. To support ODX between storage arrays, the copy manager for the storage arrays must support cross-storage array ODX, and the storage arrays must be from the same vendor

Be connected by using one of the following protocols:

Fibre Channel over Ethernet

Serial Attached SCSI (SAS)

Use one of the following configurations:

One server with one storage array

One server with two storage arrays

Two servers with one storage array

Two servers with two storage arrays

Software requirements

To use ODX, your environment must support the following:

The computer initiating the data transfer must be running Windows Server 2012 R2, Windows Server 2012, Windows 8.1, or Windows 8.

File system filter drivers such as antivirus and encryption programs need to opt-in to ODX. ODX is not supported by the following file system filter drivers:

BitLocker Drive Encryption

Files must be on an unencrypted basic partition. Storage Spaces and dynamic volumes are not supported.

Files must be on a volume that is formatted by using NTFS. ReFS and FAT are not supported. Files can be directly transferred to or from this volume, or from one of the following containers:

A virtual hard disk (VHD) that uses the .vhd or .vhdx format

A file share that uses the SMB protocol

The files must be 256В KB or larger. Smaller files are transferred by using a traditional (non-ODX) file transfer operation.

The application that performs the data transfer must be written to support ODX. The following currently support ODX:

Hyper-V management operations that transfer large amounts of data at one time, such as creating a fixed size VHD, merging a snapshot, or converting VHDs.

Copy commands in Windows PowerShell

Copy commands in the Windows command prompt (including Robocopy)

Files should not be highly fragmented. Transfers of highly fragmented files will have reduced performance.

Hyper-V Requirements

To use ODX with virtual machines on a server running Hyper-V, the virtual machines need to access storage from an ODX-capable storage array. You can achieve this by using any of the following approaches.

Store the VHD on an ODX-capable iSCSI LUN.

Assign ODX-capable iSCSI LUNs to the virtual machine’s iSCSI initiator.

Assign ODX-capable Fibre Channel LUNs to the virtual machine’s virtual Fibre Channel adapter.

Connect the host or virtual machine to an SMB file share on another computer that is hosted on an ODX-capable storage array.

Step 1: Gather storage array information

Before deploying ODX, gather the following information about the copy manager (operating system) of the storage array:

What is the name and version of the copy manager?

Does the copy manager support ODX?

Does the copy manager support an ODX operation across multiple storage arrays from the same vendor?

What is the default inactive timer value? This specifies how long the copy manager waits to invalidate the idle token after the timer expiration.

What is the maximum token capacity of the copy manager?

What is the optimal transfer size? This tells Windows how to send Read and Write commands that are optimally sized for the storage array.

Step 2: Validate file system filter drivers

To use ODX, validate all the file system filter drivers on all servers that are hosting the storage support ODX.

To validate the opt-in status of file system filter drivers, use the following procedure:

To validate file system filter driver opt-in status

On each server on which you want to use ODX, list all of the file system filter drivers that are attached to the volume on which you want to enable ODX. To do so, open a Windows PowerShell session as an administrator, and then type the following command, where is the drive letter of the volume:

For each filter driver listed, query the registry to determine whether the filter driver has opted-in to ODX support. To do so, type the following command for each filter previously listed, and replace with the name of the filter.

If the SupportedFeatures registry value equals 3, the filter driver supports ODX. If the value is not 3, contact the file system filter driver vendor for an ODX-compatible version.

Step 3: Establish a performance baseline

To establish a performance baseline, use the following procedures to disable ODX on the server and create a System Performance Report during a representative data transfer.

Disable ODX

To establish a baseline of non-offloaded data transfer performance, first disable ODX on the server by following these steps:

To disable ODX on the server

Open a Windows PowerShell session as an administrator.

Check whether ODX is currently enabled (it is by default) by verifying that the FilterSupportedFeaturesMode value in the registry equals 0. To do so, type the following command:

Disable ODX support. To do so, type the following command:

Create a System Performance Report during a data transfer

To record the baseline performance of data transfers, use Performance Monitor to record system performance during a represenative data transfer. To do so, follow these steps:

To create a System Performance Report

In Server Manager, on the Tools menu, click Performance Monitor.

Initiate a large data transfer that is representative of the workload you want to accelerate and that is within or between the storage arrays that support ODX.

Start the System Performance data collector set. To do so, expand Data Collector Sets, expand System, right-click System Performance, and then click Start. Performance Monitor will collect data for 60 seconds.

Expand Reports, expand System, expand System Performance, and then click the most recent report.

Review the System Performance Report, and take note of the following counters:

CPU Utilization (in the Resource Overview section)

Network Utilization (in the Resource Overview section)

Disk Bytes/sec (in the Disk section, under Physical Disk)

Step 4: Test ODX performance

After you establish a baseline of system performance during traditional data transfers, use the following procedures to enable ODX on the server and test offloaded data transfers:

Enable ODX

To enable ODX on the server, follow these steps:

To enable ODX

Open a Windows PowerShell session as an administrator.

Type the following command:

Verify ODX performance

After ODX is enabled, create a System Performance Report during a large offloaded data transfer (see the Create a System Performance Report during a data transfer section earlier in this topic for the procedure).

When you evaluate the performance of offloaded data transfers, you should see the following differences from the baseline that you created when ODX was disabled:

CPU utilization should be much lower (only slightly higher than prior to the data transfer). This shows that the server did not need to manage the data transfer.

Network utilization should be much lower (only slightly higher than prior to the data transfer). This shows that the data transfer bypassed the server.

Disk Bytes/sec should be much higher. This reflects increased performance from direct transfers within an array or within the SAN.

After you verify ODX performance, periodically create another System Performance Report during offloaded data transfers to confirm that ODX is still operating as expected. If any performance degradation is detected, contact Microsoft Customer Support and the storage array vendor.

You can use the following command in a Windows PowerShell session to display a list of storage subsystems that support ODX and use a storage management provider. This command does not display storage subsystems that use the Storage Management Initiative Specification (SMI-S) protocol. Get-OffloadDataTransferSetting | Get-StorageSubSystem

Appendix: Deployment checklist

Use the following checklist to confirm that you completed all the steps for the deployment.

Deploying Windows Offloaded Data Transfers Checklist

Check the Windows Offloaded Data Transfers prerequisites.