我们的现代社会严重依赖通过网络由电脑提供的信息。移动设备放大了这种依赖性，因为人们可以随时随地访问网络。如果你提供此类服务，非常重要的是它们必须大部分时间都是可用的。

我们可以从数学上定义可用性为：在给定时间间隔内，服务能够被使用的总时间(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秒

有几种方法可以提高可用性。最优雅的解决方案是重写你的软件，以便你可以同时在几个主机上运行它。软件本身需要有一种方式来检测错误并进行故障转移。如果你只想提供只读的网页，那么这相对简单。然而，这通常复杂且有时不可能，因为你无法自己修改软件。以下解决方案在不修改软件的情况下也能工作：

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

    Note
    		 具有相同功能的计算机组件的可靠性数据可能会有所不同，这取决于组件的质量。大多数供应商将可靠性更高的组件作为“服务器”组件出售 - 通常价格更高。

  • 消除单点故障（冗余组件）

    • 使用不间断电源(UPS)

    • 在你的服务器中使用冗余电源供应器

    • 使用ECC-RAM

    • 使用冗余的网络硬件

    • 使用RAID作为本地存储

    • 使用分布式、冗余存储来保存虚拟机数据。

  • 减少停机时间

    • 全天候快速可访问的管理员

    • 备件可用性（{PVE}集群中的其他节点）

    • 自动错误检测（由`ha-manager`提供）

    • 自动故障转移（由 ha-manager 提供）

虚拟化环境，如{pve}，它们消除了对“硬件”的依赖，这使得实现高可用性变得更加容易。它们还支持冗余存储和网络设备的设置和使用，因此如果一个主机发生故障，你可以简单地在集群内的另一个主机上启动这些服务。

更好的是，{pve} 提供了一个名为 ha-manager 的软件堆栈，它可以自动为您完成这些任务。它能够自动检测错误并执行自动故障转移。

{pve} ha-manager 的工作方式类似于一个`‘自动化’'管理员。首先，您需要配置它应该管理的资源（虚拟机、容器等）。然后，ha-manager 会监控正确的功能性，并在出现错误时处理服务的故障转移到另一个节点。ha-manager 还可以处理正常的用户请求，这些请求可能包括启动、停止、重新定位和迁移服务。

但是高可用性是有代价的。高质量的组件更加昂贵，而使它们冗余至少增加一倍的成本。额外的备件进一步增加了成本。因此，你应该仔细计算这些好处，并且与那些额外的成本进行比较。

Tip
 将可用性从99%提升到99.9%相对简单。但是将可用性从99.9999%提升到99.99999%非常困难且成本高昂。`ha-manager`具有大约2分钟的典型错误检测和故障转移时间，所以你最多只能获得99.999%的可用性。

要求

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

  • 至少三个集群节点（以获得可靠的法定人数）

  • 虚拟机和容器的共享存储

  • 硬件冗余（到处都是）

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

  • 硬件看门狗 - 如果不可用，我们将回退到Linux内核软件看门狗（softdog）

  • 可选的硬件隔离设备

资源

我们将由`ha-manager`处理的主要管理单元称为资源。资源（也称为`‘服务’'）由服务ID（SID）唯一标识，该ID由资源类型和特定类型的ID组成，例如`vm:100`。那个例子将是一个类型为`vm`（虚拟机）的资源，其ID为100。

目前我们有两种重要的资源类型——虚拟机和容器。这里的一个基本思想是，我们可以将相关软件打包进这样的虚拟机或容器中，这样就无需像以前使用`rgmanager`那样，从其他服务中组合一个大型服务。通常，一个高可用性管理资源不应该依赖于其他资源。

管理任务

这部分简要概述了常见的管理任务。第一步是为资源启用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`。

Note
 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
Note
 这并不会启动或停止资源。

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

它是如何工作的

这一部分提供了{PVE}高可用性(HA)管理器内部详细的描述。它描述了所有涉及的守护进程以及它们是如何协同工作的。为了提供高可用性，每个节点上运行两个守护进程：

pve-ha-lrm

本地资源管理器（LRM），它控制在本地节点上运行的服务。它从当前的管理器状态文件中读取其服务的请求状态，并执行相应的命令。

pve-ha-crm

集群资源管理器（CRM）负责做出集群范围内的决策。它向本地资源管理器（LRM）发送指令，处理结果，如果出现故障，它会将资源移动到其他节点。CRM还负责处理节点隔离。

Note
LRM和CRM中的锁定
锁是由我们的分布式配置文件系统（pmxcfs）提供的。它们用来保证每个LRM是单一活跃的并且正在工作。由于LRM只有在持有锁的时候才会执行操作，如果我们能够获得它的锁，我们就可以将一个失败节点标记为已隔离。这样我们就能在没有任何来自于现在不明的失败节点的干扰下安全地恢复任何失败的HA服务。这一切都由当前持有管理器主锁的CRM来监督。

服务状态

CRM 使用一种服务状态枚举来记录当前的服务状态。这个状态会在图形用户界面上显示，并且可以使用 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)

这里是可能的状态列表：

停止了

服务已停止（通过LRM确认）。如果LRM检测到已停止的服务仍在运行，它将再次停止该服务。

请求停止

服务应当停止。CRM正在等待LRM的确认。

停止

等待停止请求。但是CRM到目前为止还没有收到请求。

开始了

服务处于活动状态，如果LRM还没有启动，应尽快启动它。如果服务失败并且检测到没有运行，LRM将重启它（参见启动失败政策）。

开始

等待启动请求。但是CRM尚未从LRM那里获得任何确认服务正在运行的确认。

围栏

等待节点隔离，因为服务节点不在具有法定人数的集群分区内（参见隔离）。一旦节点成功地被隔离，服务将会被置于恢复状态。

恢复

等待服务恢复。HA管理员会尝试找到一个新的节点来运行服务。这个搜索不仅依赖于在线且具有法定人数的节点列表，而且还取决于服务是否是组成员以及这样的组是如何受限的。一旦找到一个新的可用节点，服务将被移动到那里，并最初置于停止状态。如果配置为在新节点上运行，那么新节点将会这样做。

冻结

不要触摸服务状态。我们在重启一个节点或者重启LRM守护进程时会使用这个状态（参见软件包更新）。

被忽视

就好像服务根本不受HA（高可用性）管理一样行事。这在希望暂时完全控制服务而不将其从HA配置中移除时很有用。

迁移

将服务（实时）迁移至其他节点。

错误

服务因LRM错误被禁用。需要手动干预（见错误恢复）。

排队中

服务是新添加的，CRM到目前为止还没有看到它。

残疾

服务已停止并标记为`disabled`。

本地资源管理器

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

它可以处于三种状态：

等待代理锁

LRM等待我们的独占锁。如果没有配置服务，这也被用作空闲状态。

积极的

LRM持有其独占锁并配置了服务。

失去代理锁定

LRM丢失了锁定，这意味着发生了故障，且丧失了法定人数。

在LRM进入激活状态后，它会读取`/etc/pve/ha/manager_status`中的管理状态文件，并确定它需要执行的针对其所拥有的服务的命令。对于每个命令，会启动一个工作器，这些工作器会并行运行，并且默认最多限制为4个。这个默认设置可以通过数据中心配置关键词`max_worker`进行修改。当工作完成时，工作器进程被收集起来，其结果会被保存，以供CRM使用。

Note
最大并发工作者调整提示
最多同时进行4个并发工作的默认值可能不适用于特定的设置。例如，可能会同时发生4次实时迁移，这可能导致在网络较慢和/或服务（内存方面）较大的情况下发生网络拥塞。此外，要确保在最坏的情况下，尽可能减少拥塞，即使这意味着降低`max_worker`的值。相反，如果你有一个特别强大的高端设置，你也可能希望增加它。

每个由CRM请求的命令都可以通过一个UID来唯一识别。当工作器完成时，其结果将被处理并写入LRM状态文件`/etc/pve/nodes/<nodename>/lrm_status`中。在那里，CRM可能会收集它，并让其状态机器 - 针对命令的输出 - 作出相应的行动。

CRM和LRM之间的每项服务操作通常总是保持同步。这意味着CRM请求一个由UID唯一标记的状态，然后LRM执行这个操作*一次*并反馈结果，结果也由相同的UID来标识。这是为了确保LRM不会执行过时的命令所必需的。唯一的例外是`stop`和`error`命令；这两个命令不依赖于产生的结果，并且在停止状态时总是执行，在错误状态时执行一次。

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

集群资源管理器

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

它可以处于三种状态：

等待代理锁

CRM等待我们的独占锁。如果没有配置服务，这也被用作空闲状态。

积极的

CRM持有其独占锁并配置了服务

失去代理锁定

CRM丢失了其锁定，这意味着发生了故障并且丧失了法定人数。

它的主要任务是管理配置为高可用性的服务，并尽量始终强制执行请求的状态。例如，一个请求状态为“已启动”的服务，如果尚未运行，将被启动。如果它崩溃了，将会自动重新启动。因此，CRM指挥LRM需要执行的操作。

当一个节点离开集群仲裁时，其状态变为未知。如果当前的CRM能够随后获得失败节点的锁，服务将被"窃取"并在另一个节点上重启。

当集群成员判断自己不再处于集群法定人数中时，LRM(本地资源管理器)将等待新的法定人数形成。只要没有法定人数，节点就不能重置看门狗。这将在看门狗超时后触发重启（这通常在60秒后发生）。

HA模拟器

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

默认情况下，模拟器允许您观察并测试一个拥有6个虚拟机的现实世界3节点集群的行为。您还可以添加或移除额外的虚拟机或容器。

您无需设置或配置真实的集群，HA（高可用性）模拟器开箱即用。

使用apt进行安装：

apt install pve-ha-simulator

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

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

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

ssh root@<IPofPVE> -Y

在Windows系统上，它与[mobaxterm](https://mobaxterm.mobatek.net/)兼容。

在连接到已安装模拟器的现有{pve}上，或者在您的本地基于Debian的系统上手动安装它之后，您可以按照以下方式尝试使用。

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

mkdir working

然后，简单地将创建的目录作为参数传递给 pve-ha-simulator:

pve-ha-simulator 正在工作/

你接下来可以启动、停止、迁移模拟的高可用性服务，或者甚至检查节点故障时会发生什么。

配置

HA堆栈与{pve} API紧密集成。因此，例如，可以通过`ha-manager`命令行界面或者{pve}网页界面配置HA - 这两个界面都提供了一种简便的管理HA的方式。自动化工具可以直接使用API。

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

资源

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

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

它以资源类型开头，紧接着是特定于资源的名称，二者之间用冒号分隔。二者合起来形成了HA资源ID，该ID被所有`ha-manager`命令用来唯一地识别一个资源（例如：vm:100 或 ct:101）。以下几行包含了额外的属性：

comment`: `<string>

描述。

group`: `<string>

HA组标识符。

max_relocate`：<整数> (0 - N) (默认值= 1)

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

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

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

state`：<disabled | enabled | ignored | started | stopped>（默认值=started）

请求的资源状态。CRM会读取这个状态并做出相应行动。请注意，`enabled`只是`started`的一个别名。

已开始

CRM尝试启动资源。在成功启动后，服务状态被置为`started`。在节点故障或启动失败时，它会尝试恢复资源。如果所有尝试都失败了，服务状态会被置为`error`。

已停止

CRM尝试将资源保持在`stopped`状态，但它仍然会在节点故障时尝试重新定位资源。

禁用

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

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

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

群组

HA组配置文件`/etc/pve/ha/groups.cfg`用来定义集群节点的组。资源可以被限制只在这样的组的成员上运行。一个组配置看起来像这样：

group: <group>
nodes <node_list>
<property> <value>
...
comment`: `<string>

描述。

nodes`: `<node>[:<pri>]{,<node>[:<pri>]}*

集群节点成员列表，可以给每个节点指定一个优先级。绑定到组的资源将在具有最高优先级的可用节点上运行。如果在最高优先级类中有更多的节点，服务将会分配到这些节点上。优先级只具有相对意义。

nofailback`：<布尔值>（默认值=0）

CRM试图在具有最高优先级的节点上运行服务。如果一个具有更高优先级的节点上线了，CRM会将服务迁移到那个节点。启用nofailback可以阻止该行为。

restricted`: <boolean> (default = 0)

绑定到受限组的资源只能在该组定义的节点上运行。如果没有组节点成员在线，资源将被置于停止状态。如果所有组成员都离线，不受限组的资源可以在任何集群节点上运行，但是一旦组成员上线，它们会迁移回来。可以使用只有一个成员的不受限组来实现“首选节点”的行为。

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

# 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 管理器不要立即将此服务移回。

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

击剑

在节点故障时，围栏机制确保出错的节点一定会被脱机处理。这是确保当资源在另一个节点上恢复时不会重复运行的必要条件。这是一个非常重要的任务，因为没有这个机制，就不可能在另一个节点上恢复资源。

如果一个节点没有被隔离，它将处于一个未知状态，可能仍然可以访问共享资源。这非常危险！想象一下，如果每个网络都断了，但存储网络还在。现在，虽然从公共网络上无法访问，虚拟机仍在运行并对共享存储进行写操作。

如果我们简单地在另一个节点上启动这个虚拟机，我们将会遇到一个危险的竞争条件，因为两个节点都在进行写操作。这样的条件可能会破坏所有虚拟机数据，整个虚拟机可能会变得无法使用。如果存储系统防止多重挂载，恢复操作也可能会失败。

如何{pve}围栏

有不同的方法来隔离一个节点，例如，围栏设备可以切断节点的电源或完全禁用它们的通信。这些方法往往相当昂贵，并且会为系统带来额外的关键组件，因为如果它们失效了，你将无法恢复任何服务。

因此，我们想要整合一种更简单的围栏方法，这种方法不需要额外的外部硬件。这可以通过使用看门狗定时器来实现。

可能的围栏方法

  • 外部电源开关

  • 通过在交换机上禁止所有网络流量来隔离节点

  • 使用看门狗定时器进行自我防护

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

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

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

配置硬件看门狗

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

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

这个配置被’watchdog-mux’服务读取，在启动时加载指定的模块。

恢复已隔离的服务

节点失败并且成功隔离后，CRM尝试将服务从失败的节点移动到仍然在线的节点。

服务恢复在哪些节点上进行的选择，受到资源`group`设置、当前活跃节点列表及其各自活跃服务数量的影响。

CRM首先构建一个集合，该集合由用户从`group`设置中选择的节点与可用节点的交集组成。随后选择具有最高优先级的节点子集，最终选择活跃服务数最少的节点。这样可以将节点过载的可能性降到最低。

Caution
 在节点故障时，CRM将服务分配给其余的节点。这会增加那些节点上的服务数量，可能导致高负载，尤其是在小型集群上。请设计你的集群，确保它能够应对这种最糟糕的情况。

启动失败策略

启动失败策略在服务在节点上启动失败一次或多次时生效。它可用于配置在同一节点上应触发重启的频率，以及服务应多久重新定位一次，以便它有机会在另一个节点上启动。这项策略的目标是为了规避特定节点上共享资源的临时不可用性。例如，如果共享存储在一个仲裁节点上不再可用，比如因为网络问题，但在其他节点上仍然可用，那么重新定位策略允许服务仍然可以启动。

每个资源都可以配置两个特定的服务开始恢复策略设置。

最大重启次数

在当前节点上重新启动失败服务的最大尝试次数。默认设置为一次。

最大重新定位

尝试将服务迁移到不同节点的最大次数。仅在实际节点上超过最大重启次数后，才会发生迁移。默认设置为一次。

Note
 "The relocate count state will only reset to zero when the service had at least one successful start. That means if a service is re-started without fixing the error only the restart policy gets repeated." 翻译成中文是： "重定位计数状态只有在服务至少成功启动一次时才会重置为零。这意味着，如果一个服务在没有修正错误的情况下重新启动，只有重启策略会被重复执行。"

错误恢复

如果在所有尝试之后，服务状态仍然无法恢复，它将被置于错误状态。在这种状态下，服务将不再由HA栈执行任何操作。唯一的解决方法是禁用服务：

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

这也可以在网页接口中完成。

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

  • 将资源恢复到安全且一致的状态（例如：如果服务无法停止，则杀掉其进程）

  • 禁用资源以移除错误标记

  • 修复导致这些失败的错误

  • 在你修正了所有错误之后，你可以请求服务重新开始

软件包更新

在更新ha-manager时，您应该逐个节点进行更新，出于各种原因，决不能一次全部更新。首先，虽然我们会彻底测试我们的软件，但不能完全排除影响您特定设置的错误。逐个节点更新并在完成更新后检查每个节点的功能，有助于从可能出现的问题中恢复，而一次性全部更新可能会导致集群瘫痪，通常来说这不是一个好的做法。

此外，{pve} HA堆栈使用一个请求确认协议来在集群和本地资源管理器之间执行操作。对于重启，LRM向CRM发出请求以冻结其所有服务。这防止了在LRM重启的短时间内，其服务被集群触及。在此之后，LRM可以在重启期间安全地关闭看门狗。这类重启通常在包更新期间发生，正如已经说过的，需要一个活跃的主CRM来确认来自LRM的请求。如果不是这种情况，更新过程可能会耗时太长，最坏的情况下，可能会导致由看门狗触发的重置。

节点维护

有时候需要对节点进行维护，比如更换硬件或者仅仅是安装一个新的内核镜像。这也适用于HA堆栈正在使用的情况。

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

  • 对于常规的关机或重启，行为可以被配置，见Shutdown Policy。

  • 对于不需要关闭或重启的维护，或者不应该在一次重启后自动关闭的维护，您可以启用手动维护模式。

维护模式

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

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

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

启用节点的维护模式
# ha-manager crm-command node-maintenance enable NODENAME

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

一旦相应节点上的LRM接收到命令，它将标记自身为不可用，但仍会处理所有迁移命令。这意味着LRM的自我隔离看门狗将保持活动状态，直到所有活动服务都被转移，所有运行中的工作者都完成。

请注意，一旦LRM捕获到请求的状态，LRM状态将显示为`维护`模式，并不仅仅是在所有服务都被移走之后，这种用户体验计划在将来得到改善。目前，您可以检查节点上是否有任何活跃的HA服务，或者观察日志行，如：pve-ha-lrm[PID]: watchdog closed (disabled)，以了解节点何时完成过渡到维护模式。

Note
 手动维护模式在节点重启时不会自动删除，只有在使用`ha-manager`命令行界面手动停用或手动清除管理器状态时才会删除。
关闭节点的维护模式
# ha-manager crm-command node-maintenance disable NODENAME

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

如果您停用维护模式，所有在启动维护模式时处于该节点上的服务都将被移回。

关机政策

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

关机策略可以在Web界面中进行配置（Datacenter → Options → HA Settings），或者直接在`datacenter.cfg`文件中配置：

ha: 关闭政策=<值>

迁移

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

Note
 在关机期间迁移过程中看门狗仍然处于活动状态。如果节点失去法定人数，它将被隔离并且服务将被恢复。

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

故障转移

这种模式确保所有服务都会被停止，但如果当前节点不能很快恢复在线，这些服务也会被恢复。当在集群规模上进行维护时，这种模式可能非常有用，尤其是当一次性关闭的节点过多时，实时迁移虚拟机可能无法执行，但你仍然希望建立高可用性服务，并确保这些服务能够尽快恢复并重新启动。

冻结

这种模式确保所有服务都被停止和冻结，以便在当前节点再次上线之前它们不会被恢复。

条件的

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

关闭

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

Note
 近期的硬件拥有大量的内存（RAM）。因此，我们停止所有资源，然后重启它们，以避免所有那些RAM的在线迁移。如果你想要使用在线迁移，你需要在关闭节点之前手动调用该功能。
重新启动

节点重启是通过’reboot’命令启动的。这通常在安装新内核后进行。请注意，这与`‘shutdown’'不同，因为节点会立即重新启动。

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

手动资源移动

最后但同样重要的是，在关闭或重启一个节点之前，您也可以手动将资源移动到其他节点。其优势在于你可以完全控制，并且你可以决定是否使用在线迁移。

Note
 请不要关闭诸如`pve-ha-crm`、`pve-ha-lrm`或`watchdog-mux`这样的服务。它们管理并使用看门狗，因此这可能导致节点立即重启甚至重置。

集群资源调度

集群资源调度器（CRS）模式控制HA如何为恢复服务以及由关闭策略触发的迁移选择节点。默认模式为`basic`，您可以在Web UI（数据中心 → 选项）中更改它，或者直接在`datacenter.cfg`文件中修改：

crs: ha=static

这一变更将从下一轮经理周期开始生效（几秒钟后）。

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

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

基本调度器

每个节点上活动的HA服务数量被用来选择恢复节点。目前，非HA管理的服务不在计数范围内。

静态负载调度器

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

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

在此选择中，依次考虑每个节点，就好像服务已经在其上运行一样，使用的是与之关联的客户配置中的CPU和内存使用情况。然后对于每个这样的备选方案，考虑所有节点的CPU和内存使用情况，内存被赋予更多权重，因为它是真正有限的资源。对于CPU和内存，都会考虑节点之间的最高使用率（给予更多权重，因为理想情况下不应该有节点超额承载）以及所有节点的平均使用率（以便在已经有节点超额承载的情况下仍然能够区分）。

Important
 服务越多，可能的组合就越多，因此如果你有成千上万个HA管理的服务，目前不建议使用它。

CRS调度积分

CRS算法并不在每一轮中对每项服务都应用，因为这将意味着大量的常态迁移。根据工作负载的不同，这可能会给集群带来比通过持续平衡所能避免的更大压力。这就是为什么{pve} HA 管理器更倾向于保持服务在其当前节点上。

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

  • 服务恢复（始终处于活动状态）。当一个具有活跃HA服务的节点失败时，所有的服务都需要恢复到其他节点。此时将使用CRS算法在剩余节点之间平衡这种恢复。

  • HA组配置更改（始终处于激活状态）。如果一个节点从组中被移除，或者其优先级被降低，HA堆栈将使用CRS算法为该组中的HA服务找到一个新的目标节点，匹配调整后的优先级约束。

  • HA服务已停止 → 开始转换（自愿加入）。请求启动一个已停止的服务是检查根据CRS算法最适合的节点的好机会，因为移动已停止的服务比移动已启动的服务要便宜，尤其是当它们的磁盘卷位于共享存储上时。您可以通过在数据中心配置中设置ha-rebalance-on-start CRS选项来启用此功能。您也可以在Web UI中更改该选项，路径为`数据中心` → 选项 → 集群资源调度。