Failover replica, but keep old source as seed?

[glennsantacruz]

Consider this scenario: a WAN-separated production datacenter ( call it "DC-A" ), and failover datacenter ( call it "DC-B" ), with Veeam performing replication from DC-A to DC-B, for a few dozen VMs. To test a site failure of DC-A, we can perform a failover of each replica VM, then ensure all of them work as expected in DC-B. We can then simply failback and continue production within DC-A. All is good.

Now suppose we want to "swap" the datacenter roles ( make DC-B production, and DC-A standby/failover ). We can certainly perform a failover of the replicas, then commit them with a "permanent failover". But now we need to re-create a target replica in DC-A, to ensure that we are protected from DC-B failure. This involves seeding the newly-failed-over VM from DC-B to DC-A.

If we are lucky enough to plan downtime and make this a controlled datacenter "swap", we can ensure that we lose no data by simply shutting down the source VMs, and performing a 'final replica' to the target datacenter, followed by a permanent failover. At this point in time, both datacenters will have a 'mirror-image' of the VMs. It seems that Veeam should have a method for converting ( or reclassifying ) the original source VMs into replica targets.

Simply put, what I'm asking for is a "change roles" function on a replication job, or some workaround to achieve this.

[foggy]

Glenn, you will need to create new jobs with DC-B VMs as a source and map them to the corresponding VMs in the DC-A site.

[glennsantacruz]

Thanks for the response. I'm aware of what needs to be done in the current model. What I'm hoping for is a better solution -- think about it for a minute. At a controlled point of replica failover, we have a moment where both source and target VMs are the exact same. By manipulating a bit of metadata, these two VMs could switch roles and eliminate the need to re-seed. This would be an incredibly powerful feature.

[glennsantacruz]

Also - just to be clear ( or at least to clarify my current understanding of the product ), I'm describing a situation where I want to swap roles of a datacenter, beyond the scope of a simple test. If I understand the product, the "real failback" feature allows a similar goal : that we could failover the VM from DC-A to DC-B, run in DC-B for a period of time, then failback from DC-B to DC-A ( and Veeam would transfer whatever changes occurred at DC-B, back to DC-A ). This is a very nice feature, but seemingly would allow for only a brief period (depending on rate of data change) for DC-B to act as production. Also, I would anticipate that this "delta sync" would occur at failback time ( instead of periodically, like in a replication job ). So depending on the amount of time that DC-B ran as production, a failback could take a considerable amount of time -- since it has to perform the delta sync.

Based on my understanding, it looks like 'real failback' is engineered to handle a temporary role-swap of datacenters, not a permanent role-swap like I'm describing.

[foggy]

Yes, failback is a separate task implemented for a different scenario. Anyway, thank you for the feedback.

[glennsantacruz]

Perhaps we could achieve this by the following steps:
1) Shutdown source VM
2) Perform final replication to target
3) Perform failover, then make final ; target is now "new source"
4) Rename "new source" for production naming conventions ( to remove "_replica", for example )
5) Create new replication job for "new source"; use seeding with replica mapping of "old source"
6) Remove former replication job ( no longer needed )

If the above can be done via powershell scripting, then I may have the answer I'm looking for ; we could create a set of commands to achieve a "replication role swap". Do you agree? Do you see any obvious issues with the above?

[foggy]

This is just what I've suggested first - creating new jobs and mapping them to the original VMs in the source site. I believe you can somehow automate that process via PowerShell, however I'm not good at scripting. You can ask in the corresponding forum for help.

[veremin]

1) Shutdown source VM

It can be done via PowerCLI.

To Power off VM gracefully use the following line:

Code: Select all

Get-VM -Name “Name of your VM” | Shutdown-VMGuest -Confirm:$false

To hard power off:

Code: Select all

Stop-VM -VM $vm -Confirm:$false

2) Perform final replication to target

Code: Select all

Start-VBRJob -Job  $Job

3) Perform failover, then make final ; target is now "new source"

Code: Select all

asnp VeeamPSSnapin
$RestorePoint = Get-VBRReplica -name "Name of your Replication Job" | Get-VBRRestorePoint | ? {$_.VmName -eq "Name of your VM"} | Sort-Object CreationTime -Descending | Select -First 1
Start-VBRViReplicaFailover -RestorePoint $RestorePoint -Confirm:$False

4) Rename "new source" for production naming conventions ( to remove "_replica", for example )

Code: Select all

Get-vm –name “Name you want to change” |set-vm -name "Name you want to set" -confirm:$false

Please be aware that the abovementioned line will change only display name of the given VM, meanwhile all the corresponding files will stay untouched.

5) Create new replication job for "new source"; use seeding with replica mapping of "old source"

It’s possible to create a replication job using Add-VBRViReplicaJob method. There is also a way to enable VM mapping option:

Code: Select all

asnp VeeamPSSnapin
$Job = Get-VBRJob -name "Name of your Replication Job"
$JobOptions = $Job.GetOptions()
$JobOptions.ViReplicaTargetOptions.InitialSeeding = $True
$JobOptions.ViReplicaTargetOptions.UseVmMapping = $True
$Job.SetOptions($JobOptions) 

However, I don’t happen to know how to map the replication job object to the existing Virtual Machine, probably, such functionality doesn’t even exist .

6) Remove former replication job ( no longer needed )

Code: Select all

$Job = Get-VBRJob -name "Name of your replication job"
$Job.Delete()

Hope this helps.
Thanks.