With version 6 of Veeam Backup and Replication comes an entirely new architecture on how to set up WAN replication of your virtual machines. Their marketing propaganda claims HUGE improvements in WAN replication speeds because of this change. If you follow my blog you may have read one of the previous articles I wrote detailing some of these changes, but the short story is that Veeam can now replicate to a remote proxy at your DR site which allows them to optimize their WAN traffic without needing to inject a bloated agent into ESXi.
Being the skeptic that I am, I decided I needed to test this while doing an upgrade at a customers site. So remember this isn’t lab data, these tests were done with real data from a real VM and over a real WAN circuit.
The Test Scenario
- The main Site has a Veeam Backup server as well as a vSphere Cluster and EMC SAN
- The VM to be replicated is a domain controller that is already backed up with Veeam
- The DR site is 25+ miles away with a Point 2 Point fiber connection running at 17Mbps
- The DR site also has an EMC SAN with a single Cisco UCS server running ESXi
- Hyper IP is in place and properly configured with a 10 Mbps license (more on this later)
In order to get as close to apples to apples as possible, I created two Replication jobs. The first job would utilize the new Veeam 6 architecture where I replication to a Veeam Proxy at the DR site and let it push that data down into the VMDK file. The second job would be your standard replication job where I would force the local and remote proxy to the proxy at the main site (this essentially replications the “old way” of Veeam Replication.
On both jobs I told Veeam to seed the replication with the backup that it already had of the domain controller, this will ensure that the data being moved across the wire is exactly the same size in both tests. Well I should say that the “seeded” data is exactly the same, one of the new features of Veeam 6 is that you can seed across the wire from a previous backup, then after the seed has transferred Veeam will take a current snapshot of the VM and sync the seed up to the snapshot for an up to date copy at your DR site.
One last thing to note is that because we have HyperIP in place the bandwidth available will be 10Mbps (of our 17Mbps) and it should be “optimized” in both tests.
The results of the first replication job (the “new” way) were 2h18m47s, in that time frame we processed 33.9GB, of which 9.5GBwas transferred to our DR site.
Here is a screenshot of the results:
Replication test 2 results (the “old” way)… 2h47m20s and we processed and transferred the exact same amounts of data to the DR site.
And the screenshot:
As you can see Veeam has clearly made some improvements. In this case, Veeam 6 is 17% faster than the Veeam 5 style of replication. All thanks to a little Windows-based proxy at your DR site.
But what about HyperIP?
This next part really shocked me. This customer has HyperIP in place to optimize all of their Veeam traffic, and it was working great with Veeam 5 replication jobs. In fact, it was able to reduce the WAN traffic we were seeing by up to 30%. Before HyperIP was in place this customer had to have a 30 Mbps circuit to get their Veeam 5 replication jobs completed in their window, and as I stated they only needed a 10 Mbps HyperIP license to do the same work (in a shorter amount of time I might add).
Here is the traffic graph that I grabbed while I was doing these tests:
This graph is from the HyperIP console and shows two things: the Blue is the amount of data that Veeam needs to get to the DR site and the Purple line is the amount of WAN traffic that HyperIP is actually pushing across the WAN connection. The very spiky blue area on the far right is the second replication job (the Veeam 5 style) where we are replicating directly to ESXi. As you can see HyperIP is able to optimize that traffic by more than 80% (because Veeam is sending more then 80Mbps to HyperIP and it’s still able to only use 10Mbps of WAN bandwidth) that’s pretty awesome!
Now the blue area that is flat (to the left of the spiky area) is the traffic for the Veeam 6 style replication job (the one that took 30 minutes less time). What I have found is that HyperIP is not able to compress or optimize the Veeam6 traffic at all, aside from converting it to a UDP stream from a TCP stream. I even called HyperIP and they had me tweak a couple of the settings, and we still were not able to get any gain.
First off I would like to say that further testing still needs to be done. While it is clear to see that Veeam 6 replication is far superior to Veeam 5 replication, I now have bigger questions… like “Is Veeam 6 replication able to stand on its own, without the need of any WAN optimization?”. However to support that I will need to set up a lab where I can easily put HyperIP in and run a replication job, then pull it out and run the job again. Hopefully, I can get that done in January, but since it had been almost a month since my last post I didn’t want to hold this post up any longer.
Great article, we’re really enjoying V6 at our office and replication is much better. Started to get worried about you after not posting in almost a month. Glad you’re ok! Happy Holidays!
We get super busy around the end of the year and the start of the year. A lot of people trying to get stuff put in before Christmas and then after EOY new budgets kick in so people want their next year projects installed asap.
Awesome article Justin.
Apologies for my lack of understanding.
Some questions, I’ve read others have been implementing local and remote proxy servers. But from what you’re saying, that’s the ‘old’ method? Just to confirm, only 1 proxy is required at the DR site?
What happens if the head office burns down? How can you recover the VM from the DR Site without the Veeam Server? Can the DR proxy server be a VM? and is there any storage requirements for proxy servers (local or remote)?
Thanks in advance.
The number of proxies you have at the production and DR site depends on how much data you will be replicating. IF you main office were to burn down and you were replicating with veeam, then your VM’s would be in VMware format on an ESXi host at your DR site ready to power on, all you need to do is go there, login to vcenter console and power them on. The DR proxy CAN be a VM… this is what i normally make them btw. and the only storage requirements for proxies is that they need to be able to hold a copy of windows, They send all of the VM data to a VMware datastore or a backup repository (which can be local storage if its large enough, or a NAS)