15、高可用

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

我们可以从数学上把可用性定义为(A)，即某一服务在给定时间间隔内能够被使用的总时间，与(B)，即时间间隔的长度之比。它通常表示为给定年份中正常运行时间的百分比。

表15.1:可用性-每年停机时间

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

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

  请注意
  具有相同功能的计算机组件可能有不同的可靠性数字，这取决于组件的质量。大多数供应商以更高的价格出售可靠性更高的“服务器”组件。

• 消除单点故障(冗余组件)

  • 使用不间断电源(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)唯一标识，SID由资源类型和特定类型的ID组成，如vm:100。该示例将是ID为100的类型为vm(虚拟机)的资源。

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

15.3、管理任务

本节简要介绍常见的管理任务。第一步是为资源启用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 manager和资源状态:

# 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

这使用在线迁移，并试图保持VM运行。在线迁移需要通过网络传输所有使用的内存，因此有时关闭虚拟机，然后在新节点上重新启动它会更快。这可以通过使用relocate命令实现:

# ha-manager relocate vm:100 node2

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

# ha-manager remove vm:100

请注意
这不会启动或停止资源。

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

15.4、如何工作

介绍Proxmox VE HA manager的内部结构。它描述了所有涉及的守护进程以及它们如何一起工作。为了提供HA，在每个节点上运行两个守护进程:

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

pve-ha-crm
集群资源管理器(CRM)，它作出集群范围内的决策。它向LRM发送命令，处理结果，并在发生故障时将资源移动到其他节点。CRM还处理节点隔离。

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

15.4.1、服务状态

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)

以下是可能的状态列表:

stopped
服务停止(经LRM确认)。当LRM检测到已停止的服务仍在运行时，会再次停止该服务。

request_stop
服务应该停止。CRM等待LRM的确认。

stopping
等待停止请求。但到目前为止，客户关系管理系统还没有收到这一请求。

started
服务是活跃的，如果没有运行，LRM应该尽快启动它。如果服务失败并且检测到没有运行，LRM将重新启动它(参见启动失败策略15.8节)。

starting
即将开始的请求。但是CRM还没有从LRM得到服务正在运行的任何确认。

fence
等待节点fencing(服务节点不在法定集群分区内)。一旦节点被成功隔离，服务将被恢复到另一个节点，如果可能的话(参见隔离15.7节)。

freeze
请勿触摸服务状态。当我们重新启动一个节点时，或者当我们重新启动LRM守护进程时，我们会使用这个状态(见包更新15.10节)。

ignored
就像服务根本不受HA管理一样进行操作。当需要暂时完全控制服务，而不需要从HA配置中删除服务时，此功能非常有用。

migrate
迁移服务(live)到其他节点。

error
由于LRM错误，服务被禁用。需要人工干预(见错误恢复15.9节)。

queued
服务是新增的，目前CRM还没有看到。

disabled
服务停止并被标记为禁用

15.4.2、本地资源管理器

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

它可以有三种状态:

wait for agent lock
LRM等待我们的排他锁。如果没有配置服务，这也被用作空闲状态。

active
LRM持有它的排他锁，并配置了服务。

lost agent lock
LRM丢失了它的锁，这意味着发生了故障并且仲裁丢失了。

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

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

CRM请求的每个命令都由UID唯一标识。当worker完成时，它的结果将被处理并写入LRM状态文件/etc/pve/nodes//lrm_status。在那里，CRM可以收集它并让它的状态机(对应于命令输出)对它进行操作。

CRM和LRM之间的每个服务上的操作通常总是同步的。这意味着CRM请求一个由UID唯一标记的状态，然后LRM执行此操作一次并写回结果，结果也可以由相同的UID标识。这是需要的，这样LRM就不会执行过时的命令。这种行为的唯一例外是stop和error命令;这两个不依赖于生成的结果，总是在停止状态下执行，在错误状态下执行一次。

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

15.4.3、集群资源管理器

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

它可以有三种状态:

wait for agent lock
CRM等待我们的独家锁定。如果没有配置服务，这也被用作空闲状态

active
CRM持有它的独占锁并配置了服务

lost agent lock
CRM丢失了锁，这意味着发生了故障，仲裁丢失了。

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

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

当集群成员确定它不再位于集群仲裁中时，LRM将等待形成新的仲裁。只要没有仲裁，节点就不能重置看门狗。这将在看门狗超时后触发重新启动(在60秒后发生)。

