Replication for migration methodology

[bproteau]

I'm trying to deterine a methodology for cutovers from one datacenter to another. We are using the same IP for source and destination so we can't have them powered on at the same time. My thought was to:

(a) Decrease the replication job interval as I get closer to the cutover (down to say 5 minutes a few hours before the cutover)
(b) Power down the source VM and run the job one last time.
(c) Power on the source

I've been testing with a transactional DB and although each pass seems to be quicker and shorter, it's still taking about 30 minutes. I'm considering a continuous replication when applicable but, I'm trying to work out what my cutover process would look like. If I power off the source while the continuous replication job is running, what will be the indication that I'm completely synchronized? Would I stop the job and run it normally one last time?

I'm trying to get a sense for downtime requirements to set expectations.

[Vitaliy S.]

If you want to be completely synchronized between two datacenters, you need to run replication job while source VMs are powered off. This process relates to both cases: jobs with continuous replication and not, so your initial plan looks good to me.

[bproteau]

That's what I figured but, I wondered if (after powering off the source), I could tell if the server was synchronized with a "continuous" job (i.e. would there be an indication that the final deltas had been committed or will I be staring at this job that would run indefinately no longer sending changes. That was my question about whether I ned to stop the continuous job and run a standard job.

Only reason I would consider a "continuous" type job is if it somehow made that last pre-cutover replication faster. I plan to test the theory but wondered if anyone had some insight. Below is a test job I scheduled to run over and over again.

This particular VM has a pretty active transactional DB on it which I assume explains the relatively long replication times. I seem to be leveling out to 20-25 minutes. Is this way off or does it sound right? Environments are ESXi to ESXi which I've heard doesn't perform as well as ESX. (NOTE: Initial replication job obviously took much longer and is not refelcted here).

Start Time End Time Job Session Performance Rate Transferred Data Status
8/16/2011 14:37 8/16/2011 15:05 Replication Job 1 123 MB/s 200.00 GB Success
8/16/2011 14:12 8/16/2011 14:36 Replication Job 1 140 MB/s 200.00 GB Success
8/16/2011 13:49 8/16/2011 14:11 Replication Job 1 151 MB/s 200.00 GB Success
8/16/2011 13:26 8/16/2011 13:48 Replication Job 1 154 MB/s 200.00 GB Success
8/16/2011 13:04 8/16/2011 13:25 Replication Job 1 163 MB/s 200.00 GB Success
8/16/2011 12:35 8/16/2011 13:03 Replication Job 1 121 MB/s 200.00 GB Success
8/16/2011 11:55 8/16/2011 12:23 Replication Job 1 123 MB/s 200.00 GB Success
8/16/2011 10:55 8/16/2011 11:28 Replication Job 1 106 MB/s 200.00 GB Success
8/16/2011 10:02 8/16/2011 10:28 Replication Job 1 133 MB/s 200.00 GB Success
8/16/2011 9:03 8/16/2011 9:36 Replication Job 1 105 MB/s 200.00 GB Success
8/16/2011 7:51 8/16/2011 8:43 Replication Job 1 66 MB/s 200.00 GB Success
8/15/2011 13:31 8/15/2011 15:27 Replication Job 1 29 MB/s 200.00 GB Success
8/15/2011 10:16 8/15/2011 12:23 Replication Job 1 27 MB/s 200.00 GB Success

[Gostev]

Yes, looks normal for ESXi target and v5.

[mkretzer]

I want to do something similar - migrate from one very large database server to a new SQL cluster while minimizing risk (so if all goes wrong the original server can be brought online again).

Is this a valid way or can it be optimized?
- Replicating in very short intervals with Veeam
- Shutting down the original DB server
- Doing one final replication run
- Disabling the replication job and removing the replica VM from Veeam config (so it won't do anything to it)
- Removing the snapshot(s) from the replica
- Attaching the SQL data and log disks from the replica to the already formed SQL cluster and attaching the databases
- Take the application online again
- Start DB mirroring to the secondary cluster node and start a fresh backup of the cluster with Veeam so that log backup works again

Markus

[david.domask]

Hi @mkretzer,

Planned Failover removes a lot of that busy work for you

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

So I think it's pretty much fine, just schedule a maintenance window, run the planned failover, then handle the SQL side of things during the failover. If all is well, commit the Failover and you're golden

[mkretzer]

Since we don't really want to do a "failover" but just need the data disks in the new cluster the planned failover is not really the right solution for us it seems...

[david.domask]

How so?

As I see it, it removes these steps for you:

- Replicating in very short intervals with Veeam
- Shutting down the original DB server
- Doing one final replication run
- Disabling the replication job and removing the replica VM from Veeam config (so it won't do anything to it)
- Removing the snapshot(s) from the replica

I realize it's not complete, but I think it saves you a LOT of effort and time You still need to manually manage the SQL part of course, but you have to do that anyways.

[mkretzer]

Does it change the original Servers config?

[david.domask]

Original Server isn't touched during failovers, so pretty much nothing is changed from your process; again, it mostly just automated every step of the quoted parts and hopefully saves some time and potential human errors on stuff like disabling replication job, failover over to the Replica and handling the snaps

[mkretzer]

Nice. I am going to test this, thank you!

[david.domask]

Sure, let us know how it works!

(note: a small clarification, the source VM is powered off as per your other procedure, but it's the only thing done to the original VM; it's just turned off)

[mkretzer]

"turned off" or "shut down cleanly"?

[david.domask]

Cleanly as best I know. I'm 99.9% sure it's just the Power Off command from VMware.

[21.06.2022 22:43:05] <01> Info [Soap] PowerOff 'vm-108032'
[21.06.2022 22:43:05] <01> Info [Soap] PowerOff, vmRef 'vm-108032'
[21.06.2022 22:43:05] <01> Info [VimApi] PowerOffVM, type "VirtualMachine", ref "vm-108032"

As far as I know, as long as VMwareTools is installed (open-vmware-tools should work the same way), PowerOff works with the GuestOS to do a clean shutdown. Only docs I can find are for vRealize, but I believe it works the same way with normal vCenter.

A quick test though in lab and I did see the Windows "unexpected shutdown" appeared, so depending on your situation, you might need to do some prepwork still