SIOS SANless clusters High-availability Machine Learning monitoring
SIOS 对北美和英国的 250 多位 IT 高管进行了调查，以了解企业目前如何保护关键业务应用程序。研究揭示了复杂的 IT 环境与传统高可用性和灾难恢复 (HA/DR) 策略的可靠性之间存在日益扩大的差距，表明尽管在混合云和多云基础设施方面投入巨资，应用程序停机问题依然存在。
立即下载完整的 SIOS 2026 高可用性调查报告，了解现代 IT 痛点、隐藏的系统漏洞以及高可用性 (HA) 和灾难恢复 (DR) 的未来支出重点。
经许可转载SIOS
在最近的一次贸易展上，一个问题被反复提及：SIOS LifeKeeper 实际运行在哪里？
答案至关重要。LifeKeeper 直接安装在每台受保护服务器的操作系统上。这种安装方式使其能够访问应用程序、其支持资源以及维持工作负载可用性所需的依赖项。
这与仅仅依靠基础设施层或容器层的HA（高可用性）有所不同。
虚拟机管理程序级别的高可用性可以检测到发生故障的物理主机，并将其虚拟机重启到其他位置。容器编排平台可以替换发生故障的容器，或在节点之间迁移工作负载。
这些功能提供了有效的保护，但它们是在应用程序外部运行的。即使虚拟机内部的数据库挂起或 Web 服务崩溃，虚拟机仍可能继续运行。同样，容器重启后，可能并未彻底解决数据、存储、网络或依赖服务方面的问题。
提供高可用性的层决定了它可以看到哪些故障以及如何精确地做出响应。
由于 LifeKeeper 在操作系统内运行，因此它可以监控实际应用程序环境的运行状况，而不仅仅是托管该应用程序的服务器、虚拟机或容器。
这使得 LifeKeeper 能够：
这种应用感知方法有助于缩小“服务器正在运行”和“应用程序可用”之间的差距。
HA（住房援助）的居住地点应根据必须保留的资源来决定。
如果主要目标是从硬件或主机故障中恢复，那么基础架构级别的高可用性可能就足够了。但如果可用性目标涉及业务关键型应用程序及其数据，那么更接近应用程序的保护措施可以提供更高的可见性和更有针对性的恢复。
这些方法并非必须相互排斥。基础设施层、容器层和应用层高可用性可以协同工作，形成多层保护。关键在于理解每一层监控的内容，以及恢复责任的起始点和结束点。
高可用性解决方案与应用程序的贴近程度越高，出现故障时就能获得越多的上下文信息。对于服务级别协议 (SLA) 要求严格、恢复时间目标 (RTO)/恢复点目标 (RPO) 要求高的企业而言，这种上下文信息至关重要，它决定了企业是重启基础设施还是恢复用户真正依赖的服务。
准备好弥合您环境中的可用性差距了吗？联系我们的团队，了解 SIOS LifeKeeper 如何帮助您实现最关键的正常运行时间目标。
作者：Ben Roy，SIOS 市场营销项目专员
经许可转载SIOS
你有没有仔细观察过洗手液的包装？“杀灭99.99%的细菌”通常会醒目地印在包装的某个位置。如果你和我一样，可能会产生一个很合理的疑问：“那剩下的0.01%呢？”究竟是什么让这最后的0.01%如此难以杀灭？我们在高可用性（HA）软件方面也会遇到同样的问题。在讨论HA正常运行时间时，你很可能已经见过99.99%这个数字。问题依然存在：为什么我们无法实现100%的正常运行时间？
首先，我们来谈谈 99.99% 正常运行时间究竟意味着什么。正常运行时间指的是应用程序运行并可供最终用户使用的时间。通常，这是以年为单位进行衡量的。要达到 99.99% 的正常运行时间，停机时间不得超过 52.60 分钟。平均而言，这意味着：
每年52分36秒
每月 4 分 23 秒
每周 1 分 0 秒
每天 0 分钟 8 秒
那只是很短的时间，但算不了什么，那么它究竟是从哪里来的呢？
我们先来看看一些最基本的停机原因。事实上，无论你的高可用性软件多么出色，执行诸如切换之类的常见操作总是需要一些时间。每次你主动发起切换时，都会产生极短的停机时间。根据层级结构的大小，这可能需要几秒钟到几分钟不等。为了理解其中的原因，我们需要了解切换发生时的具体情况。在资源层面，我们必须首先将资源从当前活动节点上完全移除，然后再将资源完全启用到新的活动节点上。根据应用程序的不同，这可能意味着运行几个简单的命令，也可能意味着运行冗长而复杂的优雅关闭操作，然后在另一台服务器上进行缓慢的冷启动。在层级层面，在很多情况下，我们必须一次执行一个操作。如果一个资源有任何子资源，那么在开始移除初始资源之前，必须先将所有子资源完全移除；然后，在另一台服务器上，我们必须先让所有子服务完全投入运行，才能开始启动主服务。对于多层级架构和复杂的切换流程，这会造成相当大的时间损失。这是一种固有的、不可避免的停机时间，但幸运的是，在大多数情况下，最终用户除了会感觉到加载时间略微延长或需要短暂重新连接之外，不会察觉到任何异常。然而，这确实会增加停机时间的计算。
另一种固有的停机形式是维护。幸运的是，大多数维护工作都可以以高可用性的方式进行。这意味着先在备份节点上执行维护，进行切换，然后再在之前运行的系统上执行维护。如上所述，这会造成一定程度的停机，但停机时间应该很短。然而，有些维护工作无法以高可用性的方式进行。在这种情况下，可能会出现相当长的停机时间，从而增加全年的总停机时间。
一旦我们开始关注高可用性软件的主要用途：灾难恢复，就会发现其中的利害关系。即使一切都按计划完美进行，任何故障都会造成一定程度的停机时间。我们首先来看看在成功故障转移过程中停机时间是如何产生的。为了从故障中正确恢复，我们必须首先检测并验证故障。这是一个需要权衡的难题。如果故障检测过于激进，可能会检测到实际上并未发生的故障（误报故障）。如果检测不够激进，则故障检测速度可能会过慢。大多数故障首先会被定期运行的进程检测到。对于单个资源故障，通常是检查脚本失败；对于整个服务器故障，通常是心跳丢失。在这两种情况下，我们都不会在出现一次故障后立即启动恢复。相反，我们会进行重试，并等待多次故障以验证真正的故障。例如，执行更复杂的资源状态测试的深度检查脚本默认每五分钟运行一次。这意味着检测某些故障可能需要长达五分钟的时间，而根据故障类型的不同，验证故障可能需要更长时间。在检测并验证故障后，根据故障类型，我们可能会尝试多次本地恢复。如果恢复成功，可以节省一些停机时间；但如果恢复失败，则会略微增加故障切换的停机时间。在检测故障、验证故障并尝试本地恢复后，我们将执行故障切换。根据故障的具体类型，故障切换所需的时间可能与之前描述的切换停机时间类似。所有这些潜在的延迟因素加起来，可能会显著增加停机时间。幸运的是，大多数故障都能被快速检测到，并且与上述切换类似，最终用户几乎不会察觉到故障的发生。
第二个导致意外停机的原因是故障转移失败。一旦发生故障转移，停机时间会显著增加，因为故障转移需要合格的技术人员介入并正确地恢复系统。虽然这种情况比较少见，但确实会发生。幸运的是，故障转移几乎总是可以预防的。确保故障转移按计划进行的最佳方法是提前进行测试。配置错误很容易发生，但只需运行一次故障转移测试即可发现任何此类问题。确保故障转移成功的另一种方法是确保集群尽可能频繁地做好故障转移准备。这意味着要确保备份系统正常运行，并且资源处于 ISP（服务保护）状态。例如，未处于镜像状态的 DataKeeper 镜像不会处于 ISP 状态，因此发生故障时将无法进行故障转移。为确保资源能够顺利切换，应采取措施确保 DataKeeper 尽可能频繁地进行镜像，并且其他资源也保持最新状态，随时准备进行故障转移。
导致意外停机的最后一个原因是 LifeKeeper 无法控制的问题。网络问题可能导致故障转移成功或失败，但也可能使看似健康的集群无法访问，具体取决于系统的设置方式。同样，底层云或虚拟化软件的问题也可能导致 LifeKeeper 无法处理的问题。为了避免这些问题，尽可能地将系统隔离，可以让 LifeKeeper 免受这些问题的影响。所有系统都位于同一可用区或同一网络上的集群比包含分散系统的集群更容易出现问题。LifeKeeper 无法控制的另一个问题是内部应用程序问题和人为错误。例如，意外删除关键数据可能会给最终用户带来问题，而这些问题很可能无法被 LifeKeeper 检测到或修复。使用备份软件可以帮助从这类问题中恢复，但无法弥补损失的正常运行时间。最后，高可用性并不一定能抵御恶意行为者和网络安全威胁。某些攻击可能会导致正常运行时间损失。为防止此类问题，建议使用可信赖的防病毒/反恶意软件套件。
正如上文多节所述，许多停机原因完全可以避免。我不会在此一一列举所有可避免的停机类型，但会重点介绍几种最常见的类型。
在初始设计集群拓扑结构时，需要考虑以下几点。脑裂是指两个节点都认为自己是主节点的情况，可以通过某种形式的仲裁机制来避免。如果您正在开发一个通用应用程序，请务必编写并使用快速检查和深度检查脚本，以便能够真正检测到故障。最后，请确保设置多条通信路径，这些路径跨越多个网卡和网络。
系统配置不当也会导致停机。前面已经提到了一些例子。首先，确保受保护的应用程序、底层操作系统和高可用性软件都已更新到最新版本。很多停机是由于一些原本可以完全避免的、但已被修复的漏洞造成的。其次，在集群配置完成后以及之后定期进行切换和故障转移测试。通过这些测试，可以提前发现并预防许多可能导致故障转移失败的问题。第三，确保始终有一个备用节点处于运行状态并随时准备接管。
配置不当的系统会导致停机。为避免这种情况，LifeKeeper 和 DataKeeper 提供了可调参数，用于优化性能、心跳间隔、资源检查和重试设置。虽然默认设置通常足够，但任何更改都应在充分了解其影响和必要性后进行。务必优先考虑 SIOS 支持团队的指导，因为他们的建议基于丰富的专业知识，应严格遵循以确保系统可靠性。
作者：Carter Chandler，SIOS公司副软件工程师
经许可转载SIOS
在 AWS EC2 上构建弹性、高可用性的工作负载对于运行关键业务应用程序的组织至关重要。本次网络研讨会将探讨如何设计和运营此类工作负载。AWS中的高可用性架构同时兼顾复杂性、合规性和成本。
探讨如何应对诸如单点故障、恢复缺口和运营复杂性等常见挑战，并结合真实案例进行分析。金融服务，卫生保健， 和建筑维护系统获取实用指导，以增强韧性、降低风险并优化您的 AWS 环境。
经许可转载SIOS
人们想到高可用性 (HA) 时，首先想到的是集群、自动故障转移、复制和灾难恢复等技术。这些功能对于确保应用程序和服务的可用性至关重要。然而，HA 解决方案中一个容易被忽视的方面是管理员如何与环境交互和管理环境。
如今，许多解决方案都同时提供图形用户界面 (GUI) 和命令行界面 (CLI)。两者各有其用，最佳选择通常取决于手头的任务、环境规模以及组织的运营实践。
虽然图形用户界面 (GUI) 提供了一种直观的方式来可视化集群健康状况并执行管理任务，但命令行界面 (CLI) 则提供了一系列不同的优势，这些优势在高可用性环境中尤为有用。了解这些优势有助于组织确定命令行界面如何融入其整体管理策略。
CLI 最广为人知的优势之一是其与自动化工具和脚本的集成能力。诸如检查集群状态、修改配置或执行例行维护等管理任务通常可以集成到 shell 脚本、编排平台或配置管理工具中。这使得组织能够自动化重复性流程，从而提高跨环境的一致性并最大限度地减少人为错误。随着基础设施的扩展，自动化例行操作的能力对于简化维护任务而言变得越来越重要。
单个集群的管理需求与数十个甚至数百个集群的管理需求截然不同。随着环境的扩展，管理员通常需要寻找在多个系统中高效执行常见任务的方法。命令行界面 (CLI) 可以简化重复性操作的脚本编写、健康信息收集、报告生成以及跨大型环境的协同维护等操作。命令行工具并非要取代图形化管理，而是通过提供高效的界面来补充图形化管理，从而实现大规模的管理操作。
在任何生产环境中，一致性都是一项重要的考量因素，尤其是在高可用性环境中。命令行界面 (CLI) 允许管理员在开发和生产环境中执行相同的命令。标准化流程可以被记录、审查和重复使用，从而帮助团队以一致的方式执行常见的管理任务。这种一致性有助于减少配置随时间推移而发生的偏差，并使维护窗口期间的操作流程更容易重现。
高可用性环境通常分布在多个数据中心、云区域或地理位置。管理员可能需要远程管理集群，有时需要在网络条件不佳的情况下进行。命令行界面 (CLI) 提供了一种轻量级的方法，可以通过安全连接与集群进行交互。这在带宽有限或图形化管理工具不可用时尤为有用。虽然图形用户界面 (GUI) 通常提供更丰富的视觉体验，但 CLI 提供了一种替代管理选项，在各种操作场景下都能保持有效。了解更多关于如何选择高可用性云的信息。
对许多组织而言，选择图形用户界面 (GUI) 还是命令行界面 (CLI) 的问题并非在于是否使用其中之一，而在于如何有效地使用它们。GUI 的优势在于能够清晰地展示集群运行状况、可视化资源关系，并使各种用户都能轻松访问管理功能。另一方面，CLI 通常非常适合自动化、脚本编写、重复性操作以及大型环境的管理。将这两种界面结合使用，可以让管理员充分利用各自的优势，并为特定任务选择最合适的工具。
管理高可用性环境不仅仅是维持正常运行时间；它还需要工具来支持在维护或事件响应期间高效、一致且可靠的操作。命令行界面在自动化、可重复性和一致性等方面具有优势。同时，图形界面通过简化可视化和日常管理，继续发挥着重要作用。
与其将一种界面视为另一种界面的替代品，组织或许更应该了解每种界面如何为有效的集群管理做出贡献。通过在最合适的地方充分利用这两种界面，管理员可以构建能够随着其高可用性基础架构而扩展的操作工作流程。。
作者Tristan Allen，SIOS Technology Corp 的助理软件工程师
经许可转载SIOS