Proxmox VE 6.0管理指南——14 高可用性

14 高可用性

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

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

表17.可用性-每年的停机时间
可用性 ％	每年停机时间
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进行本地存储
  • 对VM数据使用分布式冗余存储
• 减少停机时间
  • 快速访问的管理员（24/7）
  • 备件的可用性（Proxmox VE集群中的其他节点）
  • 自动错误检测（由ha-manager提供）
  • 自动故障转移（由ha-manager提供）

像Proxmox VE这样的虚拟化环境可以轻松实现高可用性，因为它们消除了“硬件”依赖性。它们还支持设置和使用冗余存储和网络设备。因此，如果一台主机发生故障，您只需在集群中的另一台主机上启动这些服务即可。

更好的是，Proxmox VE提供了称为ha-manager的软件堆栈，可以自动为您完成此操作。它能够自动检测错误并执行自动故障转移。

Proxmox VE ha管理器的工作方式类似于“自动化”管理员。首先，配置它应管理的资源（VM，容器等）。然后，ha-manager会观察到正确的功能，并在出现错误的情况下将服务故障转移到另一个节点。ha-manager还可以处理正常的用户请求，这些请求可能会启动，停止，重定位和迁移服务。

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

将可用性从99％增加到99.9％相对简单。但是，将可用性从99.9999％提高到99.99999％非常困难且昂贵。ha-manager具有典型的错误检测和故障转移时间，大约为2分钟，因此您可获得的可用性不超过99.999％。

14.1 要求

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

• 至少三个群集节点（以获得可靠的仲裁）
• VM和容器的共享存储
• 硬件冗余（无处不在）
• 使用可靠的“服务器”组件
• 硬件看门狗-如果不可用，我们将退回到linux内核软件看门狗（softdog）
• 可选的硬件围栏设备

14.2 资源资源

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

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

14.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

您还可以使用常规的VM和容器管理命令。他们自动将命令转发到HA堆栈，因此

# qm start 100

只需将请求的状态设置为started。同样适用于QM停止，这台被请求国停止。

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

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

# ha-manager config

vm：100

        状态停止

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

# ha-manager status

仲裁确定

主节点1（活动，2016年11月23日星期三11:07:23）

lrm elsa（正在使用，2016年11月23日星期三11:07:19）

服务vm：100（node1已启动）

您还可以启动资源迁移到其他节点：

# ha-manager migrate vm：100 node2

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

# ha-manager relocate vm：100 node2

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

# ha-manager remove vm：100

这不会启动或停止资源。

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

14.4 这个怎么运作

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

pve-ha-lrm

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

pve-ha-crm

集群资源管理器（CRM），它负责集群范围内的决策。它会向LRM发送命令，处理结果，并在出现故障时将资源移至其他节点。CRM还处理节点防护。

锁定LRM和CRM 锁由我们的分布式配置文件系统（pmxcfs）提供。它们用于确保每个LRM一次活动并正常工作。由于LRM仅在持有其锁定时才执行操作，因此，如果我们可以获取其锁定，则可以将发生故障的节点标记为已隔离。这样一来，我们就可以安全地恢复所有失败的HA服务，而不会受到现在未知的失败节点的任何干扰。所有这些都由当前持有经理主锁的CRM进行监督。

14.4.1 服务状态

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

# ha-manager status

仲裁确定

master elsa（正在活动，2016年11月21日星期一）

lrm elsa（正在活动，2016年11月21日星期一）

服务ct：100（elsa，已停止）

服务ct：102（已启动elsa）

服务vm：501（elsa，已启动）

以下是可能的状态列表：

停止了

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

request_stop

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

停止

等待停止请求。但是到目前为止，CRM尚未收到请求。

开始了

如果服务处于活动状态，则LRM如果尚未运行，则应尽快启动它。如果该服务失败并且被检测为未运行，则LRM会重新启动它（请参阅“ 启动失败策略”）。

开始

等待开始请求。但是CRM尚未从LRM得到有关服务正在运行的任何确认。

