能力越大，维护越高效：集群维护最佳实践

在IT基础设施领域，正常运行时间至关重要。确保用户在线且功能正常是大多数现代企业赖以生存的基石。在宕机如同超级反派一般肆虐的时代，集群技术则成为了拯救企业于危难之中的英雄。然而，正如标题所言，“能力越大，责任越大”。正如虚构作品中的英雄必须控制自己的力量以避免滥用一样，集群（以及维护集群的工程师）也必须受到有效管理，才能确保在灾难来临时能够力挽狂澜。在本篇博客中，我们将探讨一些通用的最佳实践，帮助您的集群做好应对灾难的准备。就像主角一样，一切都始于培训和维护。

集群环境中的存储变更

集群是一种强大的工具；但强大的功能也带​​来了一些单系统配置无需考虑的限制。维护集群系统时，您必须执行比基本系统所需的额外验证。例如，通过云提供商控制台只需点击几下即可配置额外的存储空间；然而，在集群环境中，您不应操之过急。具有镜像数据的集群环境对存储的要求远比普通服务器严格。了解这一点以及如何使用集群存储是确保集群全天候保持满负荷运行的关键。有关正确存储流程的详细概述，请参阅此技术文档：

DataKeeper 卷大小调整

除了存储之外，您还应该让工程师了解集群的其他相关事项。理解集群和防病毒软件之间的相互作用是防止关键集群文件/进程被意外隔离的关键。妥善记录系统更新并确保集群节点保持一致，可以让当前和未来的工程师充分理解所有变更，并防止因节点不一致而导致的问题。

Windows 版 DataKeeper 的防病毒软件、恶意软件等排除项

网络变更和镜像端点

集群的另一个重要因素是网络。为了确保集群能够通信，网络必须正常运行，并且配置的地址必须保持一致。在单服务器环境中，网络基础设施的变更几乎不会产生影响，但在集群环境中，所有节点都必须通过专用网络路径保持通信，而更改这些路径需要更新集群配置。SIOS 提供了用于更新这些值的工具，但在进行任何更改之前，务必了解相关步骤。

点击这里了解更多关于更改镜像端点的信息。

总而言之，从标准的单服务器配置升级到“超级”集群并非一蹴而就，也并非无需人工干预。就像任何超级英雄一样，它需要适当的培训和维护才能发挥“超级”水平。在存储、网络、防病毒软件和其他系统变更方面，必须谨慎考虑，才能确保您的集群始终保持最佳状态，避免客户和业务因宕机而遭受损失。如需了解更多信息和培训，请随时查看。更多博客请访问我们的网站文档网站完成我们的在线培训或者联系support@us.sios.com如果您有兴趣与专门的 SIOS 工程师进行更全面的同步培训课程。

作者Connor Toohey，SIOS Technology 高级产品支持工程师

经许可转载SIOS

人工智能发展迅速，关键应用仍需保持运行。

人工智能正在改变企业服务客户、分析信息和完成工作的方式。机遇真实存在，企业探索这一机遇是理所应当的。但随着人工智能项目吸引更多关注和资源，高可用性和灾难恢复绝不能被忽视。

客户仍然期望应用程序在需要时能够正常运行。员工仍然需要访问运行日常运营的系统。一旦这些系统出现故障，即使是短暂的故障，也会导致工作停滞，并损害员工的信心。将人工智能引入企业并不会降低其对可靠基础设施的依赖。在许多情况下，它反而会增加需要保护的新依赖项。

过去的停电事件给我们敲响了警钟

过去的故障案例清楚地表明了这一点。在一次有据可查的事件中，Cloudflare Workers KV 服务使用的存储基础设施发生故障，导致多个 Cloudflare 产品中断超过两小时。受影响的服务包括访问和安全工具以及 Workers AI。一个底层依赖项的故障对众多服务都造成了影响。

同样，AWS北弗吉尼亚区域的一次重大服务中断始于DynamoDB DNS问题，随后影响了其他服务，包括EC2实例启动和部分网络负载均衡器。此次中断表明，即使应用程序自身的服务器运行正常，问题也可能通过其依赖的服务蔓延开来。

