У меня есть два веб-сервера, к каждому из которых подключен диск. Этот диск синхронизируется между ними с помощью 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
ИМХО вы уже выбрали лучший SB-полис для DRBD. Итак, в вашем случае должны были быть изменения в одной и той же части файловой системы (например, DRBD-блок) с ОБЕИХ сторон.
Так что в этом случае - да - вам придется решать это вручную.
У меня возникает вопрос почему произошли эти одновременные доступы?
Вам следует исследовать это направление. Если сеть не работает, с одной стороны не должно быть доступа, поэтому «отменить нулевые изменения» должно помочь, но этого не произошло.
Кроме того, вы должны предотвратить разделение мозгов, имея два или более НЕЗАВИСИМЫХ сетевых подключений. Я всегда использую три из них на своих кластерах.