Volume Autosize Alert Not Working

[christop]

I am trying to test Operations Manager alerting for a volume autosize event with DFM 3.7.1 and ONTAP 7.3.1.

I would think that all I need to do is trigger an autosize event on the controller, and I would see the information-level event for "volume autosize" on the Operations Manager GUI.

How soon after an autogrow event happens on the controller should I see an event show up in Operations Manager?  Does anything need to be configured on the controller or within Operations Manager to get this to work?

Thanks,

Chris

[tanmoy]

Hi Chris,

You need to set the snmp traphost as your DFM server IP on controller to get that information event on server.

E.g

Filer> snmp traphost add <dfm-server-ip>

Thanks

Tanmoy

[christop]

Thanks.  I set the snmp traphost on the controller and still cannot get the alert to generate.

The DFM host diag passed the SNMP verification test from the DFM server.

Is there anything else I'm missing with my controller setup?  Anything need setup on the DFM server itself?

[adaikkap · Accepted solution]

Hi Chris,

          What is the value of snmp init the filer ?

The value should be 1 this initializes the snmp daemon in case of init commands.

Also these events are of the severity information. so they wont appear in the dfm report view events <volumename/id>.

Rather you must use dfm report view events-history to view the same.

In the web ui under the events sub section of the volumes details page there are two links current and history by default

current events are shown. These events will appear under history.

Regards

adai

[pascalduk]

I wondered also some time ago why that event did not appear. Setting the snmp traphost and snmp init to 1 fixed it. I did not need to set snmp authtrap to 1 to get it working.

Was this anywhere documented and I just missed it?

[shailaja]

The list of events generated in OpsManager that are dependent on traps sent from the storage system are listed in OpsManager documentation.

(Appendix A - List of Events and Severity Levels) This includes volume autosize, snapshots getting autodeleted on a volume and maxdirsize limit reached.

The steps to add a traphost on a storage system would be available in ONTAP documentation (Network Management Guide).

Can be done by CLI or FilerView (SNMP --> Configure)

snmp init -- Enables (with value 1) or disables (with value 0) built-in traps and the traps defined using the snmp traps command

snmp traphost [{add|delete} { hostname|ipaddress}] -- Adds or deletes SNMP hosts that receive traps from Data ONTAP.

Thanks,

Shailaja

[christop]

Thank you!  "snmp init 1" and setting "snmp traphost" to the IP of my DFM server worked like a charm!

I also modified the event severity from "informational" to "emergency" with "dfm eventtype modify <event-name>" at the DFM CLI.

In our customer's case, we are using these alerts to manage a thin-provisioned SAN environment and we are treating autosize events as emergency events that require immediate action.

Not sure how other customers are using this, but I would think since an autosize event is consuming space we should consider setting this event to "critical" by default in future releases.

[ameet]

Hi Christopher,

This is not related to your query, but is it possible to describe your thin provisioning configuration?

Does your configuration have the danger of writes failing when aggregate runs out of space ?

Thanks,

Ameet

[adaikkap]

Hi Chris,

              It is not advisible to change the event severity of this event.

As there is no neutralization event for the same.So your volumes status will always not be normal (green) even

when autodelete stops or volume size becomes ok

Regards

adai

[christop]

Thank you for the feedback on changing the event severity.  I think we will need to manually delete or acknowledge the event to clear the "emergency" status.  I was not aware there was no neutralization event, but that makes sense since ONTAP does not provide one.  I think we can live manually acknowledging/deleting events for our setup.

Our thin-provisioning setup consists of FCP only.  Volume guarantees set to none, LUN space reservations disabled, space reservations set to zero, and autodelete/autogrow enabled.  Autodelete will kick in if a volume needs space, then autogrow triggers if autodelete fails to provide enough capacity for a write operation.

We also have SnapVault relationships going to a secondary controller for each primary volume.  Autodelete will preserve the SnapVault snapshot in all cases.

This thin provisioning setup is in a certification phase at the moment.  We hope to deploy to production in the coming months and will be relying on Operations Manager for volume autosize alerts.

Are there also alerts for snapshot autodelete events?  I did not see any at first glance at GUI, but I did not look too deep into the events available via the DFM CLI.

[shailaja]

>> Are there also alerts for snapshot autodelete events?  I did not see any at first glance at GUI, but I did not look too deep into the events available via the DFM CLI.

dfm eventtype list | grep autodelete

volume-snapshots-auto-deleted                 Information  snapshot.autodelete

This is also an informational event and dependent on traps from storage system.

Thanks,

Shailaja

[ameet]

Thanks for the describing your confguration to us.

- I did not follow what you mean by set "space reservations set to zero" ?

- I understand why you need auto-delete, but why do you need auto size on your volumes if they are of "none" guarantee? you can just create the

  volume of size = max-size itself, both ways you dont consume any space from aggregate? In your case auto-delete kicks in first and only if that fails

  you start consuming space from aggregate retricted by max size of volume and in the case I suggested auto-delete happens in the end if the

   volume becomes full. Is that distinguishing factor for you ?

- Also, have you looked at "Provisioning Manager", it provides policies to thin provision volumes, based on NetApp best practices ?

~Ameet

[christop]

Ameet:

This is probably a lot easier to discuss over the phone.

Please send me a calendar invite for when you or anyone else on your team would like to talk.

I'm looking forward to discussing this further with you!

My email ID is christop@netapp.com

Thanks!

Chris

[jenni]

Hi,

I'm currently out of the office with limited access to email. I'll be back

in the office on May 07.

If this is an urgent support issue requiring NetCache L3 attention, contact

my manager Dick Hacking (Dick.Hacking@netapp.com). Otherwise, you may call

our support line at 1-888-4NETAPP.

I'll return return any mails when I'm back in the office.

Regards,

-jenni

--

Jennifer Coopersmith

NetCache Sustaining Engineer

NetApp Global Services

NetApp

408.822.6908 Direct

jenni@netapp.com

www.netapp.com