灾难恢复事件响应：不冲动行事的原则

警告出现，服务停止响应，工单开始堆积，有人喊道：“我们得做点什么！”这种立即启动恢复工作的本能是可以理解的，因为在事件发生时，采取行动会让人感觉高效，而等待则会让人觉得不负责任。在这种压力下，做任何事都比什么都不做要好。

然而，一些最具破坏性的决定灾后恢复之所以会产生误会，并非因为无人采取行动，而是因为有人在不了解事情真相的情况下就采取了行动。哲学家马可·奥勒留经常论述将事件本身与我们对其形成的判断区分开来的重要性。我们首先会获得对事件的印象，然后我们的思维会迅速形成一种解释。如果我们不停下来审视这种解释以及导致这种情况发生的行为，我们就会开始将一种假设当作事实来对待。

为什么冲动性事件反应会增加风险

例如，假设一台服务器无法访问。我们可能立即得出结论，认为它已经故障，但实际上我们只知道无法与其通信。它可能仍在运行，只是由于网络问题导致我们无法看到它。

这种差异很重要高可用性环境手动将应用程序迁移到另一台服务器或许可以恢复服务，但也可能导致两台服务器都认为自己应该处于活动状态。在高可用性环境中，这种情况通常被称为“服务器冲突”。裂脑情景两个系统各自表现得好像拥有同一个应用程序或资源。旨在提高最终用户可用性的响应措施可能会给应用程序或其数据带来风险。

在对非关键组件进行常规故障排除时，我们也会观察到同样的问题。重启服务或许能暂时解决问题，但同时也改变了我们试图了解的情况。重启完成后，关于原始问题的有用信息可能就消失了。我们可能在未了解问题根源或是否可能再次发生的情况下，就恢复了服务。

观察与假设的区别

这并不意味着团队在系统故障期间应该按兵不动，因为奥雷利乌斯并没有提倡犹豫不决，而克制也不应成为拖延或不作为的借口。关键在于根据我们已知的信息采取行动，而不是基于我们对可能发生情况的担忧。我认为，当事件变得令人焦虑时，这种区分很容易被忽略。人们渴望了解最新进展，警报不断出现，电话会议中的沉默时间也会感觉比实际更漫长。有人可能会建议重启系统，因为上次遇到类似重大事件时重启确实奏效了。

因此，即使当前问题的原因可能不同，但症状却与之前的问题相似，这个建议听起来也像是可行的方案。经验固然有用，但也可能导致我们思维上的捷径。识别熟悉的症状固然重要，但想当然地认为它一定与上次事件的原因相同则不然。相似的症状可能源于截然不同的问题。

更规范的应对方式是只陈述已确认的信息。与其说“服务器宕机了”，不如说“服务器在此位置没有响应”。这种措辞看似微不足道，但却能避免团队将结论误认为观察结果。同时，也为其他人报告服务器在其他地方可以访问留下了余地。

为什么在系统故障期间进行规范的故障排除至关重要

这时，事件响应就不仅仅是技术知识的问题了。它要求我们克制住急于解决问题的冲动，不要在真正理解问题之前就急于求成。有时候，仅仅多做一项检查就足以改变调查方向和后续步骤。

第二个监控位置可能会显示应用程序在内部仍然可用，而本地控制台可能会确认看似故障的服务器实际上运行正常且已被隔离。这些信息可以避免不必要的恢复操作，并帮助团队找到真正的问题所在。

自动化在灾难恢复中的作用

设计良好的自动化流程遵循类似的原则。自动化流程的价值在于它可以持续响应，无需等待管理员起床或加入通话。然而，速度本身并不能保证自动化响应的正确性。

当恢复条件明确时，自动化系统应立即采取行动。当可用信息不完整或相互矛盾时，更稳妥的做法可能是停止操作并寻找更多证据。高可用性系统通过多种方式考虑到了这一点。独立的通信路径有助于区分……一个连接出现故障避免整个服务器瘫痪。当系统之间无法再相互通信时，仲裁机制或见证机制可以提供另一种视角。这些控制措施至关重要，因为系统对环境的感知可能准确，但并不完整。

SIOS LifeKeeper 如何支持更明智的康复决策

生命守护者可以通过资源监控、定义的依赖关系和恢复策略来支持这种决策。该技术有助于执行已制定的恢复计划但它无法决定特定企业可接受的风险水平。这种判断必须由相关人员在环境稳定时做出，而不是在事故发生后临时做出。

