Software Development Kit (SDK) and API Discussions

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

Antony_LogicMonitor
5,703 Views

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

6 REPLIES 6

JoelEdstrom
5,442 Views

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
5,438 Views

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
5,430 Views

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:

 

zedi_7mode_aggr_space_commit.PNG

 

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
5,370 Views

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

 

Cheers!

JoelEdstrom
5,155 Views

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
4,373 Views

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

Public