与高可用性相关的应用程序智能

与高可用性相关的应用程序智能

高可用性 (HA) 背景下的应用程序智能是指系统实时了解应用程序的行为和健康状况并做出智能响应以保持持续服务可用性的能力。

什么是应用智能？

那么，什么是应用智能？应用智能涉及监控、分析和响应多种因素。这些因素包括应用程序状态，例如应用程序处于启动状态还是关闭状态。性能指标包括响应时间、错误率、吞吐量和内存使用情况。应用程序依赖项，例如数据库或外部服务。最后，他们会关注用户行为或模式。使用应用程序智能可以更全面地了解应用程序。它使用各种数据点来对应用程序本身的状态（而不仅仅是基础设施）做出明智的决策。让我们以 Web 服务器为例；仅仅知道服务器是否正在运行是不够的，还要知道网站是否可以无错误地访问？响应速度是否很慢？用户是否需要多次刷新才能访问？网站所依赖的数据库是否也正常运行且可访问？以上所有都是应用程序智能衡量成功的因素示例。

LifeKeeper 如何使用应用程序智能

那么，生命守护者如何使用应用智能来增强关键应用的高可用性？让我们来详细分析一下。LifeKeeper 使用特定于应用程序的恢复工具包 (ARK)包含每个应用程序的知识（树液，SQL，PostgreSQL，甲骨文等）。这使得 LifeKeeper 能够处理每个应用程序的启动/关闭过程，监控应用程序及其依赖项的健康状况，并在不损坏任何数据的情况下协调智能故障转移/故障恢复操作。用户可以在 LifeKeeper 中将相关资源按层次结构组合在一起，这使得 LifeKeeper 能够理解不同应用程序组件之间的依赖关系（例如，当服务依赖于 IP 或数据库时）。这确保了 LifeKeeper发生故障转移按照正确的顺序和恢复操作不会破坏应用程序或使其处于不一致或损坏的状态。

此外，LifeKeeper 还会进行深度健康检查，不仅确定服务器是否正常运行，还会进行更详细的检查，例如数据库是否正在接受连接，或者 Web 服务是否返回预期响应。它甚至可以监控某些预期的后台进程是否正在运行。LifeKeeper 还使用特定于应用程序的配置文件来确保跨节点的数据配置一致性，并确保应用程序设置得到正确保存或恢复。最后，LifeKeeper 能够使用自定义脚本进一步微调这些深度检查，以智能地支持不太常见或自主开发的应用程序。

PostgreSQL ARK：应用程序智能的真实示例

为了更深入地了解，我们可以看看 PostgreSQL ARK 如何使用应用程序智能。PostgreSQL ARK 通过了解特定的 PostgreSQL 启动和关闭命令、了解 postgresql.conf 和 pg_hba.conf 等关键配置文件，以及理解数据目录布局和锁定文件行为，使用特定的逻辑来监控、启动、停止和故障转移 PostgreSQL。

PostgreSQL 的智能监控和有序故障转移

此外，它不仅检查 PostgreSQL 是否正在运行，还会检查数据库是否响应查询、正确的数据目录是否可访问以及事务日志中是否存在任何损坏。它使用依赖项跟踪来确保 PostgreSQL 经常依赖的资源可用，例如用于客户端连接的虚拟 IP 以及用于其数据目录的已挂载存储。这确保了 LifeKeeper 在发生故障转移时能够按正确的顺序启动资源，例如先挂载磁盘，启动 IP，然后启动 PostgreSQL，最后验证服务健康状况。

防止裂脑并确保数据完整性

最后，LifeKeeper 使用应用程序智能来避免裂脑（一种多个节点认为自己是“主”节点的现象）场景，避免启动两个具有相同数据目录的活动 PostgreSQL 服务器，并通过在写入仍在进行时不进行故障转移来避免数据损坏。这些都是 LifeKeeper 和各种 ARK 实现应用程序智能的不同方式的示例，旨在使组合产品尽可能具有弹性。

通过智能高可用性增强应用程序的弹性

总之，LifeKeeper 的内置应用程序智能通过了解应用程序的行为方式及其正确运行所需的条件，实现了精确、快速和可靠的故障转移和恢复。

