在Linux环境中部署网络存储之后，最容易被忽视的环节就是持续且高可用的监控。很多团队用单台服务器跑监控代理，一旦这台机器重启或网络隔离，存储异常就无人知晓。真正稳妥的做法是把监控能力本身做成集群服务，当某个节点不可用时，另一个节点自动接手采集与告警。
一、整体架构设计
高可用网络存储监控通常由三部分组成：存储探测脚本、监控数据收集器、集群资源管理器。存储探测脚本负责检查挂载点是否可读写、延迟是否超标；监控数据收集器可以是Prometheus Node Exporter的扩展，也可以是自研Agent；集群资源管理器推荐使用Corosync与Pacemaker，它们能确保监控服务在多个节点间只运行一份，且故障即迁移。
为什么不能直接用Keepalived加脚本。Keepalived擅长IP漂移，但对服务健康状态的细粒度判断较弱，容易出现IP切了但监控进程已死的情况。Pacemaker支持资源约束、顺序启动、位置偏好，更适合把监控代理作为资源托管。下表对比两种方案：
| 方案 | 故障检测精度 | 资源依赖管理 | 脑裂防护 |
|---|---|---|---|
| Keepalived | 弱，主要看VRRP | 不支持 | 靠脚本辅助 |
| Corosync+Pacemaker | 强，可自定义监控 | 支持顺序与互斥 | Quorum机制 |
二、准备双节点集群
假设我们有两台Linux主机 node1 与 node2，系统为Ubuntu 22.04，均挂载了同一个NFS共享到 /mnt/storage。第一步是配置主机名解析与免密SSH，便于后续Pacemaker分发配置。务必保证两台机器时间同步，否则Corosync投票会出现抖动。
安装集群软件包时，建议关闭系统自带的防火墙干扰，或显式放行5404、5405 UDP端口。安装命令如下：
# 在两台节点分别执行 sudo apt update sudo apt install -y corosync pacemaker pcs sudo systemctl enable pcsd sudo systemctl start pcsd # 设置hacluster用户密码 echo 'hacluster:monitorpass' | sudo chpasswd
初始化集群前，用pcs cluster auth完成节点互信，再用pcs cluster setup创建名为 storage-mon 的集群。此时Corosync配置文件会自动生成，不需要手工编辑 corosync.conf。
三、编写存储监控脚本
监控脚本要能反映真实业务视角的存储健康度。仅看 mount 命令输出不够，因为内核挂载点存在但后端存储卡死时，mount仍显示正常。我们采用写入探针文件并读取的方式。
下面脚本检查 /mnt/storage 是否可写，并测量写读延迟，超过两秒则报错退出。注意使用 timeout 防止脚本卡死导致Pacemaker判定超时：
#!/bin/bash
# storage_health.sh
MP=/mnt/storage
TEST_FILE=$MP/.health_check_$$
if ! mountpoint -q "$MP"; then
echo "挂载点不存在"
exit 1
fi
start=$(date +%s%N)
timeout 2 bash -c "echo probe > $TEST_FILE && cat $TEST_FILE > /dev/null"
rc=$?
rm -f $TEST_FILE
end=$(date +%s%N)
cost=$(( (end - start) / 1000000 ))
if [ $rc -ne 0 ]; then
echo "存储读写超时"
exit 1
fi
if [ $cost -gt 2000 ]; then
echo "存储延迟过高: ${cost}ms"
exit 1
fi
echo "存储正常 延迟${cost}ms"
exit 0
该脚本退出码非0时，Pacemaker会认为资源不健康。我们将其封装为systemd服务并配合看门狗，比单纯 cron 更可靠，因为systemd能在进程挂掉时自动拉起。
四、将监控纳入Pacemaker资源
创建一个名为 storage-mon 的systemd资源，并配置为仅能在单一节点运行。这样避免两个节点同时探测造成写入冲突。使用 pcs 命令定义资源：
pcs resource create storage-mon systemd:storage-mon.service op monitor interval=30s timeout=10s pcs constraint location storage-mon prefers node1=50 node2=40 pcs constraint order start storage-mon then start prometheus-agent
上面的约束表示监控服务优先放node1，但若node1宕机，node2接管。顺序约束保证监控代理先于数据收集器启动。为防止脑裂，还需配置Quorum策略：
pcs property set no-quorum-policy=stop
当集群只剩一个节点且不具备法定票数时，停止资源而非继续运行，这避免了双主写入存储探针的怪象。对于两节点集群，可加一个仲裁设备，例如qdevice，提升可用性。
五、对接Prometheus告警
监控脚本的结果可以暴露为文本指标，由Node Exporter的 textfile 收集器读取。我们在脚本成功时写 OK 文件，失败时写 FAIL 文件，Prometheus据此生成告警。
# 在脚本尾部追加 if [ $rc -eq 0 ]; then echo "storage_health 1" > /var/lib/node_exporter/storage_health.prom else echo "storage_health 0" > /var/lib/node_exporter/storage_health.prom fi
Prometheus抓取配置中加入对应job，然后编写Alertmanager规则。当 storage_health == 0 持续一分钟，就向运维群发送消息。由于监控服务本身高可用，这条告警链路不会因单点失效而断掉。
六、验证与日常维护
部署完成后，可手动将node1置于待机模式，观察资源是否在node2启动，以及告警是否继续。命令如下：
pcs node standby node1 pcs status pcs node unstandby node1
日常维护中，存储后端升级时建议先 standby 监控节点，避免误报。日志集中在 /var/log/pacemaker 与 journalctl -u storage-mon.service，出现迁移异常时优先看 Corosync 成员关系变化。只要按上述结构落地，Linux上的网络存储监控就能在节点故障下依然守住告警底线。