Extending PA data retention in OCUM v5.2 for CDOT

[dcornely1]

Hello,

Does anyone know how to change the data retention periods for Performance Advisor data in OnCommand v5.2 for CDOT?  In the Manage Performance section of the NetApp Management Console I go to Setup and then Clusters.  Here I can now see all the objects PA data is collected for along with the retention period.  However, I'm unable to modify the retention period via the Data Collection drop down because it is grayed out:

For the OCUM server I have running against 7mode systems this drop down option is not grayed out and I can modify retention periods via this method.  Is there a CLI equivalent I'm missing?  I can't imagine this ability is gone for OCUM with CDOT but stranger things...  Thanks.

-Dave

[kryan]

Hi Dave,

UM 5.x Cluster-Mode PA is not configurable.

There are few other posts on this topic.  Here is a recent example:

https://communities.netapp.com/thread/32497

Thanks,

Kevin

[dcornely1]

Wow - okay, thanks.

I'm absolutely floored by this -- I'm literally at a loss for words at at this point.

[adaikkap]

Hi,

     Just curious as to what you do by changing the retention  ? Do you use it for trending ? Would you mind helping me understand a little more ?

Regards

adai

[JGPSHNTAP]

Adai,

Why else would you need it? Of course for trending, that is what I would use it for

[dcornely1]

The ability to modify PA data retention levels is useful for:

• Trending.  Specifically, establishing performance profiles for applications.
• Managing space that PA data consumes.  Although a weeks worth of data for volumes won't take up much space, a years worth of data for nodes is too much.
• Unexpected requests for data.  Many times our business units and/or application owners ask for data from months ago during a critical period of time that is useful to them.

Retaining PA data for a week is simply too short while retaining it for a year may be too long and might consume too much disk space.  Bottom line is I need the ability to control PA data retention for all objects so I can balance my needs and the needs of my customers with realistic OnCommand filesystem space consumption.

Moving to CDOT is challenging enough without a direct upgrade path for existing 7mode arrays but losing critical functionality in the supporting toolsets like this raises other more fundamental concerns.  As an example, the OCUM 6.x line at this time lacks so much functionality (e.g., reporting, resource groups, comment fields) that we can't even consider using it until many of these features reappear.  So to see this type of thing crop up in the 5.x line really concerns me.

[dcornely1]

Allow me to elaborate on the trending piece with a real situation we're involved in right now.  We're actively looking at a higher density (but lower performing) unit-of-build for some of our lower performing application workloads.  In order to identify which workloads (at the volume level) might be good candidates for this array, we need the ability to profile their workload over the course of several months.  A look back period of only a week isn't enough of a picture to establish a valid profile because many applications may have specific times of the month and/or year where they require differing levels of performance.

We can do this now because the data is coming from the 7mode OCUM systems we have but if we were dealing with a CDOT OCUM system we wouldn't have the ability to do this.  Make sense?

[jweihs]

Thanks Dave for the detail information. One clarifying question -  When you state "several months" - is that 3 month or 6 months? Are you willing to trade off data resolution (5 minute vs. 1 hour samples) for longer time period retention?

Thanks,

Yossi