☰

Heartbeat/DRBD 故障转移未按预期工作。如何使故障转移更加稳健？

tag-icon • tag-icon linux redhat drbd heartbeat
Heartbeat/DRBD 故障转移未按预期工作。如何使故障转移更加稳健？

我遇到过这样一种情况，即 DRBD-heartbeat 设置中有一个节点发生故障，但没有进行故障转移。当时的情况是主节点已锁定，但并未直接停机（无法通过 ssh 或 nfs 挂载访问，但可以 ping 通）。理想的行为应该是检测到此情况并故障转移到辅助节点，但似乎由于主节点没有完全停机（服务器之间有专用网络连接），heartbeat 的检测机制没有发现这一点，因此没有进行故障转移。

有人见过这个吗？我需要配置什么才能实现更强大的集群故障转移？DRBD 似乎工作正常（当我重新启动旧主服务器时必须重新同步），但如果没有良好的故障转移，它的用途就会受到限制。

  • 心跳 3.0.4
  • drbd84
  • RHEL 6.1
  • 我们没有使用Pacemaker

nfs03 是此设置中的主服务器，nfs01 是辅助服务器。

哈夫

  # Hearbeat Logging
logfacility daemon
udpport 694


ucast eth0 192.168.10.47
ucast eth0 192.168.10.42

# Cluster members
node nfs01.openair.com
node nfs03.openair.com

# Hearbeat communication timing.
# Sets the triggers and pulse time for swapping over.
keepalive 1
warntime 10
deadtime 30
initdead 120


#fail back automatically
auto_failback on

这是 haresources 文件：

nfs03.openair.com   IPaddr::192.168.10.50/255.255.255.0/eth0      drbddisk::data  Filesystem::/dev/drbd0::/data::ext4 nfs nfslock

答案1

我猜你必须实施一些监控来检查你的主系统是否按预期运行。如果任何检查失败，你应该关闭服务器（通过 IPMI/ILO 或交换式 PDU）并让心跳完成其工作。

我认为你总会发现它不能按照你期望的方式工作的情况。

答案2

这不是完美的解决方案，但 2-3 年前我在使用较旧的系统时遇到过这个问题drbd。我所做的是在两个主机上添加一个脚本，cron检查实际主机是活动主服务器还是从服务器。如果它在从服务器上，它会检查 NFS 目录中的某个已知文件是否可用。如果没有；我认为 NFS 已损坏；它会通过 sshpower off命令发送。您可以尝试按照这种方式工作。我相信它们有更好的方法。这个对我来说已经足够好了。

相关内容