LINUX.ORG.RU
ФорумAdmin

DRBD PRI/SEC Split-Brain и/или альтернатива DRBD.

 , ,


0

1

Добрый день!

Хочу использовать DRBD для репликации между двумя нодами Proxmox, но на тестах каждый раз ловлю Split-Brain.

И так последовательность моих действий:

1 нода - primary

2 нода - secondary

Роняю первую ноду, перевожу вторую ноду в режим primary, начинаю работу со второй нодой, спустя некоторое время подымаю первую ноду в режиме secondary и ловлю split-brain.

pve-node1
r0 role:Secondary
  disk:UpToDate
  pve-node2 connection:Connecting

pve-node2
r0 role:Primary
  disk:UpToDate
  pve-node1 connection:StandAlone

После чего «раму собрать» не получается.

Вру! Все работает после:

Solution:
Step 1: Start drbd manually on both nodes

Step 2: Define one node as secondary and discard data on this

drbdadm secondary all
drbdadm disconnect all
drbdadm -- --discard-my-data connect all
Step 3: Define anoher node as primary and connect

drbdadm primary all
drbdadm disconnect all
drbdadm connect all

Но как то все равно не камельфо синькать полностью раздел после каждого падения. А если раздел будет на 4TB? Ждать пол-суток пока все синькнется?

Вот конфиг:

global {
        usage-count no;
}
resource r0 {
        protocol C;
        startup {
                wfc-timeout 0;
                degr-wfc-timeout 60;
        }
        net {
                after-sb-0pri discard-zero-changes;
                after-sb-1pri discard-secondary;
                after-sb-2pri disconnect;
                max-epoch-size          8192;
                max-buffers             8192;
                sndbuf-size             0k;
        }
       on pve-node1 {
                device     /dev/drbd0;
                disk       /dev/mapper/pve--node--vg-drbd ;
                address    192.168.111.201:7788;
                meta-disk  internal;
        }
       on pve-node2 {
                device     /dev/drbd0;
                disk       /dev/mapper/pve--node--vg-drbd ;
                address    192.168.111.202:7788;
                meta-disk  internal;
        }
}

Может чего не правильно делаю?

Почитав данную статью https://habrahabr.ru/post/219295/, как то совсем засомневался в использовании DRBD, быть может есть альтернативы? Цеф я так понял не «свой в доску», может GlusterFS?



Последнее исправление: Sherman (всего исправлений: 3)

Мне вот чё-то кажется, что для того, чтобы split brain'а не было, нужно нечётное количество хостов с кворумом.

DRBD так, вроде, не умеет же?

post-factum ★★★★★
()
Ответ на: комментарий от post-factum

На сколько я понял его вообще проблематично завести на 2+ хостах...

Sherman
() автор топика
Ответ на: комментарий от post-factum

я просто не могу понять, почему split brain происходит в связке pri+sec? Ведь не логично как то, ладно на pri+pri...

Sherman
() автор топика
Ответ на: комментарий от post-factum

да, но уже почти склонен к тому, что бы установить корыто для хранилища...

Вроде как drbd не плохой вариант, но не устраивает, что каждый раз придется синькать разделы полностью, а это больше 6ТБ...

Sherman
() автор топика
Ответ на: комментарий от Sherman

Я бы внимательно посмотрел на действия на «упавшей» ноде по переводу ее в secondary. Возможно есть действие, которое аннулирует все содержимое диска.

IMHO SB не может быть в режиме pri-sec

vel ★★★★★
()
Ответ на: комментарий от vel

Ноду отключаю от свитча, отмонтирую раздел с диском drbd, перевожу в secondary, на второй ноде перевожу в primary, монтирую раздел, работаю некоторое время, отмонтирую раздел, перевожу в secondary, на первой ноде подключаю сеть, перехожу на primary, монтирую раздел.

Sherman
() автор топика
Ответ на: комментарий от Sherman

Ноду отключаю от свитча, отмонтирую раздел

А разве могло быть иначе? При демонтировании фс пишет какой-то бит, про который второй узел ничего не знает. Сеть нужно отключать после перевода в secondary, как мимнимум после отмонтирования(если при переводе ничего важного не пишется).

DonkeyHot ★★★★★
()
Ответ на: комментарий от DonkeyHot

Тогда в чем смысл системы? Я имитирую внезапную смерть ноды, когда невозможно перевести ее в то или иное состояние. Меня удивляет почему drbd не обрабатывает такие ситуации. Даже если не делать ничего с первой нодой, а просто уронить, а потом также ничего не делая поднять, результат будет тот же - каждая из нод не будет видеть соседа, пока на одной из них не убить все файлы. Мне нужен отказоустойчивый кластер из двух нод, к сожалению я не могу поставить третий сервер/корч для запиливания сетевого хранилища или развертывания ceph. Остается только вариант с мультинодовым сервером, но это уже оверкилл. Как то же люди настраивают drbd и у них все работает. Я видимо где то допустил/допускаю ошибку, но не могу понять где...

Sherman
() автор топика
Ответ на: комментарий от Sherman

Мне нужен отказоустойчивый кластер из двух нод

Отказоустойчивый кластер из с консистентными данными не может пережить обрыв сети. Вообще никак. Просто падение, вероятно, мог бы — но это очень похоже на сильную зависимость от удачи и отсутствия трафика и деталей реализации[где мои знания заканчиваются]. Авторы могли этим не заморачиваться, т.к. всё равно никаких гарантий и никому не нужно.

