pacemaker+corosync加密需三处同时配置才生效：corosync.conf中crypto块encrypt=on且hash=sha256；/etc/corosync/authkey权限400、内容一致；crm_mon -1不显示crypt:none。
如何确认 Pacemaker + Corosync 集群的通信加密已真正启用
默认不加密，光配 crypto 选项没用，必须同时满足三处配置才生效。
-
corosync.conf中crypto块必须存在且encrypt设为on，hash推荐用sha256（sha1已被多数发行版弃用） - 所有节点的
/etc/corosync/authkey文件权限必须是400，且内容一致——用corosync-keygen生成，别手写或复制错字节 - Pacemaker 不参与加密协商，但若
crm_mon -1输出里出现crypt: none，说明 Corosync 根本没读到加密配置，优先检查corosync -t是否报crypto: invalid config
为什么 pcs resource cleanup 有时清不掉 stuck 资源
不是命令没执行，而是底层状态没同步或资源代理返回了模糊退出码。
- 先看
pcs status是否显示Failed或Unmanaged；如果是后者，得先pcs resource unmanage再manage -
cleanup只清理 LRM（Local Resource Manager）缓存，不重启服务——若资源进程卡死，得手动kill -9后再 cleanup - 某些资源代理（如
systemd类型）在stop阶段超时后会直接标记为failed，此时 cleanup 无效，需加--full参数强制重置全状态
使用 crm_resource --cleanup 与 pcs resource cleanup 的实际区别
前者是底层命令，绕过 pcs 抽象层，能处理部分 pcs 屏蔽掉的异常状态，但风险更高。
-
pcs resource cleanup默认只清理当前节点的记录，加--all才广播到集群；而crm_resource --cleanup默认作用于整个集群，无节点范围限制 - 当资源定义含
clone或master/slave时，pcs会自动补全实例名，crm_resource必须显式指定完整 ID，例如myip:1而非仅myip -
crm_resource --cleanup不校验资源配置语法，若资源已删除但残留状态，它可能报No such resource并静默退出，不如pcs给出明确提示
Corosync 日志里反复出现 Could not find joiner 的真实原因
不是网络不通，大概率是 quorum 策略和节点上线顺序冲突导致的“假失联”。
- 检查
quorum.provider：若用corosync_votequorum，所有节点必须同时启动或严格按顺序加入；若用qdevice，确认 qnetd 进程存活且端口（默认5403）可达 - 节点重启后若
corosync启动早于pacemaker，会出现短暂joiner找不到状态，属正常；但若持续超过 30 秒，查journalctl -u corosync -n 100是否有Cannot initialize votequorum - 多播模式下，交换机 IGMP snooping 若开启，会导致新节点无法收到 join 请求——改用
udpu或关掉 IGMP snooping 更可靠
