为什么 99.99% 的正常运行时间并不意味着 100% 的正常运行时间

为什么 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

网络研讨会：通过设计实现弹性——确保关键业务工作负载在 AWS 上持续运行

网络研讨会：通过设计实现弹性——确保关键业务工作负载在 AWS 上持续运行

在 AWS EC2 上构建弹性、高可用性的工作负载对于运行关键业务应用程序的组织至关重要。本次网络研讨会将探讨如何设计和运营此类工作负载。AWS中的高可用性架构同时兼顾复杂性、合规性和成本。

探讨如何应对诸如单点故障、恢复缺口和运营复杂性等常见挑战，并结合真实案例进行分析。金融服务，卫生保健， 和建筑维护系统获取实用指导，以增强韧性、降低风险并优化您的 AWS 环境。

经许可转载SIOS

了解 CLI 在高可用性环境中的作用

了解 CLI 在高可用性环境中的作用

人们想到高可用性 (HA) 时，首先想到的是集群、自动故障转移、复制和灾难恢复等技术。这些功能对于确保应用程序和服务的可用性至关重要。然而，HA 解决方案中一个容易被忽视的方面是管理员如何与环境交互和管理环境。

如今，许多解决方案都同时提供图形用户界面 (GUI) 和命令行界面 (CLI)。两者各有其用，最佳选择通常取决于手头的任务、环境规模以及组织的运营实践。

虽然图形用户界面 (GUI) 提供了一种直观的方式来可视化集群健康状况并执行管理任务，但命令行界面 (CLI) 则提供了一系列不同的优势，这些优势在高可用性环境中尤为有用。了解这些优势有助于组织确定命令行界面如何融入其整体管理策略。

支持自动化和可重复性

CLI 最广为人知的优势之一是其与自动化工具和脚本的集成能力。诸如检查集群状态、修改配置或执行例行维护等管理任务通常可以集成到 shell 脚本、编排平台或配置管理工具中。这使得组织能够自动化重复性流程，从而提高跨环境的一致性并最大限度地减少人为错误。随着基础设施的扩展，自动化例行操作的能力对于简化维护任务而言变得越来越重要。

随着环境发展而扩展

单个集群的管理需求与数十个甚至数百个集群的管理需求截然不同。随着环境的扩展，管理员通常需要寻找在多个系统中高效执行常见任务的方法。命令行界面 (CLI) 可以简化重复性操作的脚本编写、健康信息收集、报告生成以及跨大型环境的协同维护等操作。命令行工具并非要取代图形化管理，而是通过提供高效的界面来补充图形化管理，从而实现大规模的管理操作。

鼓励持续运营

在任何生产环境中，一致性都是一项重要的考量因素，尤其是在高可用性环境中。命令行界面 (CLI) 允许管理员在开发和生产环境中执行相同的命令。标准化流程可以被记录、审查和重复使用，从而帮助团队以一致的方式执行常见的管理任务。这种一致性有助于减少配置随时间推移而发生的偏差，并使维护窗口期间的操作流程更容易重现。

远程管理的灵活性

高可用性环境通常分布在多个数据中心、云区域或地理位置。管理员可能需要远程管理集群，有时需要在网络条件不佳的情况下进行。命令行界面 (CLI) 提供了一种轻量级的方法，可以通过安全连接与集群进行交互。这在带宽有限或图形化管理工具不可用时尤为有用。虽然图形用户界面 (GUI) 通常提供更丰富的视觉体验，但 CLI 提供了一种替代管理选项，在各种操作场景下都能保持有效。了解更多关于如何选择高可用性云的信息。

选择合适的界面

对许多组织而言，选择图形用户界面 (GUI) 还是命令行界面 (CLI) 的问题并非在于是否使用其中之一，而在于如何有效地使用它们。GUI 的优势在于能够清晰地展示集群运行状况、可视化资源关系，并使各种用户都能轻松访问管理功能。另一方面，CLI 通常非常适合自动化、脚本编写、重复性操作以及大型环境的管理。将这两种界面结合使用，可以让管理员充分利用各自的优势，并为特定任务选择最合适的工具。

结论

管理高可用性环境不仅仅是维持正常运行时间；它还需要工具来支持在维护或事件响应期间高效、一致且可靠的操作。命令行界面在自动化、可重复性和一致性等方面具有优势。同时，图形界面通过简化可视化和日常管理，继续发挥着重要作用。

与其将一种界面视为另一种界面的替代品，组织或许更应该了解每种界面如何为有效的集群管理做出贡献。通过在最合适的地方充分利用这两种界面，管理员可以构建能够随着其高可用性基础架构而扩展的操作工作流程。。

作者Tristan Allen，SIOS Technology Corp 的助理软件工程师

经许可转载SIOS

网络研讨会：从恐慌到主动：高可用性入门指南

网络研讨会：从恐慌到主动：高可用性入门指南

