PVE高可用性 - PVE 虚拟化

我们的现代社会严重依赖计算机通过网络提供的信息。移动设备放大了这种依赖性，因为人们可以随时随地访问网络。如果您提供此类服务，那么它们在大多数时间都可用非常重要。

我们可以在数学上将可用性定义为 (A)（给定时间间隔内服务能够使用的总时间）与 (B)（时间间隔长度）的比率。它通常表示为给定年份正常运行时间的百分比。

表 18. 可用性 – 每年的停机时间
可用性％	每年停机时间
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% 的可用性。

15.1. 要求

在开始 HA 之前，您必须满足以下要求：

至少三个集群节点（以获得可靠的仲裁）
虚拟机和容器的共享存储
硬件冗余（无处不在）
使用可靠的“服务器”组件
硬件看门狗 – 如果不可用，我们会使用 Linux 内核软件看门狗 ( softdog )
可选的硬件围栏设备

15.2. 资源

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

目前我们有两种重要的资源类型——虚拟机和容器。这里的一个基本想法是，我们可以将相关软件捆绑到这样的虚拟机或容器中，因此不需要像rgmanager那样从其他服务组成一项大服务。一般来说，HA 管理的资源不应依赖于其他资源。

15.3。管理任务

本节简要概述常见管理任务。第一步是为资源启用 HA。这是通过将资源添加到 HA 资源配置来完成的。您可以使用 GUI 来执行此操作，或者仅使用命令行工具，例如：

# ha-manager 添加 vm:100

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

# ha-manager 设置 vm:100 --state 已停止

并稍后再次启动：

# ha-manager set vm:100 --state 已启动

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

# qm 开始 100

只需将请求的状态设置为开始。这同样适用于qm stop，它将请求的状态设置为Stopped。

HA 堆栈完全异步工作，需要与其他集群成员进行通信。因此，您需要几秒钟才能看到此类操作的结果。

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

# ha 管理器配置
虚拟机：100
        状态停止

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

# ha-经理状态
法定人数确定
主节点1（活跃，2016 年 11 月 23 日星期三 11:07:23）
lrm elsa（活跃，2016 年 11 月 23 日星期三 11:07:19）
服务虚拟机：100（节点1，已启动）

您还可以发起资源迁移到其他节点：

# ha-manager 迁移 vm:100 node2

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

# ha-manager 重新定位 vm:100 node2

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

# ha-manager 删除 vm:100

这不会启动或停止资源。

但所有与 HA 相关的任务都可以在 GUI 中完成，因此根本不需要使用命令行。

15.4。怎么运行的

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

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

锁定 LRM 和 CRM

锁由我们的分布式配置文件系统 (pmxcfs) 提供。它们用于保证每个 LRM 都激活一次并正常工作。由于 LRM 仅在持有锁时才执行操作，因此如果能够获取其锁，我们就可以将故障节点标记为受防护。这样我们就可以安全地恢复任何失败的 HA 服务，而不会受到现在未知的失败节点的任何干扰。这一切都受到当前持有经理主锁的 CRM 的监督。

15.4.1。服务状态

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

# ha-经理状态
法定人数确定
master elsa（活跃，2016 年 11 月 21 日星期一 07:23:29）
lrm elsa（活跃，2016 年 11 月 21 日星期一 07:23:22）
服务 ct：100（elsa，已停止）
服务 ct:102（elsa，已启动）
服务虚拟机：501（elsa，已启动）

以下是可能的状态列表：

停止了: 服务已停止（由 LRM 确认）。如果 LRM 检测到已停止的服务仍在运行，它将再次停止它。
请求停止: 应停止服务。CRM 等待 LRM 的确认。
停止: 等待停止请求。但目前CRM并未收到该请求。
开始了: 服务处于活动状态，如果尚未运行，LRM 应尽快启动它。如果服务失败并且检测到未运行，LRM 会重新启动它（请参阅启动失败策略）。
开始: 等待启动请求。但 CRM 尚未从 LRM 获得任何服务正在运行的确认。
栅栏: 等待节点防护，因为服务节点不在仲裁集群分区内（请参阅防护）。一旦节点成功被隔离，服务将被置于恢复状态。
恢复: 等待服务恢复。HA 管理器尝试找到可以运行服务的新节点。此搜索不仅取决于在线和仲裁节点的列表，还取决于该服务是否是组成员以及如何限制该组。一旦发现新的可用节点，服务将移至那里并最初置于停止状态。如果它被配置为运行新节点将会这样做。
冻结: 请勿触摸服务状态。我们在重新启动节点或重新启动 LRM 守护程序时使用此状态（请参阅包更新）。
被忽略: 就好像该服务根本不由 HA 管理一样。当需要暂时完全控制服务而不将其从 HA 配置中删除时非常有用。
迁移: 将服务（实时）迁移到其他节点。
错误: 由于 LRM 错误，服务被禁用。需要手动干预（请参阅错误恢复）。
排队: 服务是新增加的，CRM目前还没有看到。
残疾人: 服务已停止并标记为禁用

