cas添加共享存储报错

现象总结
集群共 13 台 CVK；由非欧拉版本升级至 CAS 欧拉 R0785P03；12 台节点添加共享存储正常，仅 1 台节点报错【该存储无法访问】。
关键背景：升级操作系统后出现单点异常，其余节点正常 → 问题锁定在故障节点本地系统、服务、配置、内核模块、防火墙、残留旧版本缓存，排除存储侧全局权限问题。
根因优先级排序（由高到低）
1、升级后节点本地服务异常（最高概率）
CAS 依赖cvk-agent、fsmd存储管理服务，跨系统版本升级（非欧拉→欧拉）极易出现服务文件残缺、自启异常。
正常节点升级包完整，故障节点升级过程存在中断 / 文件缺失。
2、欧拉系统防火墙 / SELinux 策略差异
旧版非欧拉系统防火墙规则宽松；升级欧拉后 firewalld 默认策略收紧，故障节点防火墙拦截存储协议报文（iSCSI/NFS/CIFS）。其他节点升级后自动生成放行规则，此节点规则未同步。
3、OCFS2/O2CB 集群残留信息（共享文件系统场景）
升级前节点非正常卸载共享存储，本地遗留集群心跳信息；新系统 OCFS2 进程判定节点锁冲突，拒绝挂载共享文件系统。
4、多路径 / 存储内核模块加载异常（SAN/iSCSI 存储）
multipathd、open-iscsi服务启动失败；multipath.conf配置与正常节点不一致，WWID 黑名单异常，无法识别存储 LUN。
5、主机标识、集群缓存不一致
升级后 CVM 集群数据库内主机信息与故障节点本地标识不匹配，存储托管校验失败。
6、底层网络驱动 / 网卡参数异常
升级欧拉内核后网卡驱动变更，存储网存在丢包、MTU 不匹配，仅单节点链路异常。
标准化分层排查步骤（现场直接执行）
操作前提：确认存储类型（NFS /iSCSI/ FC SAN），先收集报错界面完整截图。
第一层：基础连通性测试（故障节点 SSH 执行）
bash
#1. 连通性
ping 存储IP
#iSCSI测试端口3260；NFS测试2049、111
telnet 存储IP 3260

#2. 临时关闭防火墙验证（测试用！业务低峰执行）
systemctl stop firewalld
setenforce 0
✅关闭防火墙后可以添加存储 → 永久方案：配置 firewalld 放行存储协议端口。
第二层：CAS 存储相关服务校验
bash
#查看核心服务状态
systemctl status cvk-agent
systemctl status fsmd
systemctl status open-iscsid
systemctl status multipathd

#异常则重启
systemctl restart cvk-agent
systemctl restart fsmd
查看日志定位报错：
bash
journalctl -u cvk-agent -n 100
journalctl -u fsmd -n 100
第三层：SAN/iSCSI 存储额外检查
bash
#发现存储目标
iscsiadm -m discovery -t st -p 存储IP
#多路径查看设备
multipath -ll
对比正常节点输出，若无法发现 target：iscsi 服务异常 / 网络拦截。
第四层：NFS 共享存储额外检查
bash
showmount -e 存储IP
#无法获取导出列表：客户端组件缺失/防火墙拦截
第五层：集群残留 OCFS2 清理（共享文件系统场景）
⚠️风险操作！确认该节点无虚拟机使用此共享存储
bash
#停止ocfs2集群服务
systemctl stop o2cb
systemctl stop ocfs2
#清理本地挂载残留
umount /vms/对应存储目录
第六层：CAS 平台层面修复方案
方案 A：主机【重新托管】（优先尝试，界面操作）
CAS 平台 → 主机管理 → 选中故障 CVK 主机 → 更多操作 → 重新托管
作用：清空节点集群缓存、重新注册 CVM、同步存储配置。
方案 B：清理主机与存储池关联（命令行，CVM 主控执行）
bash
#删除主机在存储池内旧关联信息
cvm storagepool removehost -p 存储池名称 -n 故障主机名
执行完成后，在故障节点重新添加共享存储。
第七层：终极验证手段
将故障节点重启（升级操作系统后部分内核模块必须重启才能正常加载）
重启无效：对比正常节点 /etc/multipath.conf、/etc/ocfs2/cluster.conf配置差异

