我正在测试双节点集群并测试各种裂脑场景。
一切运行良好，资源按照我预期的那样运行，只是我对特定情况下的时间安排感到疑惑。
我正在跑步
auto_tie_breaker: 1
auto_tie_breaker_node: lowest
在我的例子中，最低的是节点 1。
当资源位于节点 1 上并且我导致脑裂场景时，一切似乎都很好。
但是，当资源位于节点 2 上时，并且我导致了脑裂，则资源在节点 2 上关闭并在节点 1 上启动，这完全合理。
但我对时间安排感到疑惑。现在两个节点无法相互通信，有什么机制可以确保节点 1 上的资源在节点 2 上的资源关闭后启动？
我可以想象在资源的启动脚本中放置一个睡眠状态，但我想知道是否有官方认可的方法来处理这个时间？
或者我可能用错了方法。也许我应该使用某种粘性。当检测到裂脑情况时，告诉节点继续执行它们正在执行的操作。换句话说，检测到裂脑时不要更改任何内容。
答案1
tl;dr -- 通过 corosync-qdevice 为您的集群获得第三票
原帖 (我是原帖的作者) 的问题在于原始问题中没有包含大量的细节。
经过另外几天的测试和阅读，我清楚地发现，互联网上描述了许多构建双节点 HA 集群的错误方法。
第一个问题应该很容易理解，即在一个节点上停止服务，而在另一个节点上启动服务。根据定义，节点处于裂脑状态，无法知道另一个节点的状态，因此无论延迟或等待多久都无法高度可靠地解决这种情况。此外，一旦集群处于裂脑状态，节点 2 只会认为服务在节点 1 上启动。它不知道它是否启动了。因此，当节点 2 离线时，服务可能不可用。
第二点最后建议，也许某种令牌系统会起作用。换句话说，什么也不做。它的效果不是最佳的，因为如果带有令牌的系统死机，就会发生裂脑，而一个完好的待机系统会因为选择什么也不做而处于闲置状态。
我最终选择了第三方仲裁设备，这与 3 节点或奇数编号集群只有一点不同。我使用了 corosync-qdevice 和 corosync-qnetd。
我现在在双节点集群中拥有了第三票。它解决了我在 OP 中提到的裂脑问题，并消除了所有无法解决的双节点边缘情况。
剩下的就是 STONITH，这是所有集群之神都拥有的强大武器。如果我要从头开始构建集群，除了资源阻塞之外，我还会使用 STONITH。
然而，我继承了这个特定的集群，它位于共享硬件上，虽然它有 IPMI 和其他好东西，但我不允许关闭电源。
至于虚拟 STONITH，我并不确信它与资源阻塞有什么不同，但这应该是一个不同的问题。
因此，如果您正在努力设置具有资源隔离的 HA 双节点集群，请阅读 corosync-qdevice 并为您的集群添加第三个投票。
答案2
理想情况下，您需要配置并启用 STONITH 设备以供 Pacemaker 使用。否则，无法保证在节点 1 尝试接管之前，服务会在节点 2 上实际停止。睡眠/延迟可能会给服务额外的时间来停止，但如果服务因任何原因无法停止，节点 1 仍将尝试接管服务。
STONITH 设备配置为使用带外通信通道强制从集群中删除无响应或断开连接的对等设备（通常通过关闭电源）。
一旦您在 Pacemaker 集群中实现了 STONITH，您就消除了几乎所有可能出现集群挂起/分裂的情况。