Offloaded Data Transfers (ODX) Introduction
QUADStor storage virtualization software now supports offloaded data transfer (ODX) technology. Offloaded data transfer was introducted Windows Server 2012 and Windows 8 which helps in reducing network load by offloading a copy operation to the storage array. From a SCSI terminology point of view this is an XCOPY (actually an XCOPY-lite) operation and is similar in many ways to the XCOPY (Extended Copy) operation as a part of vSphere Storage APIs - Array Integration (VAAI). While there are differences at the SCSI protocol level and from an array implementation point of view, the overall requirement remains the same - offload certain IO operations to the storage array
The following links provide a deeper understanding of ODX and the deployment scenarios
Benefits of ODX
Similar to vSphere Storage APIs - Array Integration (VAAI), offloading copy operations to the storage array brings down the network utilization to almost zero. Network is utilized by the host only to instruct the array of the source and destination locations of the copy and to inquire the status of the copy operation.
Also with the storage array aware of the copy operation, many optimizations can be made. For example in QUADStor's implementation, if the source and destination is the same VDisk or VDisks belonging to the same pool, the copy operation is usually a simple increment of a reference counter in a metadata, therefore avoiding reading the source blocks specified in the copy operation and writing the blocks to the target blocks in the copy operation. Why ? Because eventually the target blocks will be duplicate copies of the source blocks. So not only are we saving on network bandwidth but also on reads from disk and writes to disk.
There are certains restrictions with QUADStor's current implementation of offloaded data transfers as listed below
- The source of the copy and the destination of the copy need to have the same sector size. So if the source is a VDisk with a 4k sector size but the destination of the VDisk has a 512 byte sector size, the copy operation will be terminated and the host will revert back to the non-ODX copies for that copy operation
- With full support for 4K drives in Windows Server 2012 and Hyper-V 3.0 (see Microsoft support policy for 4K sector hard drives in Windows), the recommendation is to use VDisks with the default block/sector size and avoid the 512e emulation mode altogether
Additional statistics related to offloaded data transfers are available as seen in the figure below
Populate Token Size indicates total read size of the copy operation and Write Token Size indicates the total write size of the copy operation. In the statistics described the source and destination VDisk for the copy operation were the same.