SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

Date: 5月 11, 2024

What Causes Failovers to Happen

是什么导致发生故障转移？

在支持工作中，我们从客户那里得到的最常见问题之一是“是什么促使我们故障转移从我的主节点到辅助节点？”。

发生这种情况的原因有多种……我们将尝试解释最常见的原因以及如何识别这些原因。

在我们开始之前，让我们区分“故障转移”和“切换”，因为许多客户可以互换使用这些术语。

“切换”是手动将层次结构从主节点移动到辅助节点的行为。这可以通过 GUI、在辅助节点上执行“In Service”或通过命令行来完成：

Perform_action -a Restore -t $LKTag（使层次结构投入使用）

另一方面，“故障转移”是在没有任何手动交互的情况下执行的……并且被定义为在先前活动的服务器、应用程序或硬件/网络发生故障时自动切换到备份服务器。

故障转移和切换本质上是相同的操作，不同之处在于故障转移是自动的并且通常在没有警告的情况下运行，而切换是有意的并且需要人为干预。

以下是启动“故障转移”的最常见“故障”：

  1. 服务器层面原因

服务器故障

  • 主服务器断电或关闭。
  • 负载过大导致的 CPU 使用率 — 在 I/O 负载非常重的情况下，延迟和内存不足的情况可能会导致系统变得无响应，从而生命守护者可能会检测到服务器已关闭并启动故障转移。
  • 仲裁/见证 – 作为仲裁/见证 I/O 防护机制的一部分，当主服务器失去仲裁时，“快速启动”：，“快杀“ 或者 ”奥苏” 被执行（基于设置）并启动故障转移。在确定何时进行故障转移时，见证服务器仅在验证主服务器已发生故障且不再属于群集的情况下才允许在备份服务器上投入使用资源。这将防止由于节点之间的简单通信故障而发生故障转移，而这些故障不会影响对服务中节点的整体访问和性能。

通讯（心跳）失败

LifeKeeper 有一个内置的“心跳”信号，可以定期通知配置中的每个服务器其配对服务器正在运行。默认情况下，LifeKeeper 每五秒在服务器之间发送一次心跳（这对于繁忙的集群是可调整的）。如果通信问题导致心跳跳过两次心跳，但在第三次心跳时恢复，LifeKeeper 不会采取任何操作。然而，如果通信路径在三个节拍内保持无效状态，LifeKeeper 会将该通信路径标记为无效。如果冗余通信路径也失效（我们建议两条路径），它将启动故障转移。

以下情况可能会导致心跳丢失：

  • 与主服务器的网络连接丢失。
  • 网络延迟。
  • TCP 通信路径上的网络流量过大可能会导致意外行为，包括错误故障转移和 LifeKeeper 初始化问题。
  • 网卡故障。
  • 网络切换失败。
  • 手动拉/删除网络连接
  • 主服务器断电或关闭。
  • 负载过大导致的 CPU 使用率 — 在非常重的 I/O 负载下，延迟和内存不足的情况可能会导致系统无响应，从而 LifeKeeper 可能会检测到服务器已关闭并启动故障转移。

调整心跳参数：

LCMNUMHBEATS=Y（其中 Y 是在日志中记录通信路径失败错误之前的心跳数）。默认值为 3，如果您的系统繁忙或跨 WAN，则可以更改，以避免错误的通信路径故障。

LCMHBEATTIME=5（这是以秒为单位的间隔，这是默认值，不应更改）。

默认情况下，这些可调参数不在 /etc/default/LifeKeeper 文件中。您将需要添加它们来更改心跳值。

在 /etc/default/LifeKeeper 中添加这些可调参数和值后，您需要停止 LifeKeeper 并重新启动它。您可以使用命令 lkstop -f，该命令会停止 LifeKeeper，但不会关闭受保护的应用程序。

您需要在两个系统上执行此操作。

这将允许 LifeKeeper 在将通信路径标记为失败之前等待 5 倍 Y 秒。

