Двойной первичный OBFS2 DRBD встречается с расщепленным мозгом. Всегда ли восстановление будет ручным в этом случае?
У меня есть два веб-сервера, к каждому из которых прикреплен диск. Этот диск синхронизируется между ними с помощью drbd
(2:8.3.13-1.1ubuntu1) в режиме 'dual-primary', и поверх этого я запускаю 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:
Узел 01: http://pastebin.com/gi1HPtut
Узел 02: http://pastebin.com/4XSCDQdC
1 ответ
ИМХО вы уже выбрали лучший SB-полис для DRBD. Таким образом, в вашем случае должны были быть изменения в той же части файловой системы (то есть DRBD-блок) на ОБА сторон.
Так что в этом случае - да - вы должны решить это вручную.
Вопрос, который возникает у меня, заключается в том, почему произошли эти параллельные доступы?
Вы должны исследовать это направление. Если сеть не работает, не должно быть доступа с одной стороны, поэтому "сброс нулевых изменений" должен помочь - но это не так.
Кроме того, вы должны предотвратить разделение мозгов, имея два или более НЕЗАВИСИМЫХ сетевых подключений. Я всегда использую три из них на своих кластерах.