Потеря кворума в Proxmox

Proxmox - достаточно гибкая система виртуализации. С его помощью можно построить как многонодовые кластеры с High Availability, так и запустить пару виртуалок на отдельном серваке. В моем случае используется 2 сервера с общим хранилищем бекапов на nfs.
Не буду вдаваться в теорию настройки (можно почитать в wiki), упомяну только, что для управления кластером необходим непрерывный доступ к общему хранилищу, даже если оно используется раз в несколько дней. Однако бывают ситуации, когда этот самый доступ неожиданно пропадает. Сетевое оборудование, например, заглючило, или nfs понадобилось перезагрузить.И вот тогда начинаются проблемы. Нет, с виртуалками все нормально - работают, доступны, настраиваются. А вот с бекапом, миграцией, созданием и удалением все не так радужно. Дело в том, что ноды кластера теряют кворум.
При входе в веб интерфейс Proxmox это заметно по состоянию нод:

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

Упс... Что делать?
Пробуем дергать сервисы:
/etc/init.d/cman restart - не помогает
/etc/init.d/rgmanager restart - мимо
/etc/init.d/pve-manager restart - не то
/etc/init.d/pve-cluster restart - 8(
/etc/init.d/pve-daemon restart - все, демоны кончились.

Да что такое! Я ведь помню, что реанимировал кластер в прошлый раз именно таким образом. Собственно, я не помню последовательность перезапуска, поэтому и начал писать заметку на память.
Лезу в историю команд, выявлять закономерность. Ага, в прошлый раз были cman, rgmanager и pve-cluster, а сейчас pve-manager еще затесался. Делаю как раньше - кворум!

Судя по выводу в консоль при выполнении команд, к нашей проблеме имеют отношение только cman и pve-cluster, остальное можно не дергать. Так это или нет - проверю в следующий раз.

Openfire в Elastix

Как выразился коллега с форума elastix.org - facking elastix!
Иногда по необъяснимым причинам перестают работать сервисы, запущенные на этой замечательной системе. Asterisk, там, или, как сегодня - openfire. С зависанием астера пока не разобрался, лечусь ребутом раз в пару месяцев, а вот сервер сообщений победить удалось.
Симптомы следующие: отваливаются клиенты, нет соединения на порт 9090, при этом сервис openfire запущен и его рестарт ничего не дает.
В логах на - пусто, единственное сообщение про avahi. На всякий случай перезагружаем и его - ничего.
В веб-интерфейсе после перезагрузок состояние openfire переходит в service not activated. Гугл предлагает уже проведенные манипуляции с /etc/init.d/openfire.
И тут меня осенило!

ps aux|grep open

daemon    7342  158  2.6 673520 54144 ?        Sl   15:50   0:09 /opt/openfire/jre/bin/java -server -DopenfireHome=/opt/openfire -Dopenfire.lib.dir=/opt/open.jar

/etc/init.d/openfire stop
ps aux|grep open

А картина та же! После остановки сервиса его процесс остается запущенным. Естественно, новый процесс не может подключиться к занятым портам, клиенты и браузер соответственно тоже.
Убить!

kill -9 7342
 /etc/init.d/openfire start
Теперь все в порядке.

Миграция между локальными хранилищами в Proxmox.

Обнаружил что я необычайно туп.
Около года занимаюсь администрированием класьера из 2 нод на базе Proxmox. Сначала система была организована с использованием drbd, однако производительность дисковой подсистемы оставляла желать лучшего. Нагруженные виртуальные машины (например сервер 1С, терминальный сервер или сервер баз данных) нельзя было разместить в таком хранилище, а оставшиеся несколько (ldap, DC, мониторинг) имели очень маленький объем, и в случае чего восстанавливались из бэкапа буквально за пару минут. После очередного split brain я заменил HDD в серверах на SAS и переконфигурировал кластер с использованием только локальных хранилищ. Честно говоря, проблем с его обслуживанием стало намного меньше (когда я словил первый split brain прошлым летом, мне даже пришлось пропустить корпоратив на Алтае - автобус с коллегами устал ждать пока я все починю 8( ). Единственным минусом для меня была невозможность миграции межу серверами. Для переноса виртуальной машины я сначала архивировал ее, потом восстанавливал на другой ноде, гасил на первой и включал на второй. Согласитесь, весьма времязатратное мероприятие. Если же все-таки провести миграцию, то виртуальная машина с конфигами переместится на другую ноду, но образ диска останется на первой:

 После этого можно с помощь scp скопировать фай образа, однако это же не комильфо...
Я даже писал на официальном форуме, но ответа не получил.
Но сегодня мои мучения подошли к концу! Когда я бороздил просторы Хабра. то натолкнулся на цикл статей по использованию кластера Proxmox: статья1, статья2. статья3. Потребности у нас с автором разные, соответственно настройки тоже. Однако некоторые рассуждения натолкнули меня на мысль поэкспериментировать.
Итак...
В настройках хранилища Proxmox есть одна любопытная опция "Общедоступно". По примеру доставшегося мне в наследство хранилища на drbd,я всегда ставил там галку. Но подумайте, что она означает? Эта галочка означает, что все сервера в кластере имеют прямой доступ к данному хранилищу, то есть могут туда свободно писать и читать. Ведь для локального хранилища это не так! Убираем галочку:

Миграция тут же проходит успешно:

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

Или я опять не догоняю?

openSUSE 12.3, ldap, sssd и crash thunderbird

Сразу после релиза openSUSE 12.3 сделал обновление на рабочем компе. Тут же вылезли косяки - не проходила аутентификация пользователя через ldap сервер, не запускался X при перезагрузке (приходилось стартовать руками) и т.д. Обычно я не использую новые версии ОС, предпочитаю подождать несколько месяцев пка накопится достаточное количество обновлений и исправлений. Вот и в этот раз откатился на 12.2.
Однако на днях прикупил новый SSD и, помня о неудачном обновлении "сюзи", решил поставить на него систему с нуля. Установка, первоначальная настройка - а проблемы все те же. Итак, приступим.
По умолчанию настройка клиента ldap в openSUSE 12.3 произходит с использованием демона sssd. Что это такое и с чем его едят рассказывать не буду, хотя в теории штука весьма "вкусная". Скажу только, что для "сюзи" (пробовал и 12.2 и 12.3) нормально его приготовить у меня не получилось. Технология достаточно новая, нормальная документация есть только у РедХат, howto в Интернете мало, а на русском тем более. Поэтому освоение ее я отложил на потом. Однако работать с ldap надо уже сейчас! Меня уже не испугать настройкой ldap из командной строки (ссылка, ссылка), поэтому сразу же удаляю sssd и устанавливаю pam_ldap и nss_ldap:

zypper rm sssd
zypper in pam_ldap nssd_ldap

После этого редактирую /etc/ldap.conf согласно моим настройкам сервера:

base dc=mydomain,dc=local
uri ldap://mydomain.local

Тут же начинают работать команды id user и getent passwd. Казалось бы можно работать, но не тут-то было - аутентификация по прежнему не работает. Логи малоинформативны, но однозначно говорят, что ldap работает. Что еще может влиять на  логин пользователя? Конечно же pam! Сравнение файлов конфигурации из каталога /etc/pam.d/ на openSUSE 12.1 и 12.3 ничего не дает, там все идентично. В дело вступает google.ru
Я уже не помню что и как искал, но в конце концов наткнулся на ресурс, с которого и следовало начать - openSUSE 12.3: Security Guide Во второй главе Authentication with PAM черным по белому написано как настраивать pam для тех или иных случаев. Меня интересует всего лишь одна команда:


pam-config --add --ldap

Все. После этого система работает также как и 12.2, и 12.1, и 11.4 до нее. Я расслабляюсь и получаю удовольствие от нового KDE 4.10
Но это еще не все. При настройке почты сталкиваюсь с крэшем thunderbird сразу при запуске. Вспоминаю о подобном в Xubuntu 12.04 и проверяю nscd. В openSUSE 12.3 он установлен и работает по умолчанию. В логах пусто. Пробую strace. Я не программист, поэтому ничего не понимаю в выводе, но замечаю перед записью дампа обращение к либам ldap. Выясняю, что действительно крах thunderbird происходит только для пользователя с авторизацией в ldap. В поиске находится масса аналгичных ситуаций для freebsd, ubuntu, fedora и opensuse, но решения с переименованием библиотек, наложением патчей и прочей серьезной правкой системы я стараюсь не применять. В конце концов на каком-то opensuse-форуме встречаю любопытное предложение - nss-pam-ldapd. Ну чтож, проверим:

zypper in nss-pam-ldapd

Установка требует удаления nss_ldap и pam_ldap. Несколько минут чтения документации на новое ПО и правка файла /etc/nslcd.conf

base dc=mydomain,dc=local
uri ldap://mydomain.local

Теперь точно все. Аутентификация в ldap через nss-pam-ldapd и thunderbird работает!