这些事件再次强调了理解应用程序依赖关系并做好应对各种故障准备的重要性。如果恢复环境依赖于同一个不可用的服务，企业可能仍然面临同样的问题。

保持沟通畅通

企业在规划人工智能投资时，也应该重新审视一些实际问题：

• 哪些应用程序是必不可少的？确定支持客户、员工和日常运营的系统。
• 企业能够承受多长时间的停机时间？根据业务影响设定明确的恢复目标。
• 每个应用程序都依赖于什么？包括数据库、存储、网络、身份验证和外部服务。
• 故障转移和恢复程序是否经过测试？确认应用程序能够在业务所需的时间内恢复服务。

这些问题既适用于现有应用程序，也适用于新型人工智能工作负载。高可用性有助于应用程序在某些故障情况下保持运行，而灾难恢复则帮助组织在发生更大规模的中断后恢复运营。随着环境的变化，两者都需要持续关注。

在可靠系统上构建创新

人工智能项目或许能带来更快的决策速度或更佳的客户体验，但这些优势取决于其背后系统的可用性。保障系统正常运行与创新同等重要，理应纳入规划和预算考量之中。

企业可以在推进人工智能发展的同时，继续投资于系统韧性建设。将高可用性和灾难恢复放在首位，有助于确保新功能和日常业务运营的可靠性。

作者：Ben Roy，SIOS 营销项目经理

经许可转载SIOS

什么是高可用性（HA）？

如今世界上充斥着各种各样的缩写词；有时，要记住它们的含义着实不易，尤其对于没有技术背景的普通用户而言更是如此。HA 这个缩写词已经存在了几十年。那么，用通俗易懂的语言来解释它的含义是什么呢？HA 代表高可用性（High Availability）。HA 指的是，公司赖以生存的计算机系统（公司和客户都依赖这些系统）在客户每天任何时间访问时都能正常运行。例如，您尝试通过手机或笔记本电脑上的应用程序访问您的银行账户，查看余额或进行电子存款。但您收到一条错误消息，提示系统无法连接，请稍后再试。您可能认为只有您遇到了这个错误，于是重启了笔记本电脑和手机。但您仍然收到同样的错误提示：“系统无法连接”。这意味着什么？这意味着银行的计算机系统似乎宕机了，您无法访问！您可能会疑惑——银行的计算机系统怎么会离线呢？如果企业未能为其运营系统实施高可用性 (HA) 解决方案，则可能会出现这种情况。

HA 的工作原理

那么，高可用性（HA）在实际应用中是如何运作的呢？让我们来详细了解一下。HA 可以通过运行在企业计算机上的软件或内置于企业计算机的硬件来实现。本文重点在于概括性地描述 HA 软件在企业计算机上提供的功能。HA 的作用是确保计算机始终保持运行状态，以便企业及其客户可以随时访问数据和信息。HA 如何保证计算机始终保持运行状态呢？HA 由几个关键组件构成。

• 计算机之间的监控– 在高可用性 (HA) 系统中，通常有两台计算机协同工作，以确保其中一台始终处于运行状态。每台计算机都会按照可配置的时间间隔与另一台计算机通信，并询问“你在线吗？”。如果没有收到“你在线吗？”的回复，HA 软件就会决定让另一台计算机运行业务，并实时自动执行此切换，无需人工干预。
• 监控计算机上运行的应用程序企业高效运营依赖于计算机上运行的各种应用程序和关键程序。监控就像主计算机询问每个应用程序：“你运行正常吗？”如果应用程序和关键程序回答“不正常”，则高可用性软件会尝试在主计算机上修复问题。如果主计算机上的“不正常”状态持续存在，则高可用性软件会自动决定让另一台计算机运行业务，并实时实施这一变更。

价值论证

