在不可预测的世界中制定灾难恢复计划

计算机系统和计算机化基础设施已成为承重部分。现代商业环境因此，停机不仅令人烦恼，而且代价高昂。虽然世界变幻莫测，但制定有效的灾难恢复计划并做好应急预案，可以确保意外问题不会导致更严重的后果。这正是高可用性和灾难恢复解决方案的作用所在。

了解高可用性和灾难恢复

高可用性和灾难恢复是一个多方面、相互支持的过程。虽然这些概念相辅相成、互相促进，但了解它们之间的界限至关重要。

什么是高可用性？

高可用性指系统、应用程序或其他基础设施组件能够迅速恢复运行的能力。这包括基础设施组件在重启、迁移或以其他方式恢复时，尽可能减少运行状态的损失或退化。

也就是说，基础设施能够持续发挥其指定作用，并获取最新信息。此外，高可用性基础设施可以支持多个基础设施组件共同承担主要角色，从而确保可用性。

什么是灾难恢复？

灾后恢复指的是系统、应用程序或基础设施组件承受灾难性故障的能力。通常，灾难恢复关注的是某些基础设施组件遭受的灾难性且不可挽回的损失。

灾难恢复解决方案的一个简单例子是，将数据备份并异地存储。这样做是为了保护数据免受可能导致原始存储介质无法恢复的全面灾难的影响，符合灾难恢复解决方案的标准，尽管其实现方式仍有改进空间。

高可用性和灾难恢复如何协同工作

高可用性和灾难恢复相结合，两者可以相互促进，共同实现各自的目标。高可用性解决方案能够确保系统及时恢复运行，而用于恢复系统运行的基础设施通常是灾难恢复解决方案的一部分。

如果规划得当，将工作负载迁移到健康的基础设施的能力可以使灾难恢复解决方案快速有效地运行。最大限度减少停机时间这两个要素相辅相成，共同营造出兼顾韧性和正常运行时间的环境。

停机的真正成本

生产环境中的任何计算机系统、基础设施组件或其他要素都可能出现故障。一旦发生故障，损失的收入、生产力下降以及修复故障根源的成本等机会成本很容易衡量。据国际技术情报咨询公司 (International Technology Intelligence Consulting) 2024 年的一项研究显示，仅这些成本就相当于每小时停机损失 30 万美元或更多。在估算停机成本时，91% 的中大型企业都提到了这一数字。

然而，停机带来的“软性成本”往往被忽视。停机会削弱客户信心，损害企业声誉，并给负责环境的人员带来额外压力。虽然停机确实会给企业造成非常直接且实实在在的损失，但此类事件的连锁反应可能会在未来数月甚至数年内持续影响企业运营。

将韧性作为设计要求

基础设施只有在设计之初就以打造高可用性环境并制定强大的灾难恢复计划为目标时，才能达到高可用性和最高灾难恢复能力的巅峰。

将高可用性/灾难恢复作为设计要求的第一步是设定切合实际的预期。通常，这些预期可以通过以下方式概括：“恢复点目标”（RPO）和“恢复时间目标”（RTO）。

简要描述这些指标：

• 恢复点目标 (RPO) 描述了组织在从备份恢复时可能丢失的数据量
• 恢复时间目标描述了在不可用环境能够恢复运行之前所需的理想时间。

定义这些指标自然而然地避开了一个常见问题。由于系统是根据其高可用性/灾难恢复 (HA/DR) 需求进行优先级排序的，因此对停机时间具有更高恢复能力的系统可以使用更简单的实施方案。反过来，那些需要极低恢复时间目标 (RTO) 和恢复点目标 (RPO) 指标的系统，则可以投入更多精力来确保这些系统上部署的解决方案能够满足更高的运行标准。

利用自动化降低灾难恢复计划中的风险

在探讨高可用性和灾难恢复策略时，我们通常会关注业务关键型系统。这些系统往往需要快速可靠地解决问题，以防止问题失控。尽管负责这些系统的人员都是环境方面的专家，但在解决问题的过程中，人为错误的可能性仍然是一个可以避免的风险因素。

一个强大的高可用性和灾难恢复解决方案可以集成自动故障检测和自动恢复操作。这​​样不仅可以更快地响应问题（问题能够被自动检测并执行相应的恢复计划），而且自动响应还能有条不紊、高效地采取行动，避免人为错误。

构建超越技术层面的冗余

