Skip to main content

So.. last year we’d implemented a scheme where there were many subclients looking for VMs through vCenter as such:

We later noticed a major drag on vCenter, which was causing lockups and such.  We then changed the scheme around to something simpler, with far fewer subclients.  The issue went away.  As I see it - we simply had overburdened our ESX servers/vCenter with too many authentications and checks.

 

Now, it’s being suggested to me that we create far MORE subclients.  I’m thinking of taking what it’s found now per datastore and putting them into a static content as such:

 

VMs in the future will be handled differently (we’ve got a policy setup using category\tags in vCenter - this is our old school method for servers that haven’t been brought into the modern fold). 

 

Question - does anyone know if this will generate more authentication traffic again?  CV could just authenticate once then go about its business with the list?

We’re using a windows domain account to authenticate… I’d think that we’d have better performance if we simply used vCenter local accounts?  There’s just a little more to manage if we have to change the passwords and such.

 

Thoughts? :)

 

Thank you!

 

Hi @roc_tor,

Thank you for reaching out. 

The authentication method should not make any effect for the discovery and backup of VMs. 

 

Previously when you added content as Datastore, then every VM that is present under Datastore will be discovered and backed up at same time under same job.

 

Could you please suggest how many VMs were there under datastore when locks were happening?

 

Suggestion for segregation might be provided to increase the performance of backups. 
Can you please suggest how many access nodes you are using to run the backups

 

 

 


Reply