什么是高可用性（HA）？

什么是高可用性（HA）？

如今世界上充斥着各种各样的缩写词；有时，要记住它们的含义着实不易，尤其对于没有技术背景的普通用户而言更是如此。HA 这个缩写词已经存在了几十年。那么，用通俗易懂的语言来解释它的含义是什么呢？HA 代表高可用性（High Availability）。HA 指的是，公司赖以生存的计算机系统（公司和客户都依赖这些系统）在客户每天任何时间访问时都能正常运行。例如，您尝试通过手机或笔记本电脑上的应用程序访问您的银行账户，查看余额或进行电子存款。但您收到一条错误消息，提示系统无法连接，请稍后再试。您可能认为只有您遇到了这个错误，于是重启了笔记本电脑和手机。但您仍然收到同样的错误提示：“系统无法连接”。这意味着什么？这意味着银行的计算机系统似乎宕机了，您无法访问！您可能会疑惑——银行的计算机系统怎么会离线呢？如果企业未能为其运营系统实施高可用性 (HA) 解决方案，则可能会出现这种情况。

HA 的工作原理

那么，高可用性（HA）在实际应用中是如何运作的呢？让我们来详细了解一下。HA 可以通过运行在企业计算机上的软件或内置于企业计算机的硬件来实现。本文重点在于概括性地描述 HA 软件在企业计算机上提供的功能。HA 的作用是确保计算机始终保持运行状态，以便企业及其客户可以随时访问数据和信息。HA 如何保证计算机始终保持运行状态呢？HA 由几个关键组件构成。

• 计算机之间的监控– 在高可用性 (HA) 系统中，通常有两台计算机协同工作，以确保其中一台始终处于运行状态。每台计算机都会按照可配置的时间间隔与另一台计算机通信，并询问“你在线吗？”。如果没有收到“你在线吗？”的回复，HA 软件就会决定让另一台计算机运行业务，并实时自动执行此切换，无需人工干预。
• 监控计算机上运行的应用程序企业高效运营依赖于计算机上运行的各种应用程序和关键程序。监控就像主计算机询问每个应用程序：“你运行正常吗？”如果应用程序和关键程序回答“不正常”，则高可用性软件会尝试在主计算机上修复问题。如果主计算机上的“不正常”状态持续存在，则高可用性软件会自动决定让另一台计算机运行业务，并实时实施这一变更。

价值论证

现在我们已经了解了高可用性 (HA) 的概念及其基本工作原理，其价值显而易见。HA 硬件、软件和架构为企业提供了一种确保系统高可用性、持续运行的方法，无需手动监控系统以确保其正常运行。如果没有 HA，企业将面临停机、客户流失和销售损失的风险。在当今世界，任何企业都无法承受这些问题。企业高度依赖其计算机、应用程序、服务和数据来维持不间断的运营，因为停机会直接影响其盈利能力。当系统不可用时，公司不仅会损失收入，还可能面临客户流失的风险。如果客户无法及时访问所需的服务或数据，他们很可能会转向竞争对手，这是任何企业都不愿看到的局面！

作者：Sandi Hamilton，SIOS产品支持工程总监

经许可转载SIOS

如何在周五晚上的系统崩溃中幸存下来：从简陋的裸机到无缝的数据复制

如何在周五晚上的系统崩溃中幸存下来：从简陋的裸机到无缝的数据复制

那是我高二那年。周五晚上很晚了，像大多数青少年一样，我正对着电视发呆。突然，屏幕的光亮被手机的亮屏打断了。一阵嗡嗡声。接着又是一阵。然后是一阵持续不断的震动，这只能说明一件事：Discord 又崩溃了，客服工单如潮水般涌来，服务器又宕机了。

当服务器停机成为业务的一部分

那时，灾难性的宕机几乎成了我日常生活的一部分。游戏托管行业简直就是基础设施领域的蛮荒西部。竞争对手服务器发起的定向DDoS攻击、经验不足的客户误操作导致配置崩溃，以及廉价裸机服务器不可避免的硬件故障，混乱成了这个行业不可或缺的一部分。当我的同学们还在为生物考试焦头烂额时，我却在凌晨两点疯狂地通过SSH登录服务器，祈祷一次强制重启就能让节点恢复在线。

