Parallel VM Processing on a Per Job basis?

[jbarrow.viracoribt]

So, I want my backup jobs to utilize parallel processing but I want my replication jobs to only do 1 at a time. Looks to be something I cant control. Is this on the feature request list already?

[tsightler]

You can control it indirectly, just set the proxy on the target side of the replication to be limited to 1 task, that should do it.

[jbarrow.viracoribt]

That seems to only sort of work.

I have 6 replication jobs that fire off every 2 hours.

Those 6 jobs are configured to use two different virtual proxies on the production side, and two virtual proxies on the destination side, each proxy can handle 8 tasks at a time

I notice that one of my 6 replication jobs seems to take off first (even though they all start on the hour), that first job seems to gobble up all the available slots on the two proxies (processing 16 different disks) while the other 5 jobs wait for an available proxy.

With parallel processing off, each job would start at the same time but each job would only process one system/disk at a time.

If I did as you suggested i would still have one job gobbling up all the threads while the other jobs wait.

Does that make sense?

[tsightler]

I think I wasn't clear to your exact goal in the initial question. I'm still not sure I totally understand, it sounds like you want to use parallel processing, but you want the tasks to be evenly spread across all 6 jobs instead of having one job using all the resources and the others pending. Is that correct?

[jbarrow.viracoribt]

I think I wasn't clear to your exact goal in the initial question. I'm still not sure I totally understand, it sounds like you want to use parallel processing, but you want the tasks to be evenly spread across all 6 jobs instead of having one job using all the resources and the others pending. Is that correct?

For my backup job, which is just one large job, I'm fine with parallel processing working like it does. I have 140 VM's in that job and it just mows through them.

My replication jobs though, those are defined per LUN so I have many replication jobs that are supposed to fire off at the same time. The org wants replication to run every 2 hours. Right now parallel processing messes that all up because job 1 gets done first, then job 2, etc. I just wish the parallel processing setting was defined at the job level vs. server wide.

[Gostev]

We recommend managing replication jobs with a separate backup server located in the DR site (to ensure you can perform failover when the production site is down). You can simply disable parallel processing on that server?

[jbarrow.viracoribt]

We recommend managing replication jobs with a separate backup server located in the DR site (to ensure you can perform failover when the production site is down). You can simply disable parallel processing on that server?

Won't that mess me up on Veeam licenses though since it will look as if i'm managing double the hosts?

[Vitaliy S.]

It doesn't matter how many Veeam B&R servers you deploy, given that you're using your license key against the same source hosts all the time.

[jbarrow.viracoribt]

Okay, I just spent most of the day today splitting out the backup and replication environments to two, as you suggested.

Now the replication server has parallel processing turned off and the backup server has parallel processing turned on.

A new error, it seems the are now tripping over each other. The Backup job throws an error because a VM is in the middle of a replication initiated by the other server. I understand that I can set a retry counter but our policy has the system email a ticket on every failure, which is going to start spamming our helpdesk.

Thoughts?

[Vitaliy S.]

If you're using application aware image processing (aka VSS), then your jobs should not overlap, since Guest OS cannot freeze and unfreeze the OS at the same time. Setting different schedules for your job should resolve this issue.

[jbarrow.viracoribt]

If you're using application aware image processing (aka VSS), then your jobs should not overlap, since Guest OS cannot freeze and unfreeze the OS at the same time. Setting different schedules for your job should resolve this issue.

Application aware image processing is on.

Both the replication server and the backup server seem to on occasion try and process the same VM, when that happens, this error comes up. Before, when both replication and backup tasks were in the same server instance the job would give a message that it was in use by another task (or something similar), it would then wait for that task to finish and then continue with the job. Now that the jobs are split out across two different servers they are throwing this new error when they run into each other. Different schedules seems like a poor workaround as sometimes need to have my backup jobs running while replication jobs are running. Could this be fallout from using two different instances of Veeam on the same vCenter cluster?

[Vitaliy S.]

Both the replication server and the backup server seem to on occasion try and process the same VM, when that happens, this error comes up.

That's expected behavior, since both jobs interact with a VSS writer on the Guest OS, which cannot do freeze and unfreeze operations at the same time.

Different schedules seems like a poor workaround as sometimes need to have my backup jobs running while replication jobs are running. Could this be fallout from using two different instances of Veeam on the same vCenter cluster?

Yes, secondary Veeam server is not aware about jobs running on the first server, that is why the error above can show up sometimes. The workaround for that would be to use different VM schedule or disabling VSS in one of the jobs (need to confirm that).

[Delo123]

Maybe a bit off-topic, but it's been on my wish-list for some time...
We use parallel processing (and love it:)) but for some jobs we would like to control VM Processing per Job basis too...
Example:
We backup our Exchange nodes in one backup job, mainly because they belong together and for dedupe etc...
However, we had the case where a backup failed because of some bad disks on the repository etc during exchange backup.
Since both nodes are backuped at the same time (we only use our physical veeamserver as proxy due to direct SAN access we cannot controll parallel processing with number of jobs) both jobs were stuck and we had to consolidate files etc which caused a bit of downtime...
Same case for DC's, i like to backup them together, but IF something happens, the risks of something happening to all of them is quite big...

Comments?

[haslund]

Gostev: We recommend managing replication jobs with a separate backup server located in the DR site (to ensure you can perform failover when the production site is down). You can simply disable parallel processing on that server?

Is this really the recommended way of handling this situation?

Setting up one VBR server in Production site to handle backups and a seperate VBR server in DR site to handle replication?
I thought there would be some advantages to only having one consolidated VBR server and then place it in DR site.

[Gostev]

Yes, especially when there is a stable, low latency connectivity to DR site.
In other cases, placing backup server close to vCenter is preferred.

[haslund]

While I would personally prefer seperate deployments, it seems it would not be possible to setup fx:

VBR in production handling:
Backup to prod.
Backup Copy to DR

VBR in DR handling.
Replication from Backup Copy (sourced from DR site).

Is that correct?

[Gostev]

I don't see why this would not be possible to setup. Where do you see the issue here? Remember that when setting up replication from backup files, you instruct the replication job to look for backups in the specific repositories. So, you just point your replication job to the location where Backup Copy job puts them (just remember to schedule auto-import of those backup files into D&R backup server's repository).

Let's not hijack this thread any further though, since discussion becomes totally unrelated to the original topic feel free to create a new topic instead!

[jbarrow.viracoribt]

Still wishing for this feature. Please Veeam gods answer the call!