补丁管理

补丁管理

补丁管理解决方案可帮助 IT 团队在无需计划内停机的情况下应用更新、测试补丁并维护安全性。本视频将介绍 SIOS DataKeeper 和 LifeKeeper 如何通过高可用性集群、备用节点更新和自动故障转移实现近乎零停机的补丁管理，从而帮助组织保持安全、合规和不间断运行。

经许可转载SIOS

观察与计算：运用经验做出更佳的商业决策

观察与计算：运用经验做出更佳的商业决策

在本系列第一部分我们探讨了在没有完美答案的情况下，近似值如何帮助指导商业决策。本文在此基础上，进一步探讨了观察和经验如何随着时间的推移塑造更佳的判断力，从而帮助专业人士在未来的情境中做出更明智的决策。

为什么观察对于做出更好的决策至关重要

古代数学家从周围世界汲取灵感进行实践和研究的方式值得我们学习。这也不难理解，因为在当时，数学的驱动力更多地在于解决日常生活中实际问题的难题：如何简洁地表示大量数据、如何平均分割不规则形状的土地、如何计算贷款利息等等。这些问题的答案具有许多更广泛的理论意义，但它们都源于对现实世界的观察，并指导了未来的实践。

你不可能总是能凭空捏造或回忆起某种完美的公式或规律来预测或解释一切。尤其是在你没有两千年数学发展和严谨性作为支撑的情况下。在当今时代，我们往往对轶事发现嗤之以鼻，在很多情况下（数学、科学、医学领域），这的确如此。但我们现在讨论的并非这些！观察是一种非常强大的工具，或许在人际关系中是最强大的工具。这既包括公司内部的关系，也包括与用户、客户或合作伙伴等外部关系。

利用经验改进未来决策

然而，观察最大的问题在于它本质上是经验性的。你不可能在事情发生之前就进行观察，而有时等到事情真正发生后再去思考该怎么做就为时已晚了。

这时，主动的预判就显得尤为重要。你可以运用以往类似情况的经验，对即将发生的事情做出预期，并提前做好准备，以应对局面，引导事态朝着你期望的方向发展。这虽然比不上勾股定理，但在社交和商业关系中，它仍然是一种非常精于算计的方法。

观察与计算的循环

两者构成一个循环。你观察某件事，从中学习，这种观察结果会影响你未来的判断，这些判断又能帮助你更好地应对未来的情况，如此循环往复。这就像杂耍一样。

将观察法应用于会议和商务关系

考虑到这一点，你可以开始思考如何将其应用到你的事业和人际关系中。你的观察结果来自哪里？观察的内容是什么？又记录在哪里？

这些观察结果很可能来源于您的会议和活动，因此它们会留在您的记忆中，理想情况下，也会记录在笔记或会议纪要中。因此，在整理笔记和会议纪要时，您应该考虑如何充分利用它们，将它们作为您在会议中观察和体验的档案。

您可能需要记录观察结果的重要项目包括：

• 定时
• 观察到的文化
• 口述历史
• 出席人员（及其职责）
• 提出的问题

然后，当你需要再次进行类似操作时，你可以回顾之前的观察结果，并开始提出诸如以下的问题：

• “下次我怎样才能做得更好？”
• “如果他们说的是<这样>，我该怎么办？”

这些是你的计算结果。

通过经验培养更好的商业判断力

最棒的是，尽管需要大量的思考、假设和计算，但你所探索的仍然是应对你即将经历的具体现实情境的方法。这让它更容易上手，也让你在开始运用这些经验时，能够轻易地看到何时以及如何从中获益。此外，当你意识到自己正在运用自古以来就被使用和完善的方法时，或许会感到些许安慰甚至自豪！就像古人一样，你将开创属于你自己的实践理论，而这完全基于你自身的经验和对周围世界的观察。

作者：马修·波拉德

经许可转载SIOS

为什么高可用性和灾难恢复现在是业务优先事项

为什么高可用性和灾难恢复现在是业务优先事项

高可用性和灾后恢复这些职责曾经主要被视为IT部门的职责。它们固然重要，但通常被视为幕后管理的科技保障措施。

这种观念正在改变。

在当今的数字经济中，正常运行时间与收入、生产力、客户体验和品牌信任度直接相关。关键系统一旦宕机，其影响远不止于IT部门。交易中断，员工无法使用关键工具，客户感到不满，组织的信心也会迅速下降。

