tuning nworks discoveries

Unleash the power of System Center for vSphere and Hyper-V | Veeam Task Manager for Hyper-V

tuning nworks discoveries

Veeam Logoby keithkleiman » Wed Oct 10, 2012 5:58 pm

I ran a SCOM discovery report for discoveries over the last 24 hours in order to identify any excessive config churn going on in our environment and it appears that the following Discoveries were run just 594 times.

nworks.vmware.vem.VMContainsWindowsComputer.Discovery
nworks.vmware.vem.VMGUEST.PropertyDiscovery
nworks.vmware.vem.VMGUESTVirtualDisk.Discovery
nworks.vmware.vem.Topology.SV100
nworks.vmware.vem.Topology.SV102LS
nworks.vmware.vem.Topology.SV103

I understand, from p.103 of the Operations Guide, that the topology discoveries are event driven and can be controlled by internally buffering the events that trigger a topology update. Can you clarify how I might buffer the events? Any suggestions how I might address the issue of the other discoveries listed, from running to frequently? I suppose that since they are running exactly the same amount of times that they are all conencted so if I control the first one that kicks them all off I should be in better shape.

Thanks,
Keith
keithkleiman
Enthusiast
 
Posts: 42
Liked: never
Joined: Mon May 23, 2011 8:38 pm
Full Name: Keith Kleiman

Re: tuning nworks discoveries

Veeam Logoby Alec King » Thu Oct 11, 2012 4:00 pm

Hello Keith,

That is certainly a lot of discoveries. We should probably dive into your logs and see what is triggering that, because even many vMotions should not cause that. For example you should only see the SV100 events if an actual HOST is added, removed, or changed in some way - just movements of VMs such as vMotion will not cause that.

In any case, I also see that the specific setting for buffering VM discoveries seems to have been missed from the documentation - I'll get that fixed. Meantime, you will find the setting in our nworks UI, in Advanced Settings for the Collector (select Collector in Enterprise Manager tab)
The setting is VMDiscoveryIntervalBuffer and the default is 4, which means VM changes will be cached for 4 intervals (4 x 5 = 20 minutes) before triggering the topo update. You can increase this setting to whatever you feel is appropriate; just be aware that of course VM topology changes (such as vMotion to a new Host) will take longer to be updated in the SCOM topology view.
Note that this setting will not affect the actual monitoring of VMs for performance and events in any way - all that data continues to be delivered on the standard 5-minute schedule.

Please feel free to open a support case and we can dive into why you are triggering so many discoveries - meantime the above should help to reduce the VM-triggered events anyway.
Any questions let me know!
Cheers,
Alec
Alec King
Veeam Software
 
Posts: 700
Liked: 116 times
Joined: Sun Jan 01, 2006 1:01 am

Re: tuning nworks discoveries

Veeam Logoby keithkleiman » Thu Oct 11, 2012 8:38 pm

Thanks Alec! I went ahead and modified the VMDiscoveryIntervalBuffer for each of our 5 collectors and set it to 12 so that it would trigger a topology discovery once an hour. We might be ok with even increasing it to 4 hours, but will start with 1 for now. I'll also follow up with suport shortly to submit my logs just to understand the discoveries better. Thanks again!
Keith
keithkleiman
Enthusiast
 
Posts: 42
Liked: never
Joined: Mon May 23, 2011 8:38 pm
Full Name: Keith Kleiman


Return to Veeam Management Pack for Microsoft System Center



Who is online

Users browsing this forum: Yahoo [Bot] and 4 guests