ha-manager(1)

NAME

ha-manager - Proxmox VE HA 管理器

SYNOPSIS

ha-manager <COMMAND> [ARGS] [OPTIONS]

ha-manager add <sid> [OPTIONS]

创建新的 HA 资源。

<sid>: <type>:<name>: HA 资源 ID。它由资源类型和资源专用名称组成，两者用冒号分隔（例如：vm:100 / ct:100）。对于虚拟机和容器，可以直接使用 VM 或 CT ID 作为快捷写法（例如：100）。
--comment <string>: 描述。
--group <string>: HA 组标识符。
--max_relocate <integer> (0 - N) (default = 1): 服务启动失败时，尝试重定位服务的最大次数。
--max_restart <integer> (0 - N) (default = 1): 服务在某个节点上启动失败后，在该节点上尝试重启服务的最大次数。
--state <disabled | enabled | ignored | started | stopped> (default = started): 请求的资源状态。
--type <ct | vm>: 资源类型。

ha-manager config [OPTIONS]

列出 HA 资源。

--type <ct | vm>: 仅列出指定类型的资源

ha-manager crm-command migrate <sid> <node>

请求将资源迁移（在线）到另一个节点。

<sid>: <type>:<name>: HA 资源 ID。它由资源类型和资源专用名称组成，两者用冒号分隔（例如：vm:100 / ct:100）。对于虚拟机和容器，可以直接使用 VM 或 CT ID 作为快捷写法（例如：100）。
<node>: <string>: 目标节点。

ha-manager crm-command node-maintenance disable <node>

更改节点维护请求状态。

<node>: <string>: 集群节点名称。

ha-manager crm-command node-maintenance enable <node>

更改节点维护请求状态。

<node>: <string>: 集群节点名称。

ha-manager crm-command relocate <sid> <node>

请求将资源重定位到另一个节点。这会在原节点上停止该服务，并在目标节点上重新启动。

<sid>: <type>:<name>: HA 资源 ID。它由资源类型和资源专用名称组成，两者用冒号分隔（例如：vm:100 / ct:100）。对于虚拟机和容器，可以直接使用 VM 或 CT ID 作为快捷写法（例如：100）。
<node>: <string>: 目标节点。

ha-manager crm-command stop <sid> <timeout>

请求停止该服务。

<sid>: <type>:<name>: HA 资源 ID。它由资源类型和资源专用名称组成，两者用冒号分隔（例如：vm:100 / ct:100）。对于虚拟机和容器，可以直接使用 VM 或 CT ID 作为快捷写法（例如：100）。
<timeout>: <integer> (0 - N): 超时时间，单位为秒。如果设置为 0，将执行强制停止。

ha-manager groupadd <group> --nodes <string> [OPTIONS]

创建新的 HA 组。

<group>: <string>: HA 组标识符。
--comment <string>: 描述。
--nodes <node>[:<pri>]{,<node>[:<pri>]}*: 集群节点名称列表，可选择附带优先级。
--nofailback <boolean> (default = 0): CRM 会尝试在优先级最高的节点上运行服务。如果优先级更高的节点上线，CRM 会将服务迁移到该节点。启用 nofailback 可阻止这种行为。
--restricted <boolean> (default = 0): 绑定到受限组的资源只能在该组定义的节点上运行。
--type <group>: 组类型。

ha-manager groupconfig

获取 HA 组。

ha-manager groupremove <group>

删除 HA 组配置。

<group>: <string>: HA 组标识符。

ha-manager groupset <group> [OPTIONS]

更新 HA 组配置。

<group>: <string>: HA 组标识符。
--comment <string>: 描述。
--delete <string>: 要删除的设置列表。
--digest <string>: 如果当前配置文件具有不同的摘要，则阻止更改。这可用于防止并发修改。
--nodes <node>[:<pri>]{,<node>[:<pri>]}*: 集群节点名称列表，可选择附带优先级。
--nofailback <boolean> (default = 0): CRM 会尝试在优先级最高的节点上运行服务。如果优先级更高的节点上线，CRM 会将服务迁移到该节点。启用 nofailback 可阻止这种行为。
--restricted <boolean> (default = 0): 绑定到受限组的资源只能在该组定义的节点上运行。

ha-manager help [OPTIONS]

获取指定命令的帮助信息。

--extra-args <array>: 显示特定命令的帮助信息
--verbose <boolean>: 详细输出格式。

ha-manager migrate

ha-manager crm-command migrate 的别名。

ha-manager relocate

ha-manager crm-command relocate 的别名。

ha-manager remove <sid>

删除资源配置。

<sid>: <type>:<name>: HA 资源 ID。它由资源类型和资源专用名称组成，两者用冒号分隔（例如：vm:100 / ct:100）。对于虚拟机和容器，可以直接使用 VM 或 CT ID 作为快捷写法（例如：100）。

ha-manager set <sid> [OPTIONS]

更新资源配置。

