i2ks написал:
A. Может я не так что делаю:
B. А теперь коротко о pacemaker 1.1.8, в нем сейчас нет crm. Сейчас используется pcs или crmsh. В моем случае все управляется через pcs, так как crmsh я не нашел в репозиториях, а ссылка на проект crmsh ведет на пустой репозиторий.
Если мы используем centos6.x, и хотим использовать pcamekar 1.1.8 то идем сюда:
http://clusterlabs.org/rpm-next/ , и берем rh пакет, далее ставим pacemaker + corosync(он за собой подтянет cman и т.д.), далее ставим pcs, настраиваем corosync.conf и iptables, запускам все это дело.
C. Отвечу на вопрос почему порой долго останавливается corosync/pacemaker:
1. Агент pacemaker не может остановить корректно службу, или к примеру долго останавливается БД и т.д
2. Проблема с сетью, здесь порой у corosync сносит крышу.
3. Если используем drbd, то здесь так же могут возникнуть проблемы, в итоге потом получаем split-brain.
D. Возможно в скором времени напишу how-to, я так смотрю в рунете мало что есть на русском языке, хотя информация на clusterlab исчерпывающая.
А. Может и я неправ. Хотя на стенде, в виртуалки, ставил исключительно с целью отладки pacemaker'а и никакой иной дряни на них не ставил. Исключительно "базовая" установка с минимальным количеством дополнительных служб. Только то, что будет юзаться на промышленных серверах. Не более.
B. Это понятно. Но, увы, это никак не следует из описаний на clusterlabs. Приходится доходить до этого более чем опытным путем. Увы-с. Более того - подача этих описаний наводит на иные мысли. Я их озвучил ранее.
C.
1. В моем случае никаких служб еще нету, но висяк есть. Думал, что это фича "пустого" кластера, но... Там на кластерлабсе есть хавтушка по быстрому старту. В той хавтушке поднимается dummy-сервис, пустышка, как я понимаю. И с ней то же висяк. Хотя, чему там висеть???
2. Какие могут быть проблемы с сетью у двух KVM-машин, висящих на одном бридже? И iptables на хосту настроен на тотальный пропус трафика гостей. Это отпадает.
3. DRBD. Есть знатный глюк. Опытным путем выявил, что если на primary-drbd-томе поднять файловую систему ext4 и запустить на это дело самбу, то потом фиг этот том размонтируешь. Самбу остановить можно легко, но том, при этом, не освобождается полностью. Отсюда - бесконечное ожидание, когда же оно размонтируется. Все курят бамбук. Однако, если на drbd-томе развернута файловая система ext3, то никаких проблем не возникает, останавливаем самбу, размонтируем том, переводим его в secondary-режим на раз-два. Самое интересное, что если мы будем ходить по ext4-тому не самбой (её достаточно только стартовать, обращаться к ресурсам и не надо), а иным приложением, то эффект не проявляется и том размонтируется легко. Выявлено это на Fedora 17 (64bit). Есть ли на иных дистрибутивах - не знаю, еще не проверял.
И еще был один очень интересный глюк с openVPN в этом кластере (опять же на F-17). Стоило только двинуться openVPN-серверу на резервую ноду а потом вернуться назад средствами pacemaker'а, как VPN разваливалась напрочь. Точнее - трафик через туннель от клиента получателю (к этой резервной ноде) у меня шел. А вот обратно - эта резервная нода молчала как партизан в гестапо. Система очень чувствительна к порядку подъема-опускания интерфейсов и старта-стопа openVPN. Пришлось здесь отказаться от услуг pacemaker'а, написать свой инициализирующий скрипт (где четко определить кто за кем стоял) и гонять уже его между нодами в pacemaker'е.
D. Рускоязычные статьи мне попадались в большом количестве. Но, в большинстве своем это более-менее бездарые пересказы оригинальных статей кластерлабса. Даже примеры один в один перетянуты. А вот то, что интересно - найти сложно.
Мне, например, очень помогла бы хавтушка следующего направления:
1. СХД для "бедных". То есть не на специализированных СХД, а на обычной паре крмпьютеров. С показом, что нужно разместить на DRBD (файловый сервер), а что можно на glusterfs, в котором нет mandatory lock, например - хранилище общих конфигов и скриптов.
2. Ориентация этого кластера на виртуальные машины. Как и где разместить образы виртуальных машин (полагаю, что в iSCSI-target'е), как обеспечить к этому хранилищу виртуальных машин доступ с нескольких хостов, на которых будут функционировать эти машины, как обеспечить живую миграцию машин. Причем, эти машины могут мигрировать и между нодами, на которых развернут этот iscsi-target. У меня здесь пока не связывается что-то. Как оно будет переключаться?
Ну а писать хавтушку - как поднять клаcтеный IP - кому оно надо?
