Date: 8月 21, 2026
为什么 99.99% 的正常运行时间并不意味着 100% 的正常运行时间
你有没有仔细观察过洗手液的包装？“杀灭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