Fence失败会导致Pacemaker卡住不切换，因其无法确认故障节点是否真正停止，为防脑裂而拒绝资源转移，状态显示stuck或UNCLEAN。
为什么Fence失败会让Pacemaker卡住不切换
Pacemaker 在检测到节点异常（比如服务崩溃、网络中断）后，不会直接迁移资源，而是先尝试 fencing —— 即强制隔离疑似故障节点。如果 fencing 失败或未配置，Pacemaker 会认为「无法确认该节点是否已真正停止服务」，为防脑裂，默认拒绝执行任何资源转移，状态卡在 pending 或 unmanaged，pcs status 中常显示资源 stuck 或节点 marked as UNCLEAN。
怎么确认是Fence本身没生效，而不是只是配了没用
关键看三处日志和状态输出：
-
sudo pcs status若出现Node X: UNCLEAN (offline)，且无 fencing 相关动作记录，大概率 fence agent 没触发 -
sudo pcs stonith show查看 STONITH 资源是否Started；若显示Stopped或Failed，说明 agent 启动失败 -
sudo journalctl -u pacemaker -n 100 --no-pager | grep -i fence和sudo journalctl -u corosync -n 100 --no-pager | grep -i "fence\|stonith"，重点找fence failed、no devices found、timeout、permission denied - 手动测试：运行
sudo pcs stonith fence nodeX，观察是否真能断电/重启目标节点；若报错Operation not supported或卡住超时，说明底层设备通信不通
常见Fence配置错误与修复要点
Fence 不是“配了就行”，必须满足硬件可达、权限闭环、集群感知三个条件：
- agent 类型选错：
fence_ipmilan需服务器带 IPMI 接口并开启 LAN，fence_virt仅适用于 KVM/qemu 环境；Azure/AWS 上要用fence_azure_arm或fence_aws，不能硬套物理机模板 - 凭证写错：IPMI 用户名密码、云平台 service principal 密钥、SSH 私钥路径等，全部需在
pcs stonith create命令中显式传入，且注意空格和特殊字符；sudo pcs stonith update <id> passwd=xxx修改后必须pcs resource cleanup <id>清理旧状态 - 网络不可达：心跳网段和 fence 设备管理网段不能混用；例如 IPMI 口走独立带外网（10.10.10.0/24），但
bindnetaddr配的是业务网（192.168.5.0/24），Corosync 就无法调用 fence agent - 权限缺失：运行
pcs的用户需有sudo免密执行 fence 命令的权限（如hacluster ALL=(ALL) NOPASSWD: /usr/sbin/fence_*），否则 agent 启动即被拒绝
双节点集群里Fence配置特别容易踩的坑
双节点场景下，quorum 和 fencing 是一对紧耦合机制，漏掉任一环节都会导致切换瘫痪：
-
two_node: 1必须配在/etc/corosync/corosync.conf的quorum段，且所有节点一致；否则 Corosync 无法进入 two-node mode，fencing 请求会被静默丢弃 - 双节点默认启用
qdevice或qnetd仲裁时，若 qdevice 宕机或网络不通，fencing 会因等待仲裁响应而超时挂起 - 没启用
no-quorum-policy=ignore且又没配 fencing，Pacemaker 会直接拒绝任何资源操作 —— 这不是 bug，是设计使然：宁可停服，也不冒脑裂风险 - 用
fence_pcmk（基于 Pacemaker 自身消息）替代硬件 fence 仅限测试环境；生产必须用真实断电能力的 agent，否则 fencing 形同虚设
最隐蔽的问题往往出在「fence 设备本身正常，但 Pacemaker 没拿到执行结果」：比如 IPMI 命令发出去了，服务器也重启了，但 agent 因超时未收到 BMC 返回码，就判定失败。此时得调高 timeout 参数，并确认 BMC 固件版本兼容所用 fence agent。