服务器严重故障不应该导致长达数小时的紧急停机。如果您是系统管理员、新上任的数据库管理员，或者被委以重任负责系统维护的“非专业”数据库管理员，您绝不能将系统正常运行时间寄托于运气。

在这节面向初学者的点播课程中，我们将深入浅出地讲解高可用性的基本原理。您将了解导致意外中断的根本原因、自动故障转移的工作原理，以及集群和云基础设施等现代技术如何确保您的关键系统全天候稳定运行。

经许可转载SIOS

IT弹性高可用性

IT弹性高可用性

现代IT环境从未如此强大，也从未如此复杂。如今，企业需要在混合云、分布式基础设施、边缘节点和多个可用区上运行关键应用程序。

与此同时，负责管理这些环境的团队常常被要求在资源有限的情况下支持更多的系统。这给高可用性和灾难恢复 (HA/DR) 带来了日益严峻的挑战。HA/DR 对业务连续性至关重要，但传统方法通常需要深厚的技术专长、手动配置以及少数专家的持续监督。在当今的 IT 环境中，这种模式已难以为继。

过于复杂的HA/DR的风险

多年来，高可用性集群管理曾被视为一门专门的学科。只有少数专家掌握集群配置、故障转移脚本、仲裁设置和恢复流程等细节。这种方法在环境规模较小、更加集中化时或许行之有效。

如今，同一个团队可能要负责跨云端、本地和混合系统的数百个工作负载。当高可用性/灾难恢复 (HA/DR) 工具难以理解或操作时，组织就会依赖少数关键人员。如果这些人在系统故障期间无法到场，即使是“自动化”的恢复计划也会迅速演变成令人倍感压力的手动流程。

这里停机时间风险增加。环境的复杂性与团队能力之间的差距成为企业韧性的薄弱环节。

高可用性中的简洁性并不意味着控制力的降低

人们普遍误以为简单的工具功能较弱。但实际上，设计良好的高可用性/灾难恢复解决方案并不会削弱控制力，而是让控制力更容易持续有效地发挥作用。

现代高可用性/灾难恢复 (HA/DR) 解决方案应在确保执行正确策略、依赖关系和恢复步骤的同时，减少管理员所需的手动工作量。软件不应期望每位团队成员都理解所有技术细节，而应引导用户遵循成熟的工作流程，并在错误演变为服务中断之前就加以预防。

这种简洁性并非为了降低功能，而是为了在系统中构建智能，使IT团队能够专注于结果，例如保持应用程序的可用性以及在出现故障时快速恢复。

现代HA/DR应该提供什么

一个切实可行的高可用性/灾难恢复 (HA/DR) 解决方案应该让整个 IT 团队更容易管理系统弹性。这意味着要摆脱命令行操作的复杂性，并为管理员提供清晰、指导性的方法来保护关键系统。

有效的HA/DR工具应包括：

• 简单的配置工作流程：引导式设置可帮助团队保护 SQL Server、SAP、Oracle 等应用程序以及其他业务关键型工作负载，而无需依赖冗长的手动配置。
• 策略驱动型自动化：智能系统能够根据预定义的业务规则，准确地知道如何以及在哪里重启发生故障的服务。
• 视野清晰：通过单一视图即可了解整个应用程序堆栈的运行状况，以便团队能够快速了解​​事件发生期间的情况。
• 内置护栏：主动验证检查，可在配置问题、网络延迟或补丁不匹配等问题干扰恢复之前识别它们。

这些功能结合起来，使高可用性/灾难恢复更具可预测性、可重复性，并且更容易让团队在压力下进行管理。

赋能团队，而非取代专家

简化高可用性/灾难恢复系统的使用并不会取代经验丰富的IT专业人员。它能帮助他们专注于更有价值的工作。

当日常维护、监控和故障转移流程更容易管理时，高级架构师和专家可以减少管理复杂集群配置的时间，从而有更多时间来改进战略、规划现代化项目并增强组织的整体弹性。

与此同时，IT 团队也能更有信心安全地维护关键系统。当准入门槛降低时，更多的人就能在发生事件时有效应对，而无需担心会使情况变得更糟。

为什么简洁对IT弹性至关重要

高可用性和灾难恢复不仅仅是技术功能，更是业务需求。一旦发生故障，组织快速恢复的能力将直接影响生产力、客户信任度、收入和声誉。

危机发生时，复杂性会延缓响应速度。清晰、自动化且易于使用的高可用性/灾难恢复 (HA/DR) 工具能够帮助团队自信且一致地采取行动。通过减轻管理员的运维负担，组织可以缩短恢复时间，并使正常运行时间更加可预测。

对于现代IT团队而言，简洁不再仅仅是一种便利。它是业务的关键组成部分。IT弹性。

准备好简化您的业务弹性策略了吗？立即联系我们了解我们的自动化高可用性/灾难恢复解决方案如何保护您的关键工作负载并增强您的 IT 团队的能力，而无需增加复杂性。

作者：Benjamin Roy，SIOS 市场专员

经许可转载SIOS