适用场景
- 产品：
ZCF - 组件：
Cloud - 版本：
4.4.x、3.8.x - 部署形态：双管理节点
- 触发条件：ShareBlock 主存储连接失败，底层大量物理机 lock 无法释放，
vgchange卡住，并确认为sanlock历史已知 BUG。
问题现象
- ShareBlock 主存储提示连接失败。
- 大量物理机 lock 无法正常释放。
vgchange命令卡住。- 问题根因已定位到
sanlock组件历史 BUG。
判断方法
- 先确认主存储连接失败是否伴随锁释放异常。
- 检查
sanlock/lvmlockd是否存在无响应进程。 - 升级后检查
sanlock版本是否达到3.8.x。
原因说明
，本次问题并非单纯链路抖动，而是 sanlock 历史已知 BUG 导致大量锁无法释放，进一步引发 vgchange 卡住和 ShareBlock 主存储连接失败，因此修复核心是升级底层 sanlock 组件。
解决方案
- 执行前准备
- 风险等级：高
- 先关闭云主机全局高可用。
- 先备份双管理节点数据库。
- 先把物理机和存储
ping间隔调大到24h (86400s)，避免自动重连覆盖升级操作。 - 必须先单台验证，再批量推广。
- 处理步骤
- 备份数据库：
zstack-ctl dump_mysql- 在 VIP 管理节点和从节点都执行。
- 预期结果：具备平台侧回退基础。
- 在全局配置中把物理机和存储
ping时间调整到86400秒。
- 预期结果：升级期间主机不会被自动重连干扰。
- 强制结束无响应的锁进程：
pkill -9 sanlock && pkill -9 lvmlockd
ps -ef | grep -E "sanlock|lvmlockd"- 预期结果：卡死的锁进程被清理，便于继续升级。
- 单台升级
sanlock组件：
yum install ./sanlock*.rpm- 预期结果：目标主机先完成组件替换。
- 检查版本：
rpm -qa | grep sanlock- 预期结果：版本为
3.8.x。
- 单台确认流程正常后，再批量升级其他机器。
- 预期结果：避免一开始大范围推广引入不可控风险。
- 升级完成后，重连物理机。
- 恢复全局高可用与原
ping间隔配置。
- 预期结果：平台恢复正常运维策略，ShareBlock 重新稳定连接。
验证方法
- 检查
rpm -qa | grep sanlock显示为3.8.x。 - 检查 ShareBlock 主存储恢复连接。
- 检查
vgchange不再卡住。 - 检查主机重连和业务运行正常。
风险与回滚
- 风险：这是底层组件升级，若操作不当可能扩大存储影响面。
- 风险：若主机处于
Connecting / Disconnected / Unknown且链路异常时直接重连，可能导致主存储问题扩大。 - 风险等级：高。
- 风控动作：
- 在 UI 中按 UUID 找到异常主机。
- 检查该主机到 ShareBlock 的 FC/iSCSI、多路径和磁盘识别情况。
- 若只有单台异常，先隔离/维护该主机，避免影响整个主存储重连。
- 等主机恢复后再操作存储重连。
- 回滚：无细化的 RPM 降级命令，重点放在先单台验证和异常主机隔离控制风险。