围栏

等待节点防护（服务节点不在法定群集分区内）。节点成功建立隔离后，服务将尽快恢复到另一个节点（请参阅Fencing）。

冻结

请勿触摸服务状态。我们在重新启动节点或重新启动LRM守护程序时使用此状态（请参阅Package Updates）。

被忽略

就像服务完全不受HA管理一样。当需要暂时完全控制服务而不将其从高可用性配置中删除时，此功能很有用。

迁移

将服务（活动）迁移到其他节点。

错误

由于LRM错误，服务被禁用。需要手动干预（请参阅错误恢复）。

排队

服务是新添加的，到目前为止，CRM尚未看到它。

残障人士

服务已停止并标记为禁用

14.4.2 本地资源经理

本地资源管理器（pve-ha-lrm）作为启动时的守护程序启动，并等待，直到HA集群达到配额，从而集群范围的锁都在工作。

它可以处于三种状态：

等待代理锁定

LRM等待我们的排他锁。如果未配置任何服务，则也用作空闲状态。

活性

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

丢失的代理锁

LRM失去了锁定，这意味着发生了故障，并且仲裁丢失了。

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

最大同时工作人员调整提示 最多4个并发工作程序的默认值可能不适合特定设置。例如，可能同时发生4个实时迁移，这可能导致网络速度较慢和/或大型（在内存方面）服务的网络拥塞。确保在最坏的情况下也不会发生拥塞，并在需要时降低max_worker值。相反，如果您具有特别强大的高端设置，则可能还需要增加它。

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

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

阅读日志 HA Stack会记录其执行的每个操作。这有助于了解集群中发生了什么以及为什么发生某些事情。在这里重要的是要了解LRM和CRM这两个守护程序的作用。您可以在服务所在的节点上使用 journalctl -u pve-ha-lrm，并在作为当前主节点的节点上对pve-ha-crm使用相同的命令。

14.4.3 集群资源管理器

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

它可以处于三种状态：

等待代理锁定

CRM等待我们的排他锁。如果未配置任何服务，则也用作空闲状态

活性

CRM保留其独占锁并配置了服务

丢失的代理锁

CRM失去了锁定，这意味着发生了故障，并且仲裁丢失了。

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

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

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

14.5 高可用性模拟器

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

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

您不必设置或配置真实集群，HA仿真器即开即用。

使用apt安装：

apt安装pve-ha-simulator

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

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

如果您使用的是Linux计算机，则可以使用：

ssh root @ -Y

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

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

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

mkdir工作

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

PVE-HA模拟器工作/

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

14.6 配置

HA堆栈已很好地集成到Proxmox VE API中。因此，例如，可以通过ha-manager命令行界面或Proxmox VE Web界面配置HA-两个界面都提供了一种轻松的方式来管理HA。自动化工具可以直接使用API​​。

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

14.6.1 资源资源

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

<类型>：<名称>

        <属性> <值>

        ...

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

评论：

描述。

组：<字符串>

HA组标识符。

max_relocate：<整数>（0-N）（默认= 1）

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

max_restart：<整数>（0-N）（默认= 1）

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

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

请求的资源状态。CRM读取此状态并采取相应措施。请注意，启用只是一个别名开始。

开始了

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

停止了

CRM尝试将资源保持在停止状态，但是在节点发生故障时，它仍然尝试重新定位资源。

残障人士

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

被忽略

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

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

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

vm：501

    状态开始

    max_relocate 2

 

ct：102

    # 注意：所有内容均使用默认设置

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

# ha-manager add vm：501-状态已启动--max_relocate 2

# ha-manager add ct：102

14.6.2 团体

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

组：<组>

       节点

       <属性> <值>

       ...

评论：

描述。

节点：<节点> [：] {，<节点> [：]} *

集群节点成员的列表，可以为每个节点赋予优先级。绑定到组的资源将在优先级最高的可用节点上运行。如果在最高优先级类别中有更多节点，则服务将分发到这些节点。优先级仅具有相对含义。