最终，这种持续不断的混乱开始造成沉重的代价。就我个人而言，独自一人24小时不间断地负责故障响应，这种巨大的压力已经让我精疲力竭。但从商业角度来看，损失更加惨重。每一分钟的停机都意味着要从本就微薄的利润中支付服务水平协议（SLA）补偿金。这意味着自然增长的流失、潜在客户的流失，以及应对玩家们理所当然的沮丧情绪。我痛苦地意识到，停机不仅仅是技术故障，更是一笔巨大的财务损失。

寻找更佳的高可用性策略

我知道必须做出改变。我花了几个小时研究企业架构，但作为一个独自运营、资金匮乏的青少年，我的高可用性策略本质上只是一堆临时拼凑的 Bash 脚本。我找到了一些实现基本故障转移的方法，但始终找不到可靠且经济实惠的方法来确保真正的数据复制。

最终，我交出了钥匙，把主机托管业务卖给了竞争对手，之后便离开了服务器机架，走进了大学的讲堂。但随着我学业的深入，那些令人抓狂的宕机事故留下的创伤却始终挥之不去。我总是忍不住去想基础设施、停机时间，以及那些科技巨头是如何轻松应对曾经让我的网络瘫痪的故障的。我孜孜不倦地努力去理解这种差距，最终促使我获得了在SIOS的实习机会。

探索 SIOS DataKeeper 和无缝数据复制

走进这个工程环境，感觉就像踏入了一个平行世界，我青少年时期对基础设施的种种担忧都已迎刃而解。当我第一次亲眼目睹 SIOS DataKeeper 的运行时，我被深深震撼了。这正是我多年前苦苦寻觅的东西。

看着一台机器上的编辑内容无缝转移到另一台机器上，并在模拟故障转移期间完全按照预期运行，真是令人难以置信。它与其他系统无缝集成，彻底杜绝了停机时间，这让我确信，我曾经梦寐以求的完美基础设施真的存在。

从简陋的基础设施到关键任务型高可用性

如今，我的工作完美地融合了我早年奋斗的经历和行业顶尖标准。我直接站在技术支持的第一线，确保我们的软件和客户的架构完美运行。每一天，我都能帮助企业保障其关键业务数据的在线安全。

这让我感到一种无比深刻、圆满的满足感。每当我帮助客户搭建高可用性系统时，我都会想起那个独自一人在周五晚上摸黑摸索的少年。如今，我不再只是渴望拥有一个安全网，而是积极地帮助其他企业打造坚如磐石、无需恐慌的基础设施，这种感觉真是太棒了。

作者：Brit Weinstein，SIOS客户体验工程师实习生

经许可转载SIOS

接地气：错过Percona Live Amsterdam让我对HA有了哪些新的认识

接地气：错过Percona Live Amsterdam让我对HA有了哪些新的认识

坐在机场的地板上，眼睁睁地看着出发航班信息牌因为关键系统故障而变成一片红色的取消航班，而你这周的日程安排却是全力以赴地维护数据库的高可用性，这真是莫大的讽刺。

与其在 Percona Live 大会上一边吃着焦糖华夫饼一边讨论同步复制与异步复制、灾难恢复策略和连接路由等问题，我不如花几个小时观看英国空中交通管制基础设施实时演示系统故障时会发生什么。

当中央飞行处理系统发生故障时，飞机不会坠毁……人工操作员会手动降低处理能力以确保安全。这对于航空电子设备来说是良好的工程设计。但从操作和用户角度来看，吞吐量会立即降至零。

在数据基础设施领域，我们没有条件对交易进行接地处理。

单点故障剖析

一个系统可以拥有分布在三个可用区的冗余硬件、双电源以及昂贵的供应商合同。然而，如果所有流量都通过单个状态协调器、集中式配置摄取管道或共享控制平面，那么你拥有的就不是分布式系统，而是一个代价高昂的分布式单点故障（SPOF）。

