优化 IT 系统以实现高可用性的策略

优化 IT 系统以实现高可用性的策略

保持 IT 系统的高可用性 (HA) 对组织的成功至关重要。从关键数据库管理到确保无缝客户体验，实现不间断运营面临着独特的挑战，需要战略规划。以下是组织可以利用的一些关键策略来优化其 IT 系统以实现高可用性。

优化 IT 系统以实现高可用性的常见挑战

有几个不同的领域开始对 IT 系统构成挑战。其中一个经常出现的问题是与防病毒 (AV) 解决方案的兼容性。问题往往源于防病毒软件对系统的过度保护以及隔离对应用程序或 HA 解决方案运行至关重要的文件。当然，验证解决方案之间的兼容性始终很重要，但更进一步来说，对于管理系统的每个人来说，熟悉 AV 解决方案的工作原理并了解配置/请求更改 AV 解决方案的程序总是有好处的，这样关键的应用程序就不会中断。

除了 AV 解决方案外，防火墙配置也很重要——HA 解决方案通常会通过网络传输额外的通信来协调集群行为。因此，通常需要添加特定规则来适应 HA 解决方案，以防止 HA 解决方案执行错误的集群恢复操作。

最后，在配置高可用性系统时，访问控制原则会变得稍微复杂一些。虽然各个团队（例如，数据库团队、SAP 团队、云团队 – 无论事物如何分布）都需要各自域的权限，但管理 HA 解决方案的任何管理员都可以看到他们拥有通过 HA 解决方案可访问的额外权限（例如，启动应用程序的故障转移、在节点之间建立通信、锁定/解锁存储等）。因此，在委派访问权限时，考虑通过 HA 解决方案可执行的操作非常重要。可能只允许根级用户使用 HA 控制，或者您可以定义通过 HA 解决方案采取行动的程序，以便通知团队并跟踪操作。无论如何，从最小特权原则的角度来看，HA 解决方案具有复杂性，应考虑到这一点，以确保应用程序和系统只能由委派方访问和更改。

故障转移和灾难恢复策略在确保系统正常运行中的作用

故障转移功能和灾难恢复 (DR) 策略都对关键系统的正常运行时间有重大影响。显然，HA 可以提供故障转移功能，以确保单服务器问题不会导致应用程序套件中断，并且如果配置正确，故障转移几乎可以无缝进行。这允许在故障系统上进行恢复，同时备用系统将发挥主要作用来承担负载。当然，灾难恢复可以与 HA 策略紧密交织在一起。如果已经配置了冗余，为什么不确保这种冗余存在于故障域中呢？如果观察得当，应用程序可以具有高可用性和容错能力。从 IT 角度分析这些结果时，正确配置的 HA 和 DR 策略可以确保系统得到最大程度的利用，同时将停机时间降至最低。托管应用程序的地区发生的自然灾害或技术故障不太可能传播到其他地区。将计划的冗余与灾难恢复计划结合起来，可以用更少的资源满足更多的功能需求——因为仔细的规划可以确保冗余和容错都由备用站点的部署来处理。

平衡成本效益和高可用性：组织策略

配置集群环境或高可用性系统的成本可能很高。通常，至少有一个备用系统与主系统一起运行，尽管没有处理工作负载，但仍然会产生成本——但这些成本是可以降低的。以下是我建议的几种方法：考虑使用托管共享存储解决方案。如果您不需要数据的冗余副本，则可以使用共享存储来节省存储空间。像 Amazon EFS 这样的解决方案可能意味着您只需支付一半的存储费用，而不是复制磁盘配置。

考虑 DR 系统的用例。通常，这些系统只是在主站点恢复期间的权宜之计。资源不会在 DR 站点上运行很长时间，因此 – 根据工作负载 – 您可能能够在 DR 站点上配置较小的系统以节省计算成本。当然，您需要与利益相关者沟通设计决策，以便每个人都知道 DR 站点不是长期托管解决方案 – 但只要您的工作负载和员工能够处理增加的限制，就可以节省实例大小。同样，不会托管工作负载而仅在集群内协调的编排器和/或仲裁系统可能比委派给的系统工作负载小得多。