15.4.2. 本地资源管理器

本地资源管理器 ( pve-ha-lrm ) 在启动时作为守护进程启动，并等待 HA 集群达到法定人数，从而集群范围的锁开始工作。

它可以处于三种状态：

等待代理锁定: LRM 等待我们的独占锁。如果没有配置服务，这也用作空闲状态。
积极的: LRM 持有其独占锁并配置了服务。
丢失代理锁: LRM 失去了锁，这意味着发生了故障并且法定人数丢失。

LRM 进入活动状态后，它会读取/etc/pve/ha/manager_status中的管理器状态文件，并确定必须为其拥有的服务执行的命令。对于工作程序启动的每个命令，这些工作程序并行运行，并且默认情况下最多限制为 4 个。可以通过数据中心配置键max_worker更改此默认设置。完成后，工作进程将被收集，并将其结果保存到 CRM。

最大并发worker调整技巧

最多 4 个并发工作线程的默认值可能不适合特定设置。例如，4 个实时迁移可能同时发生，这可能会导致网络拥塞，网络速度较慢和/或大型（内存方面）服务。另外，请确保在最坏的情况下，拥塞最小化，即使这意味着降低max_worker值。相反，如果您有特别强大的高端设置，您可能也想增加它。

CRM 请求的每个命令都可以通过 UID 唯一标识。当工作程序完成时，其结果将被处理并写入 LRM 状态文件/etc/pve/nodes/<nodename>/lrm_status中。CRM 可以在那里收集它并让其状态机（对应于命令输出）对其进行操作。

CRM 和 LRM 之间每项服务的操作通常始终同步。这意味着CRM请求一个由UID唯一标记的状态，然后LRM执行一次该操作并写回结果，该结果也可以由相同的UID识别。这是必需的，以便 LRM 不会执行过时的命令。此行为的唯一例外是停止和错误命令；这两个不依赖于产生的结果，并且总是在停止状态下执行，在错误状态下执行一次。

阅读日志

HA 堆栈会记录它所做的每个操作。这有助于理解集群中发生了什么以及为什么发生某些事情。在这里，了解 LRM 和 CRM 这两个守护进程的作用非常重要。您可以在服务所在的节点上使用 journalctl -u pve-ha-lrm ，并在当前主节点上的pve-ha-crm上使用相同的命令。

15.4.3。集群资源管理器

集群资源管理器 ( pve-ha-crm ) 在每个节点上启动并等待管理器锁，该管理器锁一次只能由一个节点持有。成功获取管理者锁的节点将提升为 CRM 主节点。

它可以处于三种状态：

等待代理锁定: CRM等待我们的独占锁。如果没有配置服务，这也用作空闲状态
积极的: CRM持有独占锁并已配置服务
丢失代理锁: CRM 失去了锁定，这意味着发生了故障并且法定人数丢失。

它的主要任务是管理配置为高可用的服务，并尝试始终强制执行请求的状态。例如，如果请求状态为已启动的服务尚未运行，则将启动该服务。如果崩溃，它将自动重新启动。因此，CRM 规定了 LRM 需要执行的操作。

当节点离开集群仲裁时，其状态将变为未知。如果当前的 CRM 可以保护故障节点的锁定，则服务将被窃取并在另一个节点上重新启动。

当集群成员确定它不再处于集群仲裁中时，LRM 会等待新仲裁的形成。只要没有法定人数，节点就无法重置看门狗。这将在看门狗超时后触发重新启动（这会在 60 秒后发生）。

15.5。高可用性模拟器

通过使用 HA 模拟器，您可以测试和学习 Proxmox VE HA 解决方案的所有功能。

默认情况下，模拟器允许您观察和测试具有 6 个虚拟机的真实 3 节点集群的行为。您还可以添加或删除其他虚拟机或容器。

