Replication Performance

VMware specific discussions

Re: Replication Performance

Veeam Logoby tom11011 » Mon Dec 05, 2016 8:10 pm

I've opened case 01995485 on it.
tom11011
Expert
 
Posts: 124
Liked: never
Joined: Wed Dec 01, 2010 8:40 pm
Full Name: Tom

Re: Replication Performance

Veeam Logoby tsightler » Mon Dec 05, 2016 9:25 pm

You might want to try following KB 1940, specifically the section under Veeam Backup & Replication v8 and Later which shows how to use a registry key to disable this automatic CBT reset functionality (this was added as protection against the CBT corruption issues in early versions of vSphere 6). Perhaps somehow this is malfunctioning in your case as it should not reset every time.
tsightler
Veeam Software
 
Posts: 4872
Liked: 1819 times
Joined: Fri Jun 05, 2009 12:57 pm
Full Name: Tom Sightler

Re: Replication Performance

Veeam Logoby tom11011 » Mon Dec 05, 2016 9:35 pm

I'll keep it in mind thanks. I have a case open now with veeam, they are recommending I just open a case with vmware.

Unfortunately, that script only resets ALL vm's. Can't have that happening!

My only workaround is to apply that script to a single esx server instead of vcenter, (ie migrate off all the vm's I don't want reset from the single esx server). I've applied this script to one server and I am currently running a replication which will take a while. I'll report back on the results.
tom11011
Expert
 
Posts: 124
Liked: never
Joined: Wed Dec 01, 2010 8:40 pm
Full Name: Tom

Re: Replication Performance

Veeam Logoby tsightler » Tue Dec 06, 2016 12:56 am

Well, based on the "Virtual disk configuration change detected, resetting CBT" message, I'm not sure that resetting CBT is really the answer as it's obvious that we are already doing the CBT reset every single job run. This should only happen on the first run after the disk is resized, not every run. This is what Veeam support should be looking into, to understand why we are doing that on every run. I'll reach out to the support engineer on your case and make sure he understand what we are seeing. I'm thinking it might be a bug due to the excluded disk, but that's just a total guess right now.
tsightler
Veeam Software
 
Posts: 4872
Liked: 1819 times
Joined: Fri Jun 05, 2009 12:57 pm
Full Name: Tom Sightler

Re: Replication Performance

Veeam Logoby tom11011 » Tue Dec 06, 2016 1:48 am

All the vm's that this is happening on have disks excluded. IE- I am excluding the tempdb disk as it doesn't need to be replicated.
tom11011
Expert
 
Posts: 124
Liked: never
Joined: Wed Dec 01, 2010 8:40 pm
Full Name: Tom

Re: Replication Performance

Veeam Logoby tom11011 » Wed Dec 07, 2016 3:36 am

This is the message I sent to support.

"In both the veeam backup and replication job, we had an excluded disk in the job. Basically, we were excluding a drive that contained tempdb, which is useless to replicate or backup in my opinion as it is simply just recreated anytime mssql is restarted.

What we ended up doing a few months back is deleting the disk from vmware and then recreating it. It was too large for our needs so we made it smaller.

I believe this to be the cause of the issue. Veeam didn't really complain because the disk was excluded. My guess is veeam only concerns itself with the disk number (ie scsi 0:0 etc..). It doesn't really check if it is the same disk or not. So when I deleted the disk and then re-added it in vmware, the number remained in my case scsi 0:2. Veeam saw that it was only to worry about scsi 0:0 and scsi 0:1. But, somehow scsi 0:2 is relevant to veeam even though it is skipping it.

To test this theory on the backup job, I removed the exclusion. The backup did not give me the message "Virtual disk configuration change detected, resetting CBT" for one job, but it did for another. In all cases, the job worked correctly at least after the second run. After the second run completed, I again excluded the disk and now it is running normally again.

I wanted to test one other thing, could I simply just remove the exclusion and then save the config, then just re-add the exclusion and save the config again before starting the job to see if I would get the same result? That did not work for me, the job had to run once with all disks before I could successfully re enable disk exclusion.

Replications seems to be a different story.

When I removed the exclusion from the replication job, on one job it failed with "Processing configuration Error: Cannot replicate disk [XXXXXXX-LUN6-DG4-TEMPDB] xxxxxxxxxxx/xxxxxxxxxxx.vmdk because its capacity was reduced" ie the disk size change as explained above. I tried it again after manually removing snapshots but same thing. I had to go into the replica and delete the disk (who's size didn't match the vm, it was still the old size on the replica). After running the job, it seems ok, it is running now but will take a while to complete and know for sure. I did not receive the cbt message but it did have to calculate digests.

On another replication job, it did recognize the disk size change and gave a warning "VM disk size changed since last sync, deleting all restore points". It proceeded to delete all replica restore points. Then, it added the new disk to the replica, but did not remove the old disk. I have to manually delete the old replica disk once the job finishes."
tom11011
Expert
 
Posts: 124
Liked: never
Joined: Wed Dec 01, 2010 8:40 pm
Full Name: Tom

Previous

Return to VMware vSphere



Who is online

Users browsing this forum: No registered users and 1 guest