We should split the vCenter Topology job into 2 different jobs due to the high amount of CIs that it can report on big vCenter deployments.
For a 7000 VM deployment, it will create an 800+ MB Communication log with results included and 600k CIs out of which 320k CIs are storage related.
We need a new discovery job which reports only the storage topology of a vCenter, something like vCenter Storage Topology by VIM.
The current job is used and preferred as the customer will have only one set of credentials but this will bring too many CIs in one bulk. Even splitting the bulk per datacenters isn't always good as the VMware topology is specific and difficult to identify. The ESX approach isn't too used as it implies defining the same VIM credentials on hundreds of ESX servers.
Splitting the current vCenter job into 2 new jobs will allow for a better discovery schedule, a more granular one. We would use the current scripts but they will have to model a slightly different topology. For the classic job (the current vCenter topology job) we should avoid modeling the storage CIs. For the new job (vCenter topology) we should model only the storage CIs and the related CIs needed for reconciliation (root_containers, etc).
We already have similar ERs submitted on this discovery flow. Currently, we are pushing the limits of the probe and server with everything discovered in one single job.
Similar ERs performance related:
- https://community.microfocus.com/t5/CMS-Idea-Exchange/Add-property-to-ignore-VMware-storage-in-the-VMware-vCenter/idi-p/1762870 (the famous reportLUN new job parameter)
- another beta approach is to split the results in several vectors grouped by VMware datacenters
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.