Назад | Перейти на главную страницу

Двойной первичный OCFS2 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

ИМХО вы уже выбрали лучший SB-полис для DRBD. Итак, в вашем случае должны были быть изменения в одной и той же части файловой системы (например, DRBD-блок) с ОБЕИХ сторон.

Так что в этом случае - да - вам придется решать это вручную.

У меня возникает вопрос почему произошли эти одновременные доступы?

Вам следует исследовать это направление. Если сеть не работает, с одной стороны не должно быть доступа, поэтому «отменить нулевые изменения» должно помочь, но этого не произошло.

Кроме того, вы должны предотвратить разделение мозгов, имея два или более НЕЗАВИСИМЫХ сетевых подключений. Я всегда использую три из них на своих кластерах.