У меня есть несколько проблем, пытающихся понять ha.cf и то, как кластер принимает обновления.
Например, при создании нового кластера я обычно:
Хотя я обычно делаю узлы вверх / вниз, ресурсы вверх / вниз, я никогда не добавлял новый узел позже.
Просто для развлечения я решил запустить новый сервер, который указывал только один узел в кластере в его ha.cf, а затем запускал heartbeat.
Эта машина успешно присоединилась к кластеру и добавилась ко всем остальным узлам в кластере .... Меня смущает то, что даже если я выключу все узлы и перезагружу исходные 2 узла, у них обоих все равно будет третий сервер, как в кластер, но не в сети, несмотря на то, что третьего не было в исходном файле ha.cf из двух узлов.
Даже если я редактирую ha.cf и изменяю какое-то бессмысленное значение / или касаюсь файла, перезагружаю сервер и кластер, он все еще там. Итак, я пришел к выводу, что CIB имеет преимущество перед ha.cf, но я не понимаю, почему и как.
Я действительно ищу передовой опыт - нужно ли на любой машине достаточно ha.cf, чтобы "заработать", а затем делать все в CRM? Ha.cf - пустая трата времени или мне стоит использовать его гораздо чаще?
Стараюсь не быть таким расплывчатым - я действительно просто ищу, что мне делать в CRM, и что мне следует делать в ha.cf?
Спасибо,
Wil
Очевидно, вы запускаете Pacemaker, диспетчер кластерных ресурсов, поверх Heartbeat v3, уровня обмена сообщениями кластера. Вы можете найти больше информации Вот. Например, более старые версии Heartbeat требовали, чтобы пользователи добавляли конфигурацию узла ping в ha.cf, это больше не требуется для агента ресурсов pingd в Pacemaker.
Роль агента ресурсов состоит в том, чтобы абстрагироваться от услуги, которую он предоставляет, и представлять согласованное представление для кластера, что позволяет кластеру не зависеть от ресурсов, которыми он управляет. Кластеру не нужно понимать, как работает ресурс, потому что он полагается на то, что агент ресурсов будет делать правильные вещи при получении команды запуска, остановки или мониторинга.
Таким образом, вы должны различать конфигурации и проверять следующее в своем
/etc/ha.d/ha.cf
mcast ...
bcast eth..
#disables automatic joining <== Do you have "autojoin any", here ?
autojoin none
node node1 node2
# for enabling Pacemaker under Heartbeat 3.04
pacemaker respawn
#and check manpage to track deprecated directives (baud, auto_failback, stonith, etc.)
Вы перечитываете сервис хорошего сердцебиения?
kill -HUP $ GoodHeartbeatPID
CRM требуется фиксация (cib.xml (также известная как информационная база кластера) создается этой командой)
crm_verify -L -V
cib commit $ yourconf
Также проверьте свои хосты / etc / hosts, DNS и т. Д.
на все еще активном узле. Это отключит ресурсы вашего кластера.
/etc/init.d/heartbeat stop
на резервном узле (на том, где вы создали свой CIB). Это запустит локальный экземпляр Heartbeat и Pacemaker и будет ждать, пока другие узлы кластера не зарегистрируются.
/etc/init.d/heartbeat start
на вашем другом узле. Это запустит локальный экземпляр Heartbeat и Pacemaker, автоматически загрузит CIB и запустит приложения.
/etc/init.d/heartbeat start
С уважением
Я действительно очень надеялся увидеть хороший ответ.
Все, что я действительно могу сделать, это поддержать ваш опыт: единственная реальная функция сердцебиения в этих обстоятельствах - запускать кардиостимулятор, подсистему CRM. Он (как вы знаете) поддерживает свою собственную базу данных узлов и состояний, которая в моих системах /var/lib/heartbeat/crm/cib.xml. Файлы в /etc/ha.d поставить в известность heartbeat, но нет crm.
Я использую несколько пар аварийного переключения, выполняющих различные операции, большинство из которых работают более 500 дней, а некоторые - около 1000 дней, и большинство из них пережили любое количество переключений и аварийных переключений; поэтому я могу только предполагать, что делаю что-то правильно. Моя практика - не врать ha.cf, но не помещать туда почти ничего, кроме того, что требуется для обеспечения высокой доступности для запуска CRM.
Извините, у меня нет ничего более конкретного, чтобы указать вам.