☰

心跳肉机 STONITH 出现内核崩溃

tag-icon • tag-icon cluster heartbeat linux-ha
心跳肉机 STONITH 出现内核崩溃

我有一个双节点集群，其中 heartbeat 和 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

答案1

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

在linux-ha wiki 页面：

隔离是将资源锁定在状态不确定的节点之外的过程。

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

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

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

查看你的日志，似乎meatware 斯托尼特机制取决于您的集群配置。顾名思义，它意味着手动关闭另一个节点的电源，然后运行该命令。从文档：

肉制品

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

还有其他方法可以配置隔离。在建立集群时，我通常会为 PSU 配备两个 APC 交换机，并配置“APC 隔离”（stonith -t apcmaster -h）。这样，当一个节点发生故障时，另一个节点将通过登录 APC 界面并在连接的 PSU 插槽上发送关机/重启命令，对故障成员进行电源循环，从而执行硬重启（我得到两个以避免单点故障）。

相关内容