高可用性 (HA) 和灾难恢复 (DR) 不再仅仅是技术上的勾选选项。它们是业务连续性、风险管理和长期韧性的重要组成部分。

要点总结

• 停机时间是企业面临的风险：高可用性和灾难恢复不再仅仅是 IT 任务；它们对收入、品牌信任和业务连续性至关重要。
• 网络韧性是必需的：由于勒索软件以备份为目标，现代灾难恢复需要物理隔离、不可更改的基础设施来保证彻底恢复。
• 复杂性需要自动化：现代混合云、多云和容器环境需要自动故障转移和人工智能驱动的监控来有效管理弹性。
• 主动检测至关重要：混沌工程等技术使 IT 团队能够在不中断生产工作负载的情况下验证恢复准备情况。
• 将韧性与业务影响相结合：恢复时间目标 (RTO) 和恢复点目标 (RPO)必须由具体的财务、运营和监管需求决定。

计算IT停机的真实成本

随着企业对数字化系统的依赖程度越来越高，系统宕机的成本也持续攀升。一次系统故障就可能造成经济损失、运营延误、合规性问题以及声誉损害。

对于医疗机构而言，系统宕机可能导致患者信息获取延迟或医疗服务中断；对于制造商而言，可能导致生产线停工；对于金融服务公司而言，可能导致交易中断并损害客户信心。即使是短暂的宕机也可能造成持久的影响。

公共系统故障往往能迅速引起关注。2024 年的 CrowdStrike 事件就展现了单一技术故障如何影响全球的航空公司、银行和医疗机构。但如今，企业面临着更加蓄意的威胁：定向网络攻击。勒索软件运营者现在会主动攻击备份存储库，阻止企业恢复系统。因此，灾难恢复正与网络安全融合。IT 领导者正将工作重心转移到网络弹性上，确保拥有物理隔离、不可篡改且无法加密的备份。这种方法使他们能够在不支付赎金的情况下恢复“已知干净”的环境。

云和混合 IT 复杂性如何影响灾难恢复

如今的 IT 环境比以往任何时候都更加分散和复杂。企业正在摆脱传统的虚拟机，将关键应用程序迁移到多云平台、混合环境以及 Kubernetes 等容器化基础设施上。每一层都会引入依赖关系，这些依赖关系必须被理解和保护。当一个现代云原生应用程序出现故障时，团队不能仅仅恢复服务器。他们必须恢复使应用程序运行的编排平台、云配置和基础设施即代码 (IaC)。

与此同时，IT团队需要在确保系统可用性的前提下，管理补丁、升级、配置变更、安全需求以及不断变化的业务需求。许多团队还面临资源有限或人员流动导致的知识缺口。

这种复杂性使得仅靠技术难以实现韧性。组织需要清晰的流程、训练有素的团队、完善的文档化程序以及能够简化跨环境可用性的工具。

强大的高可用性和灾难恢复策略有助于减轻这种负担。通过提高可见性、自动化恢复操作和简化管理，企业可以帮助 IT 团队更快、更自信地做出响应。

将高可用性和灾难恢复集成到日常 IT 运维中

高可用性和灾难恢复曾经被视为两个独立的领域。高可用性侧重于在局部故障期间保持系统运行，而灾难恢复则侧重于从更大规模的中断中恢复，例如数据中心宕机、区域性事件或自然灾害。

如今，各个组织需要更加统一的方法。

高可用性 (HA) 和灾难恢复 (DR) 应融入日常 IT 运维，包括例行维护、补丁更新、系统更新和配置变更。团队不应仅仅将这些活动视为可用性风险，而应利用它们来验证故障转移流程并确认恢复准备情况。

定期测试至关重要。每年仅审查一两次的恢复计划可能无法反映当前的基础设施、应用程序依赖关系或人员配置情况。现代高可用性和灾难恢复方法能够实现更频繁的测试，而且通常不会中断生产工作负载。

这使得韧性从被动应对转变为主动预防。

在失败发生之前进行测试

任何组织最终都会面临中断。故障可能源于硬件问题、软件漏洞、人为失误、网络安全事件、云服务中断或意外的外部事件。最重要的是组织能够以多快的速度和多有效的方式应对这些中断。

受控的韧性测试，包括混沌工程等实践，会有所帮助。

