DR Site, difference between Network Mapping and Re-IP

[DusanM]

Hi everyone.

I am working on DR site configuration.
Connection between our production and DR site is through site to site VPN. So they are on 2 different subnets.

I am using Veeam and replication jobs to backup VMs from production to the DR site.

Replication works just fine, but I am trying to figure out how to resolve DNS and network mapping.

When configuring Replication job, there are 2 options, Network Mapping and Re-IP. What is difference between those 2? As far as I can understand, they kind of do the same job. If my VM has 10.0.5.25 address on production side, it will have 192.168.0.25 on the DR site. Do I need both of those options enabled or I can use only one of them?

Below is explanation from Veeam Help center about Network Mapping and Re-IP Rules:

Network Mapping
By default, a replicated VM uses the same network configuration as the original VM. If the network in the DR site does not match the production network, you can create a network mapping table for the replication job. The table maps source networks to target networks.
During every job run, Veeam Backup & Replication checks the network configuration of the original VM against the mapping table. If the original VM network matches a source network in the table, Veeam Backup & Replication updates the replica configuration file to replace the source network with the target one. The VM replica is then re-registered (for legacy VM replicas, not snapshot VM replicas). Thus, network settings of a VM replica are always kept up to date with the DR site requirements. In case you choose to fail over to the VM replica, it will be connected to the correct network.

Re-IP Rules
For Microsoft VMs, Veeam Backup & Replication also automates reconfiguration of VM IP addresses. If the IP addressing scheme in the production site differs from the DR site scheme, you can create a number of Re IP rules for the replication job.
When you fail over to the replica, Veeam Backup & Replication checks if any of the specified Re-IP rules apply to the replica. If a rule applies, Veeam Backup & Replication mounts VM disks of the replica to the backup server and changes its IP address configuration via the Microsoft Windows registry. The whole operation takes less than a second. If failover is undone for any reason or if you fail back to the original location, replica IP address is changed back to the pre-failover state.

[veremin]

Network Mapping: Source VM is connected to virtual network VMNet1, Replica VM is connected to virtual network VMNet2
Re-IP: Source VM has IP 172.17.50.1, Target VM has IP 172.17.53.1

[DusanM]

Thank you v.Eremin. Looks like that I really need only Re-IP. That will change the IP address, default gateway and DNS servers.

I played with this today and this is what I found that will cause a problem for me:

When I set the IP table when configure replication job, the IP addresses get changed only if I run a failover plan. If I start a VM manually from VMWare vCenter the IP addresses do not get changed.

What I would like is to have VMs shutdown and ready on the DR site, with network configuration for the DR site subnet without needing to run the failover plan. In other words, I would like that VM on the DR site has DR site IP configuration all the time. Is this doable? I mean, in case of disaster, I might not have access to the Veeam server to run the failover plan.

Any idea about how to address this?

Thank you,
Dusan

[blithespirit]

When you configure Veeam to handle replication you configure your network to be managed by the failover job. if you start the vm with vSphere you are just powering it on without control so no remapping will take place, in effect you are just powering up a vm. The script to re-ip is a veeam script which runs after the vm is powered on and controlled by VBR. You would need to have an executable script call within your VM to re-ip in your instance and a mechanism to call it.

[veremin]

Any idea about how to address this?

Have you thought about deploying backup server at DR site and controlling everything from it? Should disaster strike your production site, you would be able to execute required procedures (failover, failback) from remote backup server without any issues. Thanks.

[DusanM]

Thank you guys for your help and patience. I am getting there.

I figured out Failover plan. It works just right.
So I have a failover plan. In the plan I can add more than one VM. In case of disaster, I activate the plan, the VMs start on the other side with new set of IP addresses. When I want to fall back to the production side, I have to do that VM by VM, I cannot do multiple VMs at the same time. I do it from Replicas view. I tested this, works great. So far so good.


v.Eremin, I did not think about backup server at the DR site until 2 days ago. Now I see that I need some form of it at the DR site.

Do you mean to move my Veeam server to the DR site and run everything from there or to have 2 Veeam servers, one on the production side handling everyday backup jobs and one at the DR site handling only replication and failover plan?

[veremin]

Both approaches would work fine. The one with single server would have less orchestration complexity, in my opinion. Thanks.

[DusanM]

Thank you v.Eremin.

I saw this post where you discussed those options: veeam-backup-replication-f2/replication ... 36326.html


Would I need another Veeam license if I have second Veeam server at the DR site?

[foggy]

No, provided it backs up/replicates VMs residing on the same ESXi hosts.

[DusanM]

Thank you guys for your help. Here is an update and question:

I have configured a Veeam server in the DR site. That server does only replica jobs and failover plans. Veeam server at the production site takes care of onsite and offsite backup. It has nothing to do with DR plan. I guess down the road I might join those 2 servers and have only one server at the DR site. Both servers use the same license key.

I tested a failover plan, works so good, almost hard to believe. Veeam software takes care of the servers IP configuration (production site and DR site are in different subnets), changes servers IP, default gateway, DNS servers.
Failover plan brings the servers at the DR site up and changes IP addresses. Bringing servers up initiates changing servers IP addresses in the DNS server (Microsoft feature, Veeam has nothing to do with the DNS server), so we can still resolve them by the FQDN either from the production or DR site.

Now I am testing failback plan. I am testing with only one small server (60GB). But it takes so long. At this point, after over 2 hours, only 25% done. Good thing is that the server is still up, Veeam will bring it down and finish failback once it finishes “Calculating original signature Hard Disk 1”. task.

Is this normal behaviour, is there a way to speed up this process?

[ChrisGundry]

I would suggest having only 1 Veeam server, in the DR site. Have another server act as a Veeam proxy server in the production site, that will be much easier to manage as you can do all jobs from the single server on the DR site.

Your 2nd issue. Yes, it will be slow. It must read all blocks on the DR replica VM to check changed blocks so it can replicate only those blocks back. The only way I know of to improve it is to increase storage performance at the hardware level, or reduce the load on the storage to improve performance, ie shut off other workloads etc.

[foggy]

Dusan, failback should be faster on v9.5 Update 2 (due to ability to use CBT), unless you are already using this version.

[DusanM]

Thank you guys.

We are on version 9.5 Update 1, I will try with Update 2. We still have to figure out and test more the failback plan. At least we should have an idea how long it would take.

About one or two Veeam servers, check out this scenario.

DR site gets compromised, and you disconnect it from the production.
Further, you have to restore a file or VM on the production side. You will need a Veeam server to be able to accomplish that. Or Veeam console is enough?

[foggy]

Veeam B&R console cannot act without the backup server, so you would need it as well.

[yasuda]

Would this work?

Power off the backup server at the DR site.
Keep copying configuration backups to the DR site
If primary site is down, power up the DR backup server, restore the latest configuration, and go from there

[foggy]

Yes, having a "cold" backup server in DR and making periodic configuration backup is a valid approach.