Surebackup and SRM vSphere replication issue

[mgray_mn]

We are just starting to test SRM with vSphere replication, and have an issue when my SureBackup Exchange Verification job runs.

Right now we are testing ever thing on the local LAN, with plans to move the replication target off site when we are comfortable with the processes.

if the RPO window for my Exchange server and my SureBackup Exchange verification job overlap, the SRM vSphere replication basically has to reseed itself.

this is 100's of GB of data, and takes hours to complete on the local LAN.

It will never catch up once we are replicating across the WAN.

The scheduler for vSphere replication is very limited, so I cannot set a blackout window, only enable/disable and set frequency.

Is there something we can change on the SureBackup job?

Thanks
Mike

[veremin]

Hi, Mike,

Can you elaborate what particular goes wrong when Surebackup and SRM replication activity overlaps? I'm wondering how activity that takes place mostly in isolated environment (vLab) can affect replication process anyhow.

Thanks.

[mgray_mn]

I don't know how my vLab environment is affecting my production environment either.

vSphere replication is set by an interval and not an actual time, so the vSphere replication window changes constantly.

start 1200 end 1204 300mb
start 1304 end 1311 300mb
start 1411 end 1415 300mb

etc...

So no matter what interval I set, eventually the SureBackup job and vSphere replication will overlap.

if the vSphere replication window occurs when the SureBackup job is running, the next vSphere replication syncs +500GB of data and takes +5 hours to complete.

if the SureBackup job completes before vSphere replication starts, a "normal" 300mb sync occurs.

Hopefully this explains better.

MG

[veremin]

You might want to check this out on VMware forums, as well, since I'm not sure how backup verification process occurring mostly in isolated sand-box can result in increased amount of transferred data.

As to the workaround, is vSphere replication configurable via PowerCLI? If so, then, you can write simple script that checks whether surebackup is running and starts vSphere replication in accordance.

Thanks.

[Vitaliy S.]

Just for the sake of experiment, can you run an Instant VM Recovery task while your vSphere replication is running? Do NOT power on the VM in order not to mess up with production VMs routing. Do you see the same behavior?

[mgray_mn]

I just tried doing an Exchange Item Restore, and everything worked fine. No vSphere replication issues with Veeam Explorer for Exchange open and all stores mounted.

I have opened a support case (00552742), they are escalating it to Tier2.

I believe it has something to do with my vlab configuration. vSphere replication appears to be using the GUID and not the computername, so when my verification job is running it appears to be taking the vlab instance eventhough the computername is completely different.

I thought the vlab was supposed to be isolated and the production environment couldn't see it.

I found this in the vSphere replication log.

Code: Select all

      Delta aborted for virtual machine 05. Exchange 2010 CAS/Hub on host esx02.smbsc.com in cluster SMBSC in SMBSC: Filter failed
 
      Full sync started by System for virtual machine 05. Exchange 2010 CAS/Hub_5574696da0df4bf4ba4c1d2a27ce7d38 on host esx01.smbsc.com in cluster SMBSC in SMBSC.
 
      Delta aborted for virtual machine 06. Exchange 2010 MB on host esx03.smbsc.com in cluster SMBSC in SMBSC: Filter failed
 
     Full sync started by System for virtual machine 06. Exchange 2010 MB_e3a6e9f22c5248faaa49080322881383 on host esx01.smbsc.com in cluster SMBSC in SMBSC.

Thanks

MG

[veremin]

vSphere Replication might be tied to some VM identifier (presumably, GUID) that stays unchanged during verification process. As the result, vSphere replication is confused by the presence of two equal identifiers. You can confirm this assumption by running Instant VM Recovery, as mentioned by Vitaliy.

Thanks.