☰

Corosync HA 防止裂脑情况

tag-icon • tag-icon cluster high-availability corosync
Corosync HA 防止裂脑情况

我正在建立一个关于负载平衡和高可用性的自学测试系统，我对 Corosync 中的配置设置感到好奇，想知道有经验的人对此有何看法。

我现在正在研究和学习的是 Corosync 投票法定人数以及如何处理失效节点。在一次小型研究会议中，我发现有人在谈论 STONITH 和裂脑场景，其中两个节点都会假设它是唯一的幸存者，并认为它是主节点，试图保持主节点地位等。这当然是一种不受欢迎的情况。

在 Corosync 配置中我看到了一个特定的配置：

quorum {
        ...
        auto_tie_breaker: 1
        auto_tie_breaker_node: lowest
}

auto_tie_breaker 能否防止这种脑裂情况的发生，还是我错了？

如果我理解文档正确的话，将其设置为最低，是否意味着具有最低 nodeid 的节点将是负责的节点？

nodelist {
          node {
          ring0_addr: primary_private_ip
          name: primary
          nodeid: 1
          }

          node {
          ring0_addr: secondary_private_ip
          name: secondary
          nodeid: 2
          }
}

当然，我目前仅在双节点集群上进行测试，但目的是了解该过程的工作原理，以便将来能够成功建立更可靠的基础设施。

感谢您的意见和指导，祝您有美好的一天！:)

答案1

您的假设是正确的，auto_tie_breaker将尝试通过“强制”集群保持与正确的节点集（或两个节点集群中的单个节点）的连接来解决偶数节点配置（1/1、1/1/1/1 等）中的节点故障。

votequorum 的一般行为允许同时出现最多 50% 的节点故障 - 1 个节点，假设每个节点都有 1 票。

启用 ATB 后，集群最多可同时承受 50% 的节点发生故障，这是确定性的情况。默认情况下，集群分区或仍与具有最低节点 ID 的节点保持联系的节点集将保持多数派。其他节点将不占多数派。也可以通过指定

集群的仲裁投票通常必须在 n+1 节点场景中使用，或者与参数一起使用two_node，其中expected_votes必须设置为 2 和硬件隔离 /斯托尼特必须启用。

auto_tie_breaker_node: lowest|highest|<list of node IDs>

“lowest” 是默认值，“highest” 类似，如果当前节点集包含最高节点 ID，则它将保持仲裁。或者，可以指定维持仲裁所需的特定节点 ID 或节点 ID 列表。如果给出了（空格分隔的）列表，则按顺序评估节点，因此如果第一个节点存在，则将使用它来确定仲裁分区，如果该节点不在任何一半（即在拆分之前不在集群中），则将检查第二个节点 ID，依此类推。ATB 与仲裁设备不兼容 - 如果在 corosync.conf 中指定了 auto_tie_breaker，则将禁用仲裁设备。

记住：这不是斯托尼特设备，并且不能将其与two_node指令一起使用。

two_node: 1

启用两个节点集群操作（默认值：0）。

“双节点集群”是一种需要特别考虑的用例。在标准的双节点集群中，每个节点都有一票，集群中有 2 票。使用简单多数计算（50% 的选票 + 1）来计算法定人数，法定人数将为 2。这意味着两个节点必须始终处于活动状态，集群才能达到法定人数并正常运行。

启用 two_node: 1，quorum 人为设置为 1

因此，即使对于没有硬件防护或 STONITH 的节点群集，新的首选方法也是auto_tie_breaker。

在 n+1 集群中，法定投票仍然非常可靠，但对于高调的 Linux HA，硬件隔离/STONITH 应该仍然是王道。

与往常一样，请务必测试所有可能的情况，如网络中断、硬件故障、断电、同时资源错误、DRBD 错误（如果使用）等，并阅读这个文件关于 corosync 的“新”功能。

相关内容