This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Changing Storage Polling

We suffered an outage due to Storage behaviour suddenly being maxed out. We were polling capacity every 6 hours and between those two 2 polls was all it took.

I raised a question here about how to alert on change of behaviour and subsequently a feature request if you'd be so kind.

One request we had from the business was to increase the polling to monitor Capacity every 30mins for example instead of 6hourly. Concious this might mean a growth in DB until  the weekly/monthly averaging up takes effect but any other issues?

According to the SW document here I need to get the vendor guidance on each SAN model but any issues SW side?

Has anyone dropped the 6 hourly values right down? That first line 'changing the frequency the data is polled by SRM does not alter the frequency the data is collected' is confusing me. SW poll SAN more often but SAN might only poll itself at a fixed speed so more than that is pointless?

I found also this article which leads me to believe that the max frequency the data is provided is limited by the SMI-S in this case, or perhaps the SAN, we monitor about 37 SANs and all but 2 are direct due to issues seen with SMI-S reliability for SW SRM pass-through.

Also someone did mention /Orion/Admin/AdvancedConfiguration/Global.aspx and this setting, stating Capacity runout time is only calculated weekly, but I am hoping that may just be the Capacity Runout date, not the Capacity data changing.

Hoping someone has tried similar and has some advice/guidance

Thank you

  • The reason we direct you to the device vendor before changing that is so you can find out how frequently they are updating the values on their end before changing the interval in SRM. Polling the device more frequently when the device is not updating that value will just result in SRM collecting redundant values and that can actually make the data less valuable because we now have numerous redundant (and possibly incorrect) values in the calculations. It is also important to note that some of the vendors purposely update those values on a somewhat infrequent interval because calculating them can be taxing on device performance. So that is why it is important to understand what the vendor is doing on their side before changing the interval.

  • Thank you for the clarity

    Do you have any advice for that 7 day runout calculation in the advanced settings?

  • Yes, I spoke with the engineering team about that briefly and they said that changing that value will not help make the data any more granular. It has more to do with the priority given to the job that calculates the runout date.