关于内核恐慌的心跳肉制品 STONITH

Question

我有一个带有心跳和 DRBD 的两节点集群管理 mysql 资源。如果我停止主服务器、重新启动它或断开网络连接，故障转移效果很好。

但是，如果主服务器遇到内核崩溃（通过运行模拟echo c > /proc/sysrq-trigger），则辅助服务器不会接管资源。

这是辅助节点上的心跳日志的样子：

Jul 11 21:33:32 rad11 heartbeat: [7519]: WARN: node rad10: is dead
Jul 11 21:33:32 rad11 heartbeat: [7519]: info: Link rad10:eth0 dead.
Jul 11 21:33:32 rad11 heartbeat: [8442]: info: Resetting node rad10 with [Meatware STONITH device]
Jul 11 21:33:32 rad11 heartbeat: [8442]: ERROR: glib: OPERATOR INTERVENTION REQUIRED to reset rad10.
Jul 11 21:33:32 rad11 heartbeat: [8442]: ERROR: glib: Run "meatclient -c rad10" AFTER power-cycling the machine.

有没有人知道为什么在这种情况下二级无法接管？通常故障转移效果很好，但我试图在主节点上模拟内核崩溃。

编辑：这是我的心跳配置，ha.cf

# /etc/ha.d/ha.cf

logfile /var/log/ha-log

keepalive 1

deadtime 10

udpport 695

ucast eth0 rad11
auto_failback on
stonith_host rad10 meatware rad11
stonith_host rad11 meatware rad10
node rad10 rad11

Answer 1

当集群节点彼此失去联系时，为了避免脑裂场景，即两个节点都认为自己是主节点并尝试同时运行共享资源，从而导致潜在的灾难（这在两个节点集群中尤其是一个大问题） ，因为如果两个节点各有一票，谁拥有法定人数？），因此为了缓解这种情况，一些集群实施了各种形式的隔离。

\n\n

在linux-ha 维基页面上：

\n\n

\n

防护是将资源锁定在状态不确定的节点上的过程。

\n\n

有多种击剑技术可供选择。

\n\n

可以使用节点防护来隔离节点，也可以使用资源防护来隔离资源。有些类型的资源是自防护资源，有些资源不会因同时使用而损坏，并且根本不需要防护。

\n

\n\n

当一个节点执行干净关闭时，它将很好地离开集群，从而其他节点将知道发生了什么，因此将接管该节点可能正在运行的任何服务，然后继续运行。当节点没有很好地离开集群时会出现内核恐慌，其他集群成员将不知道其他节点的状态。从他们的角度来看，这将是“不确定的”，因此他们将执行配置的“隔离”操作，在 STONITH 的情况下，这意味着尝试从集群中强制删除故障节点（通过重新启动电源等）。

\n\n

查看您的日志，似乎为您的集群配置选择了meatware STONITH机制。顾名思义，它意味着手动重新启动另一个节点，然后运行所述命令。来自文档：

\n\n

\n

肉制品

\n\n

奇怪的名字和简单的概念。肉件需要人类的帮助才能操作。每当调用时，meatware 都会记录一条 CRIT 严重性消息\n，该消息应显示在节点\xe2\x80\x99s 控制台上。然后，操作员应确保该节点已关闭，并发出 eatclient(8) 命令，以告诉肉类软件它可以告诉集群它可能会认为该节点已死亡。有关更多信息，请参阅 README.meatware。

\n

\n\n

还有其他方法可以配置防护。在创建集群时，我通常会为 PSU:s 配备两个 APC 交换机并配置“APC fencing”（stonith -t apcmaster -h )。这样，当一个节点发生故障时，另一个节点将通过登录 APC 接口对故障成员进行电源循环并在连接的 PSU 插槽上发送关闭/重新启动命令来执行硬重启（我使用两个节点以避免单点故障） 。

\n