尽管在设计时考虑高可用性/灾难恢复 (HA/DR) 并确保解决方案能够提供自动化响应至关重要，但在关键系统的设计、创建和维护过程中，仍然存在人为因素。在这些解决方案中充分发挥人员作用的关键在于，为团队创造一个低压力的工作环境，使其能够采用谨慎且有条不紊的问题解决方法。任何涉及人员参与的工作，其结果都应经过验证流程，以确保解决方案能够按预期运行。

除了工作环境之外，确保员工能够获得有效工作所需的知识也至关重要。如果团队中只有一人能够胜任某项维护工作，那么一旦该人员无法工作，运营就可能出现中断。

运营连续性规划不仅限于系统内部的考量。确保团队协作以减少知识孤岛，并在投入生产前对成果进行测试，可以有效避免问题，从而保护系统。

弹性系统的灾难恢复规划最佳实践

虽然实施高可用性和灾难恢复解决方案没有万能的模式，但有一些指导原则和最佳实践可以帮助构建适合贵组织的灾难恢复计划策略。上述几点是很好的基础。此外，还可以通过一些普遍适用的目标来改进，例如查找并消除单点故障、记录流程并明确角色和职责、维护与生产环境完全相同的质量保证 (QA) 副本以验证流程、将系统分布在地理位置不同的区域，以及定期审查和更新文档。

为应对下一次突发事件做好灾难恢复计划的准备

中断是不可避免的，没有哪个组织愿意经历中断。停电避免了一场本可预测和避免的失败。采取有计划的安排和分阶段实施的解决方案，可以有效应对这一问题。提供具有高可用性和灾难恢复能力的环境确保无论问题是否可预测，环境都能做好准备应对问题并继续满负荷运转，从而使企业能够顺利运营。

申请演示了解 SIOS 高可用性和灾难恢复解决方案如何帮助保护关键系统并保持您的业务运行。

作者：Philip Merry，SIOS Technology Corp.

经许可转载SIOS

主动-主动 vs. 主动-被动

高可用性架构指南

主动-主动和主动-被动是两种不同的架构配置。高可用性集群中的服务器节点双活架构是指两台服务器都处于开机状态并处理数据。双被动架构则截然不同，它只有一台服务器处于活动状态处理数据，而备用服务器则处于非活动状态，以便在活动服务器发生故障时接管控制权。

高可用性系统和核心组件

高可用性其核心在于消除单点故障，这意味着，如果某个节点出现问题，另一个节点可以接手该节点的工作。

高可用性系统的关键组成部分：

• 一个带有内存和电源的主处理核心节点
• 一个带有内存和电源的备用处理核心节点
• 两个核心组件之间的通信链路
• 本地存储或核心组件之间共享的存储

主动-主动架构

在双活架构中，两台相同的服务器同时运行，均处于活动状态，且都能处理事务。事务可以由任一服务器处理。

主动-主动架构的优势

两台服务器始终处于运行状态，而其他配置中则存在一些在正常运行期间未使用的节点。潜在优势如下：

• 可扩展性，尤其是利用云平台，使得高峰使用问题成为过去。
• 可以平衡服务器的工作负载，避免单台服务器过载。
• 总体而言，在硬件数量相同的情况下，吞吐量有所提高。

可扩展性

在云平台上，双活架构具有很强的可扩展性。例如，可以使用 AWS AutoScale 按需添加更多 EC2 实例，使集群能够扩展以应对数据高峰。

负载均衡

可以在节点上游配置负载均衡器，将事务发送到负载较轻的服务器，从而确保集群内的流量均衡，以确保工作项的高吞吐量。

主动-主动用例

数据量大、事务处理量大以及多节点托管应用最适合采用主动/主动配置。以下是一些示例：

• 多节点、全球分布式数据库系统
• 用于实时应用的数学数据处理
• 大数据/数据仓库
• 高流量网站托管
• 电信网络和短信

主动-被动架构

在主备架构中，集群环境采用两台服务器。一台服务器被指定为活动模式，负责执行处理任务。另一台服务器则处于备用模式，不执行任何数据处理，但随时准备在需要时接管。故障转移来自活动节点或用户签发的切换来自活动节点。

主动-被动架构的优势

由于同一时间只有一台服务器处于活动状态，因此另一台服务器可以享受停机时间（开机但处于待机模式，主要负责满足活动服务器的数据复制需求，随时准备在需要时接管控制权，但实际上不处理任何实际工作）。潜在的优势如下：

