Comments 16
заводим два stonith ресурса, каждый отвечающий за свой узел и запрещаем им работать на узле, который они должны пристреливать
Т.е. у вас два молодца держат пистолеты у своего виска и если соседа нет — пускают пулю сами себе?
Как раз наоборот. Пистолеты они держат у виска соседа. И триггер не по отсутствию соседа, а по сбою критичного ресурса у этого соседа. Вариант с ipmi конечно далёк от идеального, но это всё что у меня пока есть.
А соеденены у вас ноды кластера как? напрямую в сетевые или через свичи? Если у вас потеряется линк между живыми нодами — у вас будет два мастера и по восстановлении линка получите кашу.
Просто по ссылке, на которую вы ссылаетесь при настройке такого механизма как раз и советуют выключить этот механизм для нод меньше трех :)
Вообще по опыту — сложные схемы запуска служб в кластерах у меня работали криво :) Может руки конечно, не исключено.
Эту схемы вы тестировали? Она уже у вас какое-то время работает?
Просто по ссылке, на которую вы ссылаетесь при настройке такого механизма как раз и советуют выключить этот механизм для нод меньше трех :)
Вообще по опыту — сложные схемы запуска служб в кластерах у меня работали криво :) Может руки конечно, не исключено.
Эту схемы вы тестировали? Она уже у вас какое-то время работает?
Соединено через свичи и да, возможна ситуация двух мастеров при выходе из строя сети. Я пробовал такой сценарий — после возвращения сети один узел другой пристреливал и ситуация в итоге нормализовалась, правда статусы ресурсов всё равно нужно было сбросить в ручную.
Я думал ввести какой-нибудь дополнительный механизм контроля, либо через COM, либо по флагу через GFS2 и общее хранилище (нужно тестировать). Но пока не реализовал.
Кластер успешно работает уже некоторое время и держит LXC контейнера с не критичными службами, продолжаю переносить туда контейнера из OpenVZ.
В планах третий узел и сценарии будут более разнообразны.
Я думал ввести какой-нибудь дополнительный механизм контроля, либо через COM, либо по флагу через GFS2 и общее хранилище (нужно тестировать). Но пока не реализовал.
Кластер успешно работает уже некоторое время и держит LXC контейнера с не критичными службами, продолжаю переносить туда контейнера из OpenVZ.
В планах третий узел и сценарии будут более разнообразны.
Спасибо за статью
Скажите а откуда взялиьс у вас /dev/mapper/mpatha1 и почему у меня их нет?
Пытаюсь повторить ваши шаги на паре виртуалок c OL 7.1
Скажите а откуда взялиьс у вас /dev/mapper/mpatha1 и почему у меня их нет?
Пытаюсь повторить ваши шаги на паре виртуалок c OL 7.1
А не подскажите как можно извернуться и включить 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
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 не подскажу, консоли под рукой нет.
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?
ибо до утсановки было
# pcs stonith list fence_ipmilan
Error: No stonith agents available. Do you have fence agents installed?
Хотл было я написать «зачем такие сложности если есть kubernetes.io», но почитал документацию — всё совсем не проще получается.
Но всё равно вопрос — как долго Вы поддерживаете свой кластер?
Но всё равно вопрос — как долго Вы поддерживаете свой кластер?
Если у вас общее хранилище, подключенное по SAS, то stonith надёжнее настроить через SBD.
Sign up to leave a comment.
HA-Cluster на основе Pacemaker под контейнерную виртуализацию LXC и Docker