We are trying to use Veeam nWorks for SCOM to monitor our ESXi 4.1 environment. This is quite an expensive (and so far flaky) solution that I'm not sure gives too much value.
Once we get nWorks working (does the "n" stand for "Not"?!) we will forward the alerts from SCOM to HP Openview. That's fine but why not just set the vCenter alarms to forward via SNMP trap straight to Openview? What does nWorks provide that this does not? The only slight advantage I can see is maybe when you are doing maintenance you can supress the alerts in SCOM, but I guess you can do the same with the alarms in VC.
Any opinions here? Why use nWorks/SCOM over just VC alarms?
I haven't used nWorks myself - I should probably put it on my to-evaluate list - but from talking to other people who do, here are two reasons that I'm aware of:
They want a more centralized repository for alerting and monitoring - "single pane of glass".
The permissions and responsibilities of their technical staff varies, leaving some with access to SCOM, but not VC.
VKernel Systems Engineer
Hi BobD - I hope I can answer your questions - BTW I am Senior Product Manager at Veeam, with special responsibility for the nworks line
First off - if you are having any issues getting nworks up and running, I hope you are engaged with our support. If you feel you are not getting traction, please let me know. I welcome all and any feedback on nworks - feature requests, our support, the product itself - feel free to contact me at alec at nworks dot com.
And regarding the value-add of nworks; first I would agree with jkilck's two points. 'Single pane of glass', and differing operational roles and responsibilities - those are two reasons that almost all enterprises use a management framework like SCOM or HP OpenView (and I see you have both!)
To the question of 'why not just forward VC Alarms straight into SCOM/HPOV? Why use nworks?' my answers would be -
1a. Virtual Center has only a handful of alarms. And they certainly don't cover all possible performance or configuration problems....This is because monitoring is not Virtual Center's core function - its a management and configuration tool.
1b. nworks however has a detailed set of performance thresholds and event triggers - well over 500 rules and policies ship out-of-box.
If Virtual Center tried to provide such a granular monitoring function - it would never scale to perform its core management function!
2a. Even if you did (manually) configure 100's more Alarms in Virtual Center (and managed not to impact the performance and stability of VC itself), and forwarded them to SCOM or HPOV via SNMP - you would still only have a very 'flat' view. Just a page of alerts, all from a single source, with your operator staff having to dig into each one and try to correlate the importance, the related impacted systems, the meaning of this particular metric or event, what are the best practices or troubleshooting steps etc.
2b. However nworks automatically builds a detailed VI topology/service map, all dependencies are automatically created (Cluster to host to datastore to VM to application, and so on), each object in the VI is a target for its own alerts and reports, and there is a comprehensive knowledge base to assist with root-cause analysis. This is what operational monitoring staff really need to be effective.
Hope the above helps - I tried to answer the question without doing too much of a sales pitch
And I do welcome all feedback on nworks - just contact me at the address above.