• 集群的功耗降低
• 延长硬件寿命——组件在较低的负载下运行，且不会持续处于极限状态时，使用寿命更长。
• 制冷需求减少，制冷量降低，电费也随之降低。
• 简化的资源视图——资源将在活动节点上处于活动状态
• 不需要负载均衡器

主动-主动模式与主动-被动模式的成本效益比较

由于集群的处理能力只有一半被用于实际工作，因此在主动-被动配置中，硬件的总体成本相对于可以执行的处理量而言更高，所以其成本效益略低于主动-主动配置。

简化管理

资源将在活动节点上处于活动状态——无需猜测哪个节点当前正在积极托管特定资源。

主动-被动使用场景

必须保持低数据丢失率的重要系统，例如：

• 金融处理系统
• 后端零售系统
• 灾难恢复解决方案
• 关系型数据库
• 为中小企业提供成本更低的高可用性
• 需要简单托管解决方案的遗留系统

灾难恢复解决方案中的双活模式与双活模式

主动-主动模式与主动-被动模式的作用

双活灾难恢复 (DR) 系统部署在地理位置分散的节点上，两个节点都处理生产流量。如果其中一个节点发生故障，工作负载将转移到仍然运行的系统。停机时间虽然一个系统宕机时工作负载处理可能会下降到比正常水平低的程度，但用户中断几乎无法察觉。

主动-被动灾难恢复（DR）系统实现了一种灾难恢复解决方案备用系统会在主系统发生故障时接管。活动节点发生故障时，系统切换过程中会出现短暂的停机时间，但备用节点接管原活动系统后，工作负载水平应该与原系统没有明显差异。

与冗余系统集成

使用冗余系统实施灾难恢复策略，旨在提供一种将活动切换到同步备份系统的能力，该备份系统上的数据与原有活动系统上的数据保持相同状态，并且新的活动系统能够在短时间内上线。在选择实施冗余系统时，还应考虑硬件冗余、通信路径冗余和软件冗余（通过高可用性实现）。

为您的企业选择主动-主动架构还是主动-被动架构

需要考虑的因素

为您的企业选择合适的架构取决于以下因素：

• 成本，包括如果希望使用云托管节点，则需支付的持续云费用。
• 是关键任务系统，还是高交易数据系统？
• 用户对偶尔少量停机时间的容忍度，以及性能要求——例如，因正常运行时间不达标而受到的 FCC 处罚？
• 节点和存储的地理分散化可降低延迟，并能根据需求增加节点以满足峰值需求。

性能和正常运行时间要求

在确定架构之前，应先明确业务的性能和正常运行时间要求。

对于正常运行时间达到三个九（99.9%），每年仅允许 8 小时停机时间的服务提供方而言，如果故障转移迅速，并且系统得到良好的监控和维护，那么使用主动-被动模式当然可以实现这一点。四个九（99.99%）正常运行时间主要属于主动-主动系统的领域。

还应考虑事务处理级别。如果预计会有大量的连续数据事务处理，则双活配置可能更合适。

主动-主动架构 vs. 主动-被动架构：哪种架构更适合您的企业？

双活和双活系统各有优势。对于企业而言，关键系统（绝对不能宕机）可能更适合采用双活架构。而对于其他可以容忍偶尔停机的系统，双活架构或许是更合适的选择。混合使用多种技术或许更能满足所有系统的需求。企业可以根据自身需求选择合适的方案：规模较大、业务分散的企业可以受益于云托管双活系统的灵活性，而规模较小的企业则可以享受双活架构的简洁性和成本优势。总有一款解决方案适合您。

如果您正在评估双活架构和双活架构在高可用性策略中的应用，申请演示了解 SIOS 如何帮助您为您的企业设计合适的架构。

作者：Paul Scrutton，SIOS 软件系统工程师

经许可转载SIOS

保障建筑物安全：维护和安防系统的高可用性

在本集中TFiR：我们来谈谈，主持人 Swapnil Bhartiya 接受采访戴夫·伯明翰SIOS Technology 的客户成功总监谈到了高可用性和弹性为何对企业至关重要。楼宇维护和安保系统伯明翰解释了这些系统与其他楼宇技术的区别，以及它们之间经常存在的交互方式，并阐述了不间断运行对于保障居住者安全和楼宇功能的重要性。对话探讨了组织如何平衡安全性和可访问性，人工智能、机器学习和物联网等新兴技术在提升可靠性方面的作用，以及通过冗余、监控和风险规划来确保系统可用性的最佳实践。

作者：Beth Winkowski，SIOS Technology Corp. 公共关系部

经许可转载SIOS

