外观
高可用入门：fencing 与 watchdog
集群与高可用已经介绍过 HA 的前提条件（至少 3 节点或 2 节点 + QDevice、共享存储、可靠 fencing）。这篇在满足前提条件之后，讲怎么真正打开 HA、它背后的两个守护进程在做什么，以及资源状态怎么理解。
为什么需要它
HA（高可用）的目标是：一个节点意外挂了，它上面配置了 HA 的客户机能在另一个节点上自动拉起来，不需要人工干预。代价是复杂度和一种新的行为模式——节点会在特定条件下自我重启，这是设计如此，不是故障。
开始之前
打开 HA 前，确认：
- 已经满足集群与高可用里列出的前提条件。
- 客户机磁盘在共享存储上，或者已经配置了ZFS 存储复制。磁盘只在本地存储、又没做复制的客户机，不要指望 HA 能把它救活在别的节点上——目标节点根本读不到它的磁盘。
- 想清楚要不要用硬件 watchdog。没有配置硬件 watchdog 时，PVE 使用 Linux 内核自带的 softdog；要用硬件 watchdog 需要在
/etc/default/pve-ha-manager里指定对应内核模块(例如WATCHDOG_MODULE=iTCO_wdt)，这类模块出于安全考虑默认是禁用的，需要额外确认硬件支持。
fencing 触发的重启是保护机制，不是故障
一个节点失去 quorum 后，如果它上面还挂着正在跑的 HA 服务，watchdog 会在超时（默认约 60 秒）后重启这个节点，确保不会出现两个节点同时跑同一台客户机（脑裂）导致数据损坏。这是 HA 正常工作的一部分。如果你不希望某台节点承担这种行为，就不要在它上面配置 HA 资源。
两个后台角色
| 组件 | 作用 |
|---|---|
pve-ha-lrm(本地资源管理器) | 跑在每个节点上，读取该节点应该运行的 HA 资源状态并执行（启动/停止/迁移），结果写回 /etc/pve/nodes/<节点名>/lrm_status |
pve-ha-crm(集群资源管理器) | 只有拿到集群锁的那个节点是"当前决策者"，负责判断某个节点是否需要被判定为失联、要不要触发 fencing 和资源接管 |
操作步骤：给一台虚拟机打开 HA
Web UI
数据中心 → HA → Add（或者选中虚拟机后从操作菜单里进入 HA 管理），选择要保护的虚拟机/容器，设置初始状态。具体入口名称以你版本的界面为准。
命令行
sh
# 把虚拟机 100 纳入 HA 管理,初始状态为 started
ha-manager add vm:100
# 修改期望状态
ha-manager set vm:100 --state started| 状态(state) | 含义 |
|---|---|
started(enabled 是它的别名) | 保持运行，节点故障后在其他节点自动恢复 |
stopped | 保持停止，但节点故障时仍会被"重新定位"到其他节点（只是不会自动开机） |
disabled | 不再被 HA 接管或迁移，是让资源从 error 状态脱离出来的唯一方式 |
ignored | HA 完全不管这个资源，相当于临时退出 HA |
检查结果
sh
ha-manager status查看资源当前状态是否符合预期(started 类资源应处于 started，而不是卡在 error 或 fence 等中间状态)。
想验证 fencing 真的有效，只能在实验环境里真做一次
最可靠的验证方法是：在一个非生产的测试集群上，真的断开一个节点的网络，观察它是否被重启、它上面的 HA 资源是否在其他节点拉起来。生产环境不要为了验证而故意断网——这等于主动触发一次真实的服务中断。官方还提供 pve-ha-simulator(apt install pve-ha-simulator)可以在不影响真实节点的情况下模拟 HA 决策过程。
常见问题
打开 HA 后节点自己重启了。 大概率是这个节点失去了 quorum,watchdog 按设计把它重启了。检查 corosync 网络是否稳定，详细排查见集群失去 quorum和节点自己重启了。
节点故障后，客户机没有在其他节点上启动。 检查磁盘是不是只在本地存储上，没有共享存储也没有配置存储复制——这种情况下 HA 无能为力。
资源卡在 error 状态出不来。 按上表，只有把状态改成 disabled 才能清除 error，排查问题后再改回 started。