考虑使用扩展或横向扩展的解决方案。扩展意味着增加单台机器的计算能力——在云环境中，这涉及当工作负载压倒较小实例时，将其资源池增加到较大实例的资源池。横向扩展意味着在需要计算能力时增加将共享应用程序负载的工作人员数量。显然，用例决定了何时何地扩展或横向扩展是更好的解决方案——但通过熟悉手头的软件和环境，您将能够做出决策并配置系统以在需要时采取适当的行动。扩展解决方案需要考虑的另一件事是考虑您的缩减规则的积极性。为了节省成本，确保实例将缩减到适当的资源池——并评估规定缩减行为的规则，以确保您不会将过多的资源配置时间延长到需要的时间。在 IT 团队、利益相关者、网络安全团队和 HA 供应商之间建立良好的沟通。确保有沟通的基础可以促进任何技术或环境升级的合作推出。此外，通过保持沟通畅通，所有团队将更了解系统上发生的活动。让所有团队保持最新状态至关重要，可以更轻松地诊断问题或在必要时开始回滚程序。最后，保持良好的沟通还可以确保团队之间有效地共享最佳实践，以便团队能够合作，而不是按照不同的原则运作。

实现高可用性：最佳实践

对于任何部署系统的人，我建议的第一个也是最重要的做法是维护一个测试环境。使测试环境尽可能接近生产环境，并对生产环境中将发生的任何程序进行试运行，以便团队在生产部署时熟悉程序和运行手册。这种做法也融入了我为系统提供的其他最佳实践中。通过维护您的测试环境，您还将维护一个可用于预先测试任何更改的系统。测试环境是验证产品兼容性和确保技术之间相互操作的任何考虑都得到充分建立的最佳场所。我一次又一次看到的一个很好的例子是配置防病毒软件的排除项——有些情况下这些排除项没有配置，生产环境会遭遇中断，因为防病毒软件可能会隔离一个访问频率非常高的文件。最后，确保您定期审核您的配置。检查安全组、访问控制、防火墙规则和软件兼容性（尤其是 HA、受保护的应用程序和防病毒软件之间的兼容性）等各个方面。保留一份完整的日志，记录这些审计结果以及由此做出的任何更改——跟踪这些详细信息可以提供可靠的记录，如果配置更改似乎导致问题，则可以查看这些记录。此外，在向供应商请求支持时，这些审计可以成为一种极好的工具，可以更快地进行全面的根本原因分析。最重要的是，这些审计将提供应如何配置的记录——如果与规定的配置有任何变化，可以参考过去的审计结果，重新调整系统以符合组织的系统配置标准。

SIOS 深知，优化 IT 系统以实现高可用性对于组织的成功至关重要。通过解决防病毒解决方案的兼容性挑战并微调防火墙配置，组织可以增强系统弹性和正常运行时间。今天与我们联系以获取更多信息。

经许可转载西欧斯

SIOS 技术有助于在高可用性和云成本之间取得平衡

SIOS 技术有助于在高可用性和云成本之间取得平衡

在两者之间找到适当的平衡高可用性成本优化可能具有挑战性。 SIOS Technology 的高级技术布道师 Dave Bermingham 谈论了影响云成本的一些关键因素以及一些优化成本的策略。他说：“我们专注于实用且有效的策略，这些策略不仅有助于降低与部署高可用性相关的成本，而且除了最大限度地减少与计划维护相关的停机时间之外，还有助于最大限度地减少意外停机时间。”

影响云环境成本的关键因素

• 影响高可用性配置中的云成本和优化成本的关键因素包括高效的资源管理、战略架构决策和持续监控。
• Bermingham 讨论了选择正确的实例、类型和大小来满足工作负载要求的重要性，以及自动扩展如何帮助降低成本和优化云支出。
• 伯明翰强调，如果跨多个时区部署高可用性解决方案，则考虑数据传输成本的重要性，并且您可以使用策略来最大限度地减少费用。
• 其他关键考虑因素包括优化存储以及实施有效的治理和成本管理政策。

在云中寻找高可用性和成本优化之间的平衡

• Bermingham 解释说，虽然高可用性会产生一些费用，但这抵消了与任何停机相关的成本，而停机时间可能是巨大的。
• 通过创建模块化和可扩展的系统以及采用 DevOps 文化和利用 CI/CD 实践的运营策略，在高可用性和最小化云成本之间取得平衡非常重要。