现在我们已经了解了高可用性 (HA) 的概念及其基本工作原理，其价值显而易见。HA 硬件、软件和架构为企业提供了一种确保系统高可用性、持续运行的方法，无需手动监控系统以确保其正常运行。如果没有 HA，企业将面临停机、客户流失和销售损失的风险。在当今世界，任何企业都无法承受这些问题。企业高度依赖其计算机、应用程序、服务和数据来维持不间断的运营，因为停机会直接影响其盈利能力。当系统不可用时，公司不仅会损失收入，还可能面临客户流失的风险。如果客户无法及时访问所需的服务或数据，他们很可能会转向竞争对手，这是任何企业都不愿看到的局面！

作者：Sandi Hamilton，SIOS产品支持工程总监

经许可转载SIOS

如何在周五晚上的系统崩溃中幸存下来：从简陋的裸机到无缝的数据复制

那是我高二那年。周五晚上很晚了，像大多数青少年一样，我正对着电视发呆。突然，屏幕的光亮被手机的亮屏打断了。一阵嗡嗡声。接着又是一阵。然后是一阵持续不断的震动，这只能说明一件事：Discord 又崩溃了，客服工单如潮水般涌来，服务器又宕机了。

当服务器停机成为业务的一部分

那时，灾难性的宕机几乎成了我日常生活的一部分。游戏托管行业简直就是基础设施领域的蛮荒西部。竞争对手服务器发起的定向DDoS攻击、经验不足的客户误操作导致配置崩溃，以及廉价裸机服务器不可避免的硬件故障，混乱成了这个行业不可或缺的一部分。当我的同学们还在为生物考试焦头烂额时，我却在凌晨两点疯狂地通过SSH登录服务器，祈祷一次强制重启就能让节点恢复在线。

最终，这种持续不断的混乱开始造成沉重的代价。就我个人而言，独自一人24小时不间断地负责故障响应，这种巨大的压力已经让我精疲力竭。但从商业角度来看，损失更加惨重。每一分钟的停机都意味着要从本就微薄的利润中支付服务水平协议（SLA）补偿金。这意味着自然增长的流失、潜在客户的流失，以及应对玩家们理所当然的沮丧情绪。我痛苦地意识到，停机不仅仅是技术故障，更是一笔巨大的财务损失。

寻找更佳的高可用性策略

我知道必须做出改变。我花了几个小时研究企业架构，但作为一个独自运营、资金匮乏的青少年，我的高可用性策略本质上只是一堆临时拼凑的 Bash 脚本。我找到了一些实现基本故障转移的方法，但始终找不到可靠且经济实惠的方法来确保真正的数据复制。

最终，我交出了钥匙，把主机托管业务卖给了竞争对手，之后便离开了服务器机架，走进了大学的讲堂。但随着我学业的深入，那些令人抓狂的宕机事故留下的创伤却始终挥之不去。我总是忍不住去想基础设施、停机时间，以及那些科技巨头是如何轻松应对曾经让我的网络瘫痪的故障的。我孜孜不倦地努力去理解这种差距，最终促使我获得了在SIOS的实习机会。

探索 SIOS DataKeeper 和无缝数据复制

走进这个工程环境，感觉就像踏入了一个平行世界，我青少年时期对基础设施的种种担忧都已迎刃而解。当我第一次亲眼目睹 SIOS DataKeeper 的运行时，我被深深震撼了。这正是我多年前苦苦寻觅的东西。

看着一台机器上的编辑内容无缝转移到另一台机器上，并在模拟故障转移期间完全按照预期运行，真是令人难以置信。它与其他系统无缝集成，彻底杜绝了停机时间，这让我确信，我曾经梦寐以求的完美基础设施真的存在。

从简陋的基础设施到关键任务型高可用性

如今，我的工作完美地融合了我早年奋斗的经历和行业顶尖标准。我直接站在技术支持的第一线，确保我们的软件和客户的架构完美运行。每一天，我都能帮助企业保障其关键业务数据的在线安全。

