🙃 🖨️ 👐🏽 两节点群集-详细说明 👨🏼‍🏭 ☯️ ✴️

哈Ha！我向您介绍了安德鲁·比克霍夫（Andrew Beekhof）撰写的文章“两个节点-细节中有魔鬼”的翻译。

许多人更喜欢两节点群集，因为它们在概念上看起来更简单，并且比三节点群集便宜33％。尽管组装两个节点的良好群集很有可能，但是在大多数情况下，由于无法解释的情况，这种配置将产生许多不明显的问题。

创建任何高可用性系统的第一步是搜索并尝试消除单个故障点，通常将其缩写为SPoF（单个故障点）。

应该记住，在任何系统中都不可能消除所有可能的停机风险。这甚至可以从以下事实得出：典型的风险保护是引入了一些冗余，这导致系统复杂性的增加和新故障点的出现。因此，我们一开始就妥协并关注与单个故障点有关的事件，而不是与相关的连锁事件有关，因此，所有不太可能发生的事件。

考虑到这些折衷，我们不仅要寻找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或IPMI设备的第二次故障来阻止恢复，则群集将保持活动状态。

选项2-添加仲裁员

在某些情况下，尽管重复分离方法在技术上是可行的，但在政治上却很复杂。许多公司希望管理员和应用程序所有者之间有一定的隔离，并且安全意识强的网络管理员并不总是热衷于将对PDU的访问权传递给任何人。

在这种情况下，建议的替代方法是创建一个中立的第三方来补充定额计算。

如果发生故障，该节点应该能够看到其伙伴或仲裁者的广播，以便恢复服务。如果两个节点都可以看到仲裁器，但彼此看不到，则仲裁器还具有断开连接的功能。

此选项应与间接分离方法（例如，硬件看门狗定时器）结合使用，该方法可以配置为在计算机与其伙伴节点和仲裁器失去连接时关闭计算机。因此，幸存者可以放心地假定在硬件看门狗定时器期满之后，其伙伴节点将处于安全状态。

仲裁器与第三个节点之间的实际区别在于，仲裁器所需的资源少得多，并且有可能服务多个群集。

选项3-人为因素

最后一种方法是让幸存者继续执行他们已经执行的任何服务，但不启动新服务，直到问题本身得以解决（网络还原，节点重新启动），或者该人员不承担手动确认的责任。另一边已经死了。

奖金选项

我是否提到过可以添加第三个节点？

两个架子

为了争辩，让我们想象一下，我已经使您相信了第三个节点的优点，现在我们必须考虑节点的物理位置。如果将它们放在同一机架中（并由它们供电），则这也表示SPoF，并且无法通过添加第二机架来解决。

如果这令人惊讶，请考虑如果具有两个节点的机架发生故障会发生什么，以及尚存的节点如何区分这种情况和网络故障。

简短的回答：这是不可能的，并且我们将再次处理两个节点的所有问题。还是幸存者：

忽略仲裁并在网络中断期间错误地尝试启动恢复（完成分离的可能性是另外一回事，取决于是否涉及PDU以及它们是否共享来自任何机架的电源），或者
尊重仲裁并在其伙伴节点发生故障时过早断开自身连接

无论如何，两个机架并不比一个机架好，并且节点必须接收独立的电源，或者在三个（或更多，取决于您有多少个节点）机架之间分配。

两个数据中心

在这一点上，不再厌恶风险的读者可以考虑从事故中恢复过来。当小行星进入我们的三个节点并分布在三个不同机架中的单个数据中心时会发生什么？显然，这很糟糕，但是根据您的需要，添加第二个数据中心可能还不够。

如果一切操作正确，则第二个数据中心将为您（这是合理的）提供服务及其数据的最新且一致的副本。但是，就像在具有两个节点和两个机架的方案中一样，系统没有足够的信息来确保最大的可用性并防止损坏（或数据集分散）。即使存在三个节点（或机架），它们在两个数据中心的分布也会使系统无法可靠地做出决策，以防（现在更有可能）双方无法连接。

这并不意味着永远不可能有两个数据中心的解决方案。公司通常希望人们在转移到备份数据中心时采取特别的措施之前意识到这一点。请记住，如果要自动执行故障，则需要第三个数据中心以使仲裁有意义（直接或通过仲裁器），或者找到可靠地禁用整个数据中心的方法。

两节点群集-详细说明