LINUX.ORG.RU
решено ФорумAdmin

corosync & iscsi (не target)


0

1

Привет всем. Что-то у меня с этим high-availability скоро крыша съедет. Хочется: подключиться к iscsi-хранилищу, смонтировать файловую систему и запустить какой-нибудь апач. Всё это в кластере. Для подключения к iscsi использую агента ocf:heartbeat:iscsi, вот с ним какая-то дурацкая проблема. Вернее, проблема с ним совершенно понятная, только непонятно почему в этом коросинке нихрена с этой проблемой сделать не удается.

В общем, настроен ресурс, из параметров только portal и target. Когда всё запущено и работает нормально, этот ресурс тоже запускается и работает. Но если вдруг в момент запуска этого ресурса target оказывается не доступен - всё, жопа.

corosync воспринимает это как полный капут, и убирает ресурс с узла кластера вообще. В логах появляется следующее:

pengine: info: get_failcount: iscsivol2 has failed INFINITY times on node2 pengine: warning: common_apply_stickiness: Forcing iscsivol2 away from node2 after 1000000 failures (max=1000000)

Просто отпадные заявления по поводу одной-единственной ошибки. А главное - вернуть его не удается, вообще. Пока кластер не перезапустишь, никакие танцы не помогают - unmanage/manage, stop/start - всё пофиг.

Вопрос: как ему сказать, что если iscsi target отвалился, то надо всего лишь попробовать запустить этот ресурс позже. Или, хотя бы, как его вручную пнуть, чтоб заработал?

pacemaker 1.1.8, corosync 2.2.0, fedora 18.

Так-с. Нашёл как его перезапустить принудительно. Ещё бы как-то его заставить работать как задумано...

Чтобы перезапустить «зависший» ресурс нужно использовать legacy команду:

crm_resource --resource <resource_name> --cleanup

после этого ресурс можно запустить повторно

pcs resource start <resource_name>

По-идее, бинарник crm_resource - наследие прошлого, и напрямую использоваться не должен (всё должно делаться через pcs или какое-нибудь gui), только в pcs соответствующей команды нет.

shamus24
() автор топика

Ресурс это - обычно - просто скрипт. Покопайся в нем и посмотри в чем проблема, там всё довольно просто, я как-то писал ресурс для iscsi таргета SCST.

blind_oracle ★★★★★
()

Почти все ресурсы - это скрипты. Если ты полностью понимаешь логику работы, то можешь написать собственные полностью (я когда-то так и делал года 2-3 назад, когда только осваивался на домашних серверах виртуализации, хотелось чего-то эдакого, т.к. были странные проблемы с апачем).

Какую ФС используешь? Multipath почему не используешь?

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

Я знаю, что ресурсы - это скрипты, проблема не в ресурсе. Он отрабатывает правильно - target недоступен, сообщает об ошибке, а что он ещё может сделать? Вопрос в том, почему pe_engine так странно на эту ошибку реагирует, а именно - навсегда помечает ресурс как полностью недоступный, и в дальнейшем просто игнорирует любую команду, связанную с этим ресурсом.

Это примерно как если бы вы сделали «cat file», а файла «file» нет, и после этого до перезапуска системы вам бы любая команда при работе с файлом «file» сообщала бы, что такого файла нет, хотя вы его уже сделали.

Кое-что нашел по этому вопросу. У кластера есть свойство «start-failure-is-fatal», его можно установить в false, но результат этого действия не совсем понятен пока. Правильно работать оно не стало, хотя что-то изменилось.

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

А почему нельзя после возобновления работы (ha.d же? там просто на start скрипта делаешь враппер на перезапуск нужного демона кластера) нельзя тупо рестартануть нужный демон?

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

Предположение было правильное.

start-failure-is-fatal=false

это то, что нужно в этом случае. Если сконфигурировано это свойство, то кластер пытается перезапустить ресурс. В моем случае это сразу не сработало, поскольку ещё и target выделывается, но это уже не относится к кластеру. Важно, что ресурс будет пытаться запуститься повторно, пока не получится, или не исчерпается количество попыток.

Свойство конфигурируется так:

pcs property set start-failure-is-fatal=false

на любом узле кластера.

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