构建更完善的灾难恢复事件运行手册

清晰的流程有助于控制局面。一份完善的事件处理手册应帮助团队在做出重大变更之前明确已知信息。它应说明如何确认应用程序是否已在其他地方激活，并确定谁有权启动恢复程序。

我们的目标并非消除人的判断，而是在时间有限的情况下，为这种判断提供一个可靠的基础。我们无法消除技术带来的不确定性：硬件会发生故障，网络会运行不稳定，应用程序偶尔也会让最了解它们的人感到意外。我们所能做的，是做好准备，去识别事件本身与我们最初对事件的解释之间的差异。

灾后恢复中的纪律

奥勒留重提此观点，是因为它最适用于困境。当一切皆有可能时，清晰的判断自然易行。但当压力迫使人们选择最快的答案时，清晰的判断就显得尤为重要。在突发事件中，房间里最冷静的人未必无所事事。他们可能正在确保下一步行动能够真正解决当前的问题。在事件响应中，纪律并非不作为，而是拒绝让压力左右你的行动。

利用专为复杂 IT 环境构建的高可用性和灾难恢复解决方案，保护关键应用程序。申请演示了解 SIOS LifeKeeper 如何帮助您的团队减少停机时间并充满信心地恢复运行。

作者：艾丹·麦克伦（助理产品支持专员）

经许可转载SIOS

高可用性和灾难恢复无处不在：从一般概念到解决方案生成

相关博客/背景阅读推荐

本博客假定读者已熟悉 LifeKeeper 资源层级框架和 LifeKeeper 集群。如需了解这些主题的背景知识，请参阅下方列出的博客。此外，本博客还基于之前一篇关于如何利用 LifeKeeper 中的“快速服务保护应用程序恢复工具包”（QSP ARK）来弥合潜在用例与支持的保护机制之间差距的博客（链接如下）。

• Linux集群/Windows 集群（本文由SIOS全球销售与市场营销副总裁霍格兰女士及SIOS市场营销团队撰写）
• 应用智能与高可用性（本文由SIOS公司IT高级系统工程师Hendricks-Sinke女士撰写）
• 资源行动和背景通用应用程序恢复工具包（本文由高级技术推广专家伯明翰先生撰写）
• 在 GenApp 和 QSP 之间进行选择：为您的关键应用程序量身定制高可用性（本文由 SIOS 的高级系统工程师 Hendricks-Sinke 女士撰写。）

然而，本博客将探讨当 QSP ARK 无法满足特定应用程序或用例的高可用性和灾难恢复需求时可用的选项。

快速回顾

本博客的前一部分本文探讨了如何思考应用程序，以便创建通用应用程序恢复工具包，从而利用 LifeKeeper 保护该应用程序。本节将第一部分介绍的应用程序基础知识应用于 LifeKeeper 的通用应用程序恢复工具包框架。

由于本篇博客系列文章最好与上一篇结合起来理解，因此这里简要回顾一下第一部分中提出的概念。

问一个尽可能简单但仍然能提供有用/可操作信息的问题

在确定如何回答宽泛的问题时，将其分解成若干个答案更简单的小问题。然后利用这些小问题，逐步构建出最初“宽泛”问题的答案。

利用所提供的信息

了解可用的工具以及这些工具如何传递信息。掌握回答“最基本问题”所需的信息后，确定如何利用应用程序 API 提供的信息来解答这些“最基本问题”。

回顾完毕，我们终于可以开始讨论 LifeKeeper 了。虽然高可用性和灾难恢复通常与复杂性联系在一起，但我们已投入大量精力，确保对特定应用程序的理解能够轻松移植到通用应用程序恢复工具包 (GARK) 框架中。有了之前的基础，现在是时候以此为基础，像 LifeKeeper 一样思考了。

像生命守护者一样思考

想象一下，你身处电影《怪诞星期五》的场景中，一个女孩和她的母亲互换了身体，由于不熟悉彼此的日常职责而手忙脚乱。和你互换身体的人要代替你参加一个上线活动，她需要知道如何启动关键应用程序、确保它们正常运行，以及如何关闭应用程序。如果你只有15分钟的电话时间进行准备，你会如何向她解释这些内容？你需要详细说明哪些信息才能让她顺利完成工作？