您无需设置或配置真正的集群，HA 模拟器开箱即用。

使用apt安装：

apt 安装 pve-ha-simulator

您甚至可以在任何基于 Debian 的系统上安装该软件包，而无需任何其他 Proxmox VE 软件包。为此，您需要下载该软件包并将其复制到要运行它的系统上进行安装。当您使用 apt 从本地文件系统安装软件包时，它还会为您解析所需的依赖项。

要在远程计算机上启动模拟器，您必须具有到当前系统的 X11 重定向。

如果您使用的是 Linux 机器，您可以使用：

ssh root@<PVE的IP> -Y

在 Windows 上，它与mobaxterm一起使用。

连接到已安装模拟器的现有 Proxmox VE 或手动将其安装到本地基于 Debian 的系统后，您可以按如下方式进行尝试。

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

mkdir 工作

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

pve-ha-模拟器工作/

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

15.6。配置

HA 堆栈很好地集成到 Proxmox VE API 中。例如，HA 可以通过ha-manager命令行界面或 Proxmox VE Web 界面进行配置 – 这两个界面都提供了管理 HA 的简单方法。自动化工具可以直接使用API。

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

15.6.1。资源

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

<类型>：<名称>
        <属性> <值>
        ...

它以资源类型开头，后跟资源特定名称，以冒号分隔。这一起形成了 HA 资源 ID，所有ha-manager命令都使用它来唯一标识资源（例如：vm:100或ct:101）。接下来的几行包含其他属性：

评论：<字符串>

描述。

组：<字符串>

HA 组标识符。

max_relocate : <整数> (0 – N) (默认 = 1 )

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

max_restart : <整数> (0 – N) (默认 = 1 )

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

状态：<禁用| 已启用 | 被忽略 | 开始| 停止>（默认= 开始）

请求的资源状态。CRM 读取此状态并采取相应行动。请注意，enabled只是started的别名。

开始了: CRM 尝试启动资源。启动成功后服务状态设置为已启动。当节点发生故障或启动失败时，它会尝试恢复资源。如果一切失败，服务状态将设置为error。
停止了: CRM 尝试使资源保持停止状态，但仍尝试在节点发生故障时重新定位资源。
残疾人: CRM 尝试将资源置于停止状态，但不会尝试在节点发生故障时重新定位资源。此状态的主要目的是错误恢复，因为这是将资源移出错误状态的唯一方法。
被忽略: 该资源将从经理状态中删除，因此 CRM 和 LRM 不再接触该资源。所有影响此资源的 {pve} API 调用都将被执行，直接绕过 HA 堆栈。当源处于此状态时，CRM 命令将被丢弃。节点故障时资源不会被重新定位。

这是一个包含一台虚拟机和一个容器的真实示例。如您所见，这些文件的语法非常简单，因此甚至可以使用您喜欢的编辑器读取或编辑这些文件：

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

虚拟机：501
    状态开始
    最大重定位 2

层数：102
    # 注意：一切都使用默认设置

上述配置是使用ha-manager命令行工具生成的：

# ha-manager 添加 vm:501 --state 已启动 --max_relocate 2
# ha-manager 添加 ct:102

15.6.2。团体

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

组：<组>
       节点 <节点列表>
       <属性> <值>
       ...

评论：<字符串>: 描述。
节点：<节点>[:<pri>]{,<节点>[:<pri>]}*: 集群节点成员列表，其中可以为每个节点赋予优先级。绑定到组的资源将在具有最高优先级的可用节点上运行。如果最高优先级中有更多节点，服务将分发到这些节点。优先级仅具有相对意义。
nofailback : <布尔值>（默认 = 0）: CRM 尝试在具有最高优先级的节点上运行服务。如果优先级较高的节点上线，CRM会将服务迁移到该节点。启用 nofailback 可以防止这种行为。
受限：<布尔值>（默认 = 0）: 绑定到受限组的资源只能在该组定义的节点上运行。如果没有组节点成员在线，资源将处于停止状态。如果所有组成员都离线，则不受限制组上的资源可以在任何集群节点上运行，但一旦组成员上线，它们就会迁移回来。人们可以使用只有一名成员的不受限制的组来实现首选节点行为。

一个常见的要求是资源应该在特定节点上运行。通常资源能够在其他节点上运行，因此您可以定义一个具有单个成员的不受限制的组：

# ha-manager groupadd Preferred_node1 --nodes node1