通过模块化和抽象化设计高可用性

迄今为止，本系列文章探讨了技术设计与修辞之间的相似之处。技术方案的“修辞”，即传达意义和目的的策略，是通过设计模式和概念来呈现的。设计模式和概念作为概念基础而存在，其意义在实施过程中转化为可应用的形式。

如前所述，这种连续性和完整性概念基础确保解决方案始终保持符合维护、改进和长期可靠性标准的要求至关重要。外部影响解决方案设计的因素挑战旨在维护解决方案设计中提出的概念基础的目标。这些外部因素可能与既定原则相冲突，因此，解决方案中使用的工具、应用程序和平台必须经过慎重选择。

在本博客系列的第三部分也是最后一部分中，我们将探讨模块化和抽象化作为一种​​设定界限的手段，以确保范围广泛的项目能够继续从结构良好、论证合理的设计中获益。

高可用性设计原则：为什么模块化和抽象化至关重要

在探讨模块化和抽象化这两种策略之前，首先需要理解为什么要实施它们。我们可以用一个类比来说明：演讲者为了说服听众接受自己的方案，首先需要阐述几个基本要点。这样，他们就能逐一提出并论证论点的各个支柱。

演讲者首先必须建立“A蕴含B”和“C蕴含D”的基础，在此基础上才能构建“B和D蕴含E”的论证。这种策略确保了“A蕴含B”的推理不会与“C蕴含D”这一独立论点相互干扰，从而避免削弱后者。这种策略之所以被广泛运用，是因为它允许演讲者论证的每个组成部分独立存在。即使“C蕴含D”的论证存在缺陷，也可以通过其他方式加以修正，而“A蕴含B”的论证仍然有效。

这种结构的原因与技术系统采用去中心化的原因相同——销售点系统的问题可以单独解决，而无需将修复工作扩展到数据库、API、网络架构等等。上述策略当然是指模块化和抽象的概念。

高可用性架构中的模块化

首先，谈到模块化，它指的是用自包含的组件构建系统。从修辞意义上讲，“A蕴含B”和“C蕴含D”这两个论证仅仅是推理模块，它们被组合成一个完整的论证。

更具体地说，模块化组件（例如前面例子中的销售点系统）允许在问题产生的模块内部完全解决问题。解决方案中的每个模块都像一个构建块，单个构建块中的问题无需拆卸整个解决方案即可解决。

抽象化作为可扩展基础设施设计的一种策略

与模块化密切相关的是“抽象”。抽象是指确保整体解决方案的设计独立于构成该整体解决方案的各个模块的设计，并且与这些模块的设计无关。

此外，抽象作为一种设计策略，其核心在于每个模块都是独立且与其他模块的设计无关的。当解决方案采用抽象元素时，这些元素可以被重用并应用于各种用例，从而在整个项目中加深理解。

设计“不碍事”的高可用性

当设计采用模块化组件时，需要划定边界。这些边界确保每个模块都能“互不干扰”。当组件被抽象化后，每个模块的内容就更容易理解。

反过来，这些边界构成了一种结构，通过这种结构可以理解设计；而边界内的抽象则为理解用例的基础提供了切入点。模块化和抽象所提供的结构，与修辞在构建理解目的的框架中所起的作用相呼应。

利用模块化高可用性解决方案管理复杂的网络架构

随着技术解决方案的不断开发以应对日益复杂的问题，对这些解决方案设计中稳固框架的需求也日益增长。网络架构通常是众多本身就十分复杂的解决方案的最终产物，它完美地诠释了日益复杂的问题以及对稳固设计框架日益增长的需求。此外，网络架构往往面临着持续增长的挑战，因为它必须整合为实现业务目标而不断扩展的庞大系统网络。

在此基础上，解决方案架构还必须采用以下解决方案：高可用性和/或灾难恢复这会造成设计冲突的发生，但可以通过模块化和抽象化的策略轻松缓解。

在SIOS高可用性软件中应用模块化和抽象化

好处高可用性软件无需繁琐的设计和临时拼凑的解决方案，即可实现高可用性。SIOS LifeKeeper 就是一个符合设计规范的高可用性工具示例，其运行原理能够与使用环境无缝集成。

LifeKeeper 采用模块化设计，不会对受 LifeKeeper 保护的系统之外的系统提出任何要求。LifeKeeper 还有助于将基础设施组件抽象成易于管理的小单元——协同工作以确保可用性的系统被分组到一个“集群”中。

