Is it impossible to find total committed bytes for an aggregate from snmp / API?

[Antony_LogicMonitor]

Hi all,

I've tried searching but haven't (as yet) found an answer to this; apologies if I've missed it (when a link to the answer will be much appreciated).

Problem:

NetApp itself claims a committed value on an aggregate of 50.7TB / 167% committed (31TB aggregate size total).

If I add up all the 'total' byte values revealed via SNMP for all the volumes in the aggregate* I get 46.7TB, which implies 147% committed.

My belief is, the difference is related to snapshot reserve allocation, but this appears to be not revealed via SNMP, nor via any NetApp API counter. All the .snapshot instances report zero total bytes from an SNMPwalk of the relevant OID table (.1.3.6.1.4.1.789.1.5.4).

I need to be able to acquire this data programatically per aggregate, i.e. via any combination of SNMP or API. This can be done per-volume and summing values, or per aggregate if there's a suitable counter or counters (can't see anything obvious though).

Any suggestions? Many thanks in advance.

*Using suitable mathematics on the HighTotalKBytes and LowTotalKBytes OIDs at .1.3.6.1.4.1.789.1.5.4.1.14.x and .1.3.6.1.4.1.789.1.5.4.1.15.x

[JoelEdstrom]

Hi There,

Couple of quick questions.

- What version of ONTAP are you using, and 7mode or cDOT?

- Do you have OCUM in the environment that you can use or do you need to get the information directly from the filers themselves?

[Antony_LogicMonitor]

Hi,

- Variously, NetApp Release 8.1.4P1 7-Mode and 8.1.4P8 7-Mode

- I need to acquire the data directly from the filers. The only protocols I can access (for the purposes of this project, currently) are SNMP and the NetApp API counters; whatever method I end up with needs to work based on just these two, i.e. in the presumption OCUM will not be available in all cases.

Many thanks

[JoelEdstrom]

Hi,

That helps narrow things down a bit.  I don't have access to my 7mode simulators at this moment to test this right now, but taking a look through the Zedi Explorer/Zexplore tool it looks you might get commit numbers with the 'aggr-space-list-info' API.  

Here's a screenshot from zexplore showing what values are expected to return:

If you have NetApp's manageability SDK installed (available from their support site) you could probably test this out pretty quickly in zexplore and see if the numbers look right.  I can try and test this out over the next day or two when I get some spare time too.

[Antony_LogicMonitor]

Ooh, now that looks promising - many thanks, I'll go look for that tomorrow when I'm back on that task.

Cheers!

[JoelEdstrom]

Unfortunately, that command didn't return the real commit/thin sizes as expected...at least not in my simulator.  It'd be worth trying out on a real filer but probably won't return the right info.

The api named 'volume-list-info' does return the right information though.  It looks like your best bet would be to run that API and filter by the attribute 'containing-aggregate'.  Once that is done you could add up attributes 'filesystem-size'  to get your max commit for an aggregate.

[antifraudsystem]

Hi!

You finally find the problem solution?

i want to get de commited space but i don´t know what is the trap who put this data