我有两个networking服务器，每个都有一个磁盘连接。 这个磁盘在两个主模式下使用drbd （2：8.3.13-1.1ubuntu1）在它们之间同步，在这个磁盘的顶部我运行ocfs2 （1.6.4-1ubuntu1）作为一个集群文件系统。 节点在专用networking192.168.3.0/24上通信。 大多数情况下，这是稳定的，运作良好。
昨天晚上，似乎有一个networking中断。 这导致了一个裂脑scheme，其中node01保留在Standalone和Primary ，而node02保留在WFConnection和primary 。 恢复是一个手动的过程，在比较两个文件系统的早上，决定node01应该是权威的，把node02放到第二个节点，然后在每个节点上发出drbdadm connect命令。 在此之后重新安装文件系统，我们正在备份并运行。
我的问题是：这种停电是否总是需要手动解决？ 或者有什么方法可以使这个过程自动化？ 我的理解是，drbd应该在脑子出现裂缝的情况下努力做出明智的决定，哪个节点应该成为主要和次要的。 看起来，在这种情况下，一个简单的networking中断都留在小学，我的configuration只是说'断开'。 看看日志，我觉得有趣的是，他们似乎都同意node02应该是SyncSource，但是在查看rsync日志时，它实际上是具有最近更改的node01 。 也有趣的是node01上的一行声明“我将成为SyncTarget，但我是主要的！”。 对我来说，看起来像drbd试图解决这个问题，但由于某种原因失败。
有没有更好的方法来做到这一点？
r0的configuration是这样的：
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上：
Node01： http ://pastebin.com/gi1HPtut
Node02： http ://pastebin.com/4XSCDQdC
恕我直言，你已经select了DRBD最好的SB政策。 所以在你的情况下，必须在文件系统的相同部分（即DRBD块）上进行更改。
所以在这种情况下 – 是的 – 你必须手动解决。
出现的问题是为什么这些并发访问发生 ？
你应该调查这个方向。 如果networking瘫痪，一方应该没有访问权限，所以“放弃零变更”应该有所帮助 – 但事实并非如此。
除此之外，你应该通过拥有两个或多个独立的networking连接来防止分裂的大脑。 我总是在我的群集上使用其中的三个。