Offloaded Data Transfer (ODX) is a feature that was added to Windows Server 2012 and later versions to enhance the performance of compatible storage area networks (SANs). Similar to vStorage APIs for Array Integration (VAAI) in VMware, ODX speeds up the movement and creation of blocks and files, which makes it a great feature to have in a virtualized environment. In this article, I will explain ODX, the system requirements, and an unfortunate issue that many SAN customers have experienced.
What is Offloaded Data Transfer (ODX)?
Imagine you have two servers that are connected to the same SAN, where both servers are using it for file storage. You want to move or copy a file from Server1 to Server2. At a high level, this is what happens:
Server1-> reads the file from the SAN a bit at a time
Server1-> sends the file, a bit at a time, to Server2 over the LAN
Server2-> sends the bits of the file back to the SAN to be stored.
It seems like a waste to send a file over the relatively latent LAN to transfer it from one LUN to another LUN on the same SAN. What if we could cut out the middleman? That’s what ODX does!
Server1 coordinates with the SAN and Server2 via a token handover. The SAN takes up the load and performs a file copy without sending the file over the LAN. This greatly speeds up data movement between servers on the same SAN.
There are other scenarios where ODX offloads data transfer from Windows to the SAN. What if a server needs to copy a file? That file copy is offloaded to the SAN. What if a Hyper-V host needs to create or extend a newly fixed virtual hard disk? That can take quite some time, but not if ODX offloads the zeroing out process. And what if you want to convert VMware virtual machines into Hyper-V virtual machines? ODX will help, even more so if you happen to use NetApp MAT to do the work.
The first and most important component is the SAN. You must have a SAN that is certified for Windows Offloaded Data Transfer and is connected to your servers using one of the following:
You can copy between different arrays if the copy manager for the storage arrays supports cross-storage array ODX. In addition, the storage arrays must be from the same vendor.
Your physical machines that are performing the copy must be running Windows Server 2012 R2, Windows Server 2012, Windows 8.1, or Windows 8.
Any file system filter drivers must opt-in to ODX or doesn’t prevent ODX. Non-supporting filters include Windows Server data deduplication and BitLocker. Pay attention to data replication and anti-malware products. The volumes must be unencrypted and Storage Spaces is not supported. The volume must be NTFS, and ReFS is not supported.
Note that you can build a Scale-Out File Server (SOFS) using a SAN that offers ODX. The SOFS nodes are connected to the SAN using legacy data protocols, and application servers connect to the SOFS using SMB 3.0. Data movement to the SAN can be optimized using ODX by the SAN.
Regarding the files — they must be 256 KB or larger to be eligible for optimization. Highly-fragmented files will naturally hurt performance.
Enabling and Disabling ODX
ODX is enabled by default and will be used by Windows Server, including Hyper-V, when compatible storage and eligible operations are discovered. This, unfortunately, has led to issues with allegedly compatible SANs, such as HP’s 3Par that could cause VHD/X data corruption, where this issue should be resolved with up-to-date installations.
You can disable ODX with a registry edit with the following PowerShell cmdlet (note that a value of 1 disables ODX):