通过这种抽象，环境的逻辑依然清晰——理解一个集群的构成是理解所有集群的基础。设计的各个层级可以根据其用途进行理解；无需对不同实现方式的差异进行特殊标注和考量。由于各个集群独立于其他集群或外部解决方案组件运行，因此可以划定一个边界，将每一层级的设计元素包含在其中，从而避免与其他基础设施层级发生冲突。

利用 SIOS 保护套件构建长期弹性基础设施

就像任何软件或工具一样，SIOS 保护套件SIOS LifeKeeper 和/或 SIOS DataKeeper 会影响其使用环境的设计。虽然这些模式的引入源于 LifeKeeper 和 DataKeeper 的保护环境，但 SIOS LifeKeeper 和 SIOS DataKeeper 精心挑选了所使用的模式，以确保这些模式能够实现整个解决方案的抽象和模块化。由于 LifeKeeper 和 DataKeeper 实现了分层抽象，这些实用程序的引入有助于与 IT 基础架构集成，从而保持解决方案设计的一致性。

由于采用了特定的设计模式，由 SIOS Protection Suite（LifeKeeper 和/或 DataKeeper）保护的集群构成了一个抽象且模块化的元素，能够无缝集成到现有的设计和解决方案中。LifeKeeper 和 DataKeeper 的功能远不止简化单个系统或各个集群的管理；它们还与部署过程中遵循的原则相契合。

借助 SIOS Protection Suite，基础设施的创建变得更加简单高效。该套件提供了一种简便的方法来理解系统在设计中的作用，同时还提供了一种简便的方法来实施高可用性和灾难恢复。管理员可以将 LifeKeeper 和 DataKeeper 作为工具，在未来数年内更好地理解、操作和改进解决方案。

了解高可用性如何在不增加复杂性的情况下支持您的基础架构设计。立即申请演示！

作者：Philip Merry，SIOS 的客户体验软件工程师

经许可转载SIOS

 

QA 和生产环境在高可用性中的关键作用

对于管理现代应用程序的IT团队而言保持高可用性推出更新可能充满挑战。实现可靠性的关键在于将质量保证 (QA) 环境与生产环境分离。这看似微不足道，但对于发现潜在问题和增强维护工作的信心至关重要。

QA环境作为高可用性的测试场地

QA环境是生产环境的副本。它提供了一个沙箱，可以在其中对新功能、配置变更和补丁进行全面测试。除了功能测试之外，QA环境还支持流程验证、性能基准测试、负载测试和安全验证。

这些活动至关重要，可以在瓶颈、漏洞或集成问题有机会影响最终用户或损害您的环境之前，识别它们。对于分布式系统或云架构QA 环境可以帮助模拟网络延迟、数据库复制延迟以及其他操作边缘情况，这些情况如果不经过测试，可能会中断业务运营。

生产环境与最终用户体验

生产环境是最终用户依赖系统稳定运行的环境。任何计划外停机或故障都可能直接导致业务损失，从收入损失到声誉受损不等。

通过将生产环境与正在进行的开发和测试工作隔离，IT 团队可以确保运营稳定性。配置完善的生产环境应包括：冗余策略故障转移机制和监控工具在部署前已在质量保证环境中通过测试验证。

通过结构化部署流程实现平稳过渡

高可用性不仅仅意味着保持系统正常运行，它还包括使更新可预测。QA 环境可以支持结构化的部署流程，从而实现分阶段发布和蓝绿发布等多种策略。在 QA 环境中预先验证的回滚流程，能够帮助团队在出现意外问题时快速恢复。结构化的方法使更新可预测，并有助于维护客户信任。

将质量保证环境与生产环境分离的运营优势

拥有独立的质量保证 (QA) 和生产环境也有助于合规性、审计准备和跨团队协作。测试系统和生产系统之间清晰的界限有助于运维和开发团队高效协作。它还有助于为监控、故障排除和维护提供可重复的框架。灾难恢复计划。

高可用性策略中的质量保证和生产环境

质量保证 (QA) 和生产环境在确保系统平稳运行方面发挥着至关重要的作用。通过隔离环境、进行全面测试以及谨慎管理部署，IT 团队可以减少停机时间、保持高可用性，并实现无缝更新过渡。这些实践有助于确保系统在发展过程中保持可靠性和弹性。

准备好提升质量保证和生产环境的高可用性了吗？申请演示了解 SIOS 如何帮助团队自信地部署更新并保持关键系统运行。

作者：Tristan Allen，SIOS Technology公司客户体验软件工程师

經 SIOS 授權轉載