SAN Storage and SCVMM
This chapter has shown a lot of great functionality that is enabled through the use of
the Windows Server platform, but this does not mean that there are not investments
related to leveraging SANs. One of the biggest features when utilizing SANs is
offloaded data transfer, or ODX.
Typically, when any file move or copy operation occurs, the server becomes the
bottleneck in the process, and significant resources are used on the server as the
following occurs:
1 . The server reads a portion of the data from the SAN.
2 . The server writes that portion of the data to the SAN.
3 . Both steps are repeated until all data is read and written.This is a highly inefficient process, because the SAN is far more capable of natively
moving or copying data. ODX allows the SAN to move or copy data itself through the
use of a series of tokens, with each token representing a portion of the data at a point
in time. The token, instead of the actual data, is passed by the host to the SAN, which
then allows the SAN to natively move or copy the data.
To utilize ODX, the SAN must support it. The good news is that, by default, ODX will
be utilized automatically where possible. Consider the action of deploying a virtual
machine from a template. In the past, the Hyper-V host would copy the template to
the new location, resulting in large amounts of processor utilization on the host and a
copy operation that may take 10 minutes to perform. With ODX, the copy would use a
negligible amount of processor resources and the copy operation would likely finish in
about 30 seconds. File operations using Windows File Explorer, the command prompt,
PowerShell, and Hyper-V will all utilize ODX where possible.
System Center Virtual Machine Manager (SCVMM) 2012 R2 also utilizes ODX when
deploying a virtual machine from a template, but not in any other scenario. If ODX
cannot be used, SCVMM will use a regular file copy, and if that does not work, it will
resort to BITS.
While native ODX allows very fast copies of data because the SAN can natively
perform the copy/move directly, it also allows SAN vendors to improve the process.
For example, there is no reason the SAN actually has to copy the data. SAN ODX
implementations may use native capabilities such as just creating a pointer to the
original data. The NetApp implementation uses its sub-LUN cloning technology,
which creates two pointers to the same block of data, so the operation finishes almost
instantly because no data is actually being moved or copied. A write-forward snapshot
is then leveraged so that changes to the new copy are written to a new area. Even
without these additional optimizations, ODX provides a huge performance
improvement during large move and copy operations.