Linux高可用集群可靠性的核心是及时故障检测、干净资源切换和杜绝脑裂；常见corosync启动失败因配置校验不通过或通信不通，需检查bindnetaddr、时间同步、防火墙端口；资源unmanaged需手动恢复管控，failed多因启动脚本错误；两节点必须配置qdevice防脑裂；亚健康状态下的决策鲁棒性才是最大挑战。

Linux 高可用集群不是装几个软件就能跑起来的，核心在于故障检测是否及时、资源切换是否干净、脑裂是否被杜绝——这三件事没理清，服务反而比单机更不可靠。

pacemaker + corosync 启动失败，日志里反复出现 corosync[xxxx]: [MAIN ] Corosync Cluster Engine exited with status 8

这是最常见的“启动即退出”问题，根本原因通常是 corosync 配置未通过校验或底层通信不通。pacemaker 依赖 corosync 正常运行，它一挂，整个集群就停摆。

• 先检查 /etc/corosync/corosync.conf 是否能被 corosync-cfgtool -s 解析成功；常见错误是 totem.interface.bindnetaddr 写成了具体 IP 而非网段（比如填 192.168.1.10 而不是 192.168.1.0）
• 确认所有节点时间同步：chronyc tracking 输出的 offset 应小于 50ms，否则 corosync 拒绝加入集群
• 防火墙必须放行 udp/5404-5405（corosync 默认端口），用 ss -uln | grep ':540' 验证端口是否真在监听

crm configure 命令添加资源后，pcs status 显示 unmanaged 或 failed

资源状态异常不等于配置写错了，而是 pacemaker 尚未尝试启动它，或启动后立刻崩溃。关键看 pcs resource debug-start <resource-id> 的实时输出。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• unmanaged 表示该资源被手动禁用（pcs resource unmanage <id>），需执行 pcs resource manage <id> 恢复自动管控
• failed 多因启动脚本返回非零码，比如 systemd 类资源依赖的 service 文件不存在，或 ocf:heartbeat:IPaddr2 的 ip 参数格式错误（应为 192.168.1.100/24，不能漏掉掩码）
• 避免直接改 crm configure 的 raw 文本，用 pcs resource update <id> param=value 更安全，否则语法错会导致整个 CIB 提交失败

两个节点都声称自己是 master，VIP 在两边同时响应（脑裂）

这不是配置遗漏，而是仲裁机制失效的典型表现。corosync 默认只做通信心跳，不判断“谁该活”，必须显式配置 qdevice 或至少一个 quorum device。

• 两节点集群必须启用 qdevice（如基于 qnetd 的仲裁服务器），否则默认 two_node: 1 实际上是危险模式：只要网络抖动，两边都会认为对方失联而抢资源
• 检查 pcs quorum status，若显示 Quorum: No，说明当前没有法定票数，所有资源会被强制停止
• 不要用 ping 节点作为仲裁手段（ocf:pacemaker:ping），它无法区分网络分区和真实宕机，极易引发误切

真正难的不是加机器、配资源，是让集群在丢包、时钟漂移、磁盘卡顿这些“亚健康”状态下依然拒绝错误决策。很多线上事故，都发生在 corosync 心跳延迟刚超阈值但还没断连的那几秒里——那里没日志，也没告警，只有沉默的 VIP 漂移。