混沌工程是指在系统中引入可控故障，以了解系统在压力下的响应。其目标是在系统出现真正故障之前发现并解决其弱点。这些测试有助于团队识别隐藏的依赖关系、改进恢复流程，并在事件发生时明确各方的角色。

这个概念类似于应急演练。在可控条件下进行演练的团队，在真正发生突发事件时能够更好地应对。

借助合适的工具，IT 团队无需将生产系统离线即可验证配置、确认故障转移就绪情况并培训员工。这既能增强运营信心，又能降低意外故障的风险。

自动化对于增强韧性至关重要

随着基础设施的扩展，人工恢复流程的管理难度越来越大。尤其是在高压突发事件中，人为响应可能速度缓慢、效果不稳定且容易出错。

自动化如今已成为高效高可用性 (HA) 和灾难恢复 (DR) 的关键，并且正在迅速发展成为人工智能驱动的弹性架构。自动化防御型人工智能可以监控系统，检测异常情况，并在系统彻底崩溃之前触发智能故障转移。预测分析有助于识别预示未来硬件故障或流量高峰的模式。当团队能够根据这些早期预警信号采取行动时，他们就可以在用户受到影响之前解决问题。

易用性也至关重要。高可用性 (HA) 和灾难恢复 (DR) 解决方案不应要求用户具备深厚的专业知识才能完成每一项任务。清晰的界面、简化的配置和强大的可视性有助于通用型 IT 团队更有效地管理系统弹性。这可以减轻运维负担并降低出错的概率。

业务优先事项应指导防护

并非所有应用程序都需要相同级别的保护。有些系统可以容忍短暂的延迟或有限的数据丢失，而另一些系统则必须保持可用状态，且中断时间必须尽可能短。

因此，高可用性和灾难恢复规划应该从业务影响入手。

组织需要明确哪些应用程序最为关键，停机会对运营造成哪些影响，以及需要达到何种恢复级别。恢复时间目标 (RTO) 和恢复点目标 (RPO) 应反映实际业务需求，而非假设。

这有助于避免两个常见问题：过度保护不太重要的工作负载和保护关键系统不足。

这种一致性不再仅仅是最佳实践，在许多情况下，它已成为一项法律要求。各国政府和监管机构正将运营韧性转化为一项严格的强制性规定。例如，欧洲的《数字运营韧性法案》（DORA）以及美国证券交易委员会（SEC）更为严格的信息披露规则，都迫使董事会不仅要记录在案，更要证明其恢复能力。

当高可用性 (HA) 和灾难恢复 (DR) 策略与业务优先级保持一致时，领导者可以更容易地向审计人员证明合规性，并就基础设施投资做出更明智的决策。当韧性与业务成果直接挂钩时，就更容易证明其合理性。

高管层的参与也至关重要。可用性应与财务风险、合规性、客户体验和运营绩效一并讨论。当领导层将正常运行时间视为共同责任时，韧性就会成为组织文化的一部分。

建立备灾文化

近年来，各种因素都可能造成干扰。软件故障、供应链问题、网络安全事件、人员变动、基础设施问题以及云服务中断都可能产生影响。业务连续性。

最具韧性的组织不仅仅是构建冗余系统，它们还会营造一种随时准备应对挑战的文化。

这意味着要制定恢复计划，定期进行测试，随着环境变化更新流程，并将系统弹性融入日常IT决策中。这也意味着要确保关键知识不会集中在某个人或团队手中。

做好准备不是一劳永逸的事情，而是一项持续不断的技能。

通过将高可用性和灾难恢复融入日常运营，组织可以降低不确定性，并提高即使面对意外事件也能提供可靠服务的能力。

结论

高可用性和灾难恢复已不再仅仅是技术上的勾选选项，它们现在是业务弹性的核心组成部分。

企业依赖关键应用程序来服务客户、创造收入、支持员工并维护信任。一旦这些应用程序不可用，企业就会立即感受到影响。

随着IT环境日益复杂，韧性需要人员、流程和技术的合理结合。将高可用性和灾难恢复纳入更广泛业务规划的组织，将更有能力应对中断、保障正常运行时间，并在变幻莫测的世界中保持信心。

目标不再仅仅是失败后的恢复，而是要让业务持续发展！

作者：Benjamin Roy，SIOS 市场专员

经许可转载SIOS

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

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

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

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

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

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

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

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

观察与假设的区别

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

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

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

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

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

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

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

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

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

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