Why can't NetApp combine OCUM, OCPM and API Services?

[machinist]

It's madness really....I have to deploy 3 separate appliances to get my Blue Medora NetApp MP working in vRealize Ops.

That's plain nuts.....and to top it all API Services is a .bin that needs an install of CentOS or similar, at least make that a deployable VMware template like the other 2.

Come on NetApp you're better than this.

/rant_over

[bobshouseofcards]

Anyone ever try installing OCUM and OPM as Linux/Windows versions on the same machine (since those are also available as standalone installs)?  Not saying it's a good idea, just wondering if it can be done.  If it could be done on a CentOS box, in theory you might get all three services on one platform.

Again, not recommending cuz it certainly would not scale.  Just curious.

And that brings me to the same answer I got from Netapp folk when I posed the single box question about DFM versus OCUM/OPM/OCAPI - it's all about scalability.  The DFM architecture wasn't designed to scale well.

Not that I wouldn't like a single box as well, but then I've never been able to get by with just a single DFM either.

[machinist]

Thanks for the reply, and I like the idea of all 3 on one Linux box.......now I am brave enough to try it out!?

[niels]

OCUM and OPM partly use the same components, services and ports. I'd expect them to collide when run on the same server.

It's not designed and tested that way.

regards, Niels

[bobshouseofcards]

Niels -

Granted - not expecting such an exercise to be either easy, or supported, but it might be fun to try.  All about the "fun"...

Bob

[niels]

Go for it - I'd rather do something different just for fun though... ;-)

regards, Niels

[JoelEdstrom]

They pretty much had to separate OCUM/DFM from the performance management side for stability and scaling reasons.  When you start having 5-10+ DFM and dozens/hundreds of controllers I think it makes sense to split monitoring and performance into independent services.

Granted, managing N*2 number of appliances for each OCUM/OCPM environment isn't great...but I don't feel like I need to worry about the DFM services going down all of the time this way.  On the 4.x and 5.x DFM/OCUM versions you could easily take down your enterprise monitoring in DFM with too much activity from the built-in Performance Advisor.

[bobshouseofcards]

Joel - Totally agree.  DFM at scale was a nightmare to deal with.  

And for everyone - of course it isn't N*2 with OCUM/OPM necessarily.  It might be but it isn't required.  For instance, I go with 1x OCUM and 3x OPM, one OPM per data center (multiple continents).  OCUM's collection points don't stress so much at the WAN distance, but OPM would totally choke at those same distances and node counts.  In 2016 I'm planning for a 2nd OPM at one location as node counts are expanding there, but it should still fit under the single OCUM. 

It's really nice to be abe to scale the component that is needed.  For that matter it's really nice to be able to just scale, and tie any number of data collectors under a single point of access for external tool systems (OC-API Server).  I grant that for the single 2 small node cluster the first full monitoring point tool combination - OCUM, OPM, OC-API - seems to be a lot compared to what DFM was. 

Bob

[JoelEdstrom]

Bob -

That's a great point about not *needing* OCUM in each area.  The data its gathering is far less intensive than OPM; one OPM per geographical location/WAN link is a great idea.

[SCOTT_LINDLEY]

I've been runnin api-services on my OCPM host for some time now, using version 1.0 then later 1.1. Starting with 1.2 it is now not possible, as it is now using conflicting versions of ocie RPMs that break OCPM. The OCPM versions are all 1.3 and the api-services versions are all 1.4. Sigh. So much for that, looksl like I'm going to have to stand up (and pay for) another Linux host just for this. If it wasn't that I have several users using it, I'd just drop it.

    Scott