Раскопал проблему:
При чтении документации по добавлению ресурса в кластер увидел вот что:
Configuring the Red Hat High Availability Add-On with PacemakerFor example, the following command creates a resource with the name VirtualIP of standard ocf, provider heartbeat, and type IPaddr2. The floating address of this resource is 192.168.0.120, the system will check whether the resource is running every 30 seconds.
1.
# pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.0.120 cidr_netmask=24 op monitor interval=30s
Потом вот такой пример:
Configuring the Red Hat High Availability Add-On with PacemakerIn the following example, there is an existing resource named dummy_resource. This command sets the failure-timeout meta option to 20 seconds, so that the resource can attempt to restart on the same node in 20 seconds.
1.
# pcs resource meta dummy_resource failure-timeout=20s
After executing this command, you can display the values for the resource to verity that failure-timeout=20s is set.
1.
2.
3.
4.
5.
6.
# pcs resource show dummy_resource
Resource: dummy_resource (class=ocf provider=heartbeat type=Dummy)
Meta Attrs: failure-timeout=20s
Operations: start interval=0s timeout=20 (dummy_resource-start-timeout-20)
stop interval=0s timeout=20 (dummy_resource-stop-timeout-20)
monitor interval=10 timeout=20 (dummy_resource-monitor-interval-10)
Из чего сделал вывод, что кластер управляет скриптом посредством команд "start/stop/monitor" и тут же исправил в своем скрипте "status" на "monitor".
Затем в логах corosync наблюдал следующее (выдержки без лишнего трафика):
corosync.logInitiating monitor operation My_application_monitor_0 locally on Node2
Result of monitor operation for My_application on Node2: 7 (not running)
Initiating start operation My_application_start_0 locally on Node2
Result of start operation for My_application on Node2: 0 (ok)
Initiating monitor operation My_application_monitor_30000 locally on Node2
Result of monitor operation for My_application on Node2: 7 (not running)
Initiating stop operation My_application_stop_0 locally on Node2 | action 2
Result of stop operation for My_application on Node2: 0 (ok)
Ну и так далее по кругу. Было очевидно, что monitor возвращает неверный ответ, хотя вручную все работает на урра.
В общем, было принято стратегическое решение "вернуть взад" параметр status вместо monitor и все завелось.
С одной стороны, я, конечно, сам дурак - в спецификации lsb нет никакого monitor. Но вот pacemaker тоже порадовал - и в параметрах команда status обозвана monitor и в логах corosync.