什么是裂脑，是什么原因导致的？

如果使用单个通信路径并且该通信路径发生故障，则 LifeKeeper 层次结构可能会尝试同时在多个系统上投入使用。这称为错误故障转移或“裂脑”场景。在里面“裂脑”情景，每个服务器都认为它控制着应用程序，因此可能会尝试访问共享存储设备并向其写入数据。为了解决裂脑情况，LifeKeeper 可能会导致服务器关闭或重新启动，或者使层次结构停止服务，以确保所有共享数据的数据完整性。此外，TCP 通信路径上的大量网络流量可能会导致意外行为，包括错误故障转移和 LifeKeeper 无法正确初始化。

以下是可能导致脑裂的情况：

  • 上面列出的任何通信故障
  • LifeKeeper 不正确关闭
  • 服务器资源匮乏
  • 丢失所有网络路径
  • DNS 或其他网络故障
  • 系统死机

使用仲裁/见证来防止裂脑

  • LifeKeeper 的 Quorum/Witness 服务器支持包（steeleye-lkQWK，以下简称“Quorum/Witness 包”）与 LifeKeeper 核心现有的故障转移流程相结合，使得在可能出现整体网络故障的情况下，系统能够更加可靠地进行故障转移。很常见。这实际上意味着可以完成本地站点故障转移和跨 WAN 的节点故障转移，同时大大降低风险裂脑情况。
  • 在考虑网络分区的分布式系统中，有一个称为仲裁的概念来获得跨集群的共识。具有仲裁的节点是指能够获得所有集群的共识并允许资源投入使用的节点。另一方面，没有仲裁的节点是无法获得所有集群共识的节点，不允许将资源投入使用。这将防止脑裂的发生。检查节点是否具有仲裁称为仲裁检查。如果有仲裁，则表示“仲裁检查成功”；如果没有仲裁，则表示“仲裁检查失败”。
  • 如果发生通信故障，使用发生故障的一个节点和另外多个节点（或其他设备）将允许节点获得有关故障节点状态的“第二意见”。获得“第二意见”的节点称为见证节点（或见证设备），获得“第二意见”称为见证检查。在确定何时进行故障转移时，见证节点（见证设备）仅在验证主服务器发生故障且不再属于集群的情况下才允许在备份服务器上投入使用资源。这将防止由于节点之间的简单通信故障而发生故障转移，而这些故障不会影响对服务中节点的整体访问和性能。在实际操作过程中，当LifeKeeper启动或恢复故障的通信路径时，将会咨询见证节点（见证设备）。见证检查只能对具有法定人数的节点执行。

  1. 资源失败原因

LifeKeeper 旨在监控单个应用程序和相关应用程序组，在受保护的应用程序发生故障时定期执行本地恢复或通知。例如，相关应用程序是主要应用程序依赖于较低级别存储或网络资源的层次结构。 LifeKeeper 监控这些受保护资源的状态和运行状况。如果确定资源处于故障状态，则将尝试在没有外部干预的情况下恢复当前系统（服务中节点）上的资源或应用程序。如果本地恢复失败，将启动资源故障转移。

应用失败

  • 检测到应用程序故障，但本地恢复过程失败。
  • 删除故障 – 在资源故障转移过程中，某些资源需要从主服务器上的服务中删除，然后在选定的备份服务器上投入使用，以提供关键应用程序的完整功能。如果此删除过程失败，将重新启动主服务器，从而导致完整的服务器故障转移。

删除失败的示例：

  • 无法卸载文件系统
  • 无法关闭受保护的应用程序（oracle、mysql、postgres 等）

文件系统问题

  • 磁盘已满 — LifeKeeper 的文件系统运行状况监控可以检测磁盘已满的文件系统状况，这可能会导致文件系统资源发生故障转移。
  • 卸载或不正确安装的文件系统 — 用户手动卸载或更改正在使用的且受 LK 保护的文件系统上的选项。
  • 重新安装失败 — 以下是重新安装失败的常见原因（可能导致故障转移）：
  • 文件系统损坏（fsck 失败）
  • 创建挂载点目录失败
  • 挂载点正忙
  • 安装失败
  • LifeKeeper 内部错误

