SIOS SANless clusters High-availability Machine Learning monitoring
在本集中TFiR：我们来谈谈，主持人 Swapnil Bhartiya 接受采访戴夫·伯明翰SIOS Technology 的客户成功总监谈到了高可用性和弹性为何对企业至关重要。楼宇维护和安保系统伯明翰解释了这些系统与其他楼宇技术的区别，以及它们之间经常存在的交互方式，并阐述了不间断运行对于保障居住者安全和楼宇功能的重要性。对话探讨了组织如何平衡安全性和可访问性，人工智能、机器学习和物联网等新兴技术在提升可靠性方面的作用，以及通过冗余、监控和风险规划来确保系统可用性的最佳实践。
作者：Beth Winkowski，SIOS Technology Corp. 公共关系部
经许可转载SIOS
迄今为止，本系列文章探讨了技术设计与修辞之间的相似之处。技术方案的“修辞”，即传达意义和目的的策略，是通过设计模式和概念来呈现的。设计模式和概念作为概念基础而存在，其意义在实施过程中转化为可应用的形式。
如前所述，这种连续性和完整性概念基础确保解决方案始终保持符合维护、改进和长期可靠性标准的要求至关重要。外部影响解决方案设计的因素挑战旨在维护解决方案设计中提出的概念基础的目标。这些外部因素可能与既定原则相冲突，因此，解决方案中使用的工具、应用程序和平台必须经过慎重选择。
在本博客系列的第三部分也是最后一部分中，我们将探讨模块化和抽象化作为一种设定界限的手段，以确保范围广泛的项目能够继续从结构良好、论证合理的设计中获益。
在探讨模块化和抽象化这两种策略之前，首先需要理解为什么要实施它们。我们可以用一个类比来说明：演讲者为了说服听众接受自己的方案，首先需要阐述几个基本要点。这样，他们就能逐一提出并论证论点的各个支柱。
演讲者首先必须建立“A蕴含B”和“C蕴含D”的基础，在此基础上才能构建“B和D蕴含E”的论证。这种策略确保了“A蕴含B”的推理不会与“C蕴含D”这一独立论点相互干扰，从而避免削弱后者。这种策略之所以被广泛运用，是因为它允许演讲者论证的每个组成部分独立存在。即使“C蕴含D”的论证存在缺陷，也可以通过其他方式加以修正，而“A蕴含B”的论证仍然有效。
这种结构的原因与技术系统采用去中心化的原因相同——销售点系统的问题可以单独解决，而无需将修复工作扩展到数据库、API、网络架构等等。上述策略当然是指模块化和抽象的概念。
首先，谈到模块化，它指的是用自包含的组件构建系统。从修辞意义上讲，“A蕴含B”和“C蕴含D”这两个论证仅仅是推理模块，它们被组合成一个完整的论证。
更具体地说，模块化组件（例如前面例子中的销售点系统）允许在问题产生的模块内部完全解决问题。解决方案中的每个模块都像一个构建块，单个构建块中的问题无需拆卸整个解决方案即可解决。
与模块化密切相关的是“抽象”。抽象是指确保整体解决方案的设计独立于构成该整体解决方案的各个模块的设计，并且与这些模块的设计无关。
此外，抽象作为一种设计策略，其核心在于每个模块都是独立且与其他模块的设计无关的。当解决方案采用抽象元素时，这些元素可以被重用并应用于各种用例，从而在整个项目中加深理解。
当设计采用模块化组件时，需要划定边界。这些边界确保每个模块都能“互不干扰”。当组件被抽象化后，每个模块的内容就更容易理解。
反过来，这些边界构成了一种结构，通过这种结构可以理解设计；而边界内的抽象则为理解用例的基础提供了切入点。模块化和抽象所提供的结构，与修辞在构建理解目的的框架中所起的作用相呼应。
随着技术解决方案的不断开发以应对日益复杂的问题，对这些解决方案设计中稳固框架的需求也日益增长。网络架构通常是众多本身就十分复杂的解决方案的最终产物，它完美地诠释了日益复杂的问题以及对稳固设计框架日益增长的需求。此外，网络架构往往面临着持续增长的挑战，因为它必须整合为实现业务目标而不断扩展的庞大系统网络。
在此基础上，解决方案架构还必须采用以下解决方案：高可用性和/或灾难恢复这会造成设计冲突的发生，但可以通过模块化和抽象化的策略轻松缓解。
好处高可用性软件无需繁琐的设计和临时拼凑的解决方案，即可实现高可用性。SIOS LifeKeeper 就是一个符合设计规范的高可用性工具示例，其运行原理能够与使用环境无缝集成。
LifeKeeper 采用模块化设计，不会对受 LifeKeeper 保护的系统之外的系统提出任何要求。LifeKeeper 还有助于将基础设施组件抽象成易于管理的小单元——协同工作以确保可用性的系统被分组到一个“集群”中。
通过这种抽象，环境的逻辑依然清晰——理解一个集群的构成是理解所有集群的基础。设计的各个层级可以根据其用途进行理解；无需对不同实现方式的差异进行特殊标注和考量。由于各个集群独立于其他集群或外部解决方案组件运行，因此可以划定一个边界，将每一层级的设计元素包含在其中，从而避免与其他基础设施层级发生冲突。
就像任何软件或工具一样，SIOS 保护套件SIOS LifeKeeper 和/或 SIOS DataKeeper 会影响其使用环境的设计。虽然这些模式的引入源于 LifeKeeper 和 DataKeeper 的保护环境，但 SIOS LifeKeeper 和 SIOS DataKeeper 精心挑选了所使用的模式，以确保这些模式能够实现整个解决方案的抽象和模块化。由于 LifeKeeper 和 DataKeeper 实现了分层抽象，这些实用程序的引入有助于与 IT 基础架构集成，从而保持解决方案设计的一致性。
由于采用了特定的设计模式，由 SIOS Protection Suite（LifeKeeper 和/或 DataKeeper）保护的集群构成了一个抽象且模块化的元素，能够无缝集成到现有的设计和解决方案中。LifeKeeper 和 DataKeeper 的功能远不止简化单个系统或各个集群的管理；它们还与部署过程中遵循的原则相契合。
借助 SIOS Protection Suite，基础设施的创建变得更加简单高效。该套件提供了一种简便的方法来理解系统在设计中的作用，同时还提供了一种简便的方法来实施高可用性和灾难恢复。管理员可以将 LifeKeeper 和 DataKeeper 作为工具，在未来数年内更好地理解、操作和改进解决方案。
了解高可用性如何在不增加复杂性的情况下支持您的基础架构设计。立即申请演示！
作者：Philip Merry，SIOS 的客户体验软件工程师
经许可转载SIOS
对于管理现代应用程序的IT团队而言保持高可用性推出更新可能充满挑战。实现可靠性的关键在于将质量保证 (QA) 环境与生产环境分离。这看似微不足道，但对于发现潜在问题和增强维护工作的信心至关重要。
QA环境是生产环境的副本。它提供了一个沙箱，可以在其中对新功能、配置变更和补丁进行全面测试。除了功能测试之外，QA环境还支持流程验证、性能基准测试、负载测试和安全验证。
这些活动至关重要，可以在瓶颈、漏洞或集成问题有机会影响最终用户或损害您的环境之前，识别它们。对于分布式系统或云架构QA 环境可以帮助模拟网络延迟、数据库复制延迟以及其他操作边缘情况，这些情况如果不经过测试，可能会中断业务运营。
生产环境是最终用户依赖系统稳定运行的环境。任何计划外停机或故障都可能直接导致业务损失，从收入损失到声誉受损不等。
通过将生产环境与正在进行的开发和测试工作隔离，IT 团队可以确保运营稳定性。配置完善的生产环境应包括：冗余策略故障转移机制和监控工具在部署前已在质量保证环境中通过测试验证。
高可用性不仅仅意味着保持系统正常运行，它还包括使更新可预测。QA 环境可以支持结构化的部署流程，从而实现分阶段发布和蓝绿发布等多种策略。在 QA 环境中预先验证的回滚流程，能够帮助团队在出现意外问题时快速恢复。结构化的方法使更新可预测，并有助于维护客户信任。
拥有独立的质量保证 (QA) 和生产环境也有助于合规性、审计准备和跨团队协作。测试系统和生产系统之间清晰的界限有助于运维和开发团队高效协作。它还有助于为监控、故障排除和维护提供可重复的框架。灾难恢复计划。
质量保证 (QA) 和生产环境在确保系统平稳运行方面发挥着至关重要的作用。通过隔离环境、进行全面测试以及谨慎管理部署，IT 团队可以减少停机时间、保持高可用性，并实现无缝更新过渡。这些实践有助于确保系统在发展过程中保持可靠性和弹性。
准备好提升质量保证和生产环境的高可用性了吗？申请演示了解 SIOS 如何帮助团队自信地部署更新并保持关键系统运行。
作者：Tristan Allen，SIOS Technology公司客户体验软件工程师
經 SIOS 授權轉載
“关机重启。” 任何有过电脑故障排除经验的人都听过这条建议。它臭名昭著，是最常见的技术解决方案，而且似乎能让每个人都变成IT故障排除高手。问题在于，它从来都不是真正的解决方案；它只是碰巧能解决大多数问题而已。通过关机重启，我们能迅速恢复运行，但却永远无法真正找到问题的根源。
此外，在高可用性的世界中，“关闭它”可能会造成巨大的问题。即使是几分钟的……停机时间对于那些必须确保关键基础设施持续运行的公司来说，这可能是一个重大问题。正因如此，作为SIOS的技术支持人员，我们很少给出这条臭名昭著的技术建议，但我们确实有自己的一套应对方法。
许多致电SIOS寻求技术支持的人都遇到了以下问题：Windows Data Keeper如果遇到镜像问题，系统会提示运行“cleanupmirror”命令。在特定情况下，该命令可以快速解决重大问题。它实际上会彻底删除镜像配置及其所有残留数据，以便我们可以重新创建镜像，摆脱之前存在的所有问题。请注意，此命令不会删除任何数据，只会删除系统间的镜像复制。
该命令无需停机，但意味着在镜像完成重新同步之前，系统可用性会受到影响。这是我们在技术支持中常用的故障排除步骤之一，但就像“重启”一样，它有时会掩盖更严重的潜在问题，而且有时也可能矫枉过正。
今天，我想谈谈这样一个案例：运行 cleanupmirror 命令虽然帮助客户解决了燃眉之急，但差点让我们忽略了一个相当严重的问题，这个问题可能会影响到很多客户，不过这个问题其实有一个非常简单的解决方法。
支持团队加入时，客户已经排查故障相当长一段时间了，他们开始感到恐慌。他们正在进行最后的尝试。切换在进行迁移测试时，DataKeeper镜像开始出现问题。此时，他们的关键基础设施瘫痪，他们担心这会影响业务运营。情况十分危急，但幸运的是，我们的支持工程师表现出色。他们权衡了压力、时间紧迫和寻找有效解决方案的迫切需求，运行了久经考验的“cleanupmirror”命令，随后重建了镜像并使其恢复正常运行。他们帮助客户摆脱了困境，一切又恢复了正常。值得庆幸的是，他们还要求客户发送日志，以“确保万无一失”。
此案的日志有些令人困惑。日志显示：某个卷册已调整大小但客户声称他们在通话中没有进行任何调整大小的操作。有时客户会遗漏重要信息，所以我们一开始以为他们可能在通话中漏掉了这个细节，但这次调整大小的操作实在令人费解。大小的变化非常小，而且所有卷都在第一次切换时同时发生了变化。客户不可能在第一次切换时，一次性减少不到 1GB 的空间来调整其 TB 级大容量硬盘的大小，这显然不合逻辑，所以我们进行了更深入的调查。结果发现，目标硬盘的容量略大于源硬盘，而我们的产品在处理容量不匹配的硬盘时存在问题。
一旦我们弄清这一点，就意识到解决这个问题只需要继续镜像即可。这是一个常见、快捷且简单的操作，只需几秒钟就能彻底修复问题。无需耗时数天重新同步，即可恢复高可用性。此外，一旦我们发现这个问题，在下一个产品版本中实现修复也非常快捷方便。
原来，客户的迁移场景比较特殊，由于目标系统的大小无法完全匹配，他们不得不将目标系统的大小略微扩大一些。他们还有几个系统需要迁移，如果我们只停留在“清理镜像”阶段，他们每次都会遇到这个问题。由于我们找到了根本原因，因此能够为他们提供一个快速简便的临时解决方案，以及一个更快捷的预防措施，让他们在执行首次切换之前就能采取。我们还发布了解决方案，以便下一个遇到类似问题的客户能够在几分钟内解决。
那么，“关机重启”到底有什么大问题呢？它掩盖了问题的根本原因。这是否意味着你永远都不应该使用它呢？它仍然是最好的技术建议之一。很多时候，你根本不需要知道问题的根本原因，而关机重启就能帮你快速摆脱困境。
对于IT专业人员来说，重要的是，在无需紧急处理问题且有时间先进行调查的情况下，应该这样做。如果时间紧迫，则应该稍后查看日志，尝试找出问题所在。
所以，请随意开关机。做个几分钟就解决问题的魔术师，让所有人都好奇你是怎么做到的。但是……偶尔……也应该花点时间想想，你为什么要开关机……并考虑一下，有没有更简单的解决方法。
要了解更多关于 SIOS DataKeeper 和高可用性解决方案如何帮助您避免此类隐藏问题的信息，申请演示今天我们团队的发言。
作者：Carter Chandler，SIOS Technology公司客户体验助理、软件工程师
经许可转载SIOS
SIOS 合作伙伴关系在实现高可用性、云弹性和集成基础设施解决方案方面发挥关键作用。
在本期播客中Harry 和 Kelly 将带领听众深入了解 SIOS 的合作伙伴生态系统，从与微软、AWS 和谷歌云的云联盟，到与 Exabeam、Milestone 和 Cimcor 等战略性独立软件开发商 (ISV) 的卓有成效的合作。他们探讨了 SIOS 如何接纳和支持新合作伙伴，分享了多年来构建成功集成方案的经验教训，并重点介绍了合作伙伴驱动的创新未来的发展方向——包括人工智能、混合云和边缘计算领域的机遇。
播客最后提供了一些实用建议和成功案例，展示了强大的技术合作伙伴关系对业务的影响。
经许可转载SIOS