当飞行处理流程因输入格式错误或集中式状态偏差而阻塞时，主节点和辅助节点通常会同时触发安全模式锁定。在我们的系统中，这相当于：

• 裂脑情景当两个主数据库节点锁定表或退出仲裁以防止数据损坏时，就会发生这种情况。
• 健康检查协调器将网络延迟误判为完全故障，导致主连接频繁切换，直到连接池耗尽。
• 一个备份集群，能够在几毫秒内忠实地复制损坏的元数据或毒丸交易。

冗余仅仅是指拥有两份相同的东西。而弹性则是指知道备用件不会重蹈覆辙。

真正的HA需要什么

如果你的系统在凌晨 2 点主路径突然中断后，无法在无人干预的情况下继续运行，那么你并没有实现高可用性，而只是拥有了一个连接在焦虑的工程师身上的警报系统。

• 基于法定人数的共识制应对脆弱的初选：依赖简单主动/被动复制和手动 DNS 故障转移的系统极易导致停机。现代集群（无论是使用 Galera、组复制还是 Raft/Paxos 等共识协议）都需要奇数个节点和法定人数，以确保自动、安全地选举领导者，避免脑裂。
• 智能交通脱钩：应用程序绝不应直接指向数据库节点的硬编码 IP 地址。七层代理、智能连接池（例如 ProxySQL）和虚拟 IP 将应用程序客户端与底层基础设施的频繁变更隔离开来。如果节点 A 发生故障，节点 B 会接管写入操作，应用程序只需不到一秒即可完成重新连接，而不会完全中断。
• 隔离故障域：真正的高可用性 (HA) 会隔离输入。如果包含致命查询或格式错误的配置数据包进入系统，则必须将其隔离。如果主节点在执行过程中崩溃，故障转移不应自动将完全相同的致命查询重放到备用节点上，从而导致整个集群宕机。
• 重在钻探而非文档：如果你还没有在模拟网络分区和高负载条件下测试过自动故障转移，那么你的故障转移计划就只是一个假设。

总结

错过阿姆斯特丹的走廊巡演和现场演示令人遗憾。但凝视着停滞不前的机场航站楼，却让我更加深刻地意识到：停机时间绝不仅仅是 Grafana 仪表盘上的一个抽象指标。它会导致真实的人员滞留、运营中断，并摧毁信任。

做好容错设计。实现故障恢复自动化。测试集群。

作者Aaron West，SIOS 销售工程师

经许可转载SIOS

SIOS LifeKeeper 与 Red Hat 高可用性附加组件：

SIOS LifeKeeper 与 Red Hat 高可用性附加组件：

如何为运行在 Linux 上的关键应用程序选择合适的高可用性解决方案？

SIOS LifeKeeper for Linux 和 Red Hat High Availability Add-On 都能通过监控资源并在发生故障时将工作负载迁移到另一个集群节点来保护应用程序。然而，它们在平台支持、应用程序集成、存储灵活性以及配置和管理集群所需的专业知识水平方面存在差异。

了解这些差异可以帮助组织选择最适合其基础设施和运营资源的解决方案。

SIOS LifeKeeper 与 Red Hat HA 附加组件：主要区别一览

红帽高可用性附加组件为运行在 Red Hat Enterprise Linux 上的应用程序提供故障转移集群。它使用 Pacemaker 进行资源管理，Corosync 进行集群通信，并采用隔离和仲裁机制来保护数据完整性并防止脑裂情况的发生。

管理员可以通过 pcs 命令行界面、RHEL Web 控制台 HA 插件或 Red Hat Enterprise Linux 系统角色来配置和管理集群，以实现自动化部署。

这种方法可能非常适合以下类型的组织：

• 他们已将基础设施标准化为 Red Hat Enterprise Linux。
• 我们已拥有强大的起搏器和Corosync技术专长。
• 希望对集群资源和策略进行详细控制
• 具备构建、测试和维护特定应用程序配置的内部资源