<sid>: <type>:<name>: HA 资源 ID。它由资源类型和资源专用名称组成，两者用冒号分隔（例如：vm:100 / ct:100）。对于虚拟机和容器，可以直接使用 VM 或 CT ID 作为快捷写法（例如：100）。
--comment <string>: 描述。
--delete <string>: 要删除的设置列表。
--digest <string>: 如果当前配置文件具有不同的摘要，则阻止更改。这可用于防止并发修改。
--group <string>: HA 组标识符。
--max_relocate <integer> (0 - N) (default = 1): 服务启动失败时，尝试重定位服务的最大次数。
--max_restart <integer> (0 - N) (default = 1): 服务在某个节点上启动失败后，在该节点上尝试重启服务的最大次数。
--state <disabled | enabled | ignored | started | stopped> (default = started): 请求的资源状态。

ha-manager status [OPTIONS]

显示 HA 管理器状态。

--verbose <boolean> (default = 0): 详细输出。包含完整的 CRM 和 LRM 状态（JSON）。

常用命令示例

查看 HA 资源状态：

# ha-manager status

列出已配置的 HA 资源：

# ha-manager config

DESCRIPTION

现代社会高度依赖由计算机通过网络提供的信息。移动设备进一步放大了这种依赖，因为人们可以随时随地访问网络。如果提供这类服务，确保它们在绝大多数时间内可用就非常重要。

从数学上讲，可用性可以定义为 (A) 服务在给定时间区间内可被使用的总时间，与 (B) 该时间区间长度之间的比值。它通常表示为某一年内正常运行时间的百分比。

Table 1. 可用性 - 每年停机时间
可用性 %	每年停机时间
99	3.65 天
99.9	8.76 小时
99.99	52.56 分钟
99.999	5.26 分钟
99.9999	31.5 秒
99.99999	3.15 秒

提高可用性有多种方式。最优雅的方案是重写软件，使其能够同时在多台主机上运行。软件本身需要具备检测错误并执行故障切换的能力。如果只是提供只读网页，这相对简单。不过，这通常很复杂，有时甚至不可能，因为无法自行修改软件。以下方案无需修改软件即可工作：

使用可靠的“服务器”组件

功能相同的计算机组件可能因为组件质量不同而具有不同的可靠性指标。多数厂商会将可靠性更高的组件作为“服务器”组件销售，通常价格也更高。

消除单点故障（冗余组件）
- 使用不间断电源（UPS）
- 在服务器中使用冗余电源
- 使用 ECC-RAM
- 使用冗余网络硬件
- 对本地存储使用 RAID
- 为虚拟机数据使用分布式冗余存储
减少停机时间
- 管理员可快速响应（24/7）
- 具备备件可用性（Proxmox VE 集群中的其他节点）
- 自动错误检测（由 ha-manager 提供）
- 自动故障切换（由 ha-manager 提供）

像 Proxmox VE 这样的虚拟化环境让实现高可用性容易得多，因为它们消除了对“硬件”的依赖。它们还支持配置和使用冗余存储及网络设备，因此如果一台主机发生故障，可以直接在集群内另一台主机上启动这些服务。

更进一步，Proxmox VE 提供了名为 ha-manager 的软件栈，可以自动完成这些工作。它能够自动检测错误并自动执行故障切换。

Proxmox VE ha-manager 的工作方式类似一位“自动化”的管理员。首先，配置它应管理哪些资源（虚拟机、容器等）。然后，ha-manager 会监控其正确运行状态，并在发生错误时将服务故障切换到另一节点。 ha-manager 也可以处理普通用户请求，例如启动、停止、重定位和迁移服务。

但高可用性是有成本的。高质量组件更昂贵，而将它们冗余化至少会使成本翻倍。额外备件会进一步增加成本。因此，应仔细计算收益，并与这些额外成本进行比较。

将可用性从 99% 提高到 99.9% 相对简单。但从 99.9999% 提高到 99.99999% 非常困难且成本高昂。ha-manager 的典型错误检测和故障切换时间约为 2 分钟，因此最多只能获得约 99.999% 的可用性。

要求

开始使用 HA 之前，必须满足以下要求：

至少三个集群节点（以获得可靠的 quorum）
用于虚拟机和容器的共享存储
硬件冗余（全范围）
使用可靠的“服务器”组件
硬件 watchdog - 如果不可用，则回退到 Linux 内核软件 watchdog（softdog）
可选的硬件 fencing 设备

资源

ha-manager 处理的主要管理单元称为资源。资源（也称为“服务”）由服务 ID（SID）唯一标识，SID 由资源类型和类型特定 ID 组成，例如 vm:100。该示例表示一个类型为 vm（虚拟机）、ID 为 100 的资源。

目前有两类重要资源类型：虚拟机和容器。这里的基本思路之一是，可以将相关软件打包到这类虚拟机或容器中，因此不需要像 rgmanager 那样由其他服务组合出一个大服务。一般来说，由 HA 管理的资源不应依赖其他资源。

管理任务

本节简要概述常见管理任务。第一步是为资源启用 HA。做法是将资源添加到 HA 资源配置中。可以通过 GUI 完成，也可以直接使用命令行工具，例如：

