Replication Advice

[pugman]

I have a scenario I need help with to insure I can do this:
I have created a lab that replicates one of our remote locations (Site B) with a different subnet than the remote site (for obvious reasons).It is connected to my headquarters LAN (Site A) with a Cisco router using 100 Mbps Ethernet card. I have a Veeam host server that is on this lab VM host. My goal is to replicate 13 VMs to the remote site B. The lab has worked fine. My settings are optimized for “LAN target”. I am replicating about a total of 630 GB on 3 replication jobs. With the changes on the first job only taking about 3 minutes to complete(1 VM), second job taking about 30 minutes(3 VMs), and the third job taking about 2-4 hours(8 VMs). I am replicating every night.
Ok so now I want to take my VM Host with the data store to site B. I know I could do seeding but since I have this complete lab ready I want to just move it to the site and change the IP address of the host then migrate the VMs to a different data store that is already at site B and change the parameters on the replication jobs back at site A to reflect the changes made. The load on the longest job is as follows: Source 27% > Proxy 1% > Network 3% > Target 92%. My WAN connection to site B is currently only 1.5 Mbps but will be 4.5 Mbps in about 20 days. Is this a feasible scenario and what issues might I encounter?

[Vitaliy S.]

Hi Phillip,

Assuming I have understood you correctly, your scenario would work just fine. If you have ESX(i) Server/vCenter Server added to Veeam B&R console by their hostname, then changing the IP address wouldn't affect your existing replication jobs. Also make sure you have two proxy servers at both sites, A and B, to make your replication jobs work over your WAN link.

Thanks!

[rbrambley]

Ok so now I want to take my VM Host with the data store to site B. I know I could do seeding but since I have this complete lab ready I want to just move it to the site and change the IP address of the host then migrate the VMs to a different data store that is already at site B and change the parameters on the replication jobs back at site A to reflect the changes made.

I 100% agree with Vit as far as how Veeam connects to your host after the move, but I have some more for you think about.

Since Veeam works with the objects as they appear in the VMware API, you might introduce a scenario where you change those ids of the VMs / hosts / datastores, etc in VMware and that would confuse Veeam which might still be looking at the old ids from before the move. For example, do you have to remove your host from a vCenter or between Clusters? Maybe even add it again to a second (or even the same) vCenter? That will remove that host and all of it's API objects from the VMware dbase, and then when added again those are brand new objects with new ids. Moving the VMs to a different datastore could also change the object path from Veeam's perspective.

Then again, it might just work fine. It's tough to get a full picture of your VI, replication job settings, and all from this post. Just be sure to think about your jobs from the vantage point of the objects in the vSphere API.

Good news is all you'll have to do is delete the old jobs and rebuild them as new ones if it fails. You can seed to the existing VMs, as you already know.

Vit's point about needing 2 proxies is very important as well. More here

[pugman]

Thanks for the responses. Vitaliy, I am assuming you are saying two proxies, one at site A and one at site B and not two at each site. Correct? Thanks again and the software is truly spectacular!

[Vitaliy S.]

Yes, you got it right.

[johndoe123123]

It is connected to my headquarters LAN (Site A) with a Cisco router using 100 Mbps Ethernet card.
<SNIP>

and the third job taking about 2-4 hours(8 VMs).
<SNIP>
My WAN connection to site B is currently only 1.5 Mbps but will be 4.5 Mbps in about 20 days
<SNIP>

A T1 (1.5 megabit) can push roughly 13gb/day if running 24x7

My suggestion would be to make sure you won't have problems bandwidth wise, and instead that your only issues are the time it takes to process the changes.

Since you have a Cisco router in the middle, this is easy to test. Simulate a 4.5 megabit circuit in your lab by adding this configuration:

policy-map map_police_4_5m
class classs-default
police cir 4500000
exceed-action drop

int FastEthernet0/0 <-- This should be the interface (Eth) facing the backup lab network.
service-policy input map_police_4_5m
service-policy output map_police_4_5m

[pugman]

Thanks johndoe. I was wanting to do this before I moved it. Will configure today and rerun the jobs. Will update results.

[pugman]

Made changes on the router and it did effect the Network load as you can see but still very much acceptable.
Before change: Source 27% > Proxy 1% > Network 3% > Target 92%
After bandwidth change: Source 20% > Proxy 27% > Network 45% > Target 68%
Also I did a VMHost name change from IP address to actual Host name based upon what Vitaliy recommended so I believe the jobs are are processing a liitle more overhead until the second replication takes place. It looks like the network is not going to be the problem just the source or target and I might be able to tweak that by adding a Veeam B&R server at site B along with another proxy at both locations to help with processing but I am not sure on this point. Any insight would be appreciated.

[Vitaliy S.]

It looks like the network is not going to be the problem just the source or target and I might be able to tweak that by adding a Veeam B&R server at site B along with another proxy at both locations to help with processing but I am not sure on this point.

To have the maximum processing rate possible over the WAN link you have to deploy two proxies on both ends, that would help.

[Vitaliy S.]

Phew, that was my 6k post!

[pugman]

Congrats on 6K! Keep up the good work. I appreciate the help.

[pugman]

Ok so I installed two proxies at source and target and now it is looking better. Here are my loads for each job:
Replication Job 1-Load: Source 38% > Proxy 9% > Network 73% > Target 2%
Replication Job 2-Load: Source 34% > Proxy 8% > Network 75% > Target 2%
Replication Job 3-Load: Source 46% > Proxy 9% > Network 66% > Target 2%
Replication Job 4-Load: Source 18% > Proxy 8% > Network 93% > Target 1%
Bottleneck is network which, I am assuming, is where it should be since I am replicating over the 4.5 Mb WAN. My new question is this:

I want to move the jobs to the target location(they were created at the source) so I can utilize failover, etc. at the DR site. Since we are a small enviroment I only have one Veeam Server at each location. My thought was to copy the database from the source server to the target server then delete the Backup and Surebackup jobs(they will copy over when I copy the db) off the restored db at target site. This would leave only the Replication Jobs on that server then delete the Replication Jobs off the source server. How does this sound or is there another way to do this? Would the jobs continue to work without having to do another full replication?

[Vitaliy S.]

Yes, your jobs will continue running normally, however you will NOT be able to manage these backup server through the single Enterprise Manager installation. Using database clones will create duplicated records and that will mess everything up once you add two Veeam B&R servers to the Enterprise Manager.

If you want to move replication jobs and keep the original server in place, just create new jobs on your DR Veeam Server and use replica mapping capability to continue running incremental job runs. For more info on how to do that please take a look at our User Guide (pages 47, 123). Thanks!

[pugman]

How cool is that! Much easier. Thanks for the direction. BTW I did move the replica VMs to a different datastore at the target, changed the settings on the replication jobs at source to reflect the new datastore at target and the jobs are taking a long time (still has not completed from last night) so I think as rbrambley pointed out that any change in VMWare objects will cause jobs to drag. Any major change like this should be remapped using what you suggested on User Guide (pages 47, 123). Thanks for all the help. I believe this will finish up my project. Will try it today.