Linux 高可用架构中的运维关注点

心跳检测失败时日志报“Cannot initialize crypto”是密钥不匹配或权限错误所致；authkey 须用 corosync-keygen 生成、权限 400 且 root:root 属主、各节点完全一致；crm_mon - 1 显示 offline 而 pcs status 显示 active 是因二者查询层级不同，前者反映真实运行态；DRBD 切换后挂载点残留需显式配置 RA 并禁用静态 fstab；move 迁移后资源不回原节点是因 cli-prefer 约束未清除，应手动 remove 或改用 ban 命令。

心跳检测失败时，corosync 日志里反复出现 ERROR: Cannot initialize crypto

这是密钥不匹配或权限错误的典型表现，不是配置语法问题。Corosync 启动时会校验 /etc/corosync/authkey 的完整性与可读性，但不会明确告诉你缺了哪一环。

• authkey 必须由 corosync-keygen 生成，手动生成的二进制文件（比如用 dd 或 openssl rand）大概率触发该错误
• 该文件权限必须是 400，且属主为 root:root；任何组 / 其他用户可读都会被拒绝加载
• 所有节点上的 authkey 必须完全一致——复制时别用 scp -p，它可能保留源端时间戳但改不了权限，建议手动 chmod 400 再验证

crm_mon -1 显示资源 offline，但 pcs status 却显示 active

这不是状态不一致，而是两个命令查的是不同层级：前者看 Pacemaker 实际调度结果，后者看 pcs 自己缓存的配置快照。真实运行态以 crm_mon -1 为准。

• 常见诱因是资源代理（RA）脚本退出码异常，比如 ocf:heartbeat:IPaddr2 在绑定 VIP 失败时返回 OCF_ERR_GENERIC（即 1），Pacemaker 会标记为 failed 并尝试迁移，但 pcs status 还没刷新
• 检查具体资源日志用 journalctl -u pacemaker --since "2 hours ago" | grep -A5 -B5 "resource-name"，别只盯 pcs status 输出
• 若频繁发生，确认网卡是否存在 NOARP 设置冲突，或内核参数 net.ipv4.conf.all.arp_ignore 是否干扰了 VIP 响应

DRBD 主从切换后，mount 挂载点残留导致服务启动失败

DRBD 状态切换本身不触发文件系统卸载，Pacemaker 也默认不自动 umount —— 它只管调用 RA 脚本里的 stop 方法，而很多 RA 并未在 stop 阶段做清理。

• 务必在资源定义中显式添加 meta is-managed=true allow-unmanaged-disk=false，否则 Pacemaker 可能跳过磁盘状态校验直接启动服务
• 推荐用 ocf:heartbeat:Filesystem RA 替代裸 mount 命令，并设置 op start timeout=60s on-fail=fence，避免挂载卡住拖垮整个 failover 流程
• 切忌在 /etc/fstab 里静态声明 DRBD 设备，Pacemaker 不会读它，反而会在 reboot 后造成设备忙（busy）无法接管

使用 pcs resource move 强制迁移后，资源回不去原节点

这是因为 move 实际是给资源加了临时位置约束（cli-prefer- 开头的 constraint），它不会自动清除，也不会被 pcs resource cleanup 删除。

• 查看残留约束用 pcs constraint location show --full，里面带 cli-prefer- 前缀的就是手动 move 留下的
• 清除指定资源的临时约束：pcs constraint remove cli-prefer-resource-name（注意替换 resource-name）
• 更稳妥的做法是不用 move，改用 pcs resource ban --node node1 resource-name，它生成的是时效性约束，默认 30 分钟后自动失效

高可用运维最耗时间的往往不是配置写对，而是这些“看起来动了、其实没生效”或“动过了、但没清干净”的中间态。每次操作后，多看一眼 crm_mon -1 和 pcs constraint location show，比反复重启服务有用得多。