4.2 ProxmoxVE6.3:配置并测试虚拟机的高可用性（共享存储）

4.2 ProxmoxVE6.3:配置并测试虚拟机的高可用性（共享存储）

高可用性

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

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

有几种提高可用性的方法。最优雅的解决方案是重写软件，以便可以同时在多个主机上运行它。软件本身需要一种检测错误并进行故障转移的方法。如果您只想提供只读网页，这相对容易。但是总的来说，这很复杂，有时是不可能的，因为您无法自己修改软件。以下解决方案无需修改软件即可工作：

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

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

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

使用不间断电源（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％。

要求

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

至少三个群集节点（以获得可靠的仲裁）

VM和容器的共享存储

硬件冗余（无处不在）

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

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

可选的硬件围栏设备

资源

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

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

4种请示状态

请求的资源状态。CRM 读取此状态并相应地执行操作。请注意，已启用只是启动的别名。

开始started

CRM 尝试启动资源。服务状态设置为在成功启动后启动。在节点失败时，或在启动失败时，它会尝试恢复资源。如果一切失败，服务状态设置为错误。

停止stopped

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

禁用ignored

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

忽视disabled

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

添加资源成功

测试高可用性

把节点A1的网线全部拔掉

虚拟机切换到A2节点后并重启系统