Storage Manager 5.7 Beta 1
Storage Manager 5.7 Beta 1
The Storage Manager Team is hard at work on STM 5.7. We’ve just arrived at that crucial stage of development, Beta 1, and would love your participation. Fill out this short survey to participate in the STM 5.7 Beta! Without further ado, let’s jump into what is available in Beta 1.
Improved Performance Charts
Users of Storage Manager have been pushing for a while to get more out the performance data in the product. Before I get into the solutions, let me outline some concerns voiced by you, the end user, about the current way performance data is displayed. Concerns with the current graphs have focused around several areas:
Concern | Old Chart |
---|---|
|
Unrelated to the charting package itself, but still valid concerns were:
- There were restrictions that in the product around displaying “Raw” or “Roll-Up Summary” data. Basically, in an effort to keep the product snappy and stable, STM automatically defaulted to Hourly, Daily, or Weekly Roll-up data depending time range selected. This was problematic when looking for peaks in performance data, as those peaks ended up being averaged out when looking at longer time ranges.
- The time selector only allowed you to see data from now with a defined “look-back” period of Last Hour, 6 Hours, 24 Hours, etc. If you wanted to look at a specific 6 hour period yesterday, you had to go to the Reporter tool, or you could look at the data from the last week, but were forced into problem #1 above and could only view roll-up data.
So with all that said, let’s take a look at the new and improved Storage Manager performance charts.
We’ve adopted the same charting package used by the SolarWinds Orion products. While some of the back-end software magic is different this enables several major improvements including:
New Benefit | New Chart |
---|---|
|
To address the other concerns, we also added:
New Benefit | New Chart |
---|---|
| |
For those of you playing along at home, you may have noticed one other UX improvement – contextual text highlighting! No more are you forced to guess what report you landed on! |
We made some other minor changes to the product that aren’t really super-exciting to test from an end-user perspective, but they are changes in product behavior so we’d definitely appreciate any feedback.
Change to Default Collection Frequencies
For STM 5.7, the default data collection frequencies have changed for SMI-S devices and VMware. Note that this will NOT affect upgrades, only fresh installs. If you’ve fine-tuned your collection frequencies for your environment, STM will respect that and maintain your settings upon upgrade. So why make the change? The main reason is stability of collection and matching that stability to how customers scale their systems over time. These changes were made to ensure a seamless first time user experience and allow new customers to fine tune these settings later as they better understand their monitoring needs and the product architecture. If you'd like to get a good primer on STM Deployment, this topic is discussed at length in this ThwackCamp session.
As always, if you need to modify collection frequencies post-install, you can do so through configuring STM Policies in Settings->Device Management->Policies. Remember that you have to “Push” your policies to your STM Proxy Agents for those new collection frequencies to take effect. For reference, these are new default collection frequencies for STM:
SMI-S policy | ||
Frequency type | Original value (prior to 5.7) | Updated value (5.7+) |
Asset | 12 hours | 24 hours |
Performance | 15 minutes | No Change |
Storage | 1 hour | 6 hours |
VMware policy | ||
Frequency type | Original value (prior to 5.7) | Updated value (5.7+) |
Configuration | 15 minutes | 3 hours |
Performance | 5 minutes | 30 minutes |
Storage | 1 hour | 6 hours |
Deprecating Generic “Storage Array” Reports
The “Storage Array” report category is a little bit of mystery to outside observers and deserves some historical discussion. While at first glance, the name might imply that this set of reports are what you use to report on your Storage Arrays from a single consolidated place, sadly that implication would be entirely off-target. Storage Manager’s location for all consolidated reports, across heterogeneous arrays, is the “Enterprise” reports. Any report in the “Enterprise” reports are tested by our Product Team to ensure that the data we are presenting is valid across every array we support, even when you report across heterogeneous array types in the same report. Such is not the case with the “Storage Array” reports.
So then, you might ask, “What are the purposes of the Storage Array reports?” And it is a fine question, no doubt. These reports are meant for reporting on a “Generic SMI-S Device.” “Well,” you might say, “my arrays support data collection via SMI-S, so those must be for my arrays.” Unfortunately, again, this would be off-target. The “Generic SMI-S Device” was a pie-in-the-sky dream, hatched in the early days of Storage Manager development, when there was thoughts that storage vendors might actually adopt the Storage Networking Industry Association’s (SNIA’s) Storage Management Initiative-Specification (SMI-S) standard as an actual standard. Instead, the vendors went off and implemented all of their array support via SMI-S completely differently (they are not completely at fault, of course, the standard lacked some key points mainly around how to present performance data). Thus, the “Generic SMI-S Device” in Storage Manager never really worked as anticipated and is “unsupported” as an official array type. Unfortunately, we never did as good a job as we should have to outline these restrictions thus leading to our current situation.
If the above is TL;DR, here is the nut: A good chunk of data presented in those reports is wrong because of how the vendors differed in their implementation of the SMI spec. If you want “Storage Array” report functionality, you need to use the array specific reports where the STM team has aligned the data provided to the vendor’s implementation of the spec. For example, if you own an EMC VNX, you should use the reports under Storage Array EMC VNX/CLARiiON. The data are correct in these reports.
If you are currently using these reports, we recommend you switch to the Storage Array reports for your specific devices. We have salvaged some of the reports and moved them to the “Enterprise” section, as some of the reports only needed minor modifications to report data consistently. These salvaged reports include:
- Storage – SMI-S Storage Array-LUN Masking
- Storage – SMI-S Storage Array-LUN Masking Summary (new report)
- Performance – SMI-S Storage Array-Array Performance
- Performance – SMI-S Storage Array-Controller Performance
- Performance – SMI-S Storage Array-Disk Performance
- Performance – SMI-S Storage Array-LUN Performance
Note that we did not remove the reports or their templates, but merely marked them as “Deprecated” in the product. This should give you time to move to the proper reports for your reporting purposes.
That's Not All Folks!
Note that this is only Beta 1 for STM 5.7. We have several more features we are cooking up in the lab, so watch here for future Beta announcements!
Top Comments