In XenCenter 7.1 LTSR
In XenCenter
In All products
产品文档
In XenCenter 7.1 LTSR
In XenCenter
In All products
查看 PDF

关于 XenServer 高可用性

June 28, 2019
贡献者:  C

XenServer 高可用性功能允许在基础硬件出现故障或任何托管服务器丢失时自动重新启动虚拟机。高可用性功能可以确保重要的 VM 始终在资源池中运行。启用高可用性功能后，如果一个服务器出现故障，其 VM 将智能地在同一个池中的其他服务器上重新启动，使基本服务在系统或组件出现故障的情况下得以还原，从而最大程度减少服务中断。如果池主服务器出现故障，XenServer 高可用性功能会自动选择一个新服务器来接替主服务器，以便您可以继续管理该池。池中的任何服务器都可以充当主服务器，池数据库不断在所有节点之间进行复制，而且还会备份到检测信号 SR 上的共享存储中，从而提高安全性。

XenServer 高可用性功能包括两个主要方面：可靠地检测服务器故障；计算故障计划以实现快速恢复。下面将详细介绍这两个方面。

通过检测信号判断可用性

您需要远程对服务器暂时消失与灾难性故障加以区分，因此可靠地检测服务器故障比较困难。如果我们错误地认定主服务器已发生故障并选择一个新的主服务器来替代它，则在原始主服务器恢复启动后，可能会出现意外的结果。同样，如果资源池均等地分为两个部分，则当出现网络问题时，我们只需要确保其中的一个部分能够访问共享存储，而不是确保这两个部分能够同时访问共享存储。XenServer 通过提供以下两个机制来解决所有这些问题：存储检测信号和网络检测信号。

如果在池中启用高可用性功能，应指定 iSCSI、光纤通道或 NFS 存储库作为检测信号 SR。XenServer 自动在此 SR 中创建几个小型虚拟磁盘。第一个磁盘是共享仲裁磁盘，由资源池中的每个服务器使用。每个服务器都在共享磁盘中为自己分配一个唯一的区块，并定期向该区块中写入数据以指示服务器处于活动状态。当高可用性功能启动时，所有服务器通过网络和存储通道交换数据，以说明它们通过这两个通道可以看到的服务器，即哪些 I/O 路径有效，哪些 I/O 路径无效。这些信息会一直交换，直到达到某个固定点，并且池中的所有服务器对于彼此就所见内容达成的协议表示满意。出现这种情况时，高可用性功能处于启用状态，并且资源池受到保护。对于较大的池来说，这一高可用性置备过程可能需要几分钟时间，但只有在首次启用高可用性功能时才需要进行此过程。

一旦高可用性功能处于活动状态，每个服务器都会定期向检测信号虚拟磁盘中写入存储更新，并通过管理接口写入网络数据包。应确保 绑定 网络适配器以保证恢复能力，并且存储接口使用 动态多路径 （如果支持），这两点非常重要。这样可以确保任何单个适配器或连线故障不会导致出现任何可用性问题。

服务器防护

对于高可用性功能而言，最坏的情形是服务器被视为脱机，而实际上它正在等待将数据写入共享存储，因为这种情况会导致持久性数据的损坏。为避免这种情况，XenServer 使用 服务器防护 功能，即，服务器自动关机并被阻止访问池中的任何共享资源。这样可防止在自动故障转移期间，在将受保护的虚拟机移动到池中其他运行正常的服务器时，出现故障的服务器向任何共享磁盘写入内容而破坏所存储数据的一致性。

除非满足下列任一条件，否则在出现任何检测信号故障时服务器都将进行自主防护（即，关闭电源并重新启动）。

  • 针对所有服务器存在存储检测信号，但是网络已进行分区（此时存在两组服务器）。在这种情况下，最大网络分区中的所有成员服务器仍保持运行状态，较小网络分区中的服务器将进行自主防护。此处假设 VM 已经因网络中断而被隔离，而且应在网络连接正常的服务器上重新启动。如果各个网络分区的大小完全相等，则只有其中一个分区将根据稳定选择功能进行自主防护。
  • 如果存储检测信号消失，但是网络检测信号仍存在，则服务器会检查它们能否通过网络看到所有其他服务器。如果能够看到，则这些服务器仍保持运行状态，但前提是存储检测信号已消失。这样做不会损害 VM 的安全，但是任何网络小问题都会导致服务器进行防护，因为这意味着这两种检测信号都已经消失。

故障容量规划

检测信号系统为我们提供了可靠的服务器故障通知，现在我们继续执行高可用性的第二个步骤：故障容量规划。

一个资源池由多个（例如 16 个）服务器组成，每个服务器上的内存量和正在运行的 VM 数可能各不相同。为了确保任何单个服务器故障都不会导致其 VM 在其他服务器上无法重新启动（例如，由于任何其他服务器上的内存不足），XenServer 高可用性功能将动态计算故障计划，从而计算出在发生任何服务器故障时将执行的操作。除了处理单个服务器的故障外，XenServer 高可用性功能还可以处理池中多个服务器丢失的情况（例如，网络分区故障导致丢失整组服务器）。

