Как стать автором
Обновить

Комментарии 16

заводим два stonith ресурса, каждый отвечающий за свой узел и запрещаем им работать на узле, который они должны пристреливать

Т.е. у вас два молодца держат пистолеты у своего виска и если соседа нет — пускают пулю сами себе?
Как раз наоборот. Пистолеты они держат у виска соседа. И триггер не по отсутствию соседа, а по сбою критичного ресурса у этого соседа. Вариант с ipmi конечно далёк от идеального, но это всё что у меня пока есть.
А соеденены у вас ноды кластера как? напрямую в сетевые или через свичи? Если у вас потеряется линк между живыми нодами — у вас будет два мастера и по восстановлении линка получите кашу.
Просто по ссылке, на которую вы ссылаетесь при настройке такого механизма как раз и советуют выключить этот механизм для нод меньше трех :)

Вообще по опыту — сложные схемы запуска служб в кластерах у меня работали криво :) Может руки конечно, не исключено.
Эту схемы вы тестировали? Она уже у вас какое-то время работает?
Соединено через свичи и да, возможна ситуация двух мастеров при выходе из строя сети. Я пробовал такой сценарий — после возвращения сети один узел другой пристреливал и ситуация в итоге нормализовалась, правда статусы ресурсов всё равно нужно было сбросить в ручную.

Я думал ввести какой-нибудь дополнительный механизм контроля, либо через COM, либо по флагу через GFS2 и общее хранилище (нужно тестировать). Но пока не реализовал.

Кластер успешно работает уже некоторое время и держит LXC контейнера с не критичными службами, продолжаю переносить туда контейнера из OpenVZ.

В планах третий узел и сценарии будут более разнообразны.
Ещё можно увеличить migration-threshold, тогда ресурсы не будут метаться между узлами при любом чихе и серьёзных последствий в результате split-brain быть не должно.
Спасибо за ответы, удачи в работах :)
Спасибо за статью
Скажите а откуда взялиьс у вас /dev/mapper/mpatha1 и почему у меня их нет?
Пытаюсь повторить ваши шаги на паре виртуалок c OL 7.1
Спасибо за проявленный интерес.
Это multipath устройство, так как SAS хранилище у меня подключено двумя линками. На втором сервере используется единственный FC, и там привычное /dev/sdc.

Вообще, сойдёт любое общее блочное устройство — lvm разберётся, что куда.
А не подскажите как можно извернуться и включить STONITH для виртуалок?
Есть подозрение, что в таком случае оно утрачивает свою функциональность. Можно воткнуть заглушку:
configure
primitive st-null stonith:null \
params hostlist=«alice bob»
clone fencing st-null
commit
(это на crm)
www.suse.com/documentation/sle-ha-12/book_sleha/data/sec_ha_fencing_config.html
Или через SSH прикрутить, там есть оба варианта:
clusterlabs.org/doc/crm_fencing.html

Там используется crm, с ходу на pcs не подскажу, консоли под рукой нет.
пришлось установить пакет fence-agents-all.x86_64 для поддержки fence agents
ибо до утсановки было
# pcs stonith list fence_ipmilan
Error: No stonith agents available. Do you have fence agents installed?
Похоже этот момент упустил, извините. Внёс исправление.
Хотл было я написать «зачем такие сложности если есть kubernetes.io», но почитал документацию — всё совсем не проще получается.
Но всё равно вопрос — как долго Вы поддерживаете свой кластер?
Второй месяц, срок конечно не большой, но поводов для деградации пока не видно. Полёт нормальный.
К тому же в работе у меня упор на LXC контейнера, Docker — так, посмотреть что за зверь.
И Pacemaker не такой уж и страшный, если разобраться.
Если у вас общее хранилище, подключенное по SAS, то stonith надёжнее настроить через SBD.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории