Вот можно с этого места чуть поподробнее? Я, наверное, вдоль и поперек прошерстил /etc/isci/isscsid.conf, но так и не смог заставить iscsid слушаться новых таймаутов и ретраев.  Как будто iscsid эти настройки на игнор ставит.

честно говоря сейчас у меня под рукой нет системы чтоб посмотреть. можно попробовать поговорить с народом на freenode, там обычно разрабы сидят

да, не поможет. iscsid можно настроить иначе, отключить retries

Вот можно с этого места чуть поподробнее? Я, наверное, вдоль и поперек прошерстил /etc/isci/isscsid.conf, но так и не смог заставить iscsid слушаться новых таймаутов и ретраев.  Как будто iscsid эти настройки на игнор ставит.

Почему не NFS? Ответ прост, потому что для хранения общих "метаданных" необходимых для загрузки и работы тех или иных сервисов пользуюсь glusterfs. Конфиги и прочее свалил на него и вполне этим доволен. Пытался положить на glusterfs (3.3.1) образы виртуалок... Не пошло. Точнее пошло, но жило не долго. Завалилось. Ну а на том хосту, где живет glusterfs, там NFS не жилец. Отсюда - помещаем виртуальные машины в iSCSI-LUN'ы.

если делать как я предлагаю - сторедж отдельно, гипервизоры отдельно, то гластер окажется не нужен, и можно будет спокойно поднимать NFS

да, не поможет. iscsid можно настроить иначе, отключить retries

физическая. я говорю о том что две (или более) физических машины должны держать ТОЛЬКО сторедж (кстати, почему не NFS? oн намного корректнее отрабатывает фейловер чем tgtd)

Почему не NFS? Ответ прост, потому что для хранения общих "метаданных" необходимых для загрузки и работы тех или иных сервисов пользуюсь glusterfs. Конфиги и прочее свалил на него и вполне этим доволен. Пытался положить на glusterfs (3.3.1) образы виртуалок... Не пошло. Точнее пошло, но жило не долго. Завалилось. Ну а на том хосту, где живет glusterfs, там NFS не жилец. Отсюда - помещаем виртуальные машины в iSCSI-LUN'ы.

В принципе разобрался в чем именно собака у меня зарылась. А именно "падлой" оказался сервис iscsid (iscsi-initiator) в случае, если он запущен на том же хосту, что и iscsi-target. Он, судя по проявлениям в логе, потеряв соединение с iSCSI-target'ом (мы же таргет остановили для переноса на резервный хост, да и сетевой интерфейс до таржета тоже отключён)  монополизирует почти все ресурсы процессора, останавливает всё, и пытается пропавшее соединение восстановить. При этом всё остальное если и живет, то очень-очень медленно.  И это правильно. Так iscsid долбится монопольно 2 минуты. Потом успокаивается, отдает ресуры остальным процессам и переключение быстренько завершается.

Если мы перед выгрузкой tgtd (в начале процесса миграции) выгрузим iscsi[d], то миграция на резервную ноду (да и там тоже iscsd - лишний совершенно, тоже захватит CPU, как только соединение с таржетом потеряет) проходит за пару-другую секунд. Но если этим не озаботиться, если оставить iscsi[d] на этих нодах - опаньки. Переключение на резерв и восстановление будет проходить минуты за две. А за это время запущенные на iscsi-LUNах виртуалки накроются медным тазом вместе с отслеживающим их pacemaker'ом.

Отсюда, если делаем кластер, в котором живут и iscsi-target (tgtd) и iscsi-initiator, то между ними надо ставить отношение -INFINITY, блокировать их запуск на одном физическом хосту.

Так что переход на LIO мне не поможет. Какая нафиг нам разница, какой именно пакет делает ISCSI-Target, если систему останавливает initiator?

Прошу уточнить - здесь "кластер" это сущность физическая или логическая? Иначе - смогут ли на одних и тех-же хостах ужиться одновременно heartbeat-кластер и pacemaker-кластер?

