Я работаю над проектом, задающим ритм для наших основных и подчиненных баз данных, чтобы выполнить аварийное переключение на основе IP. Будет два IP-ресурса, один для ведущего и один для ведомого, которые должны перемещаться вместе. Я понимаю, что то, что я отметил ниже, не является полным решением, но требования следующие:
Вот моя базовая конфигурация:
node $id="75463ec2-702c-427b-965b-b7ffb7814008" db1
node $id="a1f2d612-2d9f-4872-bf24-024f5bece3ce" dbslave2
node $id="d1d42f67-e4f2-4c71-950f-07d94ac01f8d" dbslave1
node $id="f243d865-c1a1-4d52-9100-b0d36a08207c" db2
primitive ip_dbmaster ocf:heartbeat:IPaddr2 \
params ip="10.153.114.100" cidr_netmask="24"
primitive ip_dbslave ocf:heartbeat:IPaddr2 \
params ip="10.153.114.101" cidr_netmask="24"
location loc-ip-dbmaster-1 ip_dbmaster \
rule $id="loc-ip-dbmaster-1-rule" 200: #uname eq db1
location loc-ip-dbmaster-2 ip_dbmaster \
rule $id="loc-ip-dbmaster-2-rule" 0: #uname eq db2
location loc-ip-dbmaster-3 ip_dbmaster \
rule $id="loc-ip-dbmaster-3-rule" -inf: #uname eq dbslave2
location loc-ip-dbmaster-4 ip_dbmaster \
rule $id="loc-ip-dbmaster-4-rule" -inf: #uname eq dbslave1
location loc-ip-dbslave-1 ip_dbslave \
rule $id="loc-ip-dbslave-1-rule" 200: #uname eq dbslave1
location loc-ip-dbslave-2 ip_dbslave \
rule $id="loc-ip-dbslave-2-rule" 0: #uname eq dbslave2
location loc-ip-dbslave-3 ip_dbslave \
rule $id="loc-ip-dbslave-3-rule" -inf: #uname eq db1
location loc-ip-dbslave-4 ip_dbslave \
rule $id="loc-ip-dbslave-4-rule" -inf: #uname eq db2
property $id="cib-bootstrap-options" \
dc-version="1.0.8-042548a451fce8400660f6031f4da6f0223dd5dd" \
cluster-infrastructure="Heartbeat" \
expected-quorum-votes="2" \
stonith-enabled="false" \
symmetric-cluster="false"
Пока что №1 и №2 работают просто отлично. # 3 похоже, что это похоже на colocation, но я не могу понять, с чего начать или как установить зависимость. Я вижу движок правил, но еще не совсем понял его. Что касается 4-5, я понятия не имею, можно ли это вообще сделать с помощью кардиостимулятора или мне нужно написать внешний скрипт для обработки этой части.
Моя цель могла бы сделать это:
crm resource move ip_dbmaster db1
и все просто уйти. Я соглашусь на
dbfailover db2
... если мне нужно закодировать что-то из этого внешнего по отношению к кардиостимулятору, или это может быть встроено.
Спасибо за вашу помощь!
Прежде всего, позвольте мне сказать, что я создал довольно много кластеров за последнее десятилетие, и я никогда не видел ни одного, где существовала бы зависимость, как вы описали. Обычно его можно настроить так, чтобы предоставляемые услуги не зависели от того, какой хост активен, а какой - резервный, и вам все равно, какой хост имеет ресурс, пока он работает на одном из них.
Единственный способ, который я могу придумать для реализации того, что вы хотите, - это реализовать подчиненный узел в качестве ресурса, который инициируется главным узлом, например, путем SSH-подключения к подчиненному узлу для запуска IPaddr2 и других необходимых вам ресурсов. Вероятно, используется аутентификация с открытым ключом SSH с файлом идентификации и записью authorized_keys, чтобы мастер мог запускать команды на подчиненном устройстве, не требуя пароля.
Таким образом, для этого потребуется создать сценарий ресурса «slaveIPaddr2», который просто заключит в оболочку такую команду:
HOST=`hostname`
exec ssh -i /path/to/ssh-identity dbslave$${HOST#db} /path/to/IPaddr2 "$@"
Затем измените ресурс ip_dbslave на «slaveIPaddr2» вместо «IPaddr2» в качестве ресурса для запуска.
Что касается сценариев, запускаемых до и после миграции, они в основном звучат так, как будто они будут обычными сценариями с несколькими ресурсами, которые составляют группу ресурсов и приоритет с использованием элементов конфигурации «группа» и «порядок». Например, создание «master_pre» (сценарий «до», который вы хотите запустить на главном сервере), «slave_pre», «master_post» и т. Д. Ресурсов, затем использование «order», чтобы указать, что они выполняются в соответствующем порядке (master_pre, slave_pre, ip_dbmaster, ip_dbslave, master_post, slave_post). Здесь вам также, вероятно, потребуется обернуть подчиненные элементы оболочкой SSH, чтобы эффективно обрабатывать их как единый хост, как я упоминал выше.
Похоже, вы хотите, чтобы сценарий «pre» запускался еще до попытки миграции, а не как часть запуска ресурса? Pacemaker не будет выполнять миграцию службы, если это не указано вами или узел, на котором в данный момент работает служба, не работает. В случае сбоя узла ваша служба все равно не работает, поэтому нет причин проверять, чтобы избежать миграции. Поэтому, если вы обеспокоены предотвращением миграции, когда вы говорите ей о миграции, лучшим ответом может быть создание сценария «миграции», который запускает ваши проверки перед обслуживанием и продолжает выполнение запроса на миграцию только в случае успеха тестов.
Я не знаю, как с помощью кардиостимулятора протестировать другие хосты в кластере перед выполнением миграции, если это то, чего вы пытаетесь достичь с помощью # 4, поэтому, скорее всего, это будет внешняя проверка, которая обеспечивает это .
Запуск других ресурсов, кроме IPaddr2, легко выполняется с помощью директив «group» и «order».