我有两个网络服务器,每个网络服务器都附加了一个磁盘。该磁盘drbd
在“双主”模式下使用(2:8.3.13-1.1ubuntu1) 在它们之间同步,并且在此之上我将ocfs2
(1.6.4-1ubuntu1) 作为集群文件系统运行。节点在专用网络上进行通信192.168.3.0/24
。在大多数情况下,这是稳定的,并且运行良好。
昨晚,似乎出现了网络中断。这导致了一个裂脑场景,其中 node01 留在Standalone
和 中Primary
,而 node02 留在WFConnection
和 中primary
。恢复是今天早上手动区分两个文件系统的过程,决定 node01 应该是权威的,将 node02 放入辅助drbdadm connect
节点,然后在每个节点上发出命令。在此之后重新挂载文件系统,我们就可以备份并运行了。
我的问题是:这种类型的中断是否总是需要手动解决?或者有什么方法可以使这个过程自动化?我的理解是,drbd 应该在出现关于确定哪个节点应该成为主要和次要节点的脑裂的情况下变得聪明。似乎在这种情况下,一个简单的网络中断在主服务器中留下了,我的配置只是说“断开连接”。查看日志,我发现有趣的是,他们似乎都同意node02
应该是 SyncSource,但在查看 rsync 日志时,它实际上node01
是最新的更改。同样有趣的是关于node01
“我将成为 SyncTarget,但我是主要的!”这一行。对我来说,看起来 drbd 试图解决这个问题,但由于某种原因失败了。
有没有更好的方法来做到这一点?
配置r0
是这样的:
resource r0 {
meta-disk internal;
device /dev/drbd0;
disk /dev/xvda2;
syncer { rate 1000M; }
net {
#We're running ocfs2, so two primaries desirable.
allow-two-primaries;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
}
handlers{
before-resync-target "/sbin/drbdsetup $DRBD_MINOR secondary";
split-brain "/usr/lib/drbd/notify-split-brain.sh root";
}
startup { become-primary-on both; }
on node02 { address 192.168.3.8:7789; }
on node01 { address 192.168.3.1:7789; }
}
Run Code Online (Sandbox Code Playgroud)
我也把kern.log
文件放在 pastebin 上:
Node01:http ://pastebin.com/gi1HPtut
Node02:http ://pastebin.com/4XSCDQdC
恕我直言,您已经为 DRBD 选择了最佳的 SB 策略。因此,在您的情况下,双方的文件系统的同一部分(即 DRBD 块)都必须进行更改。
所以在这种情况下 - 是的 - 你必须手动解决这个问题。
我想到的问题是为什么会发生这些并发访问?
你应该调查那个方向。如果网络出现故障,一侧应该无法访问,因此“放弃零更改”应该会有所帮助 - 但事实并非如此。
除此之外,您应该通过拥有两个或多个独立的网络连接来防止脑裂。我总是在我的集群上使用其中三个。