15.5、HA模拟器

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

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

您不需要设置或配置真正的集群，HA模拟器可以开箱运行。

安装:

apt install pve-ha-simulator

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

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

如果你是在Linux机器上，你可以使用:

ssh root@<IPofPVE> -Y

在Windows上，它与mobaxterm一起工作。

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

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

mkdir working

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

pve-ha-simulator working/

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

15.6、配置

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

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

15.6.1、资源

ha-manager管理的资源列表在资源配置文件“/etc/pve/ha/resources.cfg”中。列表中的资源配置是这样的:

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

它以资源类型开头，后面跟着特定于资源的名称，中间用冒号分隔。所有HA -manager命令都使用HA资源ID来唯一标识一个资源(例如:vm:100或ct:101)。接下来的几行包含了额外的属性:

comment:
描述。

group:
HA组标识符。

max_relocate: (0 - N) (default = 1)
当服务启动失败时，重新定位服务的最大次数。

max_restart: (0 - N) (default = 1)
节点上服务启动失败后重新启动服务的最大尝试次数。

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

started
CRM试图启动资源。启动成功后，服务状态设置为“已启动”。在节点故障或启动失败时，它尝试恢复资源。如果一切都失败了，则将服务状态设置为error。

stopped
CRM尝试保持资源处于停止状态，但它仍然尝试在节点故障时重新定位资源。

disabled
CRM尝试将资源置于停止状态，但不尝试在节点故障时重新定位资源。这种状态的主要目的是错误恢复，因为这是将资源移出错误状态的唯一方法。

ignored
资源从管理器状态中删除，因此CRM和LRM不再接触资源。所有影响此资源的Proxmox VE API调用都将被执行，直接绕过HA堆栈。当源处于这种状态时，CRM命令将被丢弃。资源不会在节点故障时重新定位。

下面是一个带有一个VM和一个容器的真实例子。如你所见，这些文件的语法非常简单，所以甚至可以使用你最喜欢的编辑器来读取或编辑这些文件:

