SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • 产品
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • 新闻与活动
  • 服务器集群简单化
  • 成功案例
  • 联系我们
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

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

7月 12, 2026 by Jason Aw Leave a Comment

Observation and Calculation Applying Experience to Better Business Decisions

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

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

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

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

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

利用经验改进未来决策

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

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

观察与计算的循环

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

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

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

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

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

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

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

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

这些是你的计算结果。

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

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

作者:马修·波拉德

经许可转载SIOS

Filed Under: 服务器集群简单化

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

7月 7, 2026 by Jason Aw Leave a Comment

Why High Availability and Disaster Recovery Are Now Business Priorities

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

高可用性和灾后恢复这些职责曾经主要被视为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

Filed Under: 服务器集群简单化

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

7月 3, 2026 by Jason Aw Leave a Comment

Disaster Recovery Incident Response The Discipline of Not Reacting Impulsively

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

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

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

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

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

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

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

观察与假设的区别

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

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

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

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

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

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

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

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

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

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

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

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

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

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

灾后恢复中的纪律

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

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

作者:艾丹·麦克伦(助理产品支持专员)

经许可转载SIOS

Filed Under: 服务器集群简单化

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

6月 27, 2026 by Jason Aw Leave a Comment

High Availability and Disaster Recovery Everywhere From General Concepts to Generating Solutions

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

相关博客/背景阅读推荐

本博客假定读者已熟悉 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

Filed Under: 服务器集群简单化

接管 Linux 集群的 SIOS LifeKeeper

6月 21, 2026 by Jason Aw Leave a Comment

接管 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. 查找并查看现有运行手册

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

  1. 找到您的 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

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

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

  1. 接受 SIOS 管理员培训

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

  1. 创建演示或测试集群

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

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

  1. 手动切换
  2. 服务器故障转移
  3. 应用程序恢复
  4. 维护操作
  1. 安排集群健康检查

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

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

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

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

  1. 与SIOS保持联系

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

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

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

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

经许可转载SIOS

 

Filed Under: 服务器集群简单化

  • « Previous Page
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • …
  • 115
  • Next Page »

最近的帖子

  • 在 AWS 上设置 Nginx 负载均衡器
  • 能力越大,维护越高效:集群维护最佳实践
  • 人工智能发展迅速,关键应用仍需保持运行。
  • 什么是高可用性(HA)?
  • 如何在周五晚上的系统崩溃中幸存下来:从简陋的裸机到无缝的数据复制

最热门的帖子

加入我们的邮件列表

Copyright © 2026 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in