确保应用程序的弹性和不间断的服务—请求演示或者开始免费试用今天体验 SIOS LifeKeeper 如何使用应用程序智能来保护您的关键工作负载。

作者: Cassy Hendricks-Sinke，首席软件工程师，团队负责人

经许可转载SIOS

在 Nutanix 环境中选择高可用性解决方案的 10 个注意事项

从 VMware 过渡到 Nutanix

在 Nutanix 环境中选择高可用性解决方案的 10 个注意事项

如果您计划从 VMware 迁移到 Nutanix，那么确保关键应用程序保持正常运行应是您的首要任务。虽然 Nutanix 提供了简化管理和提升性能等诸多优势，但其内置的高可用性仅涵盖虚拟机，而非应用程序本身。本文分享了十个关键见解，帮助您提前规划，避免迁移期间和迁移后出现停机。您将获得实用指导，了解如何为 Windows 和 Linux 选择合适的集群解决方案、如何在 Nutanix 中处理共享存储，以及在运行混合操作系统时需要考虑的事项。无论您是迁移到 Nutanix AHV，还是管理混合环境，都可以了解如何简化高可用性策略、降低风险并保护最重要的系统。

经许可转载SIOS

我的服务器是一次性的吗？高可用性软件如何融入云最佳实践

我的服务器是一次性的吗？高可用性软件如何融入云最佳实践

在这VMblog 文章《我的服务器是一次性的吗？高可用性软件如何融入云最佳实践》探讨了云计算的转变如何改变了服务器在现代 IT 环境中的角色和认知。随着自动化和基础设施即代码的兴起，服务器变得越来越可抛弃，易于创建、销毁和更换，这与 AWS 完善架构框架中概述的云最佳实践相一致。然而，Merry 强调，虽然基础设施可以视为临时的，但在其上运行的应用程序仍然至关重要，必须持续可用。为了弥补这一差距，高可用性 (HA) 软件发挥着至关重要的作用，它通过将应用程序连续性与底层服务器硬件分离，使 IT 团队能够保持正常运行时间和可靠性。这种方法使组织能够充分利用云环境的灵活性，同时又不损害其关键应用程序的稳定性和性能。

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

经许可转载SIOS

灾难频发世界的数据恢复策略

灾难频发世界的数据恢复策略

从事软件工程、系统管理和客户支持等工作，能够让你有机会接触各种配置和各种问题。此外，这样的职位还能让你深入了解用户的各种需求、痛点和顾虑，而纯工程岗位的从业者可能无法接触到这些。

在支持团队工作近五年，我注意到与我共事的各个团队都存在一些模式。此外，当我被要求协助处理各种配置时，我有机会比较不同的用例和根本原因。因此，我希望在开始与新团队合作时，能够确保打下基础。打下这个基础意味着确保管理实践能够与 HA/DR 套件完美协作，确保团队了解如何进行高可用性设计，以及如何利用系统上软件以外的实用程序来取得成功。这个基础对于确保团队了解如何达到或超越其运营标准至关重要。总结一下常见问题以及他们的答案，为那些对实施高可用性解决方案或者只是想改用新的高可用性解决方案。无论您是刚开始学习系统管理/系统工程的学生，还是被要求扩展职责范围以涵盖系统架构规划的资深软件工程师，以下几点都可以帮助您充分利用高可用性/灾难恢复套件。

不用多说，下面的问题总结了我在我的工作中看到的常见谈话要点，并将帮助您更轻松地理解关键概念并找到合适的解决方案。

什么是灾难恢复？它包含哪些内容？

灾难恢复，当与高可用性致力于优化恢复时间目标 (RTO)（服务恢复前无法访问的时间）和恢复点目标 (RPO)（从备份恢复时可以承受的数据丢失）。恢复时间目标描述系统在停机状态下仍能保持运行标准的时间长度。通常，此指标以百分比表示——常见的“五个九的正常运行时间”指的是 99.999% 的正常运行时间，或者每年最多停机 5 分钟左右。恢复点目标稍微复杂一些，它描述了在符合运行标准的情况下可以丢失的数据量。例如，如果系统在灾难发生后不会丢失任何数据，则称为“零 RPO”。将系统想象成一条时间轴，并将恢复点目标视为以下问题的答案会很有帮助：“如果系统遭遇灾难，您可以‘回溯’系统时间轴的多久，同时仍然满足运行标准？”

