Sizing a Hyper-V Replica Solution
After understanding the capability of Hyper-V Replica, the first question from my
clients is, “What is the impact on my storage and network, and what are the
requirements?” This is a valid question and is fairly complex. The answer ultimately
boils down to the rate of change on the storage of the virtual machines that need to be
replicated, because Hyper-V Replica works by replicating the changes. The higher the
rate of change to the storage of the virtual machine, the greater the size of the Hyper-
V Replica log (HRL) files and the more data that needs to be sent over the network
from the primary to the replica.
You also need to consider the impact on storage, both on the primary storage hosting
the primary VM VHDs, which also store the HRL files, and on the replica storage
hosting the replica VM that receives the update files and then has to merge them into
the replica VHDs as well as maintain snapshots if configured. It is not possible to
configure the HRL files to be written to different storage than the actual VHD files,
which means that the storage containing the VHD will incur whatever storage I/O is
associated with the log files.
There is a negligible impact for processor and memory, but it is generally not
considered as part of your Hyper-V Replica planning, which is focused on the network
and storage. The network is fairly simple, and the amount of network bandwidth
relates directly to the rate of change of the virtual machine. While compression does
decrease the amount of network traffic (and incur some processor overhead) by
compressing all of the zeros in the data, there aren’t really any additional
considerations. The amount of network traffic relates directly to the rate of change. If
you need a higher rate of network compression, one option is to leverage WAN
optimizers such as those from Riverbed, which will provide greater network
bandwidth savings.
If you need to throttle the amount of bandwidth used for Hyper-V Replica, you should
use network quality of service (QoS). QoS could be based on the target subnet
(assuming that the only traffic to the target subnet is Hyper-V Replica traffic), or you
can throttle based on the destination port, which is possible because Hyper-V Replica
uses port 8080 for the transmission of the log data. For example, here I limit the
replica traffic to 200Kb:
New-NetQoSPolicy "Replication Traffic to 8080" -DestinationPort 8080 `
-ThrottleRateActionBitsPerSecond 200000
The storage consideration is more complex, specifically on the replica side, where the
changes have to be merged into the replica VHDs. On the primary side, the additional
storage required to host the log files is equal to the rate of change, and the additional
I/O impact is less than 1.5 times than that of the IOPS of the workload, so less than 50
percent additional I/O. This is achieved by the use of a 32MB memory buffer to track
writes to optimize the actual writes to the log files.