Sustainability. What Does it Mean to You?

[christig]

Hello,

Question about sustainability of custom development

I want to develop a custom tool which interact with OCUM (currently 6.3)

I only need to retrieve OCUM information (no action trigger) 

So I have to method to reach my goal

- use the OCUM API (Java binding in my case)

- connect to OCUM DB and SELECT from OCUM DB Views

Are both methods sustainable (stability in next future releases) ?

What is recommanded for custom code sustainability ?

Thanks in advance for your help

Best Regards

Christian

[niels · Accepted solution]

Hi Christian,

both methods are valid, supported and sustainable.

With regards to API we (NetApp) may suggest to use OnCommand API Services instead of going to the OCUM server directly.

http://mysupport.netapp.com/NOW/cgi-bin/software/?product=OnCommand+API+Services&platform=Linux

In regards to ODBC you are also on the save side. We purposefully only disclose the DB views rather than the actual tables as the views are meant to stay wheras engineering is free to alter the actual tables in later releases as required.

Kind regards, Niels

[christig]

Thank a lot Niels for this very reactive and accurate answer

Best Regards

Christian

[bobshouseofcards]

Any hints on when OCUM 6.3 will be officially supported with OC-API Services?  Will API 1.0 support the GA OCUM 6.3 or will we be seeing a new API release?

Bob Greenwald

Lead Storage Engineer

Huron Consulting Group

NCDA cDot | NCIE-SAN cDot

[sinhaa]

Hi niels,

@ With regards to API we (NetApp) may suggest to use OnCommand API Services instead of going to the OCUM server directly.

------

What is this recommendation based on? Do I get anything using API services which I can't using OCUM APIs or DB access using SQL queries? I'm asking this because using API services comes at a cost. It will require me to have another resource and its maintanance overhead.

sinhaa

[bobshouseofcards]

Sinhaa -

OC-API Services has plusses and minuses, like anything.  You are correct that it takes another resource, but in this case it's a fairly low maintenance resource once configured.

The key benefit is that you have a single source from which to collect data.  For example, in my environment I have 3x OPM servers pushing events to 1x OCUM server.  Because my clusters are in geograhphically diverse locations (multiple continents) the OPM collection works better locally, while the single OCUM handles the general collection with ease.  But, that means four OC-servers from which to collect data for add-on applications.  It could have just as easily been 3 separate OCUM/OPM pairs  - six separate collection points.

The advantage of OC-API Services is not readily apparent if you have just one OCUM/OPM pair.  As the environment grows, it is simpler to write collection scripts against one central collection point.  OC-API also presents a REST API which is easy to integrate into most environments without worrying about direct acces to the underlying OCUM/OPM MySQL databases.

OC-API doesn't store any data - it just gathers it from the OCUM/OPM servers it fronts on demand.   It also adds group level authentication for those environments that would like to use it.  Using OC-API you can also centralize authentication at a single server for a wider audience if you so choose.

For complete collected data you would still need to go to the OCUM/OPM databases directly.  But for all the general counters that DFM provided, OC-API will do the job quite nicely.  I was headed down the direct database access route myself for a number of standard performance analysis scripts I use, but quickly converted them all to the API Services when that became available.

Hope this helps answer your question.

Bob Greenwald

Lead Storage Engineer

Huron Consulting Group

NCDA, NCIE-SAN Clustered Data Ontap

[niels]

Hi sinhaa,

this was more a general guideline as in the future API services are meant to be "the single point of integration" for more NetApp products than just ONTAP and OCUM.

It might be the better choice in larger environments rather than cumminicating with each and every product individually. But I don't see OCUM API go away so using it directly is still an option to save additional overhead.

Kind regards, Niels

[niels]

Hi Bob,

you should expect a new 1.x release to support some new APIs of UM6.3 and OPM2.0.

I cannot post a date here though.

Kind regards, Niels

[sinhaa]

Hi Bob,

@ The key benefit is that you have a single source from which to collect data.

-------

I'm not sure this is really an advantage for a programmatic solution. Why would getting data even from multiple sources be a problem for a code? If I can get data from one server, I can do it for as many servers I have to. GUI I understand, but an API client program to have this as a problem?

@  OC-API also presents a REST API

------

REST API interface can be with the OCUM server itself. Why does it need to be on an external API server?

sinhaa

[bobshouseofcards]

Hi Sinhaa -

@ The key benefit is that you have a single source from which to collect data.

-------

I'm not sure this is really an advantage for a programmatic solution. Why would getting data even from multiple sources be a problem for a code? If I can get data from one server, I can do it for as many servers I have to. GUI I understand, but an API client program to have this as a problem?