虽然这个场景是人为设计的，但它很好地展现了关键的资源保护操作。LifeKeeper 管理应用程序，确保它们只在单个系统上运行；LifeKeeper 资源层级结构则确保在恢复或移除资源时，先决条件应用程序和系统资源都能按正确的顺序处理。反过来，LifeKeeper 使开发人员能够在单个系统的上下文中思考对受通用应用程序资源保护的应用程序执行的操作。将启动、停止或查询应用程序的过程简化到最基本的要素，是定义通用应用程序操作脚本需要完成的任务的第一步。当启动、停止和查询操作按照上述策略定义后，资源操作之间便一一对应，如下所示：

• 恢复操作：应用程序启动
• 移除操作应用程序停止
• 快速检查操作查询应用程序
  • 笔记对于通用应用程序资源，快速检查操作是可选的；如果未定义快速检查操作，则不会执行监控。但是，强烈建议定期进行应用程序监控，以确保实现高可用性和灾难恢复的最佳效果！
• 地方复苏行动应用程序停止和应用程序启动（按顺序）
  • 笔记对于通用应用程序资源，本地恢复操作是可选的。如果未定义本地恢复，通用应用程序资源不会尝试在检测到故障的系统上重启以进行自我修复，而是会在故障系统上停止运行，并将应用程序的整个层次结构迁移到备用系统。

有时，LifeKeeper 需要了解正在运行的应用程序的某些详细信息才能执行上述操作。所有 LifeKeeper 资源（包括通用应用程序资源）都具有一个名为“资源信息字段”的字段，其目的是向操作脚本提供这些信息，以便在资源操作期间使用。信息字段中包含的资源信息可以在资源扩展时针对每个系统独立配置，从而允许资源操作使用特定于执行操作的系统的信息。LifeKeeper 还提供命令行实用程序，以便轻松获取或设置资源信息。

回到“怪诞星期五”的例子，如果你要和对方交换身份，你需要告诉对方哪些细节？例如应用程序文件的关键路径、命令参数的具体设置/值等等。信息字段非常适合存放那些必须知道才能确定应用程序其他细节的信息。信息字段也非常适合插入设置值、命令参数值或其他无法通过其他方式获取的值。值得注意的是，根据 LifeKeeper 的惯例，信息字段在资源的生命周期内很少（甚至从未）更改。为了避免信息字段损坏，最好将那些在资源生命周期内会发生变化的信息放在资源信息之外，而是通过 LifeKeeper 资源的操作脚本以编程方式获取，或者通过操作脚本可以调用的“辅助”脚本获取。

为了提供额外帮助，LifeKeeper 还附带用于开发通用应用程序的模板脚本。这些脚本为通用应用程序的操作脚本提供了绝佳的起点，因为它们预先准备好了 LifeKeeper 在调用特定资源的操作时将使用的输入参数。反过来，这也使得这些信息可以在资源操作脚本中使用。

结论

LifeKeeper 提供了多种应用程序保护方式。然而，某些应用程序的需求超出了 LifeKeeper 应用程序恢复工具包 (APP) 的功能范围。在这种情况下，高可用性和灾难恢复保护仍然可行，而且可能比之前想象的更容易实现。组织不应回避通用应用程序；相反，它们是 LifeKeeper 提供的众多强大工具之一，可用于提升环境的高可用性和灾难恢复能力。通用应用程序框架旨在兼顾易用性和灵活性。但是，如果您的组织没有足够的资源自行编写通用应用程序恢复工具包，SIOS 提供专业服务，由 SIOS 工程师代表您的组织协调需求并开发通用应用程序恢复工具包。如果需要持续支持，SIOS 专业服务还提供扩展服务，将常规产品支持扩展到由 SIOS 专业服务开发的通用应用程序。保护组织业务关键型应用程序的门槛正在不断降低，而适用于 Linux 或 Windows 的 SIOS Protection Suite 旨在引领潮流，使未受保护的应用程序成为过去式。

并非所有应用程序都适合标准的高可用性模型。SIOS 可以帮助您为业务关键型工作负载设计和实施合适的 LifeKeeper 解决方案。申请演示今天。

作者：Philip Merry，SIOS Technology Corp. 的支持工程师

经许可转载SIOS

接管 Linux 集群的 SIOS LifeKeeper

