Replication from HO to DC

[jumbo22]

Hello there,

I am looking at setting up replication to occur between a Head Office and datacenter for mission critical VM's hosted on VSphere 5.

We've been told by the guys that host the infrastructure at the DC that we cannot use the same ip range that we use at the HO.

Will replication work if routing has to occur between the two sites.Bearing in mind that we only have a 0.6Mb upload speed?

Thanks in advance

Simon

[Vitaliy S.]

Will replication work if routing has to occur between the two sites.Bearing in mind that we only have a 0.6Mb upload speed?

You do not need to have similar IP range in the HO and DR site. Provided that you can access DR site from the HO it should work, just do not forget to perform initial VM seeding in order to transfer VM changes only through the WAN link.

[jumbo22]

Thanks for getting back. I've been away for a while hence late response. Do you know of any customers using WAN replication over such a slow link?

[foggy]

Searching through the forums, I've been able to find a few threads with customers reporting <1Mbps link speed.. From Veeam B&R perspective, speed is not the highest concern, what is more important is that the connection should not actually drop.

[jumbo22]

Thanks Foggy

Do you know of any white papers/documents on configuring WAN replication, apart from whats in the user guide?

Thanks again

[foggy]

We do not have any best practices document so I would again advise to search this forum for "offsite+replication+best" for what other customers do while implementing their WAN scenarios.

[Gostev]

Best practice for v6 WAN replication is really short.
1. Make sure to have at least 1 proxy in both source and DR site. You may want to force the job to use those (instead of leaving it in Automatic).
2. Make sure to specify digest repository located in the source site.
3. In the advanced job settings, set storage optimization to WAN.
4. In the advanced job settings, set traffic compression to Best (unless your WAN link is quite fast, then leave on Optimal).
5. Use replica seeding or replica mapping whenever possible, avoid full sync over wire.
6. Consider utilizing traffic throttling functionality, if required. Otherwise, jobs will eat all the bandwidth they can reach to.
7. Test your replicas periodically.

[dellock6]

8. Use it!

[jumbo22]

[merged]

Hello all,

I will be attempting to configure replication to occur over a slow WAN link between HO and the DC (vpn using 1Mb link, DNS is working between the two sites)

The current configuration is:
Two ESXi5 nodes running Essentials Plus in a cluster with Veeam 6 running on a VM

I will build the third ESXi node locally to the other two, I will then:

1. Configure ESXi node 3 with local management ip address and local storage
2. Join the third node to the VCenter, but not the cluster
3. Build a Windows 7 VM on the third node
4. Add the Windows 7 machine to Veeam
5. Deploy the Backup Proxy agent to the Win 7 VM
6. Create a replication job for those VM's on nodes 1 and 2 to point to node 3
7. After the first successful replication, suspend the job
8. Move the third node to the DC site
9. Re-IP the third node and Win 7 VM (different subnet at DC)
10. Test DNS
11. Restart the replication job

Shared storage at the HO is iSCSI
Storage at the DC will be local

Can anyone see any problems with this approach?

Thanks in advance

[foggy]

Simon, I believe your scenario should work, just take into account the points Anton has outlined above.

[jumbo22]

Thanks Foggy

I'l be sure to cover off Gostev's points.

I'm right in saying that I will not have to replica seed as both source and target will be local for first run or two of the job?

[foggy]

I'm right in saying that I will not have to replica seed as both source and target will be local for first run or two of the job?

Yes, the job should just continue running normally after changing host's IP.

[jumbo22]

And will it be safe to re-ip the Windows 7 VM, that acts as the backup proxy, at the same time?

[foggy]

Yes, if you've added the server to the Veeam console by its name rather than by IP (also the case with the host, of course). Also make sure the right proxy is picked up (consider selecting the proxies manually for the job).

[jumbo22]

Thanks for all your replies, foggy. I'll let you know how successfully it works in the next two days

Cheers

[jumbo22]

Hi Foggy,

I've kicked off the local replication using the third node as a target and this seems to be running fine