# ha-manager add vm:100

HA 栈现在会尝试启动资源并保持其运行。请注意，可以配置资源的“请求”状态。例如，可能希望 HA 栈停止该资源：

# ha-manager set vm:100 --state stopped

稍后再重新启动：

# ha-manager set vm:100 --state started

也可以使用普通的虚拟机和容器管理命令。它们会自动将命令转发给 HA 栈，因此

# qm start 100

只是将请求状态设置为 started。qm stop 同样如此，它会将请求状态设置为 stopped。

HA 栈完全异步工作，并且需要与其他集群成员通信。因此，看到这些操作的结果需要几秒钟。

要查看当前 HA 资源配置，请使用：

# ha-manager config
vm:100
        state stopped

可以使用以下命令查看实际的 HA 管理器和资源状态：

# ha-manager status
quorum OK
master node1 (active, Wed Nov 23 11:07:23 2016)
lrm elsa (active, Wed Nov 23 11:07:19 2016)
service vm:100 (node1, started)

也可以发起资源向其他节点迁移：

# ha-manager migrate vm:100 node2

这会使用在线迁移，并尝试保持虚拟机运行。在线迁移需要通过网络传输所有已使用内存，因此有时先停止虚拟机再在新节点上重启会更快。可以使用 relocate 命令完成：

# ha-manager relocate vm:100 node2

最后，可以使用以下命令从 HA 配置中移除资源：

# ha-manager remove vm:100

这不会启动或停止该资源。

不过，所有 HA 相关任务都可以在 GUI 中完成，因此完全不需要使用命令行。

常用命令示例：

ha-manager status
ha-manager config
ha-manager set vm:100 --state started

工作原理

本节详细说明 Proxmox VE HA 管理器的内部机制。它描述所有相关守护进程以及它们如何协同工作。为了提供 HA，每个节点上会运行两个守护进程：

pve-ha-lrm: 本地资源管理器（LRM），用于控制在本地节点上运行的服务。它从当前 manager status 文件中读取其服务的请求状态，并执行相应命令。
pve-ha-crm: 集群资源管理器（CRM），用于做出集群范围内的决策。它向 LRM 发送命令、处理结果，并在发生故障时将资源移动到其他节点。CRM 还负责节点 fencing。

LRM 与 CRM 中的锁

锁由分布式配置文件系统（pmxcfs）提供。它们用于保证每个 LRM 只活动一次并正常工作。由于 LRM 只有在持有自己的锁时才会执行操作，如果能够取得某个失败节点的锁，就可以将该节点标记为已 fenced。这样便可安全恢复任何失败的 HA 服务，而不会受到当前状态未知的失败节点干扰。所有这些都由当前持有 manager master 锁的 CRM 监督。

服务状态

CRM 使用服务状态枚举来记录当前服务状态。该状态会显示在 GUI 中，也可以使用 ha-manager 命令行工具查询：

# ha-manager status
quorum OK
master elsa (active, Mon Nov 21 07:23:29 2016)
lrm elsa (active, Mon Nov 21 07:23:22 2016)
service ct:100 (elsa, stopped)
service ct:102 (elsa, started)
service vm:501 (elsa, started)

可能的状态如下：

stopped: 服务已停止（由 LRM 确认）。如果 LRM 检测到标记为停止的服务仍在运行，它会再次停止该服务。
request_stop: 服务应被停止。CRM 等待 LRM 确认。
stopping: 停止请求待处理。但 CRM 目前尚未获得该请求的结果。
started: 服务处于活动状态，如果尚未运行，LRM 应尽快启动它。如果服务失败并被检测为未运行， LRM 会重启它（见启动失败策略）。
starting: 启动请求待处理。但 CRM 尚未从 LRM 收到服务正在运行的确认。
fence: 等待节点 fencing，因为服务所在节点不在具备 quorum 的集群分区内（见 Fencing）。一旦节点成功 fenced，服务会被置于 recovery 状态。
recovery: 等待服务恢复。HA 管理器会尝试寻找一个可运行该服务的新节点。该搜索不仅取决于在线且具备 quorum 的节点列表，也取决于服务是否为某个组的成员，以及该组如何受限。一旦找到新的可用节点，服务会被移动到该节点，并初始置于 stopped 状态。如果配置为运行，新节点会启动它。
freeze: 不要修改服务状态。在重启节点或重启 LRM 守护进程时会使用该状态（见软件包更新）。
ignored: 表现得像该服务完全不由 HA 管理。当需要临时完全控制服务、但不想将其从 HA 配置中移除时，该状态很有用。
migrate: 将服务（实时）迁移到其他节点。
error: 服务因 LRM 错误而被禁用。需要人工干预（见错误恢复）。
queued: 服务是新添加的，CRM 目前尚未看到它。
disabled: 服务已停止，并被标记为 disabled

本地资源管理器

本地资源管理器（pve-ha-lrm）会在启动时作为守护进程启动，并等待 HA 集群具备 quorum，从而确保集群范围锁可以工作。

它可以处于三种状态：