想象一下，你站在面包车外，手里抱着孩子，正伸手去拿尿布包，这时一辆带有红色条纹的黑色大面包车停在了你旁边。车门缓缓打开，一群形形色色的人走了出来。一个身材魁梧的身影下了车，他那标志性的莫霍克发型直插云霄，浑身散发着不容置疑的威严，脖子上戴着的金链子也格外醒目。一位经验丰富的退伍老兵走了出来，告诉你，你现在是这项关键任务中不可或缺的一员。

想象一下，你坐在你最爱的乐队的独家彩排现场，位置在前排左侧中间。你听着他们一首接一首地演奏你最爱的热门歌曲。你跟着这些经典老歌的节奏，像弹空气吉他一样。你完美地配合着节奏，在座椅和腿上交替敲击出鼓点。最后，你从丢弃的大杯饮料里找到两根吸管，用它们完美地演绎了一段鼓独奏。漫长的等待终于结束，你终于成为了爆满观众中的一员，但突然间，鼓手跑下了舞台，一位焦急的经纪人指着你，让你上台。

大丹犬卡洛斯是“大男孩犬舍俱乐部”全场总冠军的热门人选。你可能只从喜欢大型犬的同事那里听说过卡洛斯，但今天你将看到卡洛斯的全新一面。事实上，你看到了卡洛斯的方方面面，因为他的训练员刚刚把他送到你家，而他自己则在外面等着拖车把他的工作用车拖走，并送来一辆代步车。“只需要一个小时，”他向你保证。但要确保一只价值百万美元的全场总冠军犬的安全可不是件容易的事。

说实话，原版《天龙特攻队》或者任何现实版的《天龙特攻队》不太可能突然停在你面包车旁边，把你带走去参加一个绝密、关键任务、拯救国家的行动。同样，就算你模仿吉米·亨德里克斯或希拉·E惟妙惟肖，不管有没有用大吸管，也未必能让你从人群中脱颖而出，成为爆满演出的焦点。虽然你可能会看到卡洛斯或其他热门选手或冠军，但除非你是它们的主人、训练员或评委，否则你不太可能在无人监管的情况下和它们待在一起。虽然这些情况发生的概率很低，但你或许会被要求接管一个 LifeKeeper for Linux 集群，这其中也蕴含着类似的风险、责任和重要性。

继承 LifeKeeper for Linux 集群时该怎么办

许多企业报告称，停机造成的损失每小时高达30万美元，甚至数百万美元。为了避免灾难和停机，企业通常会部署具有多层冗余的强大架构。

除了这些冗余措施之外，许多公司还部署了高可用性 (HA) 软件，例如适用于 Linux 的 SIOS LifeKeeper为企业关键型基础设施、应用程序和数据库添加至关重要的监控和恢复功能。LifeKeeper for Linux 提供基础设施、应用程序、服务和数据库的资源监控和恢复功能，确保业务连续性，并将停机时间降至最低或避免。虽然它不像黑车那样由专人驾驶，但它对企业至关重要。

那么，如果你突然要负责管理一个 LifeKeeper for Linux (LK-L) 环境，而这个环境带来的收入比几十个 Carlos 版本还要多，你会怎么做？

接管 Linux 集群 SIOS LifeKeeper 的 8 个步骤

接管 SIOS LifeKeeper for Linux 集群的八个关键步骤包括：

1. 查找并查看现有运行手册

查找所有现有的运行手册。这些手册通常存储在之前管理员创建的文档库中。详细的运行手册通常能够提供集群配置和架构方面的深入信息。这些信息对于管理和未来的运维工作都大有裨益。

2. 找到您的 LifeKeeper for Linux 产品版本

了解您的产品版本是接管集群的重要组成部分。SIOS 会频繁发布产品更新，提供更丰富的功能、安全更新和改进。接管现有产品集群时，您需要知道当前版本，以便评估以下几个因素：

1. 您的产品在产品和支持生命周期中处于什么阶段？
2. 您使用的是产品的最新版本吗？
3. 自您使用的版本以来，该产品新增了哪些功能或修复了哪些问题？
4. 在哪里可以找到特定版本的文档？

您可以通过用户界面查找产品版本。如果您的运行手册显示 LifeKeeper 版本为 9.8.x 或更高版本，您可以使用 https://<服务器名称>:5110（或 https://<服务器 IP 地址>:5110）启动 LifeKeeper Web 管理控制台 (LKWMC)。登录后，选择“属性”：

