Will Replication work across WAN

[Scalmie]

Firstly, please excuse the basic questioning, but I am fairly new to both VMWare and VEEAM.

We recently installed Backup and Replication V5 and I have a extremely basic Replication question. We currently run a Operations Center that houses 3 ESX servers with about 65 Vm's total. In addition we have a Recovery Site which has a single ESX server in the event of a disaster. Currently if we were to recover it would be a long process restoring all of our VMs from backup. If I'm thinking about this correctly, this is where Replication would help.

I want to replicate my "critical" vms over a 3 Mb wan at night when traffic is at a minimum. I was trying to find some resources that would help me with replication strategies and give me an idea of how much data would be transferred during the replication process. I would assume we would need to bring the ESX server from the Recovery site to the Operations site for the initial Replication, correct?

Any direction would be highly appreciated.

[foggy]

Yes, seeding the initial backup is a good practice. Though I think its much easier to use some kind of external disk than moving the whole server between sites.
Please search this forum for WAN replication for the numerous existing discussions on slow link replication strategies. Thanks.

[J1mbo]

An idea of the amount of data that will be transferred can be sought by running the VMs in questions with snapshots for some period of time. Obviously be careful when doing so, I would suggest one VM at a time, and make absolutely sure there is no possibility of running out of disk space!

Remember 3Mbps is about 340KB/s only.

[Natoli]

I run replication as backups across a 10Mbps WAN.
Here are the results of replication as an example.

Total VM size: 512.04 GB
Processed size: 512.04 GB
Processing rate: 17 MB/s
Backup mode: NBD with changed block tracking
Start time: 8/31/2011 6:00:37 PM
End time: 9/1/2011 2:50:10 AM
Duration: 8:49:32

My WAN connection is maxed out for the duration of the job.
My VM is a file share server with about 40GB free space remaining, and comprised almost entirely of small files.

[BrettM]

Natoli, could you be a little more specific about your set up? (I'm also rather new to Veeam)
You say "replication as backups", does that mean you are using Veeam replication with multiple restore points to a remote ESX(i) box? Or are you instead using Veeam backup to a remote target? Also, the metrics you provided, I assume that 9 hrs is for a full replication?

And for any Veeam support rep, I'm a bit confused about exactly what is happening where. Inline source dedupe and compression means that subsequent incremental replications shouldn't take long to get the incremental data across a WAN to a remote target, but Veeam documentation also states that a replication job uses the reverse incremental "backup" method, which means the full backup on the target gets re-created/re-written/data is merged into it, right? Doesn't that take a long time if it is done across a WAN, since the server doing the synthetic reintegration (veeam server) is not located in the same place as the target data? I assume backups would work the same way, depending on where the source, the backup server, and the target are located.

[foggy]

Brett, this is why we do recommend pull replication for ESXi target. In case of a full-blown ESX target, Veeam B&R puts a small temporary agent to the ESX host that takes all the job upon itself. This is impossible for ESXi target, so in this case we strongly recommend to install Veeam server in the target site to take care of all resource-intensive processes.
Thanks.

[Natoli]

Ugh, typed up a response and the forum timed me out before I hit submit.

My example there is an "incremental" replication.
10Mbps x 9hr ≈ 40GB

My Veeam server is a VM running on the source side.
Source is ESX 4
Target is ESX 4

Processing mode = NETWORK
Replica disks = As original (thick)
Deduplication enabled (level Optimal)
Optimized for WAN target
Use changed block tracking data enabled
Number of restore points = 1

By saying replica as backup I'm referring to what sounds like the same setup you are aiming for. Instead of keeping backup archives, which require a restoration process, I keep a replication to power on in event of disaster.

I have another job that runs as Virtual Appliance mode. I think the results are about the same due to the WAN link being the bottleneck.

[mayojs]

Scalmie,

Natoli's calculation of 10Mb/s * 9 hours ~ 40GB assumes 100% efficiency of TCP.

You will find this hard to achieve even on "perfect link" due to protocol overhead/: TCP also views dropped packets as congestion and backs off the send rate before ramping it back up. Add latency which restricts the amount of traffic in flight and on some links you will be lucky to see 30-50% utilisation.

We have worked with Veeam BU&R to maximise WAN throughput utilising HyperIP, from NetEx Software. HyperIP terminates the TCP connections locally and uses its own robust protocol to stream data across the link and retransmit dropped packets. We use 90% efficiency figure on WAN for sizing but often achieve more. HyperIP can also compress the data before transmission for greater application throughput if applicable, or offload the compression from the application server.

At 3Mb/s the estimated WAN throughput will (@90% efficiency) will be 1.2GB/hour so bear this in mind when calculating data volumes / time.

HyperIP is available for 30-day eval with unlimited (WAN up to 800Mb/s) keys. We have marketing bundles available for Veeam users at 2Mb/s. Best Practices document for HyperIP + Veeam BU&R can be found here: http://www.netex.com/index.php/download_file/view/277

John Mayo, NetEx Software

[J1mbo]

The time will depend enirely on the change rate. Also in my experience occasionally CBT seems to go mad and, whilst all logs showing it's working just fine, the replication time approaches that for a full VM replica. Hence I put large VMs in there own jobs to minimise the impact of the same, as two jobs can run concurrently no problem (and in my case improves the overall line utilisation).