wait for agent lock: LRM 等待其独占锁。如果未配置任何服务，这也用作空闲状态。
active: LRM 持有其独占锁，并且已配置服务。
lost agent lock: LRM 丢失了锁，这表示发生了故障并丢失了 quorum。

LRM 进入 active 状态后，会读取 /etc/pve/ha/manager_status 中的 manager status 文件，并确定需要为其拥有的服务执行哪些命令。每个命令都会启动一个 worker，这些 worker 并行运行，默认最多限制为 4 个。该默认设置可以通过数据中心配置键 max_worker 修改。完成后，worker 进程会被回收，其结果会保存给 CRM。

最大并发 worker 调整提示

最多 4 个并发 worker 的默认值可能不适合特定环境。例如，可能同时发生 4 次实时迁移，在较慢网络和/或大型（以内存计）服务的情况下会导致网络拥塞。还应确保即使在最坏情况下，拥塞也保持在最低水平，即使这意味着降低 max_worker 值。相反，如果环境特别强大、属于高端配置，也可以考虑提高该值。

CRM 请求的每个命令都可以通过 UID 唯一识别。worker 完成后，其结果会被处理并写入 LRM 状态文件 /etc/pve/nodes/<nodename>/lrm_status。CRM 可以在那里收集结果，并让其状态机根据命令输出采取相应动作。

CRM 与 LRM 之间对每个服务的操作通常始终保持同步。这意味着 CRM 请求一个由 UID 唯一标记的状态，LRM 随后 只执行一次 该操作，并写回同样可由该 UID 识别的结果。这是为了避免 LRM 执行过期命令。该行为只有 stop 和 error 命令例外；这两者不依赖产生的结果，在 stopped 状态下总是执行，在 error 状态下执行一次。

读取日志

HA 栈会记录它执行的每个操作。这有助于理解集群中发生了什么以及为什么发生。这里重要的是查看 LRM 和 CRM 两个守护进程分别做了什么。可以在服务所在节点上使用 journalctl -u pve-ha-lrm，并在当前 master 节点上对 pve-ha-crm 使用相同命令。

集群资源管理器

集群资源管理器（pve-ha-crm）会在每个节点上启动，并等待 manager lock，该锁同一时间只能由一个节点持有。成功取得 manager lock 的节点会被提升为 CRM master。

它可以处于三种状态：

wait for agent lock: CRM 等待其独占锁。如果未配置任何服务，这也用作空闲状态。
active: CRM 持有其独占锁，并且已配置服务。
lost agent lock: CRM 丢失了锁，这表示发生了故障并丢失了 quorum。

其主要任务是管理配置为高可用的服务，并始终尝试强制满足请求状态。例如，请求状态为 started 的服务如果尚未运行，就会被启动。如果它崩溃，则会自动再次启动。因此，CRM 会指示 LRM 需要执行的操作。

当某个节点离开集群 quorum 时，其状态会变为 unknown。如果当前 CRM 随后能够取得失败节点的锁，服务会被“窃取”并在另一节点上重启。

当某个集群成员确定自己不再处于集群 quorum 中时，LRM 会等待形成新的 quorum。在存在集群 quorum 之前，该节点无法重置 watchdog。如果节点上有活动服务，或者 LRM 或 CRM 进程未被调度或被杀死，则会在 watchdog 超时后触发重启（这会在 60 秒后发生）。

请注意，如果某节点有活动 CRM 但 LRM 处于空闲状态，quorum 丢失不会触发 self-fence reset。原因是 CRM 访问的所有状态文件和配置都由集群配置文件系统支撑，而该文件系统会在 quorum 丢失时变为只读。这意味着 CRM 只需要防止自身进程长时间得不到调度；否则另一个 CRM 可能在不了解情况的情况下接管，从而破坏 HA 状态。已打开的 watchdog 确保这种情况不会发生。

如果超过 15 分钟未配置任何服务，CRM 会自动返回空闲状态，并完全关闭 watchdog。

HA 模拟器

使用 HA 模拟器，可以测试并学习 Proxmox VE HA 方案的所有功能。

默认情况下，模拟器允许观察并测试一个真实场景中的 3 节点集群和 6 台虚拟机的行为。也可以添加或移除额外的虚拟机或容器。

无需设置或配置真实集群，HA 模拟器开箱即可运行。

使用 dnf 安装：

dnf install pve-ha-simulator

甚至可以在没有任何其他 Proxmox VE 软件包的 Debian 系统上安装该软件包。为此，需要下载该软件包，并将其复制到要运行它的系统中进行安装。从本地文件系统使用 dnf 安装该软件包时，dnf 也会为你解析所需依赖。

要在远程机器上启动模拟器，必须将 X11 重定向到当前系统。

如果使用 Linux 机器，可以使用：

ssh root@<IPofPVE> -Y

在 Windows 上，可以使用 mobaxterm。

连接到已安装模拟器的现有 Proxmox VE，或在本地 Debian 系统上手动安装后，可以按如下方式试用。

首先需要创建一个工作目录，模拟器会在其中保存当前状态并写入默认配置：