IP地址故障

当 IP 恢复套件检测到 IP 地址故障时，由此产生的故障会触发 IP 本地恢复脚本的执行。 LifeKeeper 首先尝试在当前网络接口上恢复 IP 地址的服务。如果本地恢复尝试失败，LifeKeeper 会将 IP 地址和所有相关资源故障转移到备份服务器。在故障转移期间，删除过程将取消当前服务器上的 IP 地址配置，以便可以在备份服务器上进行配置。此删除过程失败将导致系统重新启动。

  • IP冲突
  • IP冲突
  • DNS解析失败
  • NIC 或交换机故障

预订冲突

  • 受保护设备的预订丢失或被盗
  • 无法重新获得受保护资源设备的预留或控制（由手动用户干预、HBA 或交换机故障引起）

SCSI设备

  • 无法打开受保护的SCSI 设备。该设备可能出现故障或者可能已从系统中删除。

用于确定故障转移原因的资源

/var/log/lifekeeper.log

这个由 LifeKeeper 编写的日志文件应该是您在确定可能导致故障转移的原因时首先查看的地方。

例如，最常见的原因之一是通信路径故障。以下是发生这种情况时您将在 lifekeeper.log 中找到的条目示例：

9 月 21 日 11:06:57 es1ecc08tev lcm[46893]：信息：lcm.tli_hand:::005257：在开发 10.236.17.226/10.238.17.226 上错过了 48 个心跳 1（lcm 驱动程序编号 = 129）。

9 月 21 日 11:06:57 es1ecc08tev lcm[46893]：信息：lcm.tli_hand:::005257：在开发 10.236.17.226/10.237.17.226 上错过了 48 个心跳 1（lcm 驱动程序编号 = 1360929）。

9 月 21 日 11:07:02 es1ecc08tev lcm[46893]：信息：lcm.tli_hand:::005257：在开发 10.236.17.226/10.238.17.226 上错过了 48 个心跳 2（lcm 驱动程序编号 = 129）。

达到最大心跳数后，故障转移开始：

9 月 21 日 11:10:49 es6ecc08tev lcm[9416]: INFO:lcm.tli_hand:::005257:missed heartbeat 47 of 48 on dev 10.237.17.226/10.236.17.226 (lcm 驱动程序编号 = 71)。

9 月 21 日 11:10:49 es6ecc08tev eventslcm[47082]：警告：lcd.net:::004258：10.237.17.226/10.236.17.226 与 es1ecc08tev 的通信失败

9 月 21 日 11:10:49 es6ecc08tev eventslcm[47082]：警告：lcd.net:::004261：将启动系统“es1ecc08tev”的通信故障转移。

9 月 21 日 11:10:49 es6ecc08tev lifekeeper[47121]：通知：event.comm_down:::010466：通信 es1ecc08tev 失败

/var/日志/消息

这个 Linux 生成的文件通常包含由系统上运行的各种进程和服务生成的系统消息。这些消息可以包括：

系统启动消息：有关系统启动过程的信息，包括内核消息和来自 systemd 或其他 init 系统的消息。

服务启动和关闭消息：指示服务何时启动或停止的消息，包括在此过程中遇到的任何错误或警告。

内核消息：有关 Linux 内核操作的信息，包括硬件检测、设备初始化以及内核错误或警告。

网络相关消息：有关网络连接、防火墙活动和网络配置更改的信息。

系统性能信息：与系统性能监控相关的消息，例如CPU使用率、内存使用率、磁盘I/O统计信息。

SIOS 高可用性和灾难恢复

SIOS科技公司提供高可用性和灾难恢复通过针对最重要应用程序的集群管理来保护和优化 IT 基础设施的产品。今天联系我们了解更多信息。

经许可转载安全操作系统