в чем смысл системы

1. пережить контролируемое неизбежное/вероятное в будущем падение. 2. восстановить сервис с минимальными потерями.

Быстрое восстановление отказоустойчивости не обещалось.

DonkeyHot ★★★★★
()
Последнее исправление: DonkeyHot (всего исправлений: 1)
Ответ на: комментарий от Sherman

Мне нужен отказоустойчивый кластер из двух нод

Как показала практика, все чудесные и вполне работающие решения по High Availability вообще никак не рассчитаны на автоматическое приведение системы в штатное состояние _после_ ремонта поломки.

HA система спокойно переживает отказ одной ноды, а вот дальше начинается цирк с конями и лунапарк без шахмат и поэтэсс.

Для себя я принял такую методику работы с этой шнягой:

1. Система работает

2. Внезапно происходит отказ одной части, система продолжает работать.

3. Планируем штатную остановку системы для ремонта в удобное для нас время.

4. Ручками приводим систему в изначальное сотояние в удобное для нас время.

В общем, никто из создателей HA решений вообще ни разу не озаботился вопросом автоматического возвращения системы в штатный режим. Решали проблему доступности при отказе, а что там дальше будет - никого не волновало.

Так что либо самому решать эту проблему фактически с нуля, либо следовать вышеописанному алгоритму.

Stanson ★★★★★
()
Ответ на: комментарий от post-factum

Мониторы можно и на сами хосты поставить, но третий все равно не помешал бы, для кворума.

Deleted
()
Ответ на: комментарий от alestro

Бгг. :) На самом деле оно вообще не про то.

Хотя бы одно описание процесса _восстановления_ сдохшей ноды без остановки/перезапуска сервиса - в студию. :)

ЗЫ: Все хаутушки про все возможные HA в лучшем случае заканчиваются на «теперь ваш кластер/HASystem работает». И ни в одной из них нет примера того, как автоматически и без бубна восстанавливается система после ремонта и подключения сдохшей ноды. Даже наиболее адекватную галеру - и ту надо пинать, после того, как сдохшую тачку заменили.

Stanson ★★★★★
()
Ответ на: комментарий от alestro

pacemaker рулит состояниями сервисов нод, да он автоматом переведет ноду в primary/secondary, но ни как не поможет решить трабл с DRBD когда ноды не видят друг друга, до тех пор, пока не срубишь данные на упавшей ноде и не начнешь полную синхронизацию, это первое, на два - pacemaker не ставится рядом с PVE.

Sherman
() автор топика
Ответ на: комментарий от Stanson

После ресета мастер ноды(по питанию, к примеру) у меня мастер переезжает на слейв, туда же переезжает айпишник, после включения она становится слейвом - этим и рулит pacemaker. Даунтайм есть, но достаточно небольшой. Было дело, когда DAC между нодами сбоил - даже в этом случае всё отработало корректно, без сплитбрейна. После замены DAC'а вручную синхронизовал слейва и включил ноду обратно, тут пришлось пошаманить, но без даунтайма. Но это вообще не самая обыкновенная ситуация.

alestro
()
Ответ на: комментарий от alestro

После ресета мастер ноды(по питанию, к примеру) у меня мастер переезжает на слейв, туда же переезжает айпишник, после включения она становится слейвом

Это вовсе не полное восстановление изначальной конфигурации, да ещё и с даунтаймом. А весь смысл HA как раз в том, чтобы даунтайма не было вообще, ни при падении ноды, ни при её подключении.

И конфигураций, кстати, может быть великое множество.

ЗЫ: А DRBD - ваще казлы и редиски, так и не приняли патчи для protocol D от Xen/Remus, из-за чего весьма многообещающая и мегауниверсальная система обеспечения HA фактически сдохла.

Stanson ★★★★★
()
Ответ на: комментарий от alestro

не поделитесь конфигом своего DRBD? Все что вы описали выше может рулится скриптом в 10 строк и ставить для этого новогоднюю елку под название pacemaker/heartbeat/etc не вижу смысла.

Sherman
() автор топика
Ответ на: комментарий от Stanson

Ну так это DRBD, для нормального HA выше Ceph уже советовали.

alestro
()
Ответ на: комментарий от Deleted

Третий как бы обязательный, иначе хватит одного.

post-factum ★★★★★
()
Ответ на: комментарий от post-factum

Может и не так плохо это решение... а что если поднять 4 монитора цефа на двух нодах? 2 физические и 2 виртуальные для кворума в случае падения одной из нод.

Т.е схема будет заключаться в том, что при падении одной из нод, остаются 2 монитора, которые между собой реплицируют недостающие данные, а когда упавшая нода готова, то сначала включаем физический монитор, а после того как данные распределятся согласно «кворуму из трех» запускать 4-й виртуальный экран. Таким образом данные всегда будут актуальными и не будет разницы какая из нод упала.

В вашем варианте есть один недостаток - если первая нода, на которой будет 3 монитор, умрет, полностью, от слова совсем, тогда данные будут похеренытеряны.

Поправьте, если я в чем то не прав.

Sherman
() автор топика
Ответ на: комментарий от post-factum

Т.е. если я правильно понимаю, вы имеете ввиду, что на третьем мониторе никаких данных не будет храниться? Он будет отвечать только за кворум? Я просто думал, что данные хранятся на всех хостах входящих в цеф-кластер...

Sherman
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.