nofailback：（默认= 0）

CRM尝试在优先级最高的节点上运行服务。如果具有更高优先级的节点联机，则CRM会将服务迁移到该节点。启用nofailback可以防止该行为。

限制：（默认= 0）

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

一个普遍的要求是资源应在特定节点上运行。通常，资源可以在其他节点上运行，因此您可以使用单个成员定义不受限制的组：

# ha-manager groupadd preferred_node1-节点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”-受限

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

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

组：preferred_node1

       节点node1

 

组：mygroup1

       节点node2：1，node4，node1：2，node3：1

 

组：mygroup2

       节点node2，node1

       限制1

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

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

14.7 击剑

在节点发生故障时，防护可以确保错误节点保证脱机。这是确保在另一个节点上恢复资源时没有资源运行两次的必要条件。这是一项非常重要的任务，因为如果没有它，就不可能在另一个节点上恢复资源。

如果未对节点进行隔离，则该节点将处于未知状态，在该状态下它仍可以访问共享资源。这真的很危险！想象一下，除存储网络之外的每个网络都崩溃了。现在，虽然无法从公共网络访问虚拟机，但虚拟机仍在运行并写入共享存储。

如果然后仅在另一个节点上启动该VM，则将产生危险的竞争条件，因为我们从两个节点进行写入。这种情况可能会破坏所有VM数据，并且整个VM可能无法使用。如果存储可以防止多次装入，则恢复也可能失败。

14.7.1 Proxmox VE如何防护

有多种方法来隔离节点，例如，隔离设备会切断该节点的电源或完全禁用其通信。这些服务通常很昂贵，并将其他关键组件带入系统，因为如果它们失败，您将无法恢复任何服务。

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

可能的击剑方法

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

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

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

最近的服务器主板通常包括此类硬件看门狗，但是需要对其进行配置。如果没有可用的监视程序或没有配置的监视程序，我们将退回到Linux Kernel softdog。尽管仍然可靠，但它并不独立于服务器硬件，因此其可靠性低于硬件看门狗。

14.7.2 配置硬件看门狗

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

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

WATCHDOG_MODULE = iTCO_wdt

看门狗多任务服务读取该配置，该服务在启动时加载指定的模块。

14.7.3 恢复围栏服务

在节点发生故障并且其防护成功之后，CRM尝试将服务从发生故障的节点移动到仍在线的节点。

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

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

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

14.8 启动失败政策

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

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

max_restart

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

max_relocate

将服务重新定位到其他节点的最大尝试次数。仅在实际节点上超过max_restart值之后，才会发生重定位。默认设置为一。

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

14.9 错误恢复

如果毕竟尝试无法恢复服务状态，则会将其置于错误状态。在这种状态下，HA堆栈将不再处理该服务。唯一的出路是禁用服务：

# ha-manager set vm：100-状态已禁用

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

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

• 使资源回到安全一致的状态（例如：如果无法停止服务，则终止其进程）
• 禁用资源以删除错误标志
• 修复导致此故障的错误
• 之后你固定所有的错误，你可以要求服务重新开始

14.10 软件包更新

更新ha-manager时，您应该在另一个节点之后执行一个节点，出于各种原因，绝不要一次全部执行。首先，尽管我们进行了周密的测试，但不能完全排除影响您特定设置的错误。一个节点接一个节点升级，并在完成更新后检查每个节点的功能有助于从最终的问题中恢复过来，而更新所有节点可能会使您处于损坏的群集状态，通常不是一个好习惯。

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

14.11 节点维护

有时可以关闭或重新引导节点来执行维护任务。要么替换硬件，要么简单地安装新的内核映像。

14.11.1 关掉

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

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

14.11.2 重启

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

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

14.11.3 手动资源移动

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

请不要杀般的服务PVE-HA-CRM，PVE-HA-LRM或 看门狗-MUX。他们管理和使用看门狗，因此这可能导致节点重新启动。