In the article Finn explains how this feature is designed for low bandwidth, high latency networks that small and medium enterprises use for inter-site replication.
The HRL (Hyper-V Replica Log file) replay mechanism is actually quite clever; it replays the log file in reverse order, and this allows it only to store the latest writes. In other words, it is asynchronous (able to deal with long distances and high latency by write in site A and later write in site B) and it replicates just the changes.
Finn goes on explaining how, managin this kind of lines, a business can lose between 1 second and 1 hour of data.
Hyper-V Replica works in the following cluster environments:
- Standalone host to cluster
- Cluster to cluster
- Cluster to standalone host
and provide 3 replication methods:
- Over-the-wire copy
- Offline media
- Use a seed VM on the destination site
The article concludes with one of the focal points of data replication:
The Big Question: How Much Bandwidth Do I Need?
Ah, if I knew the answer to that question for every implementation then I’d know many answers to many such questions and be a very rich man, travelling the world in First Class. But I am not.
There’s a sizing process that you will have to do. Remember that once the initial synchronisation is done, only changes are replayed across the wire. In fact, it’s only the final resultant changes of the last 5 minutes that are replayed. We can guestimate what this amount will be using approaches such as these:
- Set up a proof of concept with a temporary Hyper-V host in the client site and monitor the link between the source and replica: There’s some cost to this but it will be very accurate if monitored over a typical week.
- Do some work with incremental backups: Incremental backups, taken over a day, show how much change is done to a VM in a day.
- Maybe use some differencing tool: but this could have negative impacts.