mkdir working

然后，只需将创建的目录作为参数传递给 pve-ha-simulator：

pve-ha-simulator working/

随后可以启动、停止、迁移模拟的 HA 服务，甚至可以查看节点故障时会发生什么。

配置

HA 栈与 Proxmox VE API 深度集成。因此，例如可以通过 ha-manager 命令行界面或 Proxmox VE Web 界面配置 HA，这两种界面都提供了简单的 HA 管理方式。自动化工具可以直接使用 API。

所有 HA 配置文件都位于 /etc/pve/ha/ 中，因此会自动分发到集群节点，并由所有节点共享同一份 HA 配置。

资源

资源配置文件 /etc/pve/ha/resources.cfg 存储由 ha-manager 管理的资源列表。该列表中的资源配置如下所示：

<type>: <name>
        <property> <value>
        ...

它以资源类型开头，后接资源特定名称，中间用冒号分隔。两者共同组成 HA 资源 ID，所有 ha-manager 命令都使用该 ID 唯一标识资源（例如 vm:100 或 ct:101）。后续行包含其他属性：

comment: <string>

说明。

group: <string>

HA 组标识符。

max_relocate: <integer> (0 - N) (default = 1)

服务启动失败时，尝试重定位服务的最大次数。

max_restart: <integer> (0 - N) (default = 1)

服务在节点上启动失败后，尝试重启该服务的最大次数。

state: <disabled | enabled | ignored | started | stopped> (default = started)

请求的资源状态。CRM 读取此状态并据此执行操作。请注意，enabled 只是 started 的别名。

started: CRM 会尝试启动资源。成功启动后，服务状态会设置为 started。当节点故障或启动失败时，它会尝试恢复该资源。如果所有操作均失败，服务状态会设置为 error。
stopped: CRM 会尝试将资源保持在 stopped 状态，但在节点故障时仍会尝试重定位资源。
disabled: CRM 会尝试将资源置于 stopped 状态，但在节点故障时不会尝试重定位资源。此状态的主要用途是错误恢复，因为它是将资源移出 error 状态的唯一方式。
ignored: 该资源会从管理器状态中移除，因此 CRM 和 LRM 不再处理该资源。所有影响此资源的 {pve} API 调用都会直接执行，并绕过 HA 栈。当资源处于此状态时，CRM 命令会被丢弃。节点故障时，该资源不会被重定位。

下面是一个包含一台虚拟机和一个容器的真实示例。可以看到，这些文件的语法非常简单，甚至可以使用熟悉的编辑器读取或编辑这些文件：

配置示例（/etc/pve/ha/resources.cfg）

vm: 501
    state started
    max_relocate 2

ct: 102
    # Note: use default settings for everything

screenshot/gui-ha-manager-add-resource.png

上述配置由 ha-manager 命令行工具生成：

# ha-manager add vm:501 --state started --max_relocate 2
# ha-manager add ct:102

组

screenshot/gui-ha-manager-groups-view.png

HA 组配置文件 /etc/pve/ha/groups.cfg 用于定义集群节点组。可以将资源限制为仅在这类组的成员上运行。组配置如下所示：

group: <group>
       nodes <node_list>
       <property> <value>
       ...

comment: <string>: 说明。
nodes: <node>[:<pri>]{,<node>[:<pri>]}*: 集群节点成员列表，可以为每个节点指定优先级。绑定到某个组的资源会在优先级最高的可用节点上运行。如果最高优先级类别中有多个节点，服务会分布到这些节点上。优先级仅具有相对意义，数字越大优先级越高。
nofailback: <boolean> (default = 0): CRM 会尝试在优先级最高的节点上运行服务。如果优先级更高的节点上线，CRM 会将服务迁移到该节点。启用 nofailback 可阻止这种行为。
restricted: <boolean> (default = 0): 绑定到受限组的资源只能在该组定义的节点上运行。如果没有任何组成员节点在线，资源会被置于 stopped 状态。绑定到非受限组的资源在所有组成员都离线时可以在任意集群节点上运行，但只要有组成员上线，就会迁移回去。可以使用只有一个成员的非受限组来实现“首选节点”行为。

常见需求是让某个资源运行在特定节点上。通常该资源也能够在其他节点上运行，因此可以定义一个只有单个成员的非受限组：

# ha-manager groupadd prefer_node1 --nodes node1

对于较大的集群，定义更详细的故障切换行为是有意义的。例如，可能希望在可行时将一组服务运行在 node1 上。如果 node1 不可用，则希望它们平均分布在 node2 和 node3 上。如果这些节点也失败，服务应运行在 node4 上。为实现这一点，可以将节点列表设置为：

# ha-manager groupadd mygroup1 -nodes "node1:2,node2:1,node3:1,node4"

另一种用例是，某个资源依赖仅在特定节点上可用的其他资源，例如 node1 和 node2。需要确保 HA 管理器不会使用其他节点，因此需要使用这些节点创建一个受限组：

# ha-manager groupadd mygroup2 -nodes "node1,node2" -restricted

上述命令创建了以下组配置文件：