灾难恢复与传统的应对中断的方法有何不同？

传统上，如果没有高可用性的基础设施，灾难发生后的环境可能需要很长的恢复时间。系统需要恢复，问题需要解决，应用程序需要管理员启动。根据问题的严重程度，可能需要数小时甚至更长时间才能恢复正常运行。团队必须高效工作，保持紧密沟通，以确保服务无误地恢复，以免再次延迟恢复运营。此外，此类中断期间的数据丢失可能非常严重。如果最近没有备份，或者无法访问最新数据的副本，那么团队可能会依赖已经“过时”的数据，并因关键数据的丢失而遭受组织范围内的运营挫折。从客户的角度来看，当您需要在线服务时，您愿意等待多长时间才能获得访问权限？作为客户，如果在线商店丢失了您的交易记录，您能接受吗？

引入高可用性基础架构、镜像存储方法以及协调高可用性的方法后，影响 RTO 和 RPO 的因素均会得到优化，从而能够更从容地应对灾难。高可用性基础架构具备冗余性，因此可以使用备用系统接管运行。此外，协调器（用于管理集群环境的软件）能够系统地在备用系统上启动服务，其响应速度、可靠性和效率远高于手动干预。因此，恢复时间目标得以缩短，灾难恢复时间可能只需几分钟甚至更短，而非数小时。

高可用性基础设施的另一个方面是数据冗余。磁盘可以“镜像”，连接到不同系统的磁盘都可以实时接收完全相同的数据。因此，上述备用系统上可用的数据可以是精确的副本，从而有效地维护灾难发生前的数据备份。反过来，当服务恢复时，应用程序将以接近零的恢复点目标运行，从而在编排器将操作移至备用系统时，将恢复点目标保持在尽可能最新的运行状态。

组织在设计高可用性灾难恢复 (HADR) 策略时最常犯的错误是什么？如何避免这些错误？

最常见的失误之一是缺乏 QA/测试环境。SIOS 客户体验团队已经处理过多个此类案例，这些案例中，组织试图在应用程序/操作系统上修补/升级或者仅仅是由于规划不足或某种不幸的不兼容而导致的日常维护和体验问题。然后，停机时间环境发生故障，维护过程变成了恢复过程。这会导致生产环境中出现延迟、复杂性以及螺旋式问题的可能性。

到目前为止，能给组织提供的最大建议是创建一个以质量保证能力运行的生产环境一对一副本。生产中需要执行的每个流程都应首先在 QA 环境中进行“彩排”。这使组织能够自由地执行计划中的操作并进行改进，而不会危及基础设施的生产能力。在安全、低风险的环境中进行操作练习，可确保团队随时准备在生产环境中运行，避免遇到意外问题的风险，也不必在压力下“脱稿”快速正确地做出响应。如果 QA 环境中出现问题，则可以联系支持团队，并在确保问题不会影响业务运营的前提下进行调查。这可以极大地提高以可控、有计划且有效的方式找到解决方案并将其应用于运营的可能性。

上述 QA 环境的优势对任何组织都至关重要；然而，随着组织采用更复杂的维护策略，此测试环境的存在也变得更加重要。使用此测试环境不仅可以促进更顺畅的升级流程，还能帮助公司在采用引入复杂性的维护模型时降低风险，从而在维护活动期间提高系统可用性。​​在任何情况下，在 QA 环境中测试维护计划，根据“预演”的结果改进计划，并利用从实践中获得的经验，使组织能够管理生产系统，同时最大限度地降低遇到问题的风险。

消除单点故障的重要性是什么？

