Двойной первичный 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-блок) на ОБА сторон.

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

Вопрос, который возникает у меня, заключается в том, почему произошли эти параллельные доступы?

Вы должны исследовать это направление. Если сеть не работает, не должно быть доступа с одной стороны, поэтому "сброс нулевых изменений" должен помочь - но это не так.

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

Другие вопросы по тегам