配置示例（/etc/pve/ha/groups.cfg）

group: prefer_node1
       nodes node1

group: mygroup1
       nodes node2:1,node4,node1:2,node3:1

group: mygroup2
       nodes node2,node1
       restricted 1

nofailback 选项主要用于在管理任务期间避免不必要的资源移动。例如，如果需要将服务迁移到组中优先级不是最高的节点，就需要通过设置 nofailback 选项告诉 HA 管理器不要立即将该服务移回去。

另一种场景是某个服务被 fenced 后恢复到另一节点。管理员尝试修复被 fenced 的节点，并重新将其上线，以调查故障原因并检查其是否再次稳定运行。设置 nofailback 标志可防止已恢复的服务直接迁回被 fenced 的节点。

Fencing

节点故障时，fencing 确保出错节点一定处于离线状态。这是为了确保资源在另一节点上恢复时不会同时运行两份。这是一项非常重要的任务，因为没有它，就无法在另一节点上恢复资源。

如果某个节点没有被 fenced，它会处于未知状态，可能仍然能够访问共享资源。这非常危险。设想除了存储网络之外的所有网络都断开了。此时虚拟机虽然无法从公网访问，但仍在运行并写入共享存储。

如果此时简单地在另一节点上启动该虚拟机，就会出现危险的竞争条件，因为两个节点都会写入。这种情况可能破坏所有虚拟机数据，并导致整个虚拟机不可用。如果存储防止多重挂载，恢复也可能失败。

Proxmox VE 如何执行 Fencing

对节点执行 fencing 有多种方法，例如使用 fence 设备切断节点电源，或完全禁用其通信。这些设备通常相当昂贵，并会向系统中引入额外关键组件，因为如果它们失败，就无法恢复任何服务。

因此，Proxmox VE 集成了一种更简单的 fencing 方法，不需要额外的外部硬件。这可以通过 watchdog 定时器实现。

可能的 Fencing 方法

外部电源开关
通过在交换机上完全禁用网络流量来隔离节点
使用 watchdog 定时器执行 self fencing

从微控制器出现之初，watchdog 定时器就已广泛用于关键且可靠性要求高的系统中。它们通常是简单、独立的集成电路，用于检测并从计算机故障中恢复。

正常运行期间，ha-manager 会定期重置 watchdog 定时器，防止其超时。如果由于硬件故障或程序错误，计算机未能重置 watchdog，定时器就会超时，并触发整个服务器重置（重启）。

较新的服务器主板通常包含这类硬件 watchdog，但需要进行配置。如果没有可用或已配置的 watchdog，则回退到 Linux 内核 softdog。它虽然仍然可靠，但并不独立于服务器硬件，因此可靠性低于硬件 watchdog。

配置硬件 Watchdog

默认情况下，出于安全原因，所有硬件 watchdog 模块都会被阻止。如果没有正确初始化，它们就像一把上膛的枪。要启用硬件 watchdog，需要在 /etc/default/pve-ha-manager 中指定要加载的模块，例如：

# select watchdog module (default is softdog)
WATCHDOG_MODULE=iTCO_wdt

该配置由 watchdog-mux 服务读取，该服务会在启动时加载指定模块。

恢复已 Fenced 的服务

节点失败并成功完成 fencing 后，CRM 会尝试将服务从失败节点移动到仍在线的节点。

这些服务恢复到哪些节点，会受资源 group 设置、当前活动节点列表以及各节点活动服务数量影响。

CRM 首先根据用户选择的节点（来自 group 设置）与可用节点的交集构建集合。然后选择优先级最高的节点子集，最后选择活动服务数量最低的节点。这可以尽量降低节点过载的可能性。

节点故障时，CRM 会将服务分发到剩余节点。这会增加这些节点上的服务数量，并可能导致高负载，尤其是在小型集群中。请设计集群，使其能够处理这类最坏情况。

启动失败策略

如果服务在某个节点上一次或多次启动失败，启动失败策略就会生效。它可用于配置在同一节点上应触发多少次重启，以及服务应重定位多少次，以便尝试在另一节点上启动。该策略的目标是规避特定节点上共享资源的临时不可用。例如，如果由于网络问题，某个具备 quorum 的节点不再能够访问共享存储，但其他节点仍可访问，则 relocate 策略仍允许服务启动。

有两个可针对每个资源单独配置的服务启动恢复策略设置。

max_restart: 在实际节点上重启失败服务的最大尝试次数。默认值为一。
max_relocate: 将服务重定位到其他节点的最大尝试次数。只有在实际节点上超过 max_restart 值后，才会发生 relocate。默认值为一。

只有服务至少成功启动过一次，relocate 计数状态才会重置为零。这意味着如果未修复错误就重新启动服务，只会重复执行重启策略。

错误恢复

如果在所有尝试之后仍无法恢复服务状态，它会被置于 error 状态。在该状态下， HA 栈不再触碰该服务。唯一的退出方式是禁用该服务：

# ha-manager set vm:100 --state disabled

这也可以在 Web 界面中完成。