对于更大的集群，定义更详细的故障转移行为是有意义的。例如，如果可能，您可能希望在节点 1上运行一组服务。如果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）

组：prefer_node1
       节点 节点1

组：我的组1
       节点节点2：1，节点4，节点1：2，节点3：1

组：我的组2
       节点节点2,节点1
       限制 1

nofailback选项对于避免管理任务期间不必要的资源移动非常有用。例如，如果您需要将服务迁移到组中不具有最高优先级的节点，则需要通过设置nofailback选项告诉 HA 管理器不要立即将该服务移回原处。

另一种情况是当服务被隔离并恢复到另一个节点时。管理员尝试修复受隔离的节点并将其重新上线，以调查故障原因并检查其是否再次稳定运行。设置nofailback标志可防止恢复的服务直接移回受防护的节点。

15.7。击剑

当节点发生故障时，防护可确保错误节点离线。这是为了确保资源在另一个节点上恢复时不会运行两次。这是一项非常重要的任务，因为没有它，就不可能恢复另一个节点上的资源。

如果节点没有被隔离，它将处于未知状态，但仍可以访问共享资源。这实在是太危险了！想象一下，除了存储网络之外，所有网络都崩溃了。现在，虽然无法从公共网络访问，但虚拟机仍然运行并向共享存储写入数据。

如果我们只是在另一个节点上启动该虚拟机，我们会遇到危险的竞争条件，因为我们从两个节点进行写入。这种情况可能会破坏所有虚拟机数据，并且整个虚拟机可能无法使用。如果存储防止多次装载，恢复也可能会失败。

15.7.1。Proxmox VE 如何设置围栏

有不同的方法来隔离节点，例如，隔离设备可以切断节点的电源或完全禁用其通信。这些通常非常昂贵，并且会给系统带来额外的关键组件，因为如果它们出现故障，您将无法恢复任何服务。

因此，我们希望集成一种更简单的防护方法，不需要额外的外部硬件。这可以使用看门狗定时器来完成。

可能的击剑方法

外部电源开关
通过禁用交换机上的完整网络流量来隔离节点
使用看门狗定时器进行自我防护

自微控制器问世以来，看门狗定时器就已广泛应用于关键且可靠的系统中。它们通常是简单、独立的集成电路，用于检测计算机故障并从中恢复。

在正常操作期间，ha-manager会定期重置看门狗定时器以防止其超时。如果由于硬件故障或程序错误，计算机无法重置看门狗，计时器将到期并触发整个服务器的重置（重新启动）。

最近的服务器主板通常包含此类硬件看门狗，但需要对其进行配置。如果没有可用或配置的看门狗，我们将回退到 Linux 内核软狗。虽然仍然可靠，但它并不独立于服务器硬件，因此可靠性低于硬件看门狗。

15.7.2. 配置硬件看门狗

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

# 选择看门狗模块（默认为softdog）
看门狗模块=iTCO_wdt

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

15.7.3。恢复受保护的服务

节点发生故障且防护成功后，CRM 会尝试将服务从发生故障的节点移至仍在线的节点。

恢复这些服务的节点的选择受到资源组设置、当前活动节点列表及其各自的活动服务计数的影响。

CRM 首先根据用户选择的节点（来自组设置）和可用节点之间的交集构建一组。然后，它选择具有最高优先级的节点子集，最后选择具有最低活动服务计数的节点。这最大限度地减少了节点过载的可能性。

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

15.8。启动失败策略

如果某个节点上的服务启动失败一次或多次，则启动失败策略生效。它可用于配置在同一节点上触发重新启动的频率以及应重新定位服务的频率，以便它尝试在另一个节点上启动。该策略的目的是避免特定节点上共享资源暂时不可用。例如，如果共享存储在仲裁节点上不再可用（例如由于网络问题），但在其他节点上仍然可用，则重新定位策略仍然允许服务启动。

有两个服务启动恢复策略设置，可以针对每个资源进行配置。

最大重新启动时间: 在实际节点上尝试重新启动失败服务的最大次数。默认设置为一。
最大重定位: 将服务重新定位到不同节点的最大尝试次数。仅当实际节点上超过 max_restart 值后才会发生重新定位。默认设置为一。

仅当服务至少成功启动一次时，重定位计数状态才会重置为零。这意味着如果在没有修复错误的情况下重新启动服务，则只会重复重新启动策略。

15.9。错误恢复

如果在所有尝试之后仍无法恢复服务状态，则会将其置于错误状态。在这种状态下，服务将不再受到 HA 堆栈的影响。唯一的出路是禁用服务：