这让我感到一种无比深刻、圆满的满足感。每当我帮助客户搭建高可用性系统时，我都会想起那个独自一人在周五晚上摸黑摸索的少年。如今，我不再只是渴望拥有一个安全网，而是积极地帮助其他企业打造坚如磐石、无需恐慌的基础设施，这种感觉真是太棒了。

作者：Brit Weinstein，SIOS客户体验工程师实习生

经许可转载SIOS

 

接地气：错过Percona Live Amsterdam让我对HA有了哪些新的认识

坐在机场的地板上，眼睁睁地看着出发航班信息牌因为关键系统故障而变成一片红色的取消航班，而你这周的日程安排却是全力以赴地维护数据库的高可用性，这真是莫大的讽刺。

与其在 Percona Live 大会上一边吃着焦糖华夫饼一边讨论同步复制与异步复制、灾难恢复策略和连接路由等问题，我不如花几个小时观看英国空中交通管制基础设施实时演示系统故障时会发生什么。

当中央飞行处理系统发生故障时，飞机不会坠毁……人工操作员会手动降低处理能力以确保安全。这对于航空电子设备来说是良好的工程设计。但从操作和用户角度来看，吞吐量会立即降至零。

在数据基础设施领域，我们没有条件对交易进行接地处理。

单点故障剖析

一个系统可以拥有分布在三个可用区的冗余硬件、双电源以及昂贵的供应商合同。然而，如果所有流量都通过单个状态协调器、集中式配置摄取管道或共享控制平面，那么你拥有的就不是分布式系统，而是一个代价高昂的分布式单点故障（SPOF）。

当飞行处理流程因输入格式错误或集中式状态偏差而阻塞时，主节点和辅助节点通常会同时触发安全模式锁定。在我们的系统中，这相当于：

• 裂脑情景当两个主数据库节点锁定表或退出仲裁以防止数据损坏时，就会发生这种情况。
• 健康检查协调器将网络延迟误判为完全故障，导致主连接频繁切换，直到连接池耗尽。
• 一个备份集群，能够在几毫秒内忠实地复制损坏的元数据或毒丸交易。

冗余仅仅是指拥有两份相同的东西。而弹性则是指知道备用件不会重蹈覆辙。

真正的HA需要什么

如果你的系统在凌晨 2 点主路径突然中断后，无法在无人干预的情况下继续运行，那么你并没有实现高可用性，而只是拥有了一个连接在焦虑的工程师身上的警报系统。

• 基于法定人数的共识制应对脆弱的初选：依赖简单主动/被动复制和手动 DNS 故障转移的系统极易导致停机。现代集群（无论是使用 Galera、组复制还是 Raft/Paxos 等共识协议）都需要奇数个节点和法定人数，以确保自动、安全地选举领导者，避免脑裂。
• 智能交通脱钩：应用程序绝不应直接指向数据库节点的硬编码 IP 地址。七层代理、智能连接池（例如 ProxySQL）和虚拟 IP 将应用程序客户端与底层基础设施的频繁变更隔离开来。如果节点 A 发生故障，节点 B 会接管写入操作，应用程序只需不到一秒即可完成重新连接，而不会完全中断。
• 隔离故障域：真正的高可用性 (HA) 会隔离输入。如果包含致命查询或格式错误的配置数据包进入系统，则必须将其隔离。如果主节点在执行过程中崩溃，故障转移不应自动将完全相同的致命查询重放到备用节点上，从而导致整个集群宕机。
• 重在钻探而非文档：如果你还没有在模拟网络分区和高负载条件下测试过自动故障转移，那么你的故障转移计划就只是一个假设。

总结

错过阿姆斯特丹的走廊巡演和现场演示令人遗憾。但凝视着停滞不前的机场航站楼，却让我更加深刻地意识到：停机时间绝不仅仅是 Grafana 仪表盘上的一个抽象指标。它会导致真实的人员滞留、运营中断，并摧毁信任。

做好容错设计。实现故障恢复自动化。测试集群。

作者Aaron West，SIOS 销售工程师

经许可转载SIOS