节点自己重启了

适用范围

一个集群节点在没有人手动操作的情况下自己重启了，尤其是这台节点上配置了高可用 (HA) 资源。

不适用于单机（非集群）环境的意外重启——单机没有 fencing 机制，重启原因通常是电源、硬件或内核问题，方向完全不同，见下面「排除 fencing 之外的原因」。

开始排查前

先确认这台节点是不是集群成员、有没有配置 HA 资源：

pvecm status
ha-manager status

如果这台节点不在集群里，或者集群里没有任何 HA 资源，那么本页描述的 fencing 机制不适用，直接跳到本页最后一节「排除 fencing 之外的原因」。

排查步骤

第一步：理解 HA 的自我重启（fencing）不是故障

在配置了 HA 的集群里，节点自我重启很多时候是故意设计的保护机制，叫 fencing：通过 watchdog（看门狗，一个必须被定期"喂狗"、否则会触发硬件复位的计时器）实现。

背后的逻辑：HA 需要保证同一个资源（虚拟机/容器）不会在两个节点上同时运行。如果一个节点失去了与集群多数派的联系（通常是 corosync 网络问题导致失去 quorum），其他节点上的 HA 管理进程会认为这个节点"失联"，并准备在别的节点上重新启动本该在它上面运行的资源。

但如果失联节点其实还在正常运行（只是网络断了），它上面的资源也还在跑。 这时候如果别的节点也把同一个资源启动一遍，就会出现同一台虚拟机同时在两个节点上运行、同时写同一块磁盘的情况，导致数据损坏。

Watchdog 机制正是为了避免这种情况：负责本地资源管理的服务 pve-ha-lrm 需要持续证明自己"正常且有 quorum"才能给 watchdog 计时器复位（喂狗）；一旦失去 quorum、或者它自己异常退出，就没法再复位计时器。官方文档给出的数字是watchdog 会在 60 秒后触发重启，把这台节点强制拉下线。

集群里另一侧负责统筹调度的 pve-ha-crm（每次只有一个节点的 CRM 处于主导地位）在确认某节点的锁可以被接管后，才会把原本在那台节点上的资源标记为可以在别处恢复，经过 fence 和 recovery 两个状态后在其他节点重新启动。这个"确认能接管"的前提，正是那台节点一定已经被 watchdog 重启过、不可能再继续跑着原来的资源。

这个机制的代价是"看起来像故障"

从使用者的角度看，这台节点毫无征兆地自己重启了，很像硬件问题。但如果同时伴随着 quorum 丢失的记录，大概率是这个机制在正常工作——它保护的是数据一致性，代价是这台节点被强制重启。官方文档也提到，从故障发生到恢复完成，典型耗时在 2 分钟左右，这段时间内其他节点会看到资源短暂不可用。

watchdog 可以是硬件的，也可以是软件模拟的

多数服务器主板自带硬件看门狗（需要在 /etc/default/pve-ha-manager 里配置对应内核模块才会启用），没有配置硬件看门狗时，PVE 会退回使用 Linux 内核自带的 softdog（软件看门狗）。两者效果类似，硬件看门狗通常更可靠，因为它不依赖操作系统本身还能正常调度。

第二步：确认是不是这个机制触发的

看重启前的日志（如果日志能保留到本地磁盘或已经转发到别处）：

# 重启前 corosync 的状态
journalctl -u corosync --no-pager | tail -200

# HA 相关服务的日志
journalctl -u pve-ha-crm -u pve-ha-lrm --no-pager | tail -200

看有没有在重启前出现 quorum 丢失、corosync 链路超时之类的记录。日志在重启瞬间被 watchdog 强制切断，末尾往往很突兀——如果日志停在类似"失去 quorum"或者 corosync 链路异常，且没有更早的、能解释重启的其他线索，那基本可以确认是 fencing。

第三步：根因几乎总是 corosync 网络

fencing 本身是正常工作，真正需要处理的问题是"为什么这台节点会失去 quorum"。corosync 对网络延迟和丢包比较敏感：

corosync-cfgtool -s

检查方向：

corosync 有没有独立或至少低延迟的网络，还是和虚拟机流量、备份流量、迁移流量挤在同一张网卡上。官方文档建议节点之间的延迟稳定在 5 毫秒以内（局域网水平），高负载时段（比如夜间备份）的带宽争抢，是这类"偶发自我重启"的常见根因。
交换机、网线本身是否稳定，有没有间歇性的链路抖动。
如果配置了多条 corosync 链路（冗余链路，即 link0/link1），确认所有链路是否都正常，而不是靠单一链路硬撑。

长期的解决方向是给 corosync 规划独立链路、必要时配置冗余链路，详见corosync 冗余链路规划。

第四步：排除 fencing 之外的原因

如果第二步没有找到 quorum 丢失的迹象，或者这台节点根本不在 HA 环境里，重启原因需要按常规硬件/系统问题排查：

# 系统日志里重启前的最后记录
journalctl -b -1 -n 200 --no-pager

# 是否有内核 panic 或 OOM 记录
journalctl -b -1 -p err --no-pager | grep -iE "panic|oom|watchdog|thermal"

# 硬件层面：内存、电源、温度

内核 panic、内存故障、过热保护、电源问题（尤其是多路供电中的一路故障）都可能表现为"毫无征兆地重启"，需要结合硬件日志和监控数据排查，和 HA fencing 是完全不同的方向。

确认恢复

pvecm status 显示这台节点重新加入集群且 quorum 正常。
ha-manager status 里之前的资源分布符合预期（没有出现资源"卡"在迁移中间状态）。
一段时间内（建议至少覆盖一次高负载窗口，比如一次完整的备份周期）不再复发。
如果调整过 corosync 网络配置，用 corosync-cfgtool -s 确认链路状态稳定。

仍未解决

按如何有效求助准备：

pveversion -v
pvecm status
ha-manager status

加上重启前后的 journalctl -b -1 相关片段、corosync-cfgtool -s 的输出，以及 corosync 网络的拓扑说明（哪张网卡、是否独享、是否有冗余链路）。

节点自己重启了 ​

适用范围 ​

开始排查前 ​

排查步骤 ​

第一步：理解 HA 的自我重启（fencing）不是故障 ​

第二步：确认是不是这个机制触发的 ​

第三步：根因几乎总是 corosync 网络 ​

第四步：排除 fencing 之外的原因 ​

确认恢复 ​

仍未解决 ​

参考资料 ​