Итак, после создания кластера, возникла необходимость в исполнении самописного скрипта на новой мастер ноде при переключении.
Несколько часов гуглежки и страданий нашли это:
Где-то советуют создать отдельный скрипт в /usr/lib/ocf/resource.d/heartbeat/<script_name> и добавить новый ресурс как
pcs resource create ocf:heartbeat:<script_name>
Где-то предлагают создать кастомный ресурс как
crm configure primitive script ocf:heartbeat:<script_name>
Отдельный вид искусства - это совет создать скрипт где угодно и прописывать это в ресурсе.
Все эти советы объединяет один единственный факт: они не работают. Пробовал, ругался, еще раз пробовал. Не работают.
Как сделать правильно
На обеих нодах создаем скрипт:
touch /root/custom_script.sh
Делаем его исполняемым:
chmod +x /root/custom_script.sh
В скрипт для теста добавляем команду создания файла с timestamp:
#!/bin/bash
touch /root/new_file$(date +"%Y-%m-%d_%H-%M-%S").txt
Далее начинается стандартная наша магия с созданием systemd демона:
touch /etc/systemd/system/custom_service.service
С содержанием:
[Unit]
Description=Daemon for pcs resource
[Service]
Type=oneshot
ExecStart=/root/custom_script.sh
RemainAfterExit=yes
Сразу оговоримся: параметр RemainAfterExit нам жизненно необходим, т.к. oneshot systemd service находится в состоянии inactive все время, кроме того, когда работает скрипт, который прописан у него в ExecStart.
Pacemaker'а это максимально не устраивает, он будет ругаться на то, что ресурс на обеих нодах в состоянии failed.
В нашем же случае, демон останется в состоянии active даже после того, как скрипт внутри него отработает:
Создаем новый ресурс pacemaker:
pcs resource create custom systemd:custom_service
И добавляем его в группу:
pcs resource group add NginxBalance custom
Проверяем, что все работает:
pcs status
Выключаем первую ноду и проверяем, что на второй все завелось:
А теперь то, из-за чего я написал этот пост.
Смотрим на папку /root:
Файл создался дважды. А не должен был, так как systemd демон у нас с типом oneshot. По какой-то причине, демон запустился дважды.
А вот по какой:
При выводе systemd-analyze blame мы видим, что наш демон запустился намного раньше, чем nginx. Поскольку в группе ресурсов у кластера прописан четкий порядок, pacemaker запрашивал перезапуск демона custom_service после того, как понимал, что он запустился раньше nginx.
Как это решить:
Удаляем созданный ресурс:
pcs resource delete custom
Создаем его заново:
pcs resource create custom systemd:custom_service
Добавляем в группу, но уже с флагом --before, чтобы он попал на нужное место, перед nginx:
pcs resource group add NginxBalance custom --before nginxres
Проверяем:
pcs status
Перезапускаем вторую ноду, чтобы все ресурсы перенеслись на первую
Проверяем, что наш демон отрабатывает корректно: