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.