Tomorrow, after the replication jobs have completed and I move the third node to the DC, will it be fine to modify the replication jobs for WAN replication without breaking it?

Thanks

[foggy]

Simon, if you are talking about changing the storage optimization setting to WAN, then this will require the full job run to take effect (sorry for not mentioning it earlier ). So you'd better either perform this change before moving the host to DC or simply create a new job with the required settings and map it to the existing replica VM.

[itdirector]

I am a little confused about the #3 & #4 below. I setup two test replications jobs.
- Job 1: Kept the default values for Compression & Storage Optimization : Optimal & Local target
- Job 2: Changed to Best & WAN target.

Then ran Job 1 & Job 2 three times each, over a 3 day period, with two live vSphere ESXi 5 Windows 2008 R2 servers.
- The transfer Processed, read & transferred data for all jobs are basically the same (Job 1 & 2). I thought setting the "Best compression" & "WAN Target" would significantly reduce the amount of data transfered (Transferred data) (this is to a DR site). Am I looking in the wrong place to see how much actual data was transfered across our line?

Thx

Best practice for v6 WAN replication is really short.
1. Make sure to have at least 1 proxy in both source and DR site. You may want to force the job to use those (instead of leaving it in Automatic).
2. Make sure to specify digest repository located in the source site.
3. In the advanced job settings, set storage optimization to WAN.
4. In the advanced job settings, set traffic compression to Best (unless your WAN link is quite fast, then leave on Optimal).
5. Use replica seeding or replica mapping whenever possible, avoid full sync over wire.
6. Consider utilizing traffic throttling functionality, if required. Otherwise, jobs will eat all the bandwidth they can reach to.
7. Test your replicas periodically.

[foggy]

Just to be on the same page, do you run both jobs against the same VMs? And have you performed the full job run after changing the settings on the second job? If you are doing everything right, the amount of transferred data should be less for the second job.

[cackerson]

We had a slow link to our DR site. It was only 1.5 mbps. I setup replication, seeded the VMs are and followed all the recommendations about proxies etc. I throttled the link to 666 kbps at first and had very little success replicating. I was replicating machines with large amount of changes like Exchange Server (3-5 GB). It would never work. I increased the throttling to 1000 kbps and was able to get my machines with smaller amount of changes like my Domain Controllers to replicate (200 - 400 MB).

This month we upgraded the link to 3 mbps. I seeded the VMs with large changes like Exchange and set the throttle to 3000 kbps. I was able to replicate successfully over the weekend. 4 servers with (5 - 7 GB) of changes all replicated successfully.

I know Veeam says that there is no minimum requirement for bandwidth, but for us we needed more bandwidth to replicate our servers that have a large amount of changes.

[dellock6]

Well, you can say at the end that your needed/desired RPO is your bandwidth limit. Veeam itself can operate with low bandwidth, but if your RPO is let's say two hours, you cannot replicate a VM taking 8 hours to replicate.
Exchange servers are maybe one of the worst use case: their information store is accessed with really random patterns, and in this way CBT marks many blocks as changed, so Veeam has to deal at the end with a huge daily increment.

Luca.

[jumbo22]

Just wanted to let Foggy know that replication was successful over a 768kbps connection. The VM's did take a hours to replicate but all VM's now have successfully replicated! The customer is now looking at upgrading his link to something faster (I used the seed from backup method by the way).

Apparently it is advisable to remove the tick 'seed from backup' after the first replication has completed as otherwise Veeam database corruption may occur. Can anyone substantiate this?

Cheers again

[Vitaliy S.]

Hi Simon,

Database cannot be corrupted because of that, and btw, there is no need to uncheck "seed from backup" option, as on the following scheduled run job will ignore this option and will perform an incremental pass regardless.

Thanks!

[XIANLEE78]

Does anyone know if and or how disk provisioning affects replication in regards to deduplication and data to be transferred?

Thin vs Thick, which replicates faster? or which replicates with better deduplication or lower changed data to be transferred.

[Gostev]

No difference.