嘿哈布尔！ 我向您展示这篇文章的翻译 作者：安德鲁·比克霍夫
许多人更喜欢两节点集群，因为它们在概念上看起来更简单，而且比三节点集群便宜 33%。 尽管很有可能将两个节点组成一个良好的集群，但在大多数情况下，由于未考虑到的场景，这样的配置会产生许多不明显的问题。
创建任何高可用性系统的第一步是查找并尝试消除单个故障点，通常缩写为 单点光纤 （单点故障）。
值得记住的是，不可能消除任何系统中所有可能的停机风险。 这是因为，典型的风险防御方法是引入一些冗余，这会导致系统复杂性增加并出现新的故障点。 因此，我们最初做出妥协，将重点放在与单个故障点相关的事件上，而不是相关的事件链上，因此可能性越来越小。
考虑到权衡，我们不仅寻求 SPoF，还要平衡风险和后果，因此每次部署的关键和非关键结论可能会有所不同。
并非每个人都需要拥有独立电力线的替代电力供应商。 尽管当监控检测到有故障的变压器时，至少一位客户的偏执得到了回报。 客户打电话试图向电力公司报警，直到故障变压器发生爆炸。
一个自然的起点是系统中拥有多个节点。 然而，在系统发生故障后将服务移动到幸存节点之前，通常需要确保正在移动的服务在其他地方不活动。
如果故障导致两个节点为同一静态网站提供服务，那么双节点集群不会有任何负面影响。 但是，如果结果是双方独立管理共享作业队列或提供对复制数据库或共享文件系统的不协调的写入访问，情况就会发生变化。
因此，为了防止由于单节点故障而导致数据损坏 - 我们依靠称为 “解离” （击剑）。
解离原理
分离原则的核心问题是：竞争节点是否会导致数据损坏？ 如果可能发生数据损坏，一个好的解决方案是将节点与传入请求和持久存储隔离。 最常见的解除关联方法是断开故障节点的连接。
解离方法有两类，我将其称为 直接 и 间接，但它们同样可以称为 活性 и 被动的。 直接方法包括幸存对等方的操作，例如与 IPMI（智能平台管理接口）或 iLO（一种在无法物理访问服务器的情况下管理服务器的机制）设备进行交互，而间接方法则依赖于发生故障的设备节点以某种方式认识到它处于不健康状态（或至少阻止其他成员恢复）并发出信号 关于需要断开故障节点的连接。
使用直接和间接方法时，仲裁会有所帮助。
直接解离
在直接解离的情况下，我们可以使用仲裁来防止网络故障时的解离竞争。
有了仲裁的概念，系统中有足够的信息（即使没有连接到其对等体），节点可以自动知道它们是否应该发起分离和/或恢复。
如果没有法定人数，网络鸿沟的双方都会正确地认为另一方已经死亡，并会寻求与另一方解除联系。 在最坏的情况下，双方都会设法关闭整个集群。 另一种场景是死亡竞赛，节点产生的无限循环，看不到它们的对等体，重新启动它们，并且只有当它们的对等体遵循相同的逻辑时才启动恢复以重新启动。
解除关联的问题是，由于我们想要恢复的相同故障事件，最常用的设备变得不可用。 大多数IPMI和iLO卡安装在它们控制的主机上，并且默认情况下使用相同的网络，这会导致目标主机认为其他主机处于离线状态。
不幸的是，在购买设备时很少考虑IPMI和iLo设备的操作特性。
间接解离
仲裁对于管理间接解除关联也很重要；如果操作正确，仲裁可以允许幸存者假设丢失的节点将在一段时间后过渡到安全状态。
使用此配置，如果仲裁未丢失，则硬件看门狗定时器每 N 秒重置一次。 如果计时器（通常是 N 的几倍）到期，则设备会执行非正常断电（而不是关机）。
这种方法非常有效，但如果没有仲裁，集群内就没有足够的信息来管理它。 区分网络中断和对等节点故障并不容易。 这很重要的原因是，如果无法区分这两种情况，您就被迫在两种情况下选择相同的行为。
选择一种模式的问题在于，没有任何行动方案可以最大限度地提高可用性并防止数据丢失。
- 如果您选择假设对等节点处于活动状态但实际上发生了故障，则集群将不必要地停止正在运行的服务，以补偿故障对等节点的服务损失。
- 如果您决定假设某个节点已关闭，但这只是网络故障，并且实际上远程节点正常运行，那么您最多只能在未来对结果数据集进行手动协调。
无论您使用什么启发式方法，创建一个导致双方失败或导致集群关闭幸存节点的故障都是微不足道的。 不使用仲裁确实会剥夺集群中最强大的工具之一。
如果没有其他选择，最好的办法就是牺牲可用性（这里作者参考了CAP定理）。 损坏数据的高可用性对任何人都没有帮助，并且手动协调不同的数据集也不有趣。
法定人数
法定人数听起来很棒，对吧？
唯一的缺点是，为了将其放入具有 N 个成员的集群中，您需要在剩余的 N/2+1 个节点之间建立连接。 在一个节点发生故障后，这在两节点集群中是不可能的。
这最终给我们带来了两个节点的基本问题：
仲裁在两个节点集群中没有意义，没有它就不可能可靠地确定最大化可用性并防止数据丢失的操作过程
即使在通过交叉电缆连接的两个节点的系统中，也不可能明确区分网络中断和另一个节点的故障。 禁用一端（当然，其概率与节点之间的距离成正比）将足以使链路的健康状况等于伙伴节点的健康状况的任何假设失效。
使双节点集群正常工作
有时客户不能或不想购买第三个节点，我们被迫寻找替代方案。
选项 1 - 重复解离方法
节点的 iLO 或 IPMI 设备代表一个故障点，因为如果它发生故障，幸存者将无法使用它使节点进入安全状态。 在包含 3 个或更多节点的集群中，我们可以通过计算仲裁并使用硬件看门狗（一种间接解除关联机制，如前所述）来缓解这种情况。 在有两个节点的情况下，我们必须使用网络配电单元（PDU）。
发生故障后，幸存者首先尝试联系主分离设备（嵌入式 iLO 或 IPMI）。 如果成功，恢复将照常进行。 仅当 iLO/IPMI 设备发生故障时才会访问 PDU；如果访问成功，则可以继续恢复。
请务必将 PDU 放置在与集群流量不同的网络上，否则单个网络故障将阻止对两个解除关联设备的访问并阻止服务的恢复。
这里你可能会问——PDU是单点故障吗？ 答案是，当然是。
如果这种风险对您来说很重要，那么您并不孤单：将两个节点连接到两个 PDU，并告诉集群软件在打开和关闭节点电源时使用这两个 PDU。 现在，如果一个 PDU 失效，集群仍保持活动状态，并且需要另一 PDU 或 IPMI 设备发生第二次故障才能阻止恢复。
选项 2 - 添加仲裁者
在某些情况下，虽然重复分离方法在技术上是可行的，但在政治上却很困难。 许多公司喜欢将管理员和应用程序所有者分开，并且具有安全意识的网络管理员并不总是热衷于与任何人共享 PDU 访问设置。
在这种情况下，建议的替代方案是创建一个可以补充法定人数计算的中立第三方。
如果发生故障，节点必须能够看到其对等点或仲裁器的电波，以便恢复服务。 如果两个节点都可以看到仲裁器但无法看到对方，则仲裁器还包括断开连接功能。
此选项必须与间接解除关联方法结合使用，例如硬件看门狗定时器，该定时器配置为在机器失去与其对等节点和仲裁节点的连接时终止机器。 因此，幸存者可以合理地假设其对等节点在硬件看门狗定时器到期后将处于安全状态。
仲裁器和第三节点之间的实际区别在于，仲裁器运行所需的资源要少得多，并且可以为多个集群提供服务。
选项 3 - 人为因素
最后的方法是让幸存者继续运行他们已经在运行的任何服务，但不要启动新的服务，直到问题自行解决（网络恢复、节点重新启动）或有人负责手动确认另一方已死亡。
奖金选项
我是否提到过您可以添加第三个节点？
两个机架
为了便于讨论，让我们假设我已经让您相信了第三个节点的优点，现在我们必须考虑节点的物理排列。 如果它们安装（并供电）在同一个机架中，这也构成了 SPoF，并且无法通过添加第二个机架来解决。
如果这令人惊讶，请考虑如果具有两个节点的机架发生故障会发生什么，以及幸存的节点如何区分该故障和网络故障。
简而言之，这是不可能的，我们再次处理双节点情况下的所有问题。 或者幸存者：
- 忽略仲裁并在网络中断期间错误地尝试启动恢复（完成分离的能力是另一回事，取决于是否涉及 PDU 以及它们是否与任何机架共享电源），或者
- 尊重仲裁并在对等节点发生故障时提前断开连接
无论如何，两个机架并不比一个机架好，节点必须要么接收独立的电源，要么分布在三个（或更多，具体取决于您拥有的节点数量）机架上。
两个数据中心
此时，不再厌恶风险的读者可能需要考虑灾难恢复。 当小行星撞击同一个数据中心，而我们的三个节点分布在三个不同的机架上时，会发生什么？ 显然是坏事，但根据您的需求，添加第二个数据中心可能还不够。
如果操作正确，第二个数据中心将为您提供（并且合理地）您的服务及其数据的最新且一致的副本。 然而，在两个节点、两个机架的场景中，系统中没有足够的信息来确保最大可用性并防止损坏（或数据集差异）。 即使具有三个节点（或机架），将它们分布在两个数据中心也会导致系统在发生（现在更有可能）双方无法通信的事件时无法可靠地做出正确的决策。
这并不意味着双数据中心解决方案永远不合适。 公司通常希望人们在采取转移到备份数据中心的非凡步骤之前意识到这一点。 请记住，如果您想自动执行中断，您要么需要第三个数据中心才能使法定人数有意义（直接或通过仲裁器），要么您会找到一种可靠地关闭整个数据的方法中心。
来源： habr.com