要从 error 状态恢复，应执行以下操作：

将资源恢复到安全且一致的状态（例如：如果服务无法停止，则 kill 其进程）
禁用资源以移除 error 标志
修复导致这些失败的错误
在修复所有错误之后，才可以请求再次启动该服务

软件包更新

更新 ha-manager 时，应逐个节点更新，切勿一次性全部更新，原因有多个。首先，尽管项目会全面测试软件，但无法完全排除影响特定环境的 bug。逐个节点更新，并在每个节点更新完成后检查其功能，有助于从潜在问题中恢复；而一次性全部更新可能导致集群损坏，通常也不是良好实践。

此外，Proxmox VE HA 栈使用请求确认协议在集群和本地资源管理器之间执行操作。重启时， LRM 会向 CRM 请求冻结其所有服务。这可以防止在 LRM 重启的短时间内这些服务被集群触碰。随后，LRM 可以在重启期间安全关闭 watchdog。这类重启通常发生在软件包更新期间；如前所述，需要一个活动的 master CRM 来确认来自 LRM 的请求。如果不是这样，更新过程可能耗时过长，在最坏情况下可能导致 watchdog 触发重置。

节点维护

有时需要对节点执行维护，例如更换硬件或只是安装新的内核镜像。使用 HA 栈时同样如此。

HA 栈主要可以支持两类维护：

对于常规关机或重启，可以配置其行为，见关机策略。
对于不需要关机或重启的维护，或不应在仅一次重启后自动关闭的维护，可以启用手动维护模式。

维护模式

可以使用手动维护模式将节点标记为不适用于 HA 操作，从而促使 HA 管理的所有服务迁移到其他节点。

这些迁移的目标节点会从当前其他可用节点中选择，并由 HA 组配置和已配置的集群资源调度器（CRS）模式决定。在每次迁移期间，原始节点会记录在 HA 管理器状态中，以便在维护模式禁用且节点重新上线后，可以自动将服务移回。

目前可以使用 ha-manager CLI 工具启用或禁用维护模式。

为节点启用维护模式

# ha-manager crm-command node-maintenance enable NODENAME

这会将一个 CRM 命令加入队列，当管理器处理该命令时，会在 manager status 中记录维护模式请求。这允许在任意节点上提交该命令，而不必只在要进入或退出维护模式的节点上执行。

一旦相应节点上的 LRM 接收到该命令，它会将自身标记为不可用，但仍会处理所有迁移命令。这意味着 LRM self-fencing watchdog 会保持活动，直到所有活动服务都已移动且所有正在运行的 worker 都已完成。

请注意，只要 LRM 接收到请求状态，LRM 状态就会显示 maintenance 模式，而不是等到所有服务都迁移离开后才显示。该用户体验计划在未来改进。目前，可以检查节点上是否仍有活动 HA 服务，或留意类似 pve-ha-lrm[PID]: watchdog closed (disabled) 的日志行，以判断节点何时完成进入维护模式的转换。

手动维护模式不会在节点重启时自动删除，只有通过 ha-manager CLI 手动停用，或手动清除 manager-status 时才会删除。

为节点禁用维护模式

# ha-manager crm-command node-maintenance disable NODENAME

禁用手动维护模式的过程与启用类似。使用上面所示的 ha-manager CLI 命令会将一个 CRM 命令加入队列；处理完成后，相应 LRM 节点会再次标记为可用。

如果停用维护模式，在维护模式激活时位于该节点上的所有服务都会被移回。

关机策略

下面描述节点关机时的不同 HA 策略。当前出于向后兼容性考虑，Conditional 是默认值。部分用户可能会发现 Migrate 的行为更符合预期。

关机策略可以在 Web UI（Datacenter → Options → HA Settings）中配置，也可以直接在 datacenter.cfg 中配置：

ha: shutdown_policy=<value>

Migrate

本地资源管理器（LRM）收到关机请求且启用该策略后，会将自身标记为对当前 HA 管理器不可用。这会触发当前位于该节点上的所有 HA 服务迁移。LRM 会尝试延迟关机过程，直到所有正在运行的服务都被迁走。但这要求正在运行的服务可以迁移到另一节点。换言之，服务不能绑定在本地，例如不能使用硬件直通。由于在没有可用组成员时，非组成员节点会被视为可运行目标，因此即使使用只选择部分节点的 HA 组，仍可使用该策略。但是，将组标记为 restricted 会告诉 HA 管理器该服务不能在所选节点集合之外运行。如果所有这些节点都不可用，关机会挂起，直到人工干预。关机节点重新上线后，之前被迁出的服务会被移回，除非它们在此期间已经被手动迁移。

关机迁移过程中 watchdog 仍保持活动。如果节点丢失 quorum，它会被 fenced，服务也会被恢复。

如果在当前正在维护的节点上启动一个（此前已停止的）服务，则需要对该节点执行 fencing，以确保该服务可以移动并在另一可用节点上启动。

Failover