Pacemaker 的灵活性固然重要，但也可能带来复杂性。管理员必须正确定义资源、依赖关系、约束、监控行为和隔离机制。应用程序保护可能需要选择、配置或自定义资源代理和脚本。

适用于 Linux 的 SIOS LifeKeeper

适用于 Linux 的 SIOS LifeKeeper为 Red Hat Enterprise Linux、SUSE Linux Enterprise Server、Oracle Linux 和 Rocky Linux 提供应用感知的高可用性和灾难恢复保护。

一个关键区别在于使用了应用程序恢复工具包（ARK）。这些软件模块包含特定于应用程序的智能功能，用于保护数据库和应用程序，例如 SAP、SAP HANA、Oracle、PostgreSQL、SQL Server 和其他关键工作负载。

ARK 有助于自动化发现应用程序组件、验证配置详情、创建资源层次结构、监控应用程序堆栈以及根据应用程序最佳实践管理恢复的过程。此外，还提供通用应用程序恢复工具包，用于定制和内部开发的应用程序。

LifeKeeper可能更适合以下类型的组织：

• 可在多个Linux发行版上运行
• 需要特定应用的自动化和监控
• 需要减少对专业聚类技术的依赖
• 需要同时支持共享存储和无 SAN 集群配置。
• 在本地、云端或混合环境中运行工作负载

LifeKeeper 还包含一个集中式 Web 管理控制台，可以直观地显示应用程序和资源依赖关系。这使得配置集群、了解资源关系以及监控应用程序运行状况变得更加容易，而无需通过单独的命令来管理每个组件。

存储和云灵活性

存储架构是另一个需要考虑的重要因素。

Red Hat HA 集群可以设计用于多种存储配置，但组织必须为其环境选择和配置适当的存储资源、隔离机制和支持组件。

LifeKeeper 支持传统的共享存储以及使用集成式、基于主机的块级复制的无 SAN 集群。这使得组织能够在共享存储不可用或不切实际的情况下，在集群节点之间复制本地存储，包括在 AWS、Microsoft Azure、Google Cloud、虚拟化环境以及地理位置分散的环境中。

这种灵活性对于云和混合部署尤其有价值，因为传统的共享存储架构可能与可用的基础设施不匹配。

选择合适的HA解决方案

最佳选择不仅仅取决于产品是否能够启动故障转移。企业还应考虑如何轻松地配置、验证、运行和更新环境。

Red Hat 高可用性附加组件为致力于 RHEL 并具备必要 Pacemaker 专业知识的组织提供了一个灵活的集群框架。SIOS LifeKeeper 则提供了一种更以应用为中心的方案，它内置了恢复工具包、集成了复制选项、支持多发行版，并提供了一系列旨在简化集群管理的工具。

无论选择何种平台，组织都应验证整个应用程序环境，包括存储、网络、数据库、应用程序服务、依赖项和客户端连接。高可用性并非仅仅是将工作负载迁移到另一台服务器，而是要确保在发生故障时，整个应用程序仍然可访问且可正常运行。

作者：Ben Roy，SIOS 市场营销项目专员

经许可转载SIOS

应用弹性现状：2026 年 SIOS 高可用性调查

应用弹性现状：2026 年 SIOS 高可用性调查

来自 250 多位 IT 领导者的见解，探讨如何弥合混合基础设施复杂性与真正应用程序正常运行时间之间的差距。

SIOS 对北美和英国的 250 多位 IT 高管进行了调查，以了解企业目前如何保护关键业务应用程序。研究揭示了复杂的 IT 环境与传统高可用性和灾难恢复 (HA/DR) 策略的可靠性之间存在日益扩大的差距，表明尽管在混合云和多云基础设施方面投入巨资，应用程序停机问题依然存在。

立即下载完整的 SIOS 2026 高可用性调查报告，了解现代 IT 痛点、隐藏的系统漏洞以及高可用性 (HA) 和灾难恢复 (DR) 的未来支出重点。

经许可转载SIOS