我有两个 Web 服务器，每个服务器都连接了一个磁盘。使用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; }
}
我还将kern.log文件放在了 pastebin 上：
答案1
恕我直言，您已经为 DRBD 选择了最佳的 SB 策略。因此，在您的案例中，必须在两侧对文件系统的同一部分（即 DRBD 块）进行更改。
所以在这种情况下 - 是的 - 您必须手动解决这个问题。
我想到的问题是为什么会发生这些并发访问？
您应该调查一下这个方向。如果网络中断，则一方应该无法访问，因此“放弃零更改”应该会有所帮助 - 但事实并非如此。
除此之外，你应该通过建立两个或更多个独立的网络连接来防止脑裂。我的集群上总是使用三个这样的网络连接。