# ha-manager 设置 vm:100 --state 已禁用

这也可以在网络界面中完成。

要从错误状态恢复，您应该执行以下操作：

将资源恢复到安全一致的状态（例如：如果服务无法停止，则终止其进程）
禁用资源以删除错误标志
修复导致此失败的错误
修复所有错误后，您可以请求重新启动服务

15.10。套餐更新

更新 ha-manager 时，您应该一个接一个地更新节点，而不是由于各种原因一次性更新所有节点。首先，虽然我们彻底测试了我们的软件，但不能完全排除影响您的特定设置的错误。依次更新一个节点并在完成更新后检查每个节点的功能有助于从最终的问题中恢复，而一次更新所有节点可能会导致集群损坏，通常不是一个好的做法。

此外，Proxmox VE HA 堆栈使用请求确认协议来执行集群和本地资源管理器之间的操作。为了重新启动，LRM 向 CRM 请求冻结其所有服务。这可以防止它们在 LRM 重新启动的短时间内被集群触及。之后，LRM 可以在重启期间安全地关闭看门狗。这种重新启动通常发生在软件包更新期间，并且如前所述，需要一个活动的主 CRM 来确认来自 LRM 的请求。如果不是这种情况，更新过程可能会花费太长时间，在最坏的情况下，可能会导致看门狗触发复位。

15.11。节点维护

有时需要对节点进行维护，例如更换硬件或简单地安装新的内核映像。这在使用 HA 堆栈时也适用。

HA堆栈主要可以为您提供两种类型的维护支持：

对于一般关闭或重新启动，可以配置行为，请参阅关闭策略。
对于不需要关机或重启的维护，或者仅重启一次后不应该自动关闭的维护，可以启用手动维护模式。

15.11.1。维护模式

启用手动维护模式会将节点标记为不可操作，这反过来会将所有服务迁移到通过配置的集群资源调度程序 (CRS) 模式选择的其他节点。迁移过程中会记录原节点，以便在维护模式关闭后，服务可以立即移回该节点，并重新上线。

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

启用节点维护模式

# ha-manager crm-command 节点维护启用 NODENAME

这会将 CRM 命令排队，当管理器处理此命令时，它将在管理器状态中记录维护模式的请求。这允许您在任何节点上提交命令，而不仅仅是在您想要进入或退出维护模式的节点上。

一旦相应节点上的 LRM 接收到该命令，它会将自己标记为不可用，但仍会处理所有迁移命令。这意味着 LRM 自防护看门狗将保持活动状态，直到所有活动服务都被移动并且所有正在运行的工作线程完成为止。

请注意，一旦 LRM 选择了请求的状态，LRM 状态将立即读取维护模式，不仅当所有服务都被移走时，这种用户体验计划在未来得到改善。目前，您可以检查节点上是否有任何活动的 HA 服务，或者留意类似以下的日志行：pve-ha-lrm[PID]: watchdog close (disabled)以了解节点何时完成过渡到维护状态模式。

手动维护模式不会在节点重新引导时自动删除，但仅当使用ha-manager CLI 手动停用或手动清除 manager-status 时才会删除。

禁用节点的维护模式

# ha-manager crm-command 节点维护禁用 NODENAME

禁用手动维护模式的过程与启用手动维护模式类似。使用上面显示的ha-manager CLI 命令将对 CRM 命令进行排队，该命令一旦处理，就会将相应的 LRM 节点再次标记为可用。

如果停用维护模式，则激活维护模式时节点上的所有服务都将移回。

15.11.2。关闭政策

下面您将找到针对节点关闭的不同 HA 策略的描述。由于向后兼容性，目前“条件”是默认设置。一些用户可能会发现Migrate 的行为更符合预期。

迁移

一旦本地资源管理器 (LRM) 收到关闭请求并启用此策略，它会将自己标记为对当前 HA 管理器不可用。这会触发当前位于该节点上的所有 HA 服务的迁移。LRM 将尝试延迟关闭过程，直到所有正在运行的服务都被移走。但是，这期望正在运行的服务可以迁移到另一个节点。换句话说，服务不能是本地绑定的，例如通过使用硬件直通。由于如果没有可用的组成员，则非组成员节点将被视为可运行目标，因此在仅选择部分节点的情况下使用 HA 组时仍然可以使用此策略。但是，将组标记为受限会告诉 HA 管理器该服务无法在所选节点集之外运行。如果所有这些节点都不可用，关闭将挂起，直到您手动干预。一旦关闭的节点再次恢复在线，之前被替换的服务将被移回（如果它们之间尚未手动迁移）。

