Непонятность с pacemaker'ом

08.05.2013 11:08 · отредактировано #319775

Привет всем!

Есть проблема.
1 Два стендовых виртуальных хоста под осью CentOS 6.4.
2. На них развернут DRBD в режиме Primary/Secondary стандартным образом.
3. Далее точим это дело под pacemaker. Причем иметь на drbd не один том, а несколько, LVM нам в помощь. То есть сажаем LVM на DRBD-том следующим образом (без каких либо затей):

text

#pvcreate /dev/drbd0
#vgcreate vg_drbd /dev/drbd0

И далее создаем в группе томов LVM потребное нам количество LVM-томов заданного размера.
4. Вводим это дело в pacemaker стандартным образом, делаем ресурс drbd-тома, к нему подвязываем ресурс LVM, далее поднимаем файловые системы на LVM. Всё это формально работает, стартует как прописано и мигрирует на резервную ноду кластера как положено.
НО.......
5. Проблема. На резевной ноде можно поработать даже, но если поднимается основная нода и нам надо вернуть весь этот махарай взад - всё, что сделано на резевной ноде накрывается медным тазом. Состояние DRBD возвращается к тому моменту, когда "отвалилась" нода, ведущая Primary-раздел DRBD. То есть pacemaker (или само drbd) принудительно синхронизирует состояние тома по весьма древней копии, кладет на то, что primary-раздел был перед переключением взад совсем иным...

Получается, что pacemaker+drbd+LVM гробит при миграции ресурсы. С этим кто нибудь кроме меня сталкивался?
---------------
Кстати, убрал из цепочки LVM. Всё тоже самое... Состояние возвращается в первобытное, до миграции primary-раздела drbd на резервную ноду.

Чтение журналов показывает, что drbd честно обнаруживает после восстановления primary-ноды состояние split-brian, но выполняет синхронизацию не с резевной ноды (на которой данные гораздо более актуальные, а с проснувшейся... Но это же неправильно...

08.05.2013 11:14 · отредактировано #319776

Покажи как у тебя ресурс сконфигурирован, раздел handlers, присутствует ли там опция:

text


before-resync-target "/usr/lib/drbd/snapshot-resync-target-lvm.sh";
after-resync-target "/usr/lib/drbd/unsnapshot-resync-target-lvm.sh";

Да и не забываем, то что поддержка lvm в drbd появилась как ни как с версии 8.4.

Хотя, в данном примере используется снапшоты, но все же.

08.05.2013 11:20 · отредактировано #319778

"Cruiser78⇓" написал:
что сделано на резевной ноде накрывается медным тазом. Состояние DRBD возвращается к тому моменту, когда "отвалилась" нода, ведущая Primary-раздел DRBD.

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

08.05.2013 12:13 #319787

i2ks написал:
[quote="Cruiser78⇓"]что сделано на резевной ноде накрывается медным тазом. Состояние DRBD возвращается к тому моменту, когда "отвалилась" нода, ведущая Primary-раздел DRBD.

Походу у тебя где то жестко прописано, то что одна нода может быть мастером что ли[/quote]

1. DRBD у меня версии 8.4.2. То есть - почти последняя.
2. Конфигурация тома DRBD - под спойлером, тривиальная:

Показать

resource r0 {
protocol C;
# incon-degr-cmd "echo '!DRBD! pri on incon-degr' | wall ; sleep 60 ; halt -f";
startup {
degr-wfc-timeout 120; # 2 minutes.
wfc-timeout 60;
## become-primary-on both;
}
handlers {
split-brain "/usr/lib/drbd/notify-split-brain.sh root";
}

disk {
on-io-error detach;
no-disk-flushes;
no-md-flushes;
# size 5144576;
}

net {
max-buffers 8000;
max-epoch-size 8000;
sndbuf-size 8M;
ko-count 4;
allow-two-primaries; # Важно! разрешаем быть обоим узлам primary (для зеркалирования данных)
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
}

syncer {
rate 110M;
al-extents 3389;
verify-alg crc32c;
}

on tom-virt {
device /dev/drbd0;
disk /dev/mapper/vg_tomvirt-LV_DRBD;
address 192.168.43.45:7788;
meta-disk internal;
}

on jerry-virt {
device /dev/drbd0;
disk /dev/mapper/vg_tomvirt-LV_DRBD;
address 192.168.43.43:7788;
meta-disk internal;
}
}

Там томам разрешено быть обоим в режиме Primary, но пользуюсь исключительно P/S. Не верю пока в dualPrimary.
3. Если отключаю pacemaker и пытаюсь руками смоделировать миграцию drbd-тома (таже без LVM, с ext3-файловой системой) - ошибок не возникает. Заданные правила восстановления после split-brian четко различают тома, и синхронизация идет с того тома, на котором данные актуальны. То есть ноду могу отключить (то есть остановить drbd-сервис на ней), сделать Primary другую ноду, поработать на ней, вернуть её в Secondary-состояние, потом включить первую ноду, поднять её в Prymary - все нормально синхронизируется. Смоделировать руками на DRBD данный эффект у меня не получается.
Резюме: к DRBD претензий нет
4. Поднимаем pacemaker и имеем радость -
4.1 pcs cluster standby node1 - нода отключается и drbd как положено мигрирует на резевную ноду.
4.2. работаем на резевной ноде.
4.3. pcs cluster unstandby node1 - нода включается, drbd-том том станивится на ней primary и затирает все наши работы на томе резервной ноды. Синхронизация идеи с него. А надо - с резервной на него.

Поэтому и грешу на Pacemaker (pacemaker-1.1.8-7.el6.x86_64 из стандартных CentOS репов). Что-то он мудрит при миграции drbd-тома.

08.05.2013 12:19 #319789

"Cruiser78⇓" написал:
4.2. работаем на резевной ноде.

она должна перейти в статус мастера, так ли это?
а в crm configure show что у тебя там? :-)