该模式确保所有服务都会停止；如果当前节点短时间内没有重新上线，这些服务也会被恢复。在集群规模维护时，该模式可能很有用，因为如果一次关闭太多节点，虚拟机实时迁移可能不可行，但仍希望确保 HA 服务尽快恢复并重新启动。

Freeze

该模式确保所有服务都被停止并冻结，因此直到当前节点重新上线之前，它们不会被恢复。

Conditional

Conditional 关机策略会自动检测请求的是关机还是重启，并相应改变行为。

关机

如果计划让节点停机一段时间，通常会执行关机（poweroff）。在这种情况下， LRM 会停止所有受管理服务。这意味着其他节点随后会接管这些服务。

现代硬件通常拥有大量内存（RAM）。因此，系统会停止所有资源，然后重新启动它们，以避免在线迁移全部 RAM。如果要使用在线迁移，需要在关闭节点前手动调用。

重启

节点重启通过 reboot 命令发起。这通常在安装新内核后执行。请注意，这不同于“关机”，因为节点会立即再次启动。

LRM 会告知 CRM 它希望重启，并等待 CRM 将所有资源置于 freeze 状态（软件包更新使用同一机制）。这可以防止这些资源被移动到其他节点。相反，CRM 会在重启后在同一节点上启动这些资源。

手动资源移动

最后，也可以在关闭或重启节点之前，手动将资源移动到其他节点。其优势是拥有完全控制权，并且可以决定是否使用在线迁移。

请不要 kill pve-ha-crm、pve-ha-lrm 或 watchdog-mux 等服务。它们管理并使用 watchdog，因此这样做可能导致节点立即重启甚至重置。

集群资源调度

集群资源调度器（CRS）模式控制 HA 如何为服务恢复以及由关机策略触发的迁移选择节点。默认模式为 basic，可以在 Web UI（Datacenter → Options）中更改，也可以直接在 datacenter.cfg 中更改：

crs: ha=static

screenshot/gui-datacenter-options-crs.png

该变更会从下一轮 manager 运行开始生效（几秒钟后）。

对于每个需要恢复或迁移的服务，调度器会在该服务所属组中优先级最高的节点之间迭代选择最佳节点。

未来计划添加（静态和动态）负载均衡模式。

Basic 调度器

每个节点上的活动 HA 服务数量用于选择恢复节点。当前不统计非 HA 管理的服务。

Static-Load 调度器

static 模式仍是技术预览。

每个节点上 HA 服务的静态使用信息用于选择恢复节点。当前不考虑非 HA 管理服务的使用情况。

在此选择过程中，会依次将每个节点视为该服务已经在其上运行，并使用关联客户机配置中的 CPU 和内存使用量。随后，对每个此类备选方案，都会考虑所有节点的 CPU 和内存使用量；其中内存权重高得多，因为它是真正有限的资源。对于 CPU 和内存，都会考虑节点中的最高使用量（权重更高，因为理想情况下不应有节点被过度承诺）以及所有节点的平均使用量（以便在已经存在承诺更高的节点时仍能区分）。

服务越多，可能的组合就越多，因此如果有数千个 HA 管理服务，当前不建议使用该模式。

CRS 调度点

CRS 算法不会在每一轮都应用于每个服务，因为这会导致大量持续迁移。根据工作负载不同，这可能给集群带来的压力，比持续均衡所能避免的压力还要大。因此，Proxmox VE HA 管理器倾向于让服务保持在当前节点上。

CRS 当前用于以下调度点：

服务恢复（始终活动）。当带有活动 HA 服务的节点失败时，其所有服务都需要恢复到其他节点。这里会使用 CRS 算法，在剩余节点之间均衡该恢复过程。
HA 组配置变更（始终活动）。如果某个节点从组中移除，或其优先级降低，HA 栈会使用 CRS 算法为该组中的 HA 服务寻找新的目标节点，以匹配调整后的优先级约束。
HA 服务从 stopped 到 start 的转换（可选启用）。请求启动已停止服务时，是根据 CRS 算法检查最合适节点的好机会，因为移动已停止服务的成本低于移动已启动服务，尤其是其磁盘卷位于共享存储上时。可以通过在数据中心配置中设置 ha-rebalance-on-start CRS 选项来启用此行为。也可以在 Web UI 的 Datacenter → Options → Cluster Resource Scheduling 下更改该选项。

版权和免责声明

本程序是自由软件：你可以依据自由软件基金会发布的 GNU Affero General Public License 条款重新分发和/或修改本程序；可使用该许可证第 3 版，或（由你选择）任何后续版本。

发布本程序是希望它能够有用，但不提供任何担保；甚至不包含对适销性或特定用途适用性的默示担保。更多详情请参见 GNU Affero General Public License。

你应当已经随本程序收到一份 GNU Affero General Public License 的副本。如果没有，请访问： https://www.gnu.org/licenses/

发布本程序是希望它能够有用，但不提供任何担保；甚至不包含对适销性或特定用途适用性的默示担保。更多详情请参见 GNU Affero General Public License。

你应当已经随本程序收到一份 GNU Affero General Public License 的副本。如果没有，请访问： https://www.gnu.org/licenses/