Maintain control of your Microsoft 365 data
Post Reply
MaartenA
Service Provider
Posts: 70
Liked: 24 times
Joined: Oct 31, 2021 7:03 am
Full Name: maarten
Contact:

Concurrent jobs

Post by MaartenA »

Hi,
So we are running a PoC for VBO right now. 1.5 year ago we quited VBO because we had a lot of issues where jobs stalled when also a full backup was running. Eventually all jobs queued up because of this full and we where unable to get the right RPO for the incrementals. We had a lot of contact with support and in the end we used staging proxies to create the fulls but this was very hard to manage so in the end we quited. Back then we used block storage as a repository.
So now for the PoC we are using Object storage and yes this is running better. Every proxy is setup how the BP guide tells us. Every proxy has his own bucket and every customer has his own folder/repository within this bucket. Every organization is splitted into 3 jobs (Onedrive/Exchange/ Sharrepoint & teams).

In the documentation there is a lot of focus on the number of objects per proxy while there is almost no focus on the number of running jobs at the same time per proxy. I do wonder why it matters with object storage how many objects are handled per proxy(i can imagine this limits with block storage)? My observation is when the proxy is not processing any jobs it does not matter how many objects are handled performance wise. With a few or a lot of objects managed by the proxy it is just sitting there doing like nothing.
When running like 2 or 3 jobs at the same time the proxy is still not reaching the max CPU/memory wise. When running a lot of incremental jobs at the same time, in my case 30 the memory and CPU goes sky high BUT every job is completing within a normal time frame so this is all fine. I am still happy with it.

My other observation is when 2 Full backups are running on a proxy and like 20 incrementals the stalling behavior we had before is happening again. When I am doing the same but then with 2 Fulls and only 5 incrementals the completion time is like almost the same compared to when no fulls are running.

This made me think why is there no option within the proxy to regulate the number of concurrent jobs that can be run but only an option for the number of Threads?. It would be nice to have this to get better stability and regulation on the number of jobs per proxy. My opinion here is that not the number of objects can kill the proxy (with object storage) but the number of running jobs concurrently can.

I think this option will help us as an MSP a lot because a MSP is onboarding new customers like weekly so we always have fulls running. Yes we can scale up from like 10 proxies to 20 to handle more fulls but this does not make any sense to do only for the onboarding part and not needed for the incremental part. So it would like to ask Veeam to think about to create an extra option per proxy where you can set the number of allowed jobs running concurrently and add an extra check mark that it would only honor this setting when a full backup is running so we have a choice to always run all jobs / always limit the number of running jobs or always limit the number of jobs when a full is running. This information is available within VBO so it would be easy to create right 😊? This setting is also very useful if Veeam will build a more flexible proxy concept like we spoke about in other threads on the forum .

Another must have is to set a start time when use the schedule run every…. Right now when you set like run every 8 hours it will set the start time for every job to 10.00. Yes you can use the offset but this is not manageable to do for a lot of jobs. I don’t want to hold an administration for start times.

I have also created case 06049629 for this stalling behavior and the response from support is run 1 job are the same time. Yes I would like to run less jobs at the same time but right now we cannot configure this properly and playing with the start times from a jobs is like almost impossible when running a lot of jobs. This is not manageable. The option regulate the number of jobs running at the same time is a quick fix I think with a lot of positive impact.
Mike Resseler
Product Manager
Posts: 8045
Liked: 1263 times
Joined: Feb 08, 2013 3:08 pm
Full Name: Mike Resseler
Location: Belgium
Contact:

Re: Concurrent jobs

Post by Mike Resseler » 3 people like this post

There is an architectural reason for the amount of objects. Long story short... We need to be able to maintain the list and more objects would force us to query a lot of data from MSFT before we can even build the start of any job. That said, lots of changes are coming in vNext that will make your life as a service provider much easier. Those changes will address most of your (valid by the way) concerns. I can't go into much detail yet, but more information will be given rather soon
MaartenA
Service Provider
Posts: 70
Liked: 24 times
Joined: Oct 31, 2021 7:03 am
Full Name: maarten
Contact:

Re: Concurrent jobs

Post by MaartenA »

That would be great Mike. Let me/us know when this information is available as it would help me out to make the right choice to move back to VBO.

Thanks
Mike Resseler
Product Manager
Posts: 8045
Liked: 1263 times
Joined: Feb 08, 2013 3:08 pm
Full Name: Mike Resseler
Location: Belgium
Contact:

Re: Concurrent jobs

Post by Mike Resseler » 5 people like this post

@MaartenA
Well, Veeam might have some sort of big event soon and you might be able to find my name in the speaker list :-D :-D
Post Reply

Who is online

Users browsing this forum: No registered users and 18 guests