08.05.2013 12:42 · отредактировано #319793

i2ks написал:
[quote="Cruiser78⇓"]4.2. работаем на резевной ноде.

она должна перейти в статус мастера, так ли это?
а в crm configure show что у тебя там? :-)[/quote]

1. Если она не переходит в статус мастера, то как на ней можно работать? Нет, туда (на резерв) всё уходит корректно. А вот с возвращением взад - проблемы.
2. crm почил в бозе. Нет больше этого шелла (начиная с pacemaker версии 1.8.чегототам). Вместо него предложено пользоваться унифицированным pcs. Вывод конфига по нему мне нравится меньше, чем у crm, а вот pcs status - показывает лучше.
Итак - конфиг под спойлером:

Показать

Corosync Nodes:

Pacemaker Nodes:
jerry-virt tom-virt

Resources:
Master: ms_drbd_res
Resource: drbd_res (provider=linbit type=drbd class=ocf)
Attributes: drbd_resource=r0
Operations: monitor interval=10
Group: gFS
Resource: iscsiIP (provider=heartbeat type=IPaddr2 class=ocf)
Attributes: ip=192.168.43.205 nic=eth0 iflabel=205 cidr_netmask=24
Operations: monitor interval=30s
Resource: res_fs (provider=heartbeat type=Filesystem class=ocf)
Attributes: device=/dev/drbd0 directory=/mnt/drbd/bases fstype=ext3

Location Constraints:
Resource: ms_drbd_res
Enabled on: tom-virt
Enabled on: jerry-virt (score:50)
Ordering Constraints:
promote ms_drbd_res then start gFS
Colocation Constraints:
gFS with ms_drbd_res (with-rsc-role:Master)
gFS with ms_drbd_res (with-rsc-role:Master)

Cluster Properties:
dc-version: 1.1.8-7.el6-394e906
cluster-infrastructure: cman
stonith-enabled: false
no-quorum-policy: ignore

3. Нашел, что чудесато ведет себя именно "усыпление" ноды. По pcs cluster standby|unstandby. Если pacemaker-ноду глушить более радикально (service pacemaker stop; service drbd stop), то миграция происходит чуть иначе. На резервную ноду всё уходит как положено, а вот обратно, когда pacemaker на основной ноде поднимается - drbd возвращаться в автомате не хочет. Не отрабатывает и команда pcs resource move ms_drbd_res tom-virt. Мастер drbd остается на резервной ноде. Передвинуть его на основную можно только через standby-unstandby резервной ноды. Тогда оно мигрирует куда надо. Естественно данные при этом не теряются, поскольку основная нода какое-то время пожила в Secondary режиме под действующим мастером и синхронизировалась.

А вот если хотим обойтись только pcs cluster standby|unstandby, то мастер оперативно перезжает на основную ноду и усиленно трёт все изменения на drbd, что были сделаны на резервном томе. Считает, что данные тома основной ноды более важны.

==================

Снова посадил на кластер, на DRBD LVM-тома (и уже в них развернул ext3). Теперь имею полную задницу. При возвращении пасемакером ресурса взад, с резервной на основную ноду, независимо от того, как её отключал, через pcs standby или через service stop, синхронизация томов идет только с основной ноды. И все изменения, сделанные на резервной накрываются медным тазом. :(
------------
Обновил pacemaker до самой последней версии, до 1.1.9-1512.el6, раздаваемой репозиторием разработчика, ClusterLabs'ом. Никаких изменений, всё тоже самое. Синхронизация LVM идет только в одном направлении, с основного master'a.

Похоже, надо отказаться от идеи автоматического возвращения drbd-мастера на ту ноду, где он планируется в основном режиме эксплуатации.