平台升级后单个节点无法添加共享存储，而其他节点正常，这通常是该节点升级过程中残留了旧配置、状态不一致，或新系统环境下缺少依赖组件导致的。

你可以按照从易到难的顺序，依次排查以下几个方向：

🔍 第一步：检查节点与存储的连通性（最易操作）

这是最常见的原因，故障节点可能因配置问题无法访问存储网络。

1. 检查网络连通性：登录故障节点，通过 ping <存储IP> 确认网络是否可达。

2. 检查端口连通性：确认存储协议端口是否开放。例如，NFS使用2049端口，CIFS使用445端口：

   bash

   telnet <存储IP> <端口号>

3. 检查存储访问权限：

   • NFS：执行 showmount -e <存储IP>，确认故障节点IP是否在导出列表中。

   • CIFS：执行 smbclient -L //<存储IP> -U <用户名>，验证权限。

4. 检查多路径状态：如果是SAN存储，需检查多路径服务是否正常。

   bash

   systemctl status multipathd

   • 若服务异常，尝试重启：systemctl restart multipathd。

   • 检查 /etc/multipath.conf 配置文件是否有误。

🧹 第二步：清理节点上的残留配置（重点排查）

如果连通性没问题，问题很可能出在故障节点上残留了升级前的存储配置信息。

情况一：节点故障前未正常卸载共享存储

现象：节点异常退出时未正常卸载（umount）共享存储，导致集群仍认为它在占用资源。

解决方法：

1. 登录正常CVM节点，执行命令强制解除故障主机与存储池的关联：

   bash

   cvm storagepool removehost -p <存储池名称> -n <故障节点主机名>

2. 登录故障节点，清理本地残留的存储池配置文件并重新扫描：

   bash

   rm -f /etc/libvirt/storage/<存储池名称>.xml rm -f /etc/libvirt/storage/autostart/<存储池名称>.xml cvk storagepool rescan

3. 重启libvirtd服务：service libvirtd restart

情况二：集群配置文件不一致

现象：报错信息中包含“集群配置文件不一致”或“cluster.conf”字样。

解决方法：

1. 从正常的节点上复制正确的 /etc/ocfs2/cluster.conf 文件，覆盖到故障节点的相同路径。

2. 检查并统一所有节点的 /etc/default/o2cb 文件中的 O2CB_FENCE_METHOD 参数，确保一致。

3. 在所有节点上重启OCFS2服务：

   bash

   service o2cb restart service ocfs2 restart

⚙️ 第三步：检查欧拉系统兼容性与依赖

新系统可能缺少必要的存储客户端软件。

• NFS：确保安装了NFS客户端。

  bash

  yum install nfs-utils

• CIFS：确保安装了CIFS客户端。

  bash

  yum install cifs-utils

🛠️ 第四步：在CAS管理平台进行高级操作

如果以上步骤无效，可以尝试在管理平台进行操作。

1. 尝试“重新托管”：在CAS管理平台，对故障节点执行“重新托管”或“重新加入集群”操作。平台会自动清理缓存并重新注册。

2. 扫描存储适配器：在主机管理界面，尝试“强制扫描存储适配器”。

📋 第五步：深入日志分析（定位根本原因）

如果问题依旧，需要查看系统日志来定位具体错误。

• 系统日志：cat /var/log/messages | grep -i "storage"

• CAS代理日志：cat /var/log/cas-agent.log

• FSM日志：/var/log/fsm/fsm_core.log 和 /var/log/fsm/fsm_event.log

⚠️ 操作注意事项

• 备份元数据：在执行任何删除或强制操作前，强烈建议先备份CVM的系统配置和数据。

• 迁移虚拟机：确保故障节点上没有运行关键业务的虚拟机。

• 核对命令参数：在执行命令时，务必将 <> 内的内容替换为你的实际环境名称。

• 避免手动修改心跳文件：除非有绝对把握，否则不要手动删除 /dev/shm/heartbeat_* 等心跳文件。