SIOS SANless clusters High-availability Machine Learning monitoring
地方政府的运作依赖于始终可用的信息技术系统——从法院和税务数据库到911调度中心和学校平台。一旦这些系统出现故障，其影响立竿见影且波及范围广泛，会波及公共安全、法律程序、工资发放以及社区信任。许多机构都面临着基础设施老化、预算紧张以及小型信息技术团队管理复杂混合环境等诸多挑战。
SIOS 通过高可用性 (HA) 和灾难恢复 (DR) 解决方案帮助解决这些挑战，防止停机、保护关键数据并保持基本公共服务的运行，而无需进行重大的基础设施变更或深厚的 HA 专业知识。
经许可转载SIOS
采用合适的高可用性方案，确保您的关键业务 Linux 应用程序持续稳定运行。本白皮书将 SLES HAE 和 RHEL HA 中的开源高可用性框架 Pacemaker 与 SIOS LifeKeeper for Linux（一款功能齐全的商业高可用性和灾难恢复平台）进行比较。
了解架构、部署、管理和长期可靠性方面的关键差异如何影响实际结果。无论您是经验丰富的 Linux 高可用性专家，还是需要更简单、更可预测的解决方案，本指南都能帮助您选择最合适的方案。
下载该文档，使您的 Linux 高可用性策略与您的技能、基础设施和可用性要求相匹配。
经许可转载SIOS
最近，我读了一本关于数学史的书（当然，大家都会读）。这本书主要讲述了古巴比伦和埃及的抄写员早期的数学发展和实践，以及他们如何将数学知识过渡到我们熟知的古希腊数学家，比如毕达哥拉斯和阿基米德。探索人类如何学习推理和解释周围的世界总是令人着迷。在阅读的过程中，我注意到许多行为和方法，即使是对简单的算术都一窍不通的人，也运用了这些方法。我认为这些方法同样适用于商业和人际关系！
我从他们处理一些复杂的除法和平方根运算的方法中汲取了灵感。他们会用一个稍大一些、更容易计算的数字和一个稍小一些的数字取平均值。用这种方法得到的结果与电子计算器显示的结果相比，往往惊人地准确。我甚至在学校学习平方根的时候也用过这种方法。例如，16 和 25 分别是 4 和 5 的完全平方数，所以 20 的平方根大约是 4.5（用计算器的话是 4.47）。
所以，如果你遇到需要处理棘手沟通的情况，尤其是在需要态度强硬或划定界限，却又不知如何把握分寸的时候，不妨试试这个近似方法：找出明显过于严格的最低限度，再找出明显过于宽松的上限，最后取一个介于两者之间的平均值。
只要你能为正确答案设定一些合理的“参考点”，就能比较接近你想要的答案。但如果参考点范围太广，反而会适得其反。
例如，假设你有一个大客户，他要求的服务远远超出了你们最初约定的范围。你可以把“超出范围”的界限设定为“无论如何，我都会满足他们的所有要求”，显然，这超出了他们的预期，因为这本来就是你们最初约定的内容。反之，你的“超出范围”的界限可能是“我不需要做任何超出合同明确规定的事情”。这在理论上似乎很有吸引力，有时也确实有效，但在这种情况下，它显得过于僵化，可能会损害双方的关系。我们需要更精确地设定界限。
那么，让我们从光谱的低端开始。或许你可以先列出你绝对会做并且已经同意完成的任务，然后再考虑他们提出的其他要求。一旦这些任务确定下来，无需再做任何考虑，就审视一下他们提出的其他要求，判断哪些完全不合理或者目前无法实现；这些要求就属于你做得过头了，应该从执行列表中排除。
现在，对于那些仍在考虑范围内的项目（这些项目并非明显属于“必须做”或“绝对不能做”的范畴），您已经处于近似区域。这样一来，你无需在所有事项中纠结该如何处理，而是可以缩小范围，更加精准地确定问题所在。把这些事项放在一起，直到你感觉自己已经掌握了在这种情况下应该采取的合适做法，然后再和你的伴侣讨论。此外，你甚至可能还有一些协商的空间！
现在我们已经看到了众多方法中的一种，你可以将这些源自古代、看似矛盾却又不够精确的数学度量方法，运用到你自己的挑战中！毕竟，在那个时代，数学所要解决的问题和挑战更多地根植于文明的日常需求，而不是登月或化学合成等宏大事业。重要的不是数学的起源，而是你如何运用它进行思考。提供卓越的客户体验。
作者：Matthew Pollard，SIOS客户体验软件工程师
经许可转载SIOS
在《企业时报》文章SIOS 合作伙伴联盟总监 Harry Aujla 探讨了为何灾难恢复 (DR) 在保护 SAP 环境和确保业务连续性方面应与高可用性 (HA) 同等重要。他阐明了 HA 和 DR 之间的区别，强调 HA 旨在确保系统在局部故障期间持续运行，而 DR 则侧重于在网络攻击或自然灾害等重大事件发生后恢复业务运营。
本文概述了灾难恢复投入不足所带来的业务、财务和监管风险，并引导读者了解两种核心恢复模型：站点级恢复和应用级恢复，重点介绍了每种模型的优势、权衡取舍和成本考量。Aujla 总结道，SAP 灾难恢复没有一成不变的模式，他敦促各组织根据业务优先级、服务级别要求和停机容忍度来制定策略，从而构建一个具有弹性和实用性的恢复计划。
经许可转载SIOS
当设计驱动创造时，成果便易于沟通。以设计为先导的理念能够创造出便于个人有效培训的解决方案。运用设计原则来传达目标，可以带来易于维护和改进的解决方案。当然，当解决方案基于工具构建时，工具的设计使用方式必须与它所支持的解决方案的设计结合起来考虑。
所选工具会将它们的设计假设强加于使用它们的项目中。正如之前的相关博客文章所述设计理念和目标一致是创建易于理解的解决方案的第一步。当然，项目中使用的工具可能包含与项目设计理念格格不入的模式。
初始设计与所用工具之间的冲突会造成复杂性，并降低解决方案的有效性。因此，必须选择合适的工具，使其使用与项目设计保持一致。当工具与设计协调一致时，复杂性就会降低。在高可用性和灾难恢复的背景下，设计与所用工具协调一致的影响尤为显著。
高可用性和灾难恢复设计通常预设了复杂性。IT基础设施设计模式为了满足高可用性和灾难恢复固有的高标准，各个基础设施组件越来越需要尝试在各自的范围内实施相应的模式。
各个组成部分共同努力解决以下问题：高可用性和灾后恢复就其作用而言，由于组件采用不同的设计原则来解决高可用性和灾难恢复问题，环境必然会变得臃肿。
工具不断发展，并可能形成相互竞争的设计原则，然而，环境需要的是具有凝聚力的设计。随着原本互不相关的工具开始相互干扰，复杂性也渗透到基础设施中。随着IT系统在用途和可用性标准方面的不断提升，遵循凝聚力设计并实现互补工具的基础设施的重要性也日益凸显。技术进步为实现高可用性和灾难恢复提供了多种策略，IT基础设施也在不断发展，以适应针对其他用例量身定制的设计模式。只需看看……常见的云设计模式微软在其文档中发布了这些模式。每种模式的适用性显而易见，但模式之间也可能存在冲突。模式重叠难以处理，这会使IT基础设施的设计过程变得复杂。基础设施通常需要采用多种设计模式，因此，越来越需要那些“互不干扰”的模式。
作者：Philip Merry – SIOS 软件工程师
经许可转载SIOS