属性页面加载完毕后，在产品名称下方的部分找到您的版本信息：

如果您运行的是旧版本的 Linux 版 LifeKeeper，启用 X11 转发并启动 Java 用户界面通过 SSH 客户端会话中的命令 /opt/LifeKeeper/bin/lkGUIapp。

您还可以通过命令行查看产品版本，方法如下：

# rpm -qi steeleye-lk

启动 Java 用户界面并登录后，即可访问帮助中心。获取产品版本后，可通过以下方式查看产品生命周期和版本特定信息。docs.us.sios.com

3. 查看您的技术支持协议

这技术支持协议TSA（技术支持协议）概述了SIOS为其产品提供的支持。TSA有助于识别有关维护、升级等关键信息。产品支持TSA 还包含产品修复信息。此外，TSA 还提供有关 SIOS 全天候​​支持服务及其联系方式的重要信息。了解 TSA 有助于确保您不会孤立无援，而是得到 SIOS 团队的支持。了解 TSA 还有助于您明确哪些服务包含在 TSA 的服务范围内，哪些服务不包含在内，从而避免在持续部署和维护过程中出现意外情况。

4. 接受 SIOS 管理员培训

如果您需要立即进行过渡，可能没有之前的管理员可以为您或您的新团队成员提供培训。请不要担心。SIOS 提供便捷的在线培训。该培训全面概述了 LifeKeeper for Linux 产品以及管理员所需的角色和操作。如果您的客户代表已记录在操作手册中，请直接联系他们以获取更多信息。否则，请联系我们。sales@us.sios.com或者support@us.sios.com寻求帮助。

5. 创建演示或测试集群

掌握了管理员培训后，您可以部署一个测试环境，在其中练习并磨练您的技能和理解，而不会直接危及公司的数据或应用程序。创建演示或测试集群帮助您和您的未来团队了解产品基础知识并熟悉用户界面。

此外，如果您的团队继承了运行手册，那么根据该手册构建自己的集群有助于您验证和更新这些手册，以便日后使用。如果可能，请尽可能模拟生产集群中受保护的应用程序和数据。理想情况下，您的团队构建的测试集群应尽可能与生产系统相似。这有助于您的团队在安全环境中了解依赖关系、行为和操作，然后再在生产环境中执行命令。请务必完成以下几个关键练习：

1. 手动切换
2. 服务器故障转移
3. 应用程序恢复
4. 维护操作

6. 安排集群健康检查

一个集群健康检查全面验证 SIOS LifeKeeper for Linux 环境。您可以将其视为对高可用性集群的多点检查。SIOS 专家团队将对系统日志、系统设置、运行手册、LifeKeeper 操作以及其他文档进行详细审查和验证，以确保 LifeKeeper 环境（包括应用程序恢复工具包）配置正确且运行状态最佳。健康检查报告将提供改进运行、降低潜在风险以及增强产品认知度的建议。

7. 利用 SIOS 支持和专业服务

《天龙特攻队》讲述的是一个团队的故事，而不仅仅是某个人执行一项关键任务。你最喜欢的乐队也不仅仅是主唱、鼓手或吉他手。他们是一群志同道合的专业人士，致力于成就伟业，创作美妙的音乐，避免让粉丝失望，并享受场场爆满的演出带来的喜悦。卡洛斯的成功离不开驯马师、美容师、教练、训练员、遛狗员、兽医以及众多专家和经纪人的共同努力。他们的成功是团队合作的成果，你的成功也是如此。充分利用你的SIOS支持团队。support@us.sios.com或通过支持门户网站support.us.sios.com获取宝贵的见解和信息。

SIOS 支持门户包含数百篇实用知识库文章 (KBA)，提供最新软件，并随时准备帮助工程师指导您走向成功。请联系 SIOS 支持团队，确保您拥有支持门户的登录权限，并能有效管理您的集群。支持团队还可以帮助您访问一系列 SIOS 资源。专业服务提供的服务包括更高级的培训、额外的健康检查和验证、新集群安装协助，或为您的第一次或任何未来的维护或上线窗口提供备用工程服务。

8. 与SIOS保持联系

