Pacemaker 双节点：故障判定与仲裁机制

这份文档把"双节点高可用集群到底怎么知道对方挂了、挂了之后干嘛、双方互失联时谁说了算"用大白话+类比讲清楚。它和工程部署文档互补：部署文档讲"敲哪些命令"，本文档讲"为什么这么设计、各组件谁来判谁来动手"。

1. 一句话心智模型

把整个双节点 HA 想成 两个保安守同一座金库，每人一把钥匙，但规定"钥匙不能同时用"：

• 对讲机（Corosync + knet）：两人每秒互喊"我还在"，靠心跳确认对方活着。
• 点名法官（votequorum）：数"现在还有几个活人、够不够法定票数"。
• 大脑（Pacemaker）：收到"对方没了"后决定"谁该跑什么服务"。
• 行刑队（STONITH / Fencing）：在动钥匙之前，必须先把对方物理干掉，防止两人同时开金库。
• 第三方裁判机（qdevice）：两人互相看不见时，请一个中立保安室投决胜票，决定谁有资格当班。

2. 组件角色总览（费曼命名 → 真名）

3. 怎么知道对方"失联"了

判定失联这件事是 Corosync 做的，Pacemaker 只是接收结果。具体过程：

1. 正常运行时，A、B 每秒通过 Corosync 互发心跳令牌，走 knet。
2. B 宕机或心跳网断 → B 不再回令牌。
3. A 会按配置重传令牌默认约 10 次（totem.token 默认 1000ms × token_retransmits_before_loss_const 默认 10 ≈ 10 秒，外加 join/consensus 超时）。
4. 重传耗尽仍无回应 → Corosync 宣布 B 退出成员（membership change）。这步是 Corosync 判的，Pacemaker 还没出场。
5. votequorum 立刻重算法定票：在 two_node: 1 模式下，虽预期 2 票、只活 1 台，但规则特批"剩 1 台也算有法定票"，所以 A 不会因少数而自停。

4. 失联之后会做什么（按顺序）

1. 通知大脑：Pacemaker（pacemaker-controld）收到"B 没了"的事件。
2. 先杀（关键）：因为 stonith-enabled=true（生产必开），Pacemaker 铁律是——没确认 B 真死之前，绝不把 B 的资源搬过来。pacemaker-fenced 立刻调用 fence agent 把 B 物理断电/重启（STONITH）。
3. 确认死亡：STONITH 成功返回，B 被标记为"已围栏"。
4. 业务接管：Pacemaker 在 A 上启动原本跑在 B 上的资源——VIP、应用、文件系统/共享存储等，业务恢复。
5. 回归：等 B 修好、心跳恢复后重新加入，资源可保持留在 A（resource-stickiness），也可按策略迁回。

5. 双方都以为对方失联（网络分区 / 脑裂）

最危险的情况是中间链路断了，A、B 互相都判对方 lost。这次不是"一个真死一个假死"，而是"两人都以为自己是唯一活人，都要去开金库"。

为什么纯 two_node 会"猜拳"

在 two_node: 1 下，每个节点单独都算"有法定票"。于是 A、B 都认为自己有资格 → 都去围栏对方，变成围栏竞速（fencing race）。碰运气，极端时两边都 fence 不掉、最后都活着都开金库 = 共享盘损坏。所以 RHEL 官方对双节点集群强烈建议配 qdevice。

第三方裁判机 qdevice 怎么判

金库公司设了一个独立的中立保安室（qdevice），A、B 都能单独打电话过去。保安室只做一件事：按固定规则，只认证其中一人"有资格当班"。被认证的人拿到上岗许可（法定票），可以去拉另一个人的电闸并开金库；没被认证的人必须放下钥匙、原地待命。

6. 常见直觉误区：ping 网关？仲裁盘 = SBD？

误区一："心跳断了，去 ping 一下网关看看自己状态"

想法很自然，但在脑裂场景救不了你。网关只证明"你能上网"，证明不了"对方死了"：

• 对称分区时，两边都能 ping 通网关 → 都觉得自己是唯一的活人，都要去接管 → 还是脑裂。
• 集群里 ocf:pacemaker:ping 资源确实有正经用途：配成位置约束，让服务待在联网质量好的节点上（资源选路），但绝不用来防脑裂。
• 设计铁律：分区发生时，你对自己状态的判断不能当权威。裁决必须来自独立第三方（qdevice）或不可逆动作（围栏）。

误区二："配个仲裁盘" —— 对，它就是 SBD

SBD（STONITH Block Device）= 一块两节点共享的小盘（SAN / iSCSI / FC LUN）。但要分清它的角色：

7. qdevice 是服务吗？它只投票、不指挥

是服务，而且其实是"两个"守护进程：

• corosync-qnetd：跑在那台独立的第三方裁判机上的服务（这就是 qdevice 本体）。
• corosync-qdevice：跑在每个集群节点上的客户端，负责连到 qnetd、汇报"我还活着"。

它做什么、不做什么：

8. SBD vs Dell iDRAC：能同时用吗？

先纠正前提：SBD 不做"集群级裁判"，它是围栏机制（动手的那一层）。真正的分层：

结论：qdevice 与 iDRAC 不是 alternatives（不同层，不是二选一）；iDRAC 与 SBD 才是同层 alternatives，而且可以叠成双保险——这叫 fencing 级别（levels）：

• Level 1：先试 fence_ipmilan（iDRAC 带外断电）
• Level 2：iDRAC 万一连不上/失败，自动回退到 fence_sbd（共享盘）

配置思路（pcs）：

pcs stonith create ipmi-node1 fence_ipmilan ...   # iDRAC
pcs stonith create sbd-node1   fence_sbd ...       # SBD 共享盘
pcs stonith level add 1 node1 ipmi-node1           # 先试 iDRAC
pcs stonith level add 2 node1 sbd-node1            # 不行再试 SBD

9. 名词速查表

10. 常见误区（FAQ 复盘）

11. 自测题（点开看答案）

12. 配套资料与参考

本文档聚焦"为什么这么设计"，与以下工程文档互补：

• pacemaker-core-modules-training.html — Pacemaker 核心模块培训（架构/CIB/资源/约束/属性/工具链）
• pacemaker-two-node-cluster-setup.html — 双节点集群从零部署配置手册（命令可复制）

官方来源（RHEL 10 高可用集群文档）：

• Configuring and managing High Availability clusters (RHEL 10) — docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/configuring_and_managing_high_availability_clusters/
• 章节重点：Overview of HA、Creating a cluster、Configuring quorum、Configuring quorum devices (qdevice)、Fencing (STONITH)、SBD、Fencing levels。
• 社区补充：ClusterLabs Pacemaker / Corosync 文档、kronosnet (knet) 项目。