配置示例 (/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

15.6.2、组

HA组配置文件“/etc/pve/ha/groups.cfg”用于定义集群节点的组。资源可以被限制为仅在该组的成员上运行。组配置是这样的:

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

comment:
描述。

nodes: [:]{,[:]}*
集群节点成员的列表，其中可以为每个节点赋予优先级。绑定到组的资源将在具有最高优先级的可用节点上运行。如果有更多的节点具有最高的优先级，服务将被分发到这些节点。优先级只具有相对意义。

nofailback: (default = 0)
CRM试图在具有最高优先级的节点上运行服务。如果一个具有较高优先级的节点上线，CRM就会将服务迁移到该节点。启用nofailback可以防止这种行为。

restricted: (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 manager没有使用其他节点，因此我们需要创建一个包含上述节点的受限组:

# 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 manager不要立即将该服务移回。

另一种场景是，隔离了一个服务，并将其恢复到另一个节点。管理员尝试修复受保护的节点，并使其再次联机，以调查失败的原因，并检查它是否再次稳定运行。设置nofailback标志可防止恢复的服务直接移动回隔离节点。

15.7、隔离

在节点故障时，fencing可以确保错误节点处于离线状态。这是为了确保在另一个节点上恢复资源时不会运行两次。这是一个非常重要的任务，因为如果没有这个任务，就不可能恢复另一个节点上的资源。

如果一个节点没有受到保护，那么它将处于未知状态，仍然可以访问共享资源。这真的很危险!想象一下，除了存储网络之外，所有的网络都坏了。现在，虽然无法从公共网络访问虚拟机，但虚拟机仍然运行并写入共享存储。

如果我们只是在另一个节点上启动这个VM，我们将会得到一个危险的竞争条件，因为我们从两个节点都进行写操作。这种情况会破坏所有虚拟机数据，并导致整个虚拟机无法使用。如果存储可以防止多次挂载，那么恢复也可能失败。

15.7.1、Proxmox VE如何隔离

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

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

可能的Fencing方法:

• 外部电源开关

• 通过关闭交换机上的全部网络流量来隔离节点

• 使用看门狗定时器进行自我击剑

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

ha-manager正常运行时，会定期重置看门狗定时器，以防止看门狗定时器失效。如果由于硬件故障或程序错误，计算机未能重置看门狗，计时器将超时，并触发整个服务器的重置(reboot)。

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

15.7.2、配置硬件看门狗

出于安全考虑，缺省情况下，所有的硬件看门狗模块被阻塞。如果没有正确初始化，它们就像一把上膛的枪。要启用硬件看门狗，需要在/etc/default/pve-ha-manager中指定要加载的模块，例如:

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

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

15.7.3、恢复隔离服务

当一个节点失败并且它的防护成功后，CRM尝试将服务从失败的节点移动到仍然在线的节点。

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

CRM首先在用户选择的节点(来自组设置)和可用节点之间构建一组交集。然后选择优先级最高的节点子集，最后选择活动服务计数最低的节点。这将最小化重载节点的可能性。

谨慎
当节点故障时，CRM会将业务分发到其他节点。这会增加这些节点上的服务计数，并可能导致高负载，特别是在小型集群上。请设计您的集群，使其能够处理这种最坏的情况。

15.8、启动失败策略

当一个服务在节点上多次启动失败时，启动失败策略生效。它可用于配置在同一节点上触发重启的频率，以及重新部署服务的频率，以便尝试在另一个节点上启动服务。该策略的目的是避免特定节点上共享资源的临时不可用。例如，如果一个共享存储在限定节点上不再可用(例如由于网络问题)，但在其他节点上仍然可用，那么relocate策略仍然允许服务启动。

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

max_restart
实际节点上重启失败服务的最大尝试次数。默认值为1。

max_relocate
将服务重新定位到不同节点的最大尝试次数。只有在实际节点上超过max_restart值后才会发生重新定位。默认值为1。

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

15.9、错误恢复

如果在所有尝试之后，服务状态仍无法恢复，则将其置于错误状态。在这种状态下，HA堆栈不会再碰服务。唯一的解决办法就是关闭服务

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

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

要从错误状态恢复，你应该做以下操作:

• 将资源恢复到安全且一致的状态(例如:如果服务无法停止，则终止其进程)

• 禁用资源以删除错误标志

• 修复导致此失败的错误

• 修复所有错误后，您可以请求重新启动服务

15.10、更新包

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

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

15.11、节点维护

有时需要关闭或重新启动一个节点来执行维护任务，比如更换硬件，或者只是安装一个新的内核映像。在使用HA堆栈时也是如此。HA堆栈在关闭期间的行为可以配置。

15.11.1、关机策略

下面是对节点关闭的不同HA策略的描述。当前条件是默认的，因为向后兼容。一些用户可能会发现Migrate的行为更符合预期。

Migrate

一旦本地资源管理器(LRM)收到一个关闭请求并启用了该策略，它将把自己标记为当前HA管理器不可用。这将触发迁移当前位于该节点上的所有HA服务。LRM将尝试延迟关闭进程，直到所有正在运行的服务被移走。但是，这期望正在运行的服务可以迁移到另一个节点。换句话说，服务不能在本地绑定，例如使用硬件透传。如果没有可用的组成员节点，则将非组成员节点视为可运行目标，因此在仅选择部分节点的情况下，使用HA组时仍可使用该策略。但是，将一个组标记为restricted告诉HA manager服务不能在选择的节点集之外运行。如果所有这些节点都不可用，那么关闭将挂起，直到您手动干预。一旦关闭的节点重新联机，之前替换的服务将被移回(如果它们还没有在中间手动迁移的话)。

请注意
在关闭迁移过程中，看门狗仍然是活跃的。如果节点丢失仲裁，将对其进行隔离，并恢复服务。

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

Failover

该模式可以保证所有业务停止，但如果当前节点短期内不在线，业务也会恢复。在集群规模下进行维护时，如果同时下电的节点太多，则不可能实时迁移虚拟机，但您仍然希望确保HA服务能够尽快恢复并重新启动。

Freeze

该模式确保所有业务都被停止或冻结，直到当前节点重新上线才会恢复。

Conditional

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

Shutdown

如果计划让节点处于关机状态一段时间，则通常会执行关机(下电)操作。在这种情况下，LRM将停止所有托管服务。这意味着其他节点将接管这些服务。

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

Reboot

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

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

Manual Resource Movement

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

请注意
请不要关闭像pve-ha-crm, pve-ha-lrm或watchdog-mux这样的服务。它们管理和使用看门狗，因此这可能导致立即重新启动节点，甚至复位。