接管新集群后，成功的秘诀在于与 SIOS 保持密切联系。与您的客户代表建立定期沟通机制。这种沟通渠道能让您及时了解新的选项和机遇，提前掌握许可证续期信息，并了解如何添加新集群以扩展对更多应用程序和服务的保护。

通过新闻简报和电子邮件推送与 SIOS 支持团队保持联系。电子邮件推送会提供有关任何可能影响您软件的新功能、版本发布或重要更新的最新信息。如果您需要进一步了解根本原因分析 (RCA) 或遇到需要其他专业人员检查的问题，请通过支持邮箱或支持门户提交工单。

接管 SIOS LifeKeeper for Linux 集群并不一定意味着要感到不知所措。申请演示了解 SIOS 如何帮助您保护关键应用程序、降低停机风险并自信地管理高可用性。

作者：卡修斯·鲁，SIOS Technology Corp.客户体验副总裁

经许可转载SIOS

 

消除单点故障

在企业IT领域，“单点故障”（SPOF）这个词足以让任何系统管理员夜不能寐。SPOF指的是基础设施中的任何组件——无论是服务器、网络交换机还是存储阵列——一旦发生故障，就会导致整个系统瘫痪。随着企业对系统安全的需求日益增长，这种担忧也愈发强烈。99.99%（或更高）正常运行时间识别和消除这些漏洞已不再是可选项，而是一项至关重要的要求。

如果您希望使您的基础架构万无一失，可以将高可用性 (HA) 与数据复制提供强大的企业级解决方案，消除单点故障，确保持续运行。

利用聚类消除单点故障的强大能力

高可用性的核心在于集群概念。集群是由一组独立的服务器（节点）组成，这些服务器（节点）配置为协同工作，以提供高度可靠的服务。这些服务可以是任何内容，从自定义应用程序到文件共享。

在典型的HA集群中，一个节点负责运行服务，而一个或多个节点则处于备用状态。集群管理软件（例如SIOS LifeKeeper）会持续监控活动节点的运行状况，以确保其能够正常运行服务。

如果在主节点上检测到严重故障，集群软件它会自动协调故障转移，将应用程序服务、IP 地址、存储和依赖项转移到运行正常的备用节点。通过自动化此过程，单个服务器不再是单点故障，从而确保服务连续性，并将中断降至最低。

消除SAN单点故障

传统集群通常依赖存储区域网络 (SAN) 来提供跨节点的数据共享访问。然而，这种设计存在一个关键的漏洞：SAN 会成为单点故障。如果共享存储阵列发生故障，即使各个节点仍然正常运行，整个集群也会瘫痪。

为了消除共享存储的单点故障，管理员利用数据复制来创建“无SAN”集群。每个节点不再依赖SAN，而是依靠其自身的本地附加存储。诸如此类的软件SIOS 数据保管器它位于操作系统级别，并执行从活动节点存储到备用节点存储的连续块级复制。

由于数据会实时不断复制和镜像，备用节点始终准备好使用其本地存储上的最新数据接管工作。

多条通信路径和法定人数/见证人解决方案

为了确保集群安全运行，节点之间必须保持持续通信以验证彼此的状态。它们通过交换“心跳”来实现这一点——心跳是频繁发送的小型数据包，用于指示节点是否存活且健康。

如果备用节点停止接收心跳信号，它可能会认为主节点已失效，并尝试使应用程序上线。如果主节点实际上仍在运行，最终会导致两个节点同时尝试写入数据——这种情况被称为“双节点同时写入”。裂脑。“为避免这种情况，您应该始终为集群配置仲裁或见证解决方案，该方案可作为决胜机制，以确定哪个节点应该安全地拥有活动工作负载。

此外，为防止网络基础设施出现单点故障，弹性集群架构需要多条通信路径。通过确保节点间存在多种不同的通信方式，可以保证单个网络交换机故障或电缆断裂不会导致集群逻辑中断。

利用 SIOS 系统地查找并消除单点故障

构建真正高可用的环境意味着要从最坏情况的角度审视您的架构。通过将 SIOS LifeKeeper 的智能应用监控与 SIOS DataKeeper 强大的无 SAN 复制功能相结合，您可以系统地查找并消除单点故障。

作者Trey Isaac，SIOS 高级产品支持工程师

经许可转载SIOS

LifeKeeper 通用应用程序，用于高可用性和灾难恢复

