3. HPE存储性能数据采集工具
性能优化的第一步不是调参，而是拿到可信、可对比、可追溯的性能数据。HPE 存储产品线覆盖 3PAR/Primera/Alletra、Nimble Storage、StoreOnce 等多个平台，对应的采集工具也各有侧重。本节以“对一套真实阵列完成一次性能数据采集”为目标，梳理各工具的定位、适用场景与关键操作，并给出可复用的采集流程与判读依据。
一、先分清工具的能力边界
很多初学者会把 InfoSight 当成“万能监控”，把 SSMC 当成“性能分析器”，结果采集到的数据要么粒度不够，要么时间窗口错位。理解每个工具“能采什么、采多细、保留多久”是采集任务的前提。
| 工具 | 主要定位 | 典型采集对象 | 数据粒度/窗口 |
|---|---|---|---|
| HPE InfoSight | 云端 AI 运维与跨阵列分析 | 性能、容量、健康、告警、跨层关联 | 分钟级聚合，长期保留 |
| SSMC | 3PAR/Primera 图形化管理 | 实时性能图表、告警、配置 | 秒级实时，短期保留 |
| HPE 3PAR CLI | 命令行精细采集与脚本化 | statvlun、statport、srstat 等原始计数器 | 秒级，可自定义采样 |
| HPE StoreFront | 面向 StoreOnce/备份侧的监控入口 | 备份吞吐、去重率、作业状态 | 作业级/分钟级 |
| Nimble 分析工具 | Nimble 阵列内置分析与 InfoSight 联动 | 卷/池 IOPS、时延、缓存命中 | 秒级至分钟级 |
可以看到，InfoSight 适合“看趋势、看关联”，SSMC 适合“看当下、看单点”，CLI 适合“拿原始数据、做脚本化采集”，StoreFront 与 Nimble 工具则分别覆盖备份侧和 Nimble 平台。一次完整的采集任务，往往需要组合使用，而不是只依赖其中一个。
二、采集前的准备：明确对象与时间窗口
在动手之前，先回答三个问题：采哪套阵列？采哪个时间段？采哪些指标？以一套 3PAR 阵列为例，假设我们要排查“业务高峰期卷时延偏高”的问题，采集对象应锁定在承载该业务的卷（VV）及其对应的物理磁盘（PD）、端口（Port）和节点（Node）。时间窗口建议覆盖“高峰前 30 分钟 + 高峰全程 + 高峰后 30 分钟”，这样既能拿到基线，也能看到恢复过程。
三、用 CLI 采集原始性能计数器
3PAR CLI 是获取原始数据最直接的方式。以下命令在 3PAR/Primera 的 CLI 环境中执行，采样间隔 5 秒，共采 60 次，覆盖 5 分钟窗口：
# 采集卷级性能（IOPS、时延、队列深度）
statvlun -vvsum -iter 60 -interval 5
# 采集端口级性能（吞吐、IOPS）
statport -port 0:1:1 -iter 60 -interval 5
# 采集物理磁盘性能
statpd -iter 60 -interval 5
# 采集节点级 CPU 与缓存
srstat -cpu -iter 60 -interval 5
执行时建议将输出重定向到文件，便于后续分析：
statvlun -vvsum -iter 60 -interval 5 > vlun_perf_$(date +%Y%m%d_%H%M).csv
采集完成后，重点观察三列：IOPS、svct_ms（服务时间，毫秒）、qlen（队列深度）。判断依据是：若 svct_ms 持续高于基线 2 倍以上，且 qlen 同步上升，说明后端存在瓶颈；若 qlen 很低但 svct_ms 高，则更可能是前端链路或主机侧问题。
四、用 SSMC 做实时对照与可视化
SSMC 的价值在于把 CLI 的“数字”变成“图形”。登录 SSMC 后，进入 Performance 视图，选择对应阵列，添加需要观察的卷和端口。建议把采样间隔设为 5 分钟，时间范围设为“最近 1 小时”，与 CLI 采集窗口对齐。
在 SSMC 中重点看三张图：卷的 IOPS/时延曲线、端口的吞吐曲线、物理磁盘的利用率热力图。如果 CLI 显示某卷 svct_ms 在 10:15 突增，SSMC 上应能看到同一时刻该卷所在 PD 的利用率接近 100%。两者互相印证，才能排除“单点误报”。
五、用 InfoSight 做趋势与跨层关联
InfoSight 的数据来自阵列自动上报，适合看“过去 30 天”的趋势。进入 InfoSight 后，选择目标阵列，打开 Performance 面板，可以按卷、主机、端口维度查看历史曲线。它的独特价值在于跨层关联：当某个卷时延升高时，InfoSight 会自动关联到对应的物理磁盘、端口甚至主机 HBA，并给出“可能原因”提示。
在采集任务中，InfoSight 主要承担两个角色：一是提供长期基线，帮助判断当前异常是否“真的异常”；二是提供跨阵列对比，比如同型号阵列在相似负载下的表现差异。
六、Nimble 与 StoreFront 的补充采集
如果环境中还有 Nimble 阵列，可直接使用 Nimble 内置的 Analysis 功能，查看卷级 IOPS、时延和缓存命中率。Nimble 的 InfoSight 联动会自动上传数据，采集方式与 3PAR 类似，但指标命名不同，例如 Read Latency、Write Latency、Cache Hit Ratio。
StoreFront 则面向 StoreOnce 备份设备，采集重点是备份吞吐、去重率和作业完成时间。若性能问题发生在备份窗口，StoreFront 的数据能帮助判断是备份侧瓶颈还是主存储侧瓶颈。
七、一次完整采集任务的执行顺序
综合以上工具，推荐按以下顺序执行一次真实采集任务：
- 确认阵列型号、微码版本、NTP 状态，记录采集起止时间。
- 在 SSMC 中打开实时性能视图，确认目标卷和端口可见。
- 在 CLI 中执行 statvlun、statport、statpd、srstat，输出到文件。
- 在 InfoSight 中拉取同一时间段的趋势图，保存截图或导出 CSV。
- 若涉及 Nimble 或 StoreOnce，分别用 Nimble Analysis 和 StoreFront 补充采集。
- 将 CLI 原始数据与 SSMC/InfoSight 图表按时间轴对齐，标注异常点。
- 输出采集报告：对象、窗口、指标、异常点、初步判断。
八、采集结果如何判读
采集完成后，不要只看“最大值”。建议按以下逻辑判读：先看时延是否超过基线，再看队列深度是否同步上升，最后看物理磁盘和端口利用率是否饱和。如果时延高但队列浅、磁盘利用率低，问题可能在主机或 SAN 链路；如果时延高、队列深、磁盘利用率高，问题在后端存储。
以下是一个简化的判读对照表，供采集后快速定位方向：
| 现象 | 可能方向 | 下一步采集 |
|---|---|---|
| 卷时延高，qlen 低 | 主机/SAN 链路 | 主机侧 iostat、交换机端口统计 |
| 卷时延高，qlen 高，PD 利用率高 | 后端磁盘瓶颈 | statpd 细化到单盘，检查 RAID 分布 |
| 端口吞吐高，卷时延正常 | 前端带宽接近上限 | statport 查看端口队列和错误计数 |
| InfoSight 提示缓存命中率下降 | 缓存压力或热点卷 | srstat -cpu 查看缓存使用 |
完成上述采集与判读后，你会得到一份包含原始计数器、可视化图表和初步结论的数据集。这份数据集是后续容量规划与性能调优的输入，也是验证优化效果时的对比基线。采集本身不是目的，让数据“可对齐、可对比、可追溯”才是关键。