SIOS SANless clusters High-availability Machine Learning monitoring
如今，应用程序和数据是大多数组织的命脉，每个人都期望完成工作所需的应用程序和数据能够随时可用。但要确保真正的应用程序和数据高可用性（HA）——我们指的是确保您至少在 99.99% 的时间内都能与他们互动——听起来可能代价高昂。但清晰地了解在何处应用 HA 以及如何经济高效地实施，绝对物超所值。事实上，它可以保护您免受高昂的成本和后果的影响。停机时间和灾难问题是，您如何确定如何最好地投资 HA 基础设施？
这篇网络计算文章SIOS 解决方案架构师会考虑哪些应用程序和数据值得投资 HA 基础设施，并建议组织可以采取经济有效的步骤来提高那些选择不使用完整 HA 基础设施保护的系统和数据存储的可用性。
想要与 SIOS 一起迈出下一步吗？立即申请演示了解 SIOS 如何帮助您保护关键工作负载、最大限度地减少停机时间并确保无缝高可用性。
作者：Beth Winkowski，公共关系部
经许可转载SIOS
关于制定计划、战略、设计和架构，有很多地方可以开始高可用集群当然，明智的建造者想要了解基本要求：两个节点或三个，恢复行动计划10分钟内或5分钟内，RPO接近零或绝对零。架构师还希望了解有多少节点，以及如何使硬件和网络具有弹性。您会在数据中心、云端还是两者兼而有之？除了了解底层硬件的架构之外，需求收集和设计还能帮助您了解关键应用程序、高可用性（HA）需要遵循的软件、流程和治理程序，以及报告、监控和警报分发所需的额外仪表板和集成。所有团队成员还需要了解恢复和故障转移当然是编排。
但在高可用性部署中，有一件事经常被忽视，那就是公司历史。当然，如果您打算将企业环境委托给监控、警报、恢复和故障转移编排解决方案，您当然需要了解他们是谁、他们做什么以及他们在这方面做得好多久了。这是一家位于怀俄明州布福德的新创业公司，还是一家仅在美国运营的公司，又或者是一家恰好拥有闲置的高可用性产品的跨国公司，只有在完成交易的其他部分时才会拿出来用？
当然，在构建架构时，您需要确保高可用性公司了解、理解并能很好地实现高可用性。但是，至关重要的是，在构建高可用性解决方案时，您的团队需要了解的最重要的历史并非来自他们的，而是您自己的。
作为客户体验副总裁，我曾与众多客户、团队、架构师和解决方案集成团队合作，在本地和异地部署高可用性解决方案。在许多这样的讨论中，部署完善的基础设施和HA架构是公司本身的历史。那么，为什么你的公司，或者你正在为之构建高可用性架构的公司，如此重要？公司历史应该通过五 (5) 种方式影响你的高可用性架构
公司历史将通过以下五 (5) 种方式影响您的 HA 架构：
贵公司在高可用性团队方面的历史如何？贵公司团队是否人员过多，角色和职责是否存在冲突或重叠？或者，贵公司团队规模过小，但业绩却超预期？根据贵公司的发展历史及其规模，您可能需要调整设计，以增加身份验证、更细粒度的权限和限制等。如果您的团队规模较小，那么增加开发和维护免费解决方案的负担可能会过重。如果您的团队规模较大，角色众多且职责重叠，并且有时间开发定制解决方案，请考虑商业解决方案是否更合适，以便释放这些资源用于新的开发、进一步的改进，甚至提高日常运营的效率。
贵公司的生命周期历史是怎样的？您的首席信息官/首席技术官是否会按照固定周期更新整个基础设施，还是更倾向于“没坏就别修”？如果您的公司长期在更换解决方案和供应商，那么您的架构就需要更加稳健，以应对组件和部件的更换。在这种情况下，您的高可用性架构还需要考虑在短时间内下线、生命周期终止以及潜在新解决方案的上线。应对这种高流动率的关键在于限制定制工作和硬依赖。
另一方面，如果您的高可用性解决方案将运行十年或更长时间，您需要确保供应商为基础设施中的关键组件提供维护和扩展支持。您的架构还需要充分权衡各种软件解决方案和互操作性在超过标准支持生命周期后可能遇到的挑战，以及如何降低这些风险。
作为客户体验副总裁，我最震惊的记忆之一是与一家公司合作构建高可用性解决方案。在上线后一周内，该团队的项目经理宣布他和他所在的整个团队已被解雇。上线工作将转移到一个新团队，这个团队既是公司新人，也是高可用性领域的新手。我后来了解到，Z公司的IT人员和高可用性环境的管理员实行“旋转门”政策。他们的大部分（如果不是全部）资源都是承包商。如果你的公司人员流动率很高，那么你的架构和设计必须包含运行手册，维护流程和程序也需要包含培训；正式的产品培训、程序测试、管理培训以及混乱场景。
旋转门并不是唯一需要注意的公司人员配置历史。独行侠是另一个需要了解和理解的关键场景。在 SIOS，我们的团队加入了一位困惑的项目经理，他正在寻找有关其企业系统的任何答案和信息，包括 SIOS 和其他系统。独行侠因不明原因离开了公司，在他们离开后，团队的新成员发现很多隐性知识没有记录在案，在他们能找到的任何文件中都没有说明。在设计和构建架构时，了解人员配置类型和人员配置历史可以帮助您正确地设计解决方案，并可能引导您的团队选择一种商业上可用且配备了服务的解决方案，以应对不幸的独行侠离职。
公司灾难和停机时间是高可用性解决方案设计人员需要充分理解的另一个历史节点。通常，公司灾难会作为需求融入未来的架构设计中。过去的灾难，包括其根本原因、风险缓解策略、检测、预防和报告建议，通常会被添加到初始需求中。然而，深入研究灾难历史可能会发现更多需要考虑的需求和因素。作为客户体验副总裁，我们的团队通过了解公司的灾难，收集了大量数据，从而为我们的几位客户打造了更好的体验。在一个案例中，无人值守的虚拟机维护是公司战略的重要组成部分，但也是许多公司可用性问题的根源。在与架构师合作的过程中，我们的服务团队不仅解决了应用程序可用性问题，还帮助设计团队考虑了备份和恢复、维护和升级以及在发生自动化故障时保持可用性的回滚策略。
作为客户体验副总裁，我们的团队与热衷于应用程序可用性的客户和合作伙伴紧密合作，遵守最严格的服务水平协议 (SLA)和服务级别目标。在我们与这些团队合作的过程中，他们的设计和架构规范反映了一种公司文化，即将可用性（架构、设计、硬件、网络、应用程序、集群软件、人员和流程）视为业务不可或缺的一部分。遗憾的是，并非所有公司都拥有这种公司文化。了解公司文化的历史无疑将影响您实施高可用性 (HA) 的方式，从而最大限度地发挥设计和架构的优势，无论是为了遵循公司文化，还是将其作为改进文化和业务成功的一种方法。
是的，数据中心或云提供商的公司历史很重要。如果您正在考虑将 Lou 用作数据中心，那么了解 Lou’s Low Cost Cloud, LLC（无意冒犯 Lou）的历史至关重要。该公司在 Lou 父母家中几乎没有空调的车库里运营，设备一直在严重损坏。是的，应用程序和高可用性 (HA) 供应商的公司历史也很重要。了解您的 ERP、数据库和前端应用程序提供商的历史，对于评估和降低风险、理解部署模式和方法，以及确保及时修复、更新、安全和支持成为您架构基石至关重要。但是，不要低估了解您公司历史以及关键故障如何影响您新的和正在进行的高可用性决策和基础架构的重要性。
准备好利用成熟的专业知识来加强您的 HA 架构了吗？申请演示今天看看 SIOS 如何帮助您设计和部署针对您公司的独特历史和未来需求构建的高可用性解决方案。
作者：Cassius Rhue，客户体验副总裁
经许可转载SIOS
DataKeeper 依赖于操作系统软件中的许多配置设置。因此，很多时候，当集群配置发生更改时，我们的客户并不能完全理解更改的影响。这反过来又会影响SIOS 数据管理员运行。提前了解这些依赖关系有助于升级或更改集群配置。DataKeeper 所依赖的关键操作系统功能之一是分页文件的位置。
操作系统分页文件是一个隐藏文件，当服务器的物理内存已满时，操作系统会使用它。分页文件充当额外的服务器内存，实际上驻留在服务器的驱动器上。即使物理内存不足，分页文件也能利用额外的内存，使服务器继续运行并保持系统性能。
默认情况下，操作系统页面文件位于 C:\ 或根驱动器。操作系统配置包含一个允许自动管理页面文件的选项。设置此选项后，操作系统可以在重新启动后自动将页面文件移动到系统中的任何磁盘。对于 DataKeeper，建议禁用页面文件的自动管理，以免将页面文件移动到 DataKeeper 可能使用的其他卷。操作系统不知道 DataKeeper 正在使用哪些卷，可能会意外地将页面文件移动到具有 DataKeeper 镜像的卷。如果集群中包含 DataKeeper，则页面文件需要位于未用于 DataKeeper 镜像的卷上（例如 C 盘）。
如果您的服务器上使用了 DataKeeper，那么页面文件的位置为什么很重要？页面文件的位置会影响 DataKeeper 的运行。如果页面文件位于当前作为镜像源的 DataKeeper 卷上，则一切似乎都运行正常。但是，当发生切换或故障转移时发生这种情况时，镜像的源将成为镜像的目标，并且由于目标卷上存在页面文件，DataKeeper 将无法锁定目标卷。如果 DataKeeper 无法锁定卷，则切换和故障转移将失败，从而影响高可用性。锁定镜像的目标是必需的，而卷上的页面文件将阻止 DataKeeper 锁定卷。DataKeeper v8.11.0 添加了一项新功能来帮助客户解决此问题。在 v8.11.0 中，DataKeeper 现在可以阻止在 DataKeeper 卷上创建页面文件。
DataKeeper 会特意锁定目标系统上的卷，以防止在目标系统上执行写入操作。为了使 DataKeeper 锁定目标卷，卷上不能存在操作系统页面文件。很多时候，系统在操作系统级别配置为“自动管理页面文件”，有时页面文件最终会被操作系统放置在 DataKeeper 卷上。为了解决这个问题，我们建议更改此操作系统设置。有关更多详细信息，请参阅产品文档。此外，我们建议您升级到 DataKeeper v8.11.0，以便您可以受益于这项 DataKeeper 的新功能，该功能可防止在 DataKeeper 镜像卷上创建页面文件。
想要与 SIOS 一起迈出下一步吗？立即申请演示，了解 SIOS 如何帮助您保护关键工作负载、最大限度地减少停机时间并确保无缝的高可用性。
作者：Sandi Hamilton，SIOS Technology Corp. 产品支持工程总监
经许可转载SIOS
在IT的几乎每个方面，沟通都是关键，而在数据复制方面，沟通更是至关重要。对于DataKeeper来说，确保数据在集群中的节点之间保持同步高可用性集群首先要确保系统可以通过网络相互通信。
无论你是复制数据跨区域或跨数据中心，您的首要任务是在所有参与节点之间实现安全可靠的通信。这种通信的核心是 TCP/IP 协议。DataKeeper 使用一组预定义的 TCP 端口来建立和维护复制。
什么是 TCP 端口？为什么它们对于数据复制很重要？
TCP 端口是一个数字标识符，它充当网络协议的端点，用于将流量路由到系统上运行的特定应用程序。可以将它们想象成公寓楼的地址。您可以向公寓楼发送消息，但消息可能无法到达大厅。有了地址，您就可以确保消息到达住户。如果目标地址（端口）被阻止，数据就永远无法到达目的地。
在数据管理员这些端口是节点交换关键复制数据的指定路径。如果没有开放且路由正确的端口，节点将无法通信，从而导致复制失败或停滞。
SIOS DataKeeper 使用哪些端口？
为了建立复制并维持节点之间的通信，DataKeeper 需要打开以下 TCP 端口：
10000 = 卷 A
…
10025 = 卷 Z
例如，如果您正在复制卷 F，则需要确保节点之间的端口 10005 是开放的。
数据复制不工作时应检查什么
如果复制未启动或者反复断开连接，请考虑以下事项：
137, 138, 139, 445, 9999, 10000-10025
如果您的节点托管在云环境中，例如AWS，Azure， 或者地理控制协议，确保安全组或 NSG 也允许相关 IP 地址之间的上述端口。
顺利部署 SIOS DataKeeper 的最佳实践
除了启用 TCP 流量之外，还有其他一些网络最佳实践可以提升您的 DataKeeper 体验。为了确保 DataKeeper 的可靠复制，首先要验证所有节点是否能够一致地解析彼此的主机名。这可以通过 DNS 或 hosts 文件中的静态条目来实现。名称解析问题可能是静默故障的常见原因，应尽早解决。此外，请尽可能考虑为复制流量配置专用网络接口。将复制与生产流量分离不仅可以提高性能并降低延迟，还可以通过将数据传输与用户和应用程序活动隔离来增强安全性和可靠性。
确保端口连接可靠，实现 SIOS DataKeeper 复制总结
为了使 DataKeeper 可靠地运行，网络通信必须在定义的 TCP 端口集上不受限制。了解和配置这些端口（尤其是特定于卷的复制端口）对于避免停机和确保高可用性设置兑现其承诺至关重要。
花几分钟时间审核防火墙规则并确认连接，可以在复制突然停止时节省数小时的故障排除时间。与IT领域的所有事务一样，清晰的沟通（无论是人与人之间还是系统与系统之间）至关重要。
想要更进一步吗？不妨考虑一下集群等高可用性策略如何为您的环境提供更安全、无中断的补丁支持。立即申请演示了解 SIOS 如何帮助您保护关键工作负载、最大限度地减少停机时间并确保无缝修补。
作者：Tristan Allen，SIOS Technology Corp. 助理客户体验软件工程师
经许可转载SIOS
