GPFS 集群运维「神器」：手搓一个 EC 模式可视化监控平台，实现自动化飞书告警！
01 存储运维的「黑盒」之痛
做过大规模 GPFS（IBM Spectrum Scale）集群运维的同学都懂：
- 集群拓扑全靠
mmlscluster、mmlsnsd命令脑补； - EC（Erasure Coding，纠删码）模式的磁盘、Vdisk、Pdisk 关系错综复杂，文档里翻半天才能理清；
- 健康状态依赖
mmhealth+ 人工巡检，出了问题才发现； - 告警只能靠邮件，不能及时推送到日常工作的 IM 工具。
今天和大家分享一个「手搓」的 GPFS EC 模式可视化监控运维平台—— 基于 OpenClaw 技术栈打造，把一个复杂的存储集群变成一张「看得懂、管得住」的仪表盘。
图 1：平台 Dashboard 总览，一屏掌握集群运行全貌
02 为什么选择「手搓」？
目前业界对 GPFS 的监控方案多为通用型（如 Prometheus + Grafana），但对于EC 模式的专项监控往往不够细致：
| 需求维度 | 通用方案 | 自研平台 |
|---|---|---|
| EC 拓扑可视化 | ❌ 不支持 | ✅ 完整展示 |
| Vdisk/Pdisk 关联 | ❌ 需二次开发 | ✅ 原生支持 |
| 飞书实时告警 | ❌ 需自建桥接 | ✅ 内置配置 |
| 全中文友好界面 | ⚠️ 依赖模板 | ✅ 开箱即用 |
这个平台的核心理念是：让 GPFS EC 集群的每一层架构都「透明可见」。
03 核心功能一览
3.1 一屏总览：Dashboard
登录即见「Cluster Overview」，关键指标一目了然：
- 节点状态：4 节点全在线，Quorum 达成 ✅
- 存储概览：8 块 NSD 磁盘，已用 3.2 GB / 394.7 GB（仅 0.8%）
- 文件系统：1 个文件系统（fs01），20 块 Pdisk，17 个 Vdisk
- 健康摘要：Component Health Summary 柱状图，Node State Distribution 环形图
- 实时刷新：支持 5 分钟自动刷新，数据不落伍
图 2：Component Health Summary 与 Node State Distribution，集群异常一眼定位
3.2 拓扑可视化：告别「脑补」架构
GPFS EC 模式的架构逻辑是：
Filesystem → Recovery Group → Declustered Array → Pdisks ↓ Vdisks（4+3p EC / 4Way Replication） ↓ NSD → 挂载到节点这个平台用分层拓扑图把这关系画清楚了：
图 3：GPFS 集群拓扑全景图 —— 从文件系统到底层物理磁盘的全链路可视化
拓扑面板可以看到：
- fs01文件系统挂载点及容量、Inode 使用率
- 8 个 NSD的网络映射关系
- Recovery Group rg01下的Declustered Array DA1
- 4 个 EC 节点（EC1~EC4），每个节点挂载 5 块物理磁盘，状态均为 healthy 🟢
运维价值：磁盘替换、扩容规划、故障定位时，不用再mmlsrecoverygroup翻命令行了。
3.3 节点管理：Live Node States
实时展示所有节点的存活与 Quorum 状态：
图 4：Live Node States（mmgetstate）—— 4 节点全部 active，Quorum 3/4 达标
- 节点名、状态标签（active 🟢）、Quorum 节点数
- 每个节点的3 quorum状态清晰可见
- 一旦发现节点掉线或仲裁丢失，秒级标红提示
3.4 存储资源全维度透视
📌 NSD 层（Network Shared Disks）
图 5：Storage NSDs 列表 —— NSD 到服务器、本地磁盘的映射关系
8 个 NSD 一一对应 EC01 服务器上的本地磁盘，每张盘 49.3 GB，使用率 1%，剩余 99%。
📌 Disk 层（物理磁盘详情）
图 6：Storage Disks —— 每块磁盘的元数据/数据承载状态、故障组、可用性
- 故障组（Failure Group）1/2 交替分布，确保冗余
- Holds Metadata / Holds Data：全是 yes，说明 EC 配置下磁盘同时承载数据和元数据
- 状态ready，可用性up🟢
📌 Pdisk 层（物理磁盘阵列）
图 7：Pdisks（mmlspdisk）— Recovery Group 下的物理磁盘健康与容量详情
Recovery Grouprg01下的所有 Pdisk，均归属 DA1，容量 99.9 GB，剩余约 10 GB，状态ok。
📌 Vdisk 层（虚拟磁盘与 EC 模式）
图 8：Vdisks —— 4WayReplication 与 4+3p EC 两种冗余策略一目了然
最关键的一张表，清楚展示了：
| Vdisk 类型 | RAID Code | 说明 |
|---|---|---|
| LOGHOME | 4WayReplication | 日志盘，4 副本高可靠 |
| VS001 | 4+3p | 数据盘，EC 纠删码模式 |
💡4+3p EC 的含义：数据被切分为 4 个数据块 + 3 个校验块，允许最多 3 块盘同时故障而不丢数据，存储利用率高达 57%（4/7），远高于 3 副本的 33%。
3.5 告警通知：飞书 Webhook 秒级推送
平台内置告警中枢，支持配置飞书机器人 Webhook：
图 9：Setup 配置页 —— 飞书告警、通知分级、后端参数一站式配置
- 多级告警过滤：ERROR / WARNING / INFO 按需勾选
- 一键测试：配置完立即测试 Webhook 连通性
- 即时推送：突破邮件延迟，故障秒级到达运维群
- 后端可调：GPFS 轮询间隔、UI 刷新频率、日志目录均可自定义
3.6 健康总览：mmhealth 图形化
将mmhealth cluster show的输出转成直观的健康矩阵：
图 10：Health —— mmhealth cluster show 的图形化呈现，9 大组件全绿通关
覆盖 9 大核心组件：NODE、GPFS、NETWORK、FILESYSTEM、DISK、FILESYSMGR、NATIVE_RAID、PERFMON、THRESHOLD，状态分级：
- 🟢 Healthy：健康
- 🟡 Degraded：降级
- 🔴 Failed：故障
- ⚪ Other：其他
当前集群9 大组件全绿，是个安心睡觉的好日子。
04 技术亮点总结
| 特性 | 实现效果 |
|---|---|
| EC 模式专项支持 | 完整展示 4+3p / 4WayReplication 的 Vdisk 策略 |
| 全链路拓扑 | Filesystem → RG → DA → Pdisk → Vdisk → NSD，层层穿透 |
| 实时 telemetry | 基于 IBM Storage Scale 原生命令采集，数据真实可靠 |
| 飞书原生集成 | 告警不再依赖邮件，运维响应速度提升一个数量级 |
| OpenClaw 自研 | 轻量级、可定制、无商业依赖，代码自己掌控 |
05 适合谁用？
- ✅ 运行 GPFS / IBM Spectrum Scale 的 HPC/AI 集群运维团队
- ✅ 使用 EC 纠删码替代传统副本策略的存储架构师
- ✅ 希望把「命令行式运维」升级为「可视化管理」的技术管理者
- ✅ 需要把告警推送到飞书/钉钉/企业微信的 DevOps 团队
06 写在最后
存储系统的稳定性是整个基础设施的底座。GPFS 作为一个功能强大但学习曲线较陡的分布式文件系统，EC 模式虽然在成本和可靠性之间取得了很好的平衡，但运维可视化的缺失一直是痛点。
这个平台的初衷很简单：让每一台服务器、每一块磁盘、每一个 Vdisk 的状态都清晰可见。
如果你也在做 GPFS 集群运维，希望这个项目能给你一些启发。
👇 文末互动
- 你目前在用什么工具监控 GPFS？Prometheus？自研脚本？
- 你最希望 GPFS 监控平台增加什么功能？
- 欢迎在评论区留言交流，或者转发给做存储的战友～
本文配图均为平台真实截图，集群规模为 4 节点 + 8 NSD 的测试环境。