физическая. я говорю о том что две (или более) физических машины должны держать ТОЛЬКО сторедж (кстати, почему не NFS? oн намного корректнее отрабатывает фейловер чем tgtd)

отдельный кластер для стореджа я советовал с самого начала. что же касается отключения таргета с живыми сессиями, то это проблема tgtd, надо переходить на LIO, все равно он скоро станет основным таргетом в линуксе, а ietd и tgtd отомрут

Прошу уточнить - здесь "кластер" это сущность физическая или логическая? Иначе - смогут ли на одних и тех-же хостах ужиться одновременно heartbeat-кластер и pacemaker-кластер?

...опять 25

нафик этот глючный drbd

Да не, он не глючит у меня. Разобрался немного на стенде. Там собака зарылась в iSCSI, в таргете и в инициаторе. Правда, как вывернуться - не понимаю.

Итак, дано:
1. DRBD в режиме Primary/Secondary. Пока ничего нет, тикает как часы.
2. На этом DRBD-томе поднят LVM и в нем нарезано несколько разных LV под разные нужды, под файлопомойку, под LUN'ы iSCSI. Пока ничего иного нет - тикает как часы.
3. Поднимаем iSCSI-Target и натравливаем его на отдельные LUN'ы, которые живут в LVM, который живет на  DRBD. И даже эта конфигурация тикает как часы. Ресурсы эти мигрируют между нодами pacemaker'а более чем устойчиво. Но на этом устойчивость заканчивается и начинается засада.

Засада: Поднимаем iscsi-initiator (без зависимостей от чего либо, типа как соединение с третьего компьютера). Или LSB (из /etc/init.d/iscsi, как советует LINBIT'овская книжка) или из OCF (heartbeat'овский), неважно как, эффект одинаков.
Инициатор вяжется с таргетом. Всё вроде намано. Но стоит отключить ноду кластера, где сидит таргет (то есть и Primary-том DRBD), то начинаются проблемы. Таргет отключается плохо (у него же есть живое соединение...) за ним плохо становится ресурсу LVM, и далее, по цепочке и DRBD уходит в себя. Точнее - pcs status показывает, что ресурсы то остановились, но вот включиться обратно, на новой ноде, никак не могут.И после этой напасти ресурсы кластера становятся вообще колом, возвращение отключенной ноды помогает, но очень не скоро (десятки минут).

Однако: Если я делаю зависимость (порядок запуска) инициатора с таргетом, стартую инициатор после таргета, то всё возвращается в полный порядок. Вначале выключается iscsi-initiator, потом iscsi-target, потом LVM, далее переключается DRBD и всё снова включается за несколько секунд. Ну, и если я инициируюсь с третьего, внешнго (не включенного в кластер) компьютера, то тоже все переключается намано. 

Так что если есть какой совет на предмет - как правильно организовать в pacemaker-кластере работу с iscsi и drbd (чтобы дальше на инициаторе развернуть виртуальные машины) в рамках одного кластера (чтобы всё жило в одном флаконе) - приму его с удовольствием...

Проблема, как я понимаю в том, что iSCSI-Target не хочет правильно жить с запущенными инициаторами в одном кластере. А вот как вылечить - непонятно...
=======================
Пришла в голову идея. Сервер хранения данных сделать отдельным кластером. На чистом Heartbeat'е. Поднять именно там drbd, LVM и iSCSI-Target со всеми LUN'ами. И путть оно там унутре HeartBeat'а и шуршит. Все равно больше двух нод там никогда не будет (ограничение drbd), так что хватит и HeartBeat'а.
И поднять дополнительно (уже на трех нодах) Paсemaker как ресурсный кластер. В нем, соответственно, замутить инициаторы нужные и все свои ресурсы и виртуальные машины.

Интересно, смогут ли работать одновременно и HeartBeat и PaceMaker?