保护业务关键型应用程序的成功关键

高可用性和灾难恢复必须涵盖广泛的应用场景。应用场景的数量与组织的数量一样多，远远超出任何单一解决方案的能力范围。高可用性和灾难恢复该解决方案旨在为各种场景提供开箱即用的支持。虽然许多常见应用程序都有丰富的可用高可用性和灾难恢复解决方案，但更具体的用例会限制可用于保护业务关键型应用程序的方案选择。

当然，LifeKeeper 无法开箱即用地涵盖所有用例。然而，LifeKeeper 提供了一个通用且灵活的框架，可以适应各种用例，从而弥补这一不足。虽然功能强大，但对于外行来说，这个框架可能显得复杂。本博客旨在帮助您在为特定用例构思通用应用程序恢复工具包时获得一些帮助。

相关博客和背景阅读推荐

本博客假定读者已熟悉 LifeKeeper 资源层级框架和 LifeKeeper 集群。如需了解这些主题的背景知识，请参阅下方列出的博客。此外，本博客还基于之前一篇关于如何利用 LifeKeeper 中的“快速服务保护应用程序恢复工具包”（QSP ARK）来弥合潜在用例与支持的保护机制之间差距的博客（链接如下）。

• Linux集群/Windows 集群（本文由SIOS全球销售与市场营销副总裁霍格兰女士及SIOS市场营销团队撰写）

• 应用智能与高可用性（本文由SIOS高级软件工程师Hendricks-Sinke女士撰写）
• 资源行动和背景通用应用程序恢复工具包（本文由高级技术推广专家伯明翰先生撰写）
• 在 GenApp 和 QSP 之间进行选择：为您的关键应用程序量身定制高可用性（本文由 SIOS 高级软件工程师 Hendricks-Sinke 女士撰写）。

然而，本博客将探讨当 QSP ARK 无法满足特定应用程序或用例的高可用性和灾难恢复需求时可用的选项。

应用概念化和方法定义

询问有关应用程序健康状况的最细微的问题

系统管理和软件工程都是非常注重细节的领域。一个问题背后可能包含诸多因素，因此很难找到一个简单直接的答案。在日常对话中，这很容易理解。但在代码中，复杂的答案却难以实现。提出“最小问题”的做法，就是将问题聚焦到尽可能小的层面，同时确保答案符合明确的标准。

“应用程序是否正在运行？”这是一个“大”问题，可能需要详细的回答。应用程序确实在运行，但没有响应。应用程序确实在运行，但它运行在另一个系统上，而不是你正在讨论的这个系统上。答案的标准很模糊，而且答案本身也很微妙——开发人员通常都不愿意处理这种细节。

“应用程序进程是否正在运行？应用程序是否正在积极响应查询？”

虽然表述起来更冗长，但这却是一个更小的问题。它清晰地定义了答案为“是”或“否”的条件。尽管这一改变有所改进，但它还不是“最小”的问题。之前的问题同样陷入了“X 和 Y 是否都为真？”的陷阱。“是”或“否”的答案无法提供足够的细节来独立判断 X 和 Y 的真假。最小的问题需要具体性；它必须能够全面洞察整体中最小元素的状态。“应用程序的进程是否在目标系统上运行？”这是一个小问题——在本例中，这就是最小的问题。请记住，可能存在多个“最小”的问题——在本例中，“应用程序是否响应查询”也符合条件。

虽然问题几乎可以无限细分，但还是存在一个限度。“最小的问题？”这句话的含义是“提出一个能够提供有用/可操作信息的最小问题”。问“我是否在去费城的火车上？”就足够了；进一步问“我是否在去费城的火车上，费城是哪个方向？”可以提供更多信息——但这并不能提供可操作的信息。我无法改变火车的行驶方向。我只能从“我是否在去费城的火车上？”这个问题的答案中判断是否需要打电话通知老板我会迟到。

虽然在这个例子中这一点很明显，但在开发通用应用程序时就不那么显而易见了。在保护通用应用程序的整个过程中，仍然需要着眼于全局。这和其他任何事情一样，都是一项技能——通过实践和协作，就能判断出哪些问题是最根本的问题，哪些细微之处不再能提供更多有用的信息。

通用应用程序恢复工具包的构建基础是将宽泛的问题分解为针对各个组成部分的更小、更具体、更有针对性的问题。每个“大问题”都可以通过对其中涉及的各个组成部分的解答综合起来得到解答。

