Linux 高可用集群安全与运维实践

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 更可靠

Pacemaker 和 Corosync 的状态同步机制很务实，但也很“较真”：它不猜你的意图，只认配置、时序和字节一致性。任何一步跳过验证（比如没核对 authkey md5、没等 qdevice ready 就起节点），后面的问题基本都源于此。