在关闭时的迁移过程中，看门狗仍然处于活动状态。如果节点失去仲裁，它将被隔离并且服务将被恢复。

如果您在当前正在维护的节点上启动（之前已停止的）服务，则需要对该节点进行隔离以确保该服务可以在另一个可用节点上移动和启动。

故障转移

此模式可确保所有服务停止，但如果当前节点不很快上线，它们也会恢复。在进行集群规模的维护时，它非常有用，如果一次关闭太多节点，则可能无法实时迁移虚拟机，但您仍然希望确保 HA 服务尽快恢复并重新启动。

冻结

该模式确保所有服务都停止并冻结，直到当前节点再次上线后才能恢复。

有条件的

有条件关闭策略会自动检测是否请求关闭或重新启动，并相应地更改行为。

关闭

如果计划让节点保持关闭状态一段时间，通常会执行关闭 ( poweroff )。在这种情况下，LRM 会停止所有托管服务。这意味着其他节点随后将接管这些服务。

最近的硬件具有大量内存 (RAM)。因此，我们停止所有资源，然后重新启动它们，以避免所有 RAM 的在线迁移。如果您想使用在线迁移，则需要在关闭节点之前手动调用它。

重启

节点重新启动是通过reboot命令启动的。这通常是在安装新内核后完成的。请注意，这与“关闭”不同，因为节点会立即重新启动。

LRM 告诉 CRM 它想要重新启动，并等待 CRM 将所有资源置于冻结状态（相同的机制用于包更新）。这可以防止这些资源被移动到其他节点。相反，CRM 在同一节点上重新启动后启动资源。

手动资源移动

最后但并非最不重要的一点是，您还可以在关闭或重新启动节点之前手动将资源移动到其他节点。优点是您拥有完全的控制权，您可以决定是否要使用在线迁移。

请不要终止pve-ha-crm、pve-ha-lrm或 watchdog-mux等服务。他们管理和使用看门狗，因此这可能会导致节点立即重新启动甚至重置。

15.12。集群资源调度

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

crs: ha=静态

该更改将从下一轮经理开始生效（几秒钟后）。

对于每个需要恢复或迁移的服务，调度程序会迭代地从该服务组中具有最高优先级的节点中选择最佳节点。

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

15.12.1。基本调度程序

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

15.12.2。静态负载调度程序

静态模式仍然是技术预览。

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

对于此选择，每个节点依次被视为服务已在其上运行，使用关联来宾配置中的 CPU 和内存使用情况。然后，对于每个这样的替代方案，都会考虑所有节点的 CPU 和内存使用情况，其中内存的权重要大得多，因为它是真正有限的资源。对于 CPU 和内存，都会考虑节点之间的最高使用率（权重更大，因为理想情况下不应过度使用节点）和所有节点的平均使用率（以便在已经存在更高提交度的节点的情况下仍然能够区分）。

服务越多，可能的组合就越多，因此，如果您有数千个 HA 托管服务，目前不建议使用它。

15.12.3。CRS调度点

CRS算法并不适用于每一轮的每个服务，因为这意味着大量的持续迁移。根据工作负载的不同，这可能会给集群带来比持续平衡所能避免的更大的压力。这就是 Proxmox VE HA 管理器倾向于将服务保留在当前节点上的原因。

CRS目前在以下调度点使用：

服务恢复（始终处于活动状态）。当具有活跃HA服务的节点发生故障时，需要将其所有服务恢复到其他节点。这里将使用 CRS 算法来平衡其余节点的恢复。
HA 组配置更改（始终处于活动状态）。如果节点从组中删除，或者其优先级降低，HA 堆栈将使用 CRS 算法为该组中的 HA 服务找到新的目标节点，匹配调整后的优先级约束。
HA 服务停止 → 开始转换（选择加入）。请求启动已停止的服务是根据 CRS 算法检查最适合的节点的好机会，因为移动已停止的服务比将其启动更便宜，尤其是当它们的磁盘卷驻留在共享存储上时。您可以通过在数据中心配置中设置ha-rebalance-on-start CRS 选项来启用此功能。您还可以在 Web UI 中的Datacenter → Options → Cluster Resource Scheduling下更改该选项。

作者Lin-Tech