Merge NCM and NPM Databases

I have to think that the performance hit is substantial.  SQL has its limitations - not sure where they will be met for each of our respective environments and I am by no means a DBA guru.  But time and time again, with multiple products for monitoring they all bog down as you grow and how we manage our methodologies for monitoring.  In my experience I have found it is not hard to bring the best monitoring systems to its knees.  ORION was chosen here in my environment because I had chosen to push it as I have worked with multiple products and this product seems to work very well, very intuitive, and performance was scalable and decent. 

Merging these databases into one...hmmmm....I think I am leaning more toward the side of keeping it separate for each module like dclick mentioned.  I think it makes it more scalable as well as provides better options available to deal with performance issues should you run into them.  If you house your DB's on a single instance server that is fine, but leave that capability to scale out away from that box to another SQL instance if need be due to I/O issues.  But I think we need to have the ability to auto sync within the system so we don't have to keep multiple instances/db synced so it all works well together.  Is this possible even?  If you are a small shop then you can still put it on the same box (single SQL instance but multiple db's).  There needs to be some type of migration path that is fairly straight forward so that a small business can grow into the bigger solution without growing pains.

The syncing issue now is a little thorn in the side between NCM and NPM - I have run into issues where nodes are in one and not the other, etc.  However I want my application for all my business partners to run smoothly with good performance.  I do not want to be responding and spending my time on performance tuning, fixing, issues within my EMS Environment on a regular day to day basis.  That would be very problematic and hinder adoption of monitoring solutions to solve issues and lead our organization into a pro-active type of organization rather than a re-active one.  I also want the ability to collect as much as possible as often as possible so that root cause issues can be drilled down to exactly what happened.  I know that is easier said than done...it is something that I think we all strive toward and I understand it isn't a perfect world so sacrifices are made.  Bigger window for poll times, possibly less metrics collected, or shorter time spans on keeping data before rolled up...etc, etc, etc.

I think the common theme though is "Performance".  You have a daunting task to keep us all happy...   I think I will vote Nay on the merge.  I vote Yes on some type of syncing that we can count on and keeping performance a top factor.  The systems do us no good when they crawl.

Respectfully,

NetEng33

Basically, I agree with everything you said. We are aware of the fact that this change might affect NPM and we would do our best to mitigate the consequences. It's early to expose all the ideas, but believe me that we plan to deploy measures to protect NPM performance.

Jiri,

Your statement here is a little contradictory. To your point, NTA and NPM are very much real-time and DB intensive. Also to your point, NCM is more focused around scheduled batch jobs to do config backups (unless you send configuration change traps from your devices that kick off immediate configuration download jobs). Very different behaviors, I agree. But, outside the obvious management and integration advantages, why would you consider any additional performance increase on NPM at all? You never know when NPM is very busy (its all determined by the environment), and if an NCM job kicks off during a busy time, we start seeing intermittent performance issues. In a small/medium environment, I agree...it doesn't matter where the DB goes because there isn't that much data collection/crunching to make a difference. But Orion is also being used in large Enterprise-class environments where every little bit of performance is crucial.

D

dclick,

Your idea about a single core, and my idea...same. I hadn't seen anyone else chime in on my notion, so I was beginning to think I was all alone is world and possibly crazy (which might still be a little true).

D

Hi,

For big customers it can. We definitely take this fact into account.

Regards,

Jiri