一旦将问题分解成最小的组成部分，需要传递的信息就会变得清晰得多。了解了所需信息后，开发通用应用程序恢复工具包的剩余工作就变成了如何从现有信息中提取所需信息。必须利用已有的信息进行工作。

使用应用程序 API 和 LifeKeeper API

应用程序通常会提供图形用户界面 (GUI) 来显示信息或应用程序发生的更改。虽然这对于人为操作来说非常方便，但当管理工作由应用程序执行时，这种方式就显得不太实用。GUI 是供人使用的，而应用程序（为了避免大量的编程工作和不必要的复杂性）并不具备像人一样与另一个应用程序的 GUI 进行交互的能力。对于 LifeKeeper 和通用应用程序资源而言，通用应用程序恢复工具包的操作脚本与受保护的应用程序之间的信息交换必须通过应用程序编程接口 (API) 来完成。

LifeKeeper 提供自己的 API，用于与 LifeKeeper 本身、其层级结构以及层级结构中的资源进行交互。对于 LifeKeeper 的 API，产品内置的命令行实用程序在通用应用程序中最易于使用。一般建议仅使用 LifeKeeper 产品文档中概述的命令行实用程序（Linux 命令文档/Windows 命令文档应该使用这些命令。即使有了这项建议，使用这些命令时也应谨慎细致，以确保不会产生意外后果。

当然，LifeKeeper并非通用应用程序保护的唯一要素。受保护的应用程序还需要提供API，以便操作脚本能够利用该API实现预期结果。开发通用应用程序恢复工具包确实需要了解受保护应用程序的API，以及如何在构成该工具包的操作脚本中使用该API。

在恢复脚本中使用返回码和输出流

无论是 LifeKeeper 的 API 还是受保护的应用程序，信息主要以两种方式输出：

• 返回代码
• 输出流（有时称为“STDOUT/STDERR 输出”或简称“终端输出”）

返回码如何帮助判断成功或失败

从广义上讲，返回码提供了一种快速判断实用程序是否成功的方法。通常（在 shell 环境中），返回码 0 表示成功，而非零返回码表示失败。

根据应用场景的不同，返回码的具体值可以提供更多关于所遇到错误的信息。通常，只需检查返回码即可推断通过应用 API 执行的操作的结果。

在一些更复杂的情况下，返回码可能仅仅用于告知程序在调用应用程序 API 后应采取何种操作。当处理与底层元素状态相关的实用程序时，返回码尤其有用。

输出流如何提供更详细的应用程序信息

输出流虽然在程序中使用起来比较复杂，但有时对于信息交换或验证结果来说是必不可少的。例如，如果运行一个实用程序来获取系统主机名，仅凭返回码无法确定主机名是什么，除非该实用程序成功获取了主机名。在某些情况下，即使 API 实用程序已获取到请求的信息，它也可能返回成功返回码，但该信息的有效性仍需根据具体情况进行评估。

无论使用返回码还是输出流，开发通用应用程序都需要利用现有信息。在思考如何实现资源操作（下一节将详细介绍）或确定应用程序或 LifeKeeper 资源的相关信息时，请尝试从返回码和输出流的角度思考，而不是从图形用户界面 (GUI) 的角度思考。想象一下通过电话传递信息会很有帮助。也就是说，当实用程序的输入和输出能够准确地作为输入或输出进行报告时，信息传递、操作定义和场景处理才能达到最佳效果。

构建通用应用程序保护的基础

本节主要侧重于策略的概念性阐述。这些策略为思考应用程序奠定了基础，其核心在于如何通过对应用程序提出的问题和采取的操作的响应来进行分析。接下来，我们将更具体地探讨 LifeKeeper 以及通用应用程序恢复工具包的创建过程。同时，这些策略与其他技能一样，需要通过实践来提升。无论是在技术交流、编写流程文档，还是其他任何工作中，练习这些概念化策略不仅能带来短期益处，更能带来长期的益处。

需要帮助保护不符合标准高可用性模型的关键业务应用程序吗？SIOS 可以帮助您评估环境并确定合适的 LifeKeeper 方法。申请演示今天。

作者：Philip Merry，SIOS Technology Corp. 的 L3 支持工程师

经许可转载SIOS