нафик этот глючный drbd

libvirt проверяет наличие save файла (дамп памяти) где-то в var (точно навскидку не помню). можно в init скрипт либвирта просто добавить уничтожение всех этих файлов, и тогда виртуалки просто включатся как будто у них выдернули питание

А не в курсе, как эту беду http://linuxforum.ru/viewtopic.php?id=28302 побороть?  DRBD просто клинит что-то при отключении ноды, а дальше - весь кластер в pacemaker'е накрывается  медным тазом.
Там простая зависимость: основа - drbd (Master/Slave). От мастера зависит ресурс LVM (drbd-том наррезан на LV-тома). От LVM'а зависят два ресурса, самба (самописный скрипт, который стартует все самбовые причиндалы в нужном мне порядке и останавливает их) и iSCSI-Target.
Самба при отключении ноды отключается хорошо. А вот LVM и, зависящий от него, iSCSI-Target - колбасятся и мешают переключиться мастеру drbd-тома. Он говоит, что занят и уйти в Secondary-режим не может.

Гугление проблемы как то не помогает.

Смотреть параметр

ON_SHUTDOWN=

Спасибо за наводку. Ну а первый (а за ним и второй пункт, бонусом) пункт решил простеньким выключательным скриптом, который вызываться будет из NUT'овских выключательных скриптов:

/etc/sysconfig/libvirt-guests

Смотреть параметр

ON_SHUTDOWN=

Хочу получить совет от умных людей на следующий предмет корректного выключения виртуальных машин при выключении хоста:

Дан набор хостов, которые тянут KVM-виртуалки, которые включаются принудительно (по настройке в virt-manager) при запуске операционной системы хоста.

Симптом: при такой настройке KVM не гасит запущенную виртуальлую машину, а сохраняет её статус. А при запуске - восстанавливает работу виртуалки с "точки останова". Вроде оно и правильно, но есть виртуальные машины (например с тем же астериском) которые такого восстановления не любят, теряют регистрацию у VoIP провайдеров и их приходится после такого восстановительного старта перезапускать. Что мне не очень нравится.

Да и время на сохранение этих образов тоже тратится изрядное. Что мне тоже не очень нравится. Так как подобное выключение делается не по воле админа, на профилактические какие работы, а принудительно. По причине исчерпания заряда на батареях UPS'а. Нету у меня дизель-генератора. И не будет. А бесперебойник держит, максимум, полчаса времени. Электрики же вполне могут отключить електричество (для производства своих работ) и на сильно более долгое время.  То есть, виртуалки от UPS'а надо погасить принудительно как-то иначе.

Это легко решается настройкой master/slave режима в NUT.  Виртуалки гасятся при падении заряда UPS до 20%, сами хосты гасятся при 15%. Вроде всё хорошо, разве что электричество в этот период не появится...

А теперь усложняем задачу - эти хосты объединяем в pacemaker-кластер и виртуалки делаем кластерными ресурсами. А здесь есть монитор, которому на состояние батарей UPS положить глубоко фиолетово. И который, увидев, что какой ресурс отключился, предпримет действия по его запуску. А далее - goto Симптом. Виртуалки, корректно остановленные по UPS, снова запустятся, батарея разрядится до критичесткого уровня, Pacemaker начнет непонятно какую миграцию этих виртуалок, KVM начнет сохранять их статус.... Словом, какая-то каша получается, а не корректное выключение.

Отсюда два вопроса - каков мировой опыт по "тотальному" единовременному выключению хостов pacemaker-кластера, который тянет виртуальные машины?
И второе - как научить KVM не сохранять состояние запущенных виртуальных машин при своем останове, а выключать их? Или выключать их принудительно (например виндовая машина стоит на диалоге, что в ней зарегистрирован юзер, выключиться ей или нет? и пока руками не ответишь....). В virt-manager'е я такой опции не увидел. Разве что в NUT'овские скрипты virsh shutdown интегрировать...