云成本优化和高可用性挑战

• Bermingham 强调了在不影响高可用性的情况下优化成本的常见陷阱，例如低估云成本管理的复杂性和忽视应用程序性能监控的重要性。
• 关于云成本优化最佳实践和实施 HA 解决方案的培训不足通常会导致资源利用效率低下和计划外停机。

SIOS Technology 的高可用性解决方案如何提供帮助

• Bermingham 解释了 SIOS 技术如何通过 HA 解决方案帮助应对这些挑战，这些解决方案可简化和自动化不同云环境中的 HA，从而最大限度地降低成本、最大限度地减少停机时间并管理维护。

经许可转载安全操作系统

SIOS LifeKeeper for Linux v 9.8.1 改进了公司管理 HA/DR 的方式

SIOS LifeKeeper for Linux v 9.8.1 改进了公司管理 HA/DR 的方式

在当今技术驱动的环境中，公司正在寻求创新的解决方案来有效维护其复杂的应用程序环境。在这个视频中，托德·多恩SIOS Technology 的销售工程师解释了最新版本如何适用于 Linux 的 SIOS LifeKeeper帮助公司保护关键企业系统免受停机和灾难的影响。 “该版本具有新的网页管理控制台。它是独立的，不需要额外的安装或第三方插件，”Doane 说。

经许可转载安全操作系统

在 GenApp 和 QSP 之间进行选择：为您的关键应用程序定制高可用性

在 GenApp 和 QSP 之间进行选择：为您的关键应用程序定制高可用性

GenApp 还是 QSP？这两种解决方案均受 LifeKeeper 支持，有助于防止关键应用程序停机，但了解这些解决方案之间的细微差别对于选择适合您的特定需求的解决方案非常重要。以下是一些功能、优点和潜在用例，供您决定哪些功能最适合您的环境。

GenApp,通用应用程序的缩写，是一种资源类型，允许您在 LifeKeeper 中管理自定义应用程序。借助灵活的框架，您可以使用自己的脚本来执行应用程序可能需要的各种任务，以自动执行故障转移和恢复过程。这种灵活性允许对 LifeKeeper 如何处理启动、关闭、监控、记录操作等进行精细控制，以确保应用程序的高可用性。

QSP或快速服务保护旨在成为保护操作系统服务的快速且简单的方法。 QSP 通过内置的可调整超时来自动执行这些应用程序的监控、故障转移和恢复。此外，您可以创建依赖关系，以便服务可以与需要该服务的其他应用程序一起启动和停止。

我如何选择正确的解决方案？

您需要确定的第一件事是是否可以通过停止并重新启动服务或守护程序来恢复您的应用程序。如果是这样，那么 QSP 可能是保持应用程序正常运行的最佳且最快的解决方案。这是因为它不需要编码，几分钟之内您就可以将应用程序添加为 LifeKeeper GUI 中的 QSP 资源。此外，它是核心产品的一部分，任何编码更新都包含在新产品版本中。但是，如果您的应用程序除了简单的运行状况检查和操作系统服务级别的重新启动功能之外还需要其他功能才能正确恢复，那么您将需要探索 GenApps。为 GenApp 资源类型创建自定义脚本将需要更深入的技术技能和长期维护，但是，执行保持应用程序平稳运行所需的任何任务的灵活性至关重要，尤其是对于利基应用程序。这些任务可以是监视、日志记录、清理任务或配置更改等任何任务。

想要更多技术细节吗？

Linux 和 Windows 版 LifeKeeper 均支持 GenApps 和 QSP，更多技术细节可在下面的链接中找到。

• 适用于 Linux 的 LifeKeeper 的 GenApp
• 适用于 Windows 的 LifeKeeper 的 GenApp
• 适用于 Linux 的 LifeKeeper 的 QSP
• 适用于 Windows 的 LifeKeeper 的 QSP

经许可转载安全操作系统

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

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

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

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

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

“切换”是手动将层次结构从主节点移动到辅助节点的行为。这可以通过 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启动或恢复故障的通信路径时，将会咨询见证节点（见证设备）。见证检查只能对具有法定人数的节点执行。

2. 资源失败原因

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 基础设施的产品。今天联系我们了解更多信息。

经许可转载安全操作系统