Мониторинг лака с сердцебиением и кардиостимулятором

У меня есть пара серверов, настроенных как балансировщики нагрузки высокой доступности / обратные прокси. Каждый из них работает с Ubuntu 12.04 x64 Server, Varnish, Heartbeat и Pacemaker, с трафиком балансировки нагрузки Varnish на внутренние серверы.

Если какой-либо из балансировщиков нагрузки падает, Heartbeat/Pacemaker передает группу виртуальных IP-адресов на другой сервер, и поток трафика возобновляется. Этот бит отлично работает.

Чего я не учел, так это того, что Varnish не работает ни на одном из серверов. В настоящее время возможно остановить Varnish без запуска какого-либо действия от Heartbeat/Pacemaker. Я хотел бы, чтобы отсутствие действующего Varnish на текущем сервере вызвало переход к резервной копии (а не попытка перезапустить Varnish), но я изо всех сил пытаюсь найти какое-либо руководство в Интернете. Кто-нибудь может помочь?

Редактировать пост-Дафф помощь:

Я закончил с чем-то немного отличающимся от моего первоначального запроса: Pacemaker пытается перезапустить Varnish один раз, и если это не удается, он перемещает все ресурсы на пассивный узел.

У меня два сервера: сервер A (активный) и сервер B (пассивный). Я предполагаю, что уровень обмена сообщениями (Heartbeat или Corosync) уже настроен и работает. Чтобы Pacemaker мог контролировать Varnish, нам нужно исправить скрипт инициализации Varnish в Ubuntu:

sudo vim /etc/init.d/varnish

Заменить:

--start --quiet --pidfile ${PIDFILE} --exec ${DAEMON} -- \

в функции start_varnish_d() с помощью:

--start --quiet --pidfile ${PIDFILE} --oknodo --exec ${DAEMON} -- \

поэтому он работает в соответствии с правилами, изложенными здесь. Теперь настройте базовый кластер Pacemaker на сервере A с двумя виртуальными IP-адресами:

sudo crm configure property no-quorum-policy=ignore
sudo crm configure property stonith-enabled=false
sudo crm configure primitive virtual_ip_1 ocf:heartbeat:IPaddr params ip="192.168.1.134" nic="eth1" cidr_netmask="24" broadcast="192.168.1.255" op monitor interval="10s" timeout="20s"
sudo crm configure primitive virtual_ip_2 ocf:heartbeat:IPaddr params ip="192.168.1.135" nic="eth1" cidr_netmask="24" broadcast="192.168.1.255" op monitor interval="10s" timeout="20s"

Добавьте примитив для Varnish, обеспечивающий частоту мониторинга и большие временные интервалы для запуска и остановки Varnish:

sudo crm configure primitive varnish lsb:varnish op monitor interval="10s" timeout="20s" op
start interval="0" timeout="15s" op stop interval="0" timeout="15s"

Сгруппируйте примитив лака с виртуальными IP-адресами, чтобы в случае сбоя Pacemaker перенес все ресурсы на пассивный узел:

sudo crm configure group cluster virtual_ip_1 virtual_ip_2 varnish

Установите порог миграции, чтобы Pacemaker допустил два сбоя, прежде чем перенести все ресурсы на пассивный узел. Для Varnish это означает один начальный сбой плюс одну неудачную попытку перезапуска:

sudo crm_attribute --type rsc_defaults --attr-name migration-threshold --attr-value 2

Установите время ожидания сбоя. Это, кажется, делает две вещи:

1. Дает Pacemaker время для одной попытки перезапуска Varnish перед миграцией на пассивный узел.

2. Предотвращает помечать сбойный узел как сбойный через 30 с, позволяя перемещать ресурсы обратно на него без необходимости вручную запускать лак для очистки ресурсов crm после сбоя. Это хорошая вещь для моей установки, так как у меня нет установленных весов на узлах, но это может быть действительно плохой идеей в другой среде.

sudo crm_attribute --type rsc_defaults --attr-name время ожидания сбоя --attr-значение 30 с

И это все, но посмотрите ответ Даффа ниже для комментариев о липкости, которые я в итоге не использовал. Единственный недостаток, который я вижу, это то, что если вы вручную переводите узел в режим ожидания, Pacemaker отключит Varnish на этом узле, очистив кэш в памяти. Для меня это не особенно важно.