团队可能遇到的另一个常见障碍是架构中存在“最薄弱的环节”，而该环节无法从环境其他方面所获得的规划程度中获益。最好用一个例子来描述这一点。SIOS 客户体验团队曾经与一位客户合作，该客户在设计过程中围绕如何保持SAP 应用程序在其环境中运行的服务器，并很好地避免了影响运行 SAP 应用程序的系统的问题。遗憾的是，该客户投入了大量的规划精力来保护其应用程序，而没有投入同样的精力来规划其环境的其他方面。结果，所有系统都依赖于一个单一的内部 DNS 系统来解析其私有网络内的主机。尽管在保护方面付出了巨大的努力，树液当他们的 DNS 系统出现问题时，整个环境都会面临严重的问题，因为名称解析不再可用。实际上，他们为保护 SAP 应用程序所做的努力并没有帮助他们的环境渡过难关，因为 DNS 是所有其他系统正常运行所依赖的“薄弱环节”。在规划环境时，务必退一步，放眼全局——关注架构中出现的最薄弱环节。改进最薄弱的环节可以提升整个环境抵御灾难的可能性。

对于严重依赖云服务的组织，他们如何防范区域或地区范围的灾难？

只需按地理位置分配资源即可防范区域或地区范围的灾难。例如，有人可能将其主应用服务器托管在美国东部地区。然后，为了防止影响美国东部地区的中断，在远离美国东部地区（可能是美国西部地区）的“灾难恢复站点”中托管备用系统。虽然这确实引入了一些额外的步骤来确保跨区域通信，但这种努力是无价的，因为它可以防范区域和地区范围的灾难。通过在美国西部地区运行应用程序，可以承受云提供商美国东部地区全面中断。针对特定区域发生的中断的防护不需要很复杂，并且确保存在灾难恢复站点来承担运营将提高生产环境中的应用程序可用性和数据冗余。

您建议组织如何平衡实施强大的 HA/DR 策略的复杂性和成本与业务敏捷性的需求？

人们普遍认为高可用性/灾难恢复 (HA/DR) 解决方案要么复杂，要么昂贵，或者两者兼而有之。基于这一假设，我们必须密切关注眼前的风险。系统是为了某些业务目的而运行的，而这又会转化为收入。当系统因中断而宕机时，其成本远不止收入损失。如果没有 HA/DR 策略，中断需要员工积极地排除故障，这会产生员工工时成本，并将其计入停机成本中，甚至可能在员工休息不足、无法全力以赴工作的时间进行。此外，当员工不得不将任务切换到解决生产问题，然后再切换回正常工作时，常规工作中断以及延迟/缓慢，也会产生持续的附带成本。此外，声誉成本可能会导致无法识别创收机会。例如，如果您想到“CrowdStrike”？即使这不会立即带来问题和相关的负面报道CrowdStrike 在 2024 年 7 月经历了类似的困境，但在撰写本文时（2025 年 3 月 25 日），其股价才刚刚恢复到 2024 年 7 月 19 日发行股票之前的水平。考虑到配置 HA/DR 解决方案的机会成本，上述因素可能会极大地改变分析结果。SIOS 客户通常会发现，从长远来看，实施 HA/DR 解决方案可以节省成本。此外，凭借 SIOS Technology 数十年来对 HA/DR 产品不断改进和迭代的支持，配置此类解决方案的复杂性比以往任何时候都更加易于理解和简化。如果您仍然担心将 HA/DR 解决方案引入生产环境的复杂性，SIOS Technology 提供的专业服务可以帮助您培训团队、执行安装和配置活动，或者只是验证现有配置。凭借这些机会，将高可用性引入​​系统架构不仅比以往任何时候都更简单，而且实施速度也比以往任何时候都更快。最后，对于那些担心独特配置带来的复杂性，或希望最大限度地发挥 HA/DR 解决方案效用的组织，我们世界一流的支持团队随时准备提供帮助，充分发挥任何实施方案的潜力。

SIOS 技术的解决方案如何帮助组织实施您所倡导的灾难恢复方法？

SIOS Technology 的解决方案可以满足前面提到的所有方面，以下列举其中的一些：

我们采用现代灾难恢复方法LifeKeeper 和 DataKeeper 产品，我们统称为SIOS 保护套件无论在 Linux 还是 Windows 上，这些产品均可提供集群范围的资源编排，确保快速高效地应对灾难，同时确保数据在备用系统上复制并可用。LifeKeeper 监控应用程序故障并在节点之间通信，以确保系统是应用程序恢复的有效目标。Datakeeper 实时复制数据，确保备用系统能够在出现问题时继承应用程序，并继续使用最新的可用数据运行。这些产品协同工作，最大限度地缩短应用程序停机时间，并在灾难发生时最大限度地减少数据丢失。