除了计算将执行的操作外，故障计划还考虑池中可以容忍的服务器故障数。在计算池的高可用性计划时，有两个重要的考虑因素：

  • 最大故障容量 。即允许的最大故障服务器数，超过该值后，资源将不足以运行池中所有受保护的 VM。XenServer 在计算此值时考虑池中 VM 的重新启动优先级和池的配置（服务器数量以及服务器上的 CPU 和内存容量）。
  • 服务器故障限制 。该值作为高可用性配置的一部分在高可用性计划中进行定义，用来指定池中允许的服务器故障数。例如，在由 16 个服务器组成的资源池中，如果将服务器故障限制设置为 3，则 XenServer 计算出的故障转移方案将允许任意 3 个服务器出现故障，而这时仍然能够运行池中所有受保护的 VM。可以将服务器故障限制配置为小于最大故障容量的值，这会降低池被过度使用的可能性。这在启用了 RBAC 的环境中非常有用，例如，可允许没有池操作员权限的 RBAC 用户在不违反高可用性计划的情况下将更多 VM 联机；请参阅下面的 高可用性和基于角色的访问控制 (RBAC) 。

当最大故障容量值小于指定的服务器故障限制值时，将生成系统警报。

过度使用防护

首次对池启用高可用性时，将基于当时可用的资源计算故障计划。XenServer 高可用性功能会动态计算新故障计划，以响应对池造成影响的事件（例如，启动新的 VM）。如果由于池中的资源不足（例如，可用内存不足，或者对虚拟磁盘和网络进行的更改影响了哪些 VM 可以在哪些服务器上重新启动）而导致无法计算新计划，则池被 过度使用 。

在池被过度使用时，使用高可用性重启优先级来确定应启动的 VM。在 高可用性配置 对话框或 配置高可用性 向导中为要保护的 VM 配置重启优先级时，您可以查看正在动态重新计算的池的最大故障容量，从而根据业务需求尝试使用不同的 VM 重启优先级组合，并了解最大故障容量是否适合于池中关键的 VM 所需的保护级别。

如果您尝试启动或恢复 VM 而该操作将导致池被过度使用，则将在 XenCenter 中显示警告消息。如果配置了一个电子邮件地址，系统还可能会向该电子邮件地址发送警告消息。您将能够取消该操作或者仍然继续操作，但继续操作会导致池被过度使用。

处理启用了高可用性的池

高可用性功能的最佳做法是，在启用了高可用性功能的情况下不对池进行配置更改，而应当实施“2am 保护”，在出现问题后在管理员不在现场的情况下重新启动服务器。如果您主动对池中的配置进行更改（例如应用软件更新），应在执行这些更改期间禁用高可用性功能。

  • 如果您尝试从 XenCenter 关闭受保护的 VM，XenCenter 将允许您首先将该 VM 从池故障计划中删除，然后再将其关闭。这样可以确保不会因意外的 VM 关闭而导致停机，而当您确实需要停止受保护的 VM 时，仍然可以将其停止。
  • 在启用高可用性功能的情况下，如果您需要重新启动服务器，XenCenter 会自动使用 VM 重启优先级来确定这样做是否会违反池故障计划。如果不会影响池故障计划，则服务器将会正常关闭。如果与池故障计划冲突，但最大故障容量大于 1，XenCenter 允许您将池的服务器故障限制减小 1。这样做会降低池的整体恢复能力，但却始终确保能够应对至少一个服务器故障。当服务器重新启动时，系统将自动重新计算池故障计划，并还原原始的服务器故障限制（如果适用）。
  • 使用 安装更新 向导安装 软件更新 时，必须通过单击 关闭高可用性功能 选项对池禁用高可用性功能，直到更新安装完毕。如果未禁用高可用性功能，更新将不继续进行。在安装更新期间，您需要手动监视池，以确保服务器故障不会中断池的运行。
  • 启用高可用性功能后，某些影响 VM 重新启动方案的操作（例如从池中删除服务器）可能会被禁用。要执行这些操作，应当先暂时禁用高可用性功能或者关闭受保护的 VM，然后再继续操作。

高可用性和基于角色的访问控制 (RBAC)

在实现了基于角色的访问控制 (RBAC) 的 XenServer 环境中，并非所有用户都有权更改池的高可用性配置设置。例如，有权启动 VM 的用户（VM 操作员）没有足够的权限来针对启用了高可用性的池调整故障转移容量。例如，如果启动某个 VM 会将所允许的最大服务器故障数减少到小于当前的最大故障容量，则 VM 操作员将无法启动该 VM。只有池管理员或池操作员级别的用户才能够配置所允许的服务器故障数。

在这种情况下，启用高可用性的用户（具有“池管理员”或“池操作员”角色）可以将服务器故障限制设置为实际上小于所允许的最大故障数的值。这会创建容错容量，从而确保权限较低的用户能够启动新的 VM 并降低池的故障转移容量，而不会威胁故障计划。

关于 XenServer 高可用性

June 28, 2019
贡献者:  C

本文中包含的内容

Edit this article