Я настраиваю HA-кластер для веб-приложения с 2 узлами (2 физических сервера):
master
узел)slave
узел)Используя Corosync & Pacemaker, я смог создать кластер и некоторые агенты ресурсов, включая аварийное переключение IP и веб-сервер (apache).
Failover
ресурс существует только на одном узле одновременноИспользует скрипт python для выполнения вызовов API к моему хостинг-провайдеру для обновления места назначения переключения IP.
WebServer
ресурс существует (как клон) на каждом доступном узлеСтандартный ресурс OCF с использованием Apache
server-status
обработчик
Failover
и WebServer
должен одновременно работать на сервере, чтобы он считался доступным.Теперь я хотел бы создать настраиваемый агент ресурсов (как я сделал для переключения при отказе IP), который будет:
В идеале ресурс должен запускаться только на одном узле (мастер) и остановился на всех остальных узлах (рабы). Следовательно, запуск ресурса поместит текущий узел в master
режим, и остановка переведет его в slave
Режим.
Я сделал сценарий, который легко выполняет все эти операции. Вот как это работает.
Включите локальный узел мастер Режим:
# /usr/local/bin/db_failover_switch.sh master
Включите локальный узел раб Режим:
# /usr/local/bin/db_failover_switch.sh slave 123.45.67.89
Синопсис довольно прост для понимания. Проблема, с которой я столкнулся, заключается в том, что мне, очевидно, нужно установить главный IP-адрес, чтобы подчиненное устройство могло соответствующим образом настроить службы MySQL и Redis.
В случае аварийного переключения я хочу:
node2
который становится master
узелnode1
который становится slave
узелЧтобы остановить ресурс (т.е. установить его в подчиненный режим), мне нужно знать IP-адрес (подойдет имя хоста) узла, на котором запущен ресурс.
Есть ли способ получить динамический параметр, который Pacemaker будет передавать моему агенту ресурсов? Или, может быть, я могу получить информацию о кластерах непосредственно из сценария агента ресурсов, чтобы узнать, на каком узле запущен конкретный ресурс?
После прочтения вашего комментария я не уверен, что вы все еще хотите пойти по тому маршруту, который планировали изначально, но в любом случае вот ввод для этого:
С помощью crm_mon --group-by-node -1
вы можете получить «разовое» представление текущего состояния вашего кластера, сгруппированного по вашим узлам. В -1
Параметр делает это не интерактивным, что означает, что он просто отображает данные, а затем завершает работу.
(Редактировать: Может быть, используя crm_mon -1
упрощает синтаксический анализ в вашем конкретном случае.)
Вы можете проанализировать этот вывод и действовать соответственно.
(Личное примечание: я бы также пошел по маршруту, который вы описали в своем комментарии. В конце концов, это два демона, поэтому два ресурса кажутся разумными. Кроме того, агенты ресурсов для использования уже существуют. Удачи!)