这些产品还能与您的环境完全集成。它们提供高效的网络控制机制，使客户端始终能够解析与应用服务器的连接。这些解决方案不仅可以监控应用程序或系统的特定组件，还可以监控整个系统和环境。通过使用“仲裁”功能，可以在“全局”层面监控环境，确保应用程序在正确的系统上恢复，并保护数据。SIOS Protection Suite 针对各种灾难场景提供保护措施，因此能够做出适当的响应。

SIOS Protection Suite 还能够跨区域运行，提供我们之前讨论过的针对区域级或区域级灾难的保护。应用程序可以跨区域迁移，数据可以像在同一区域内复制一样轻松地跨区域复制。此外，环境可以多层级。主区域中可以托管多个节点，并充当活动系统或备用系统，从而快速响应系统级问题，同时还可以维护位于不同区域的灾难恢复站点，以确保以相同的速度和保护效率抵御区域级灾难。

最后，SIOS Protection Suite 产品受益于数十年的实际应用。它已在各种场景和部署配置中历经考验，并受益于多年来不断改进的易用性。因此，它是一款灵活、易于部署且可无缝融入生产环境的解决方案。采用 SIOS Protection Suite，可以避免设计和配置 HA/DR 解决方案的复杂性，并享受其丰富的开发历史和无数的改进，以及世界一流的支持团队，随时准备为您解决任何疑问或担忧。除此之外，您还有机会参与 SIOS Protection Suite 产品的协作安装或验证程序，确保您的环境能够应对各种挑战。最后，对于需要经验丰富的员工并希望最大限度地利用 SIOS Protection Suite 及其组件的团队，SIOS 提供培训活动，团队可以与我们的员工合作，了解正在发挥作用的组件，并进行积极的讨论，以促进深入的理解，确保员工能够立即掌握实施解决方案所需的所有信息，以最大限度地发挥其潜力。

保护您的业务免遭停机和数据丢失——请求演示或者开始免费试用看看 SIOS 的实际运行情况。

作者：Philip Merry，CX – SIOS Technology Corp. 软件工程师

经许可转载SIOS

DataKeeper 和棒球：灾难恢复的战略举措

DataKeeper 和棒球：灾难恢复的战略举措

在我的整个职业生涯中，数据管理员正在成为“智囊团”和“茶歇间”闲聊中的行业标准，当谈到数据保护和灾难恢复。美国著名的棒球运动和 DataKeeper 有什么区别？虽然我是棒球的铁杆粉丝，但这两件事看似毫无关联，还是有一些相似之处的。

制定成功的数据保护计划

首先，棒球和 DataKeeper 都需要一个严密的“比赛计划”。在棒球比赛中，球队会进行训练并制定计划，以期击败对手并最终获胜。同样，DataKeeper 需要一个“发人深省”的策略，以确保数据保护得到充分利用，并在发生灾难性事件时能够恢复。

其次，团队合作至关重要。内野手、外野手、教练和击球手各自扮演着特定的角色，以确保获得最佳的胜率。DataKeeper 可能需要多个团队参与，例如数据库管理员、基础设施人员、客户体验/支持、管理层等等。所有团队成员都应该全力投入，有效地保护和恢复数据。

棒球和 DataKeeper 的不同之处：IT 领域的风险更高

有一些差异不容忽视。输掉一场棒球比赛，尤其是在世界大赛第七场，最后一局，2出局，3坏球，2好球，可能令人沮丧，但使用DataKeeper，风险会高得多。数据丢失会给企业带来严重后果。棒球运动员需要独特的运动技能，而DataKeeper解决方案则需要企业系统和相关流程的知识。

总而言之，虽然棒球和DataKeeper看起来完全不同，但我们可以得出一些相似之处。两者都需要：

• 战略
• 团队合作
• ……和专业知识

无论您是棒球迷还是 IT 专业人士，显然，要想取得成功都需要一定的技能和奉献精神。

您的数据保护计划是什么？

查看提供的游戏计划/解决方案us.sios.com/solutions/

打球…

作者：Gregory A. Tucker，SIOS 高级产品支持工程师

经许可转载SIOS