:: Of course anything can be done in code, but should it be needed to?  Example - I write a script against OC-API to get a certain performance metric set for all volumes and do something with that.  I then add two or three more OPM servers for whatever reason.   I add those into OC-API and all my monitoring scripts just continue to work and automatically process the newly available data - no code change needed.  I also consider the case where I am not the only data consumer.  My OC-API is open for data access to a number of different consumers in my environment to gather specific data for their own needs.  Having them all go through one location centralizes my security setup, simplifies my OCUM/OPM configurations as I don't need to maintain multiple user bases, etc.

=====

@  OC-API also presents a REST API

------

REST API interface can be with the OCUM server itself. Why does it need to be on an external API server?

:: Configuration/capacity data comes from OCUM.  Performance metrics come from perhaps multiple OPM's under one OCUM (as in my environment they do).  So if the REST API were at OCUM/OPM, I'd still have to program against multiple data sources and coordinate which one held which data.  Given a volume from OCUM for instance there isn't an easy way to determine which OPM holds the performance data unless one goes under the views that Netapp exposes in the database.  Again - simpler to provide a one stop shop.  

Most of my preference for OC-API is based on scale factors - many data consumers, and multiple OCUM servers each with multiple OPM servers underneath them.  If you have 1 OCUM and 1 OPM, my advantages are less pronounced certainly.

Bob

[sinhaa]

Hi Bob,

@ :: Of course anything can be done in code, but should it be needed to? Example - I write a script against OC-API to get a certain performance metric set for all volumes and do something with that.

-----

In my opinion having not needed to call APIs from multiple servers by my code is an insignificant advantage. I may not  worry about it. A piece of code dosn't worry about calling 1 or 10 serves. Also it reduces my risk of single point of failure. If my OCUMs are fine but my API Server isn't, then this is blocking situation for me.

Also is it true that I really won't need to go to OCUM at all and my single point API server can do everything for me? My requirement also include to set alerts, watch and acknowledge events, modify thresholds, manage users etc. API Server can't do these, I would need to call the OCUM APIs. 

So why would I have half API Server and half OCUM? Why not use the whole OCUM APIs. Thats why I asked in the beginning is there anything I can using API Server which I can't using OCUM APIs.

@ :: Configuration/capacity data comes from OCUM.  Performance metrics come from perhaps multiple OPM's under one OCUM (as in my environment they do).  So if the REST API were at OCUM/OPM, I'd still have to program against multiple data sources and coordinate which one held which data.  Given a volume from OCUM for instance there isn't an easy way to determine which OPM holds the performance data unless one goes under the views that Netapp exposes in the database.  Again - simpler to provide a one stop shop.

-----

Assume if REST APIs were available with OCUM itself. Then the above case you mentioned about single OCUM and multiple OPMs would certainly have been resolved.

My point is why does the REST API interface have to be at a new server. I see the importance of REST APis. But why at a new Sever outside of OCUM as new Product? What would I have missed if it were present at my OCUM?

sinhaa

[bobshouseofcards]

Probably we're going to have to agree to disagree on this one.  The focuses are different - yes, OC-API can query both multiple OCUMs and OPMs data with a single interface, but it is query.  For my consumers it is way easier to give them the OC-API interface than have them code against the OCUM zAPI or, to get the performance data they need, the MySQL database directly.  It also greatly simplifies my security arrangements significantly - authorization, firewalls, etc.

The OCUM zAPI itself doesn't pull the performance data at all, but then the actual management activities that you describe can't be done through OC-API.  I don't have direction from Netapp whether they plan to build in more of that in future versions (it is a 1.0 product after all) - you might be closer to that than I.

Bob Greenwald

[sinhaa]

1. Authorization : Domain Authentication support solves all problems of authorization. Same set of credentials work on all servers with their respective roles.

2. Security and firewall: The same set of firewall rules can be used at OCUM.

So I'm not sure how does the presence of a new Server i.e. API Server make anything better. Only if you consider a single point of access for a code as an advantage.

@ The OCUM zAPI itself doesn't pull the performance data at all, but then the actual management activities that you describe can't be done through OC-API.

----

Thats right. I'm not saying don't have REST APIs. REST has some very good advantage and I usderstand that. My point is why REST layer is not with the core product themselves instead of being as an external Server. External server added oveheads of having a new resource, its maintenance and unnecessary points of failure.

WFA, OC Insight and Flashray also provide REST APIs, but they are not on an external Server. They are all with the core products. Why couldn't OCUM have it too.  

@ Probably we're going to have to agree to disagree on this one.

----

. Only you get to decide what works best for you. 

Thanks Bob, it was a nice discussion.

warm regards,

Abhishek Sinha

WFA