ipaddr2资源无法秒级接管是因pacemaker默认依赖corosync心跳超时、资源监控间隔及stonith执行耗时，通常需15–30秒；压至1–3秒须同步调紧心跳周期、失败判定阈值并优化stonith。
为什么IPaddr2资源无法秒级接管？
不是配置错了，而是默认行为就不是秒级——Pacemaker 的故障检测和切换依赖 Corosync 心跳超时、资源监控间隔、以及 STONITH 执行耗时。从节点失联到 VIP 迁移完成，通常要 15–30 秒。想压到 1–3 秒内，必须同时调紧三处：心跳检测周期、资源失败判定阈值、以及禁用（或极快执行）STONITH。
pcs resource create定义VIP时的关键参数
直接用 IPaddr2 类型创建资源是最常用方式，但默认参数会拖慢响应。以下才是生产环境实测有效的最小延迟组合：
-
op monitor interval="2s" timeout="10s"：把监控频率提到每 2 秒一次，超时放宽到 10 秒（避免误判），比默认 10s/20s 快得多 -
meta migration-threshold="1" failure-timeout="30s"：只要失败 1 次就立即迁移，且 30 秒内不重试原节点 -
params ip="192.168.31.200" cidr_netmask="24" nic="eth0"：确保网卡名和子网掩码与实际一致，错一个字符会导致ip addr add失败，资源卡在starting - 不要加
op start或op stop自定义操作——IPaddr2内置逻辑已足够稳定，额外覆盖反而引入竞态
Corosync 心跳必须设为 udpu 单播 + 超短超时
多播（udp）在某些交换机或云环境中丢包率高，且默认超时太保守；双节点场景下，udpu 更可靠，且能手动压低检测窗口：
- 编辑
/etc/corosync/corosync.conf，确认transport: udpu，并在totem段加入： -
token: 3000（单位毫秒，3 秒内没收到心跳即触发怀疑） -
consensus: 3600（3.6 秒，决定是否踢出节点） -
fail_recv_before: 5（连续丢 5 个包才判故障，防瞬断误杀） - 改完必须
pcs cluster reload corosync，不能只 restart
STONITH 不是“关掉就快”，而是“换一种快法”
直接设 stonith-enabled=false 确实能省掉 fencing 时间，但脑裂风险极高，尤其在主机死机但网络未断的场景下，两节点可能同时绑 VIP，导致 ARP 冲突和服务中断。更安全的做法是：
- 用
fence_virt（KVM/QEMU）或fence_ipmilan（物理机带外）——它们通常能在 2–4 秒内完成断电 - 若无 fencing 设备，至少启用
qdevice仲裁，配合last_man_standing=1，让存活节点快速获得法定票数 - 绝对避免
no-quorum-policy=ignore单独使用——它会让集群在只剩 1 节点时继续服务，但此时无法判断对方是真宕机还是网络分区
真正影响接管速度的，从来不是 VIP 绑定那条 ip addr add 命令，而是 Pacemaker 等待 Corosync 报告“节点已死”、再等 STONITH 完成、最后才调度资源的整个决策链。每个环节松一扣，整体就慢十秒。
