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 Technology 的销售工程师解释了最新版本如何适用于 Linux 的 SIOS LifeKeeper帮助公司保护关键企业系统免受停机和灾难的影响。 “该版本具有新的网页管理控制台。它是独立的，不需要额外的安装或第三方插件，”Doane 说。

经许可转载安全操作系统

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

经许可转载安全操作系统

更好支持的三个技巧

Betsy 是一辆 1999 款 Amazon Green Ford F-150，这是我购买的第一辆车。我不知道我的卡车是如何得到“贝特西”这个名字的，也不知道为什么它被卡住了，但它确实被卡住了。在超过 17 年的时间里，贝特西做了各种各样的事，从在海滩巡游到在跑道上比赛，拖运大量的园林绿化用品，再到带着我不断壮大的家人穿越东南部。经过很多英里和多年的学习如何保养卡车后，她开始展示磨损情况。在一次下午开车时，我注意到温度计逐渐升至 H（高）。经过几次交谈后，我带贝特西去了当地一家经销商的服务部门，开始了为期一周的自我折磨。

第一次访问时，我匆忙提供了高级细节。 “几分钟后，卡车就开始发热了，”我说。六个小时后，我花了 100 美元取回了我的卡车。技术人员无法重现该问题。因此，我被送回家，并支付了诊断费，并要求如果再次发生这种情况就回来。第二次来时，我匆忙补充说，问题发生在 18 分钟或 14 英里的驾驶时间超过 45 分钟的通勤时间之后。六个小时后，花了大约 375 美元，我取回了我的卡车。技术人员能够用新的细节重现问题，并更换了恒温器和软管。第三次来的时候，技术员的电话提前打来：“先生。”鲁，你需要一个新的散热器。”

这就是这个故事的简短版本。较长的版本包括我未能向服务技术人员解释在第一次和第二次访问之间我已经更换了恒温器。它还忽略了一个事实，即我对散热器液体进行了冲洗和填充，并且很可能在此过程中使软管夹松动。最重要的是，它忽略了这样一个事实：我的邻居（一名机械师）在卡车出现此问题之前告诉我，要更换散热器并进行其他预防性维护。现在，这与更好的客户体验有什么关系呢？

以下是我从自己遭受的磨难中得到的三个教训，它们将改善您的客户体验，而不仅仅是您的下一次汽车服务。

首先，获取并提供所有详细信息。

在我第一次访问时，我匆忙向服务技术人员提供了最基本的详细信息。结果，无法实现适当的解决方案。世界上的许多事件发生在最不合时宜的时间，并带来很大的压力和时间限制，但向您的客户体验团队提供尽可能多的详细信息仍然是最佳实践。您什么时候注意到这个问题，或者问题是什么时候发生的？您注意到了什么或者问题的症状是什么？当时还发生了什么其他事情？

考虑您可能提供的任何其他支持详细信息，包括错误消息和错误代码、软件系统日志、客户端日志以及捕获错误情况或症状的任何图片。很多时候我们喜欢认为软件中的事物是不相关的，而事实上它们是非常相关的。

其次，描述你所做的事情（好的或坏的）。

当我第二次来的时候，我给自己和技术人员带来了又一次极大的伤害。我没有解释我已经尝试过的所有事情（好的和坏的），并分享解决问题的失败尝试，而是推迟了我的解决方案。如果我告诉大家我已经更换了恒温器，对散热器进行了冲洗和重新填充，也许技术人员会去其他地方寻找问题。当您分享您为解决问题所采取的措施以及您可能采取的措施使问题变得更糟时，它可以帮助您的客户体验团队改进他们的响应，专注于其他问题领域，消除虚假的转移注意力（不相关的问题或事情）伪装成真实问题），并提供整体更出色的体验。

最后，执行之前的建议。

在问题出现之前，我的邻居根据他多年的经验和我的卡车的车龄提供了建议。他告诉我更换散热器，进行一些预防性维护，并对卡车的整体健康状况进行例行检查。最有可能的是，您的客户体验团队在其知识库中提供了与您的产品相关的建议以及与企业可用性要求运营相关的多年经验。使用它们进行预防性维护、主动调整，并检查您的可用性环境是否遵守这些最佳实践。但最重要的是，当他们提出建议时，执行它。最后，您将节省大量时间、金钱和麻烦。

第三次访问两天后，新散热器的缺货到达，我更换了散热器。我又继续开着 Betsy 好几年，最后才把它换成了一辆家用 SUV。

经许可转载安全操作系统