У меня есть пара серверов, настроенных как балансировщики нагрузки / обратные прокси с высокой доступностью. Каждый запускает Ubuntu 12.04 x64 Server, Varnish, Heartbeat и Pacemaker с трафиком балансировки нагрузки Varnish на внутренние серверы.
Если один из балансировщиков нагрузки выходит из строя, Heartbeat / Pacemaker передает группу виртуальных IP-адресов на другой сервер, и поток трафика возобновляется. Этот бит работает нормально.
Я не учел, если Varnish не работает ни на одном сервере. В настоящее время можно остановить Varnish, не вызывая никаких действий со стороны Heartbeat / Pacemaker. Я бы хотел, чтобы отсутствие работающего Varnish на текущем сервере инициировало переход к резервной копии (вместо попытки перезапуска Varnish), но я изо всех сил пытаюсь найти какие-либо рекомендации в Интернете. Кто-нибудь может помочь?
В итоге я получил кое-что, немного отличное от моего первоначального запроса: Pacemaker пытается перезапустить Varnish один раз, и если это не удается, он перемещает все ресурсы на пассивный узел.
Моя установка - это два сервера: serverA (активный) и serverB (пассивный). Я предполагаю, что уровень обмена сообщениями (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 на serverA с двумя виртуальными 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"
Сгруппируйте примитив varnish с виртуальными 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
Установите тайм-аут сбоя. это кажется сделать две вещи:
Дает Pacemaker время для одной попытки перезапуска Varnish перед переходом на пассивный узел.
Предотвращает пометку отказавшего узла как отказавшего через 30 секунд, позволяя переместить на него ресурсы без необходимости вручную запускать лак для очистки ресурсов crm после сбоя. Это хорошо для моей настройки, поскольку у меня нет весов, установленных на узлах, но это может быть очень плохой идеей в другой среде.
sudo crm_attribute --type rsc_defaults --attr-name тайм-аут сбоя --attr-значение 30 секунд
И это все, но см. Ответ Даффа ниже, где есть комментарии о липкости, которые я не использовал. Единственный недостаток, который я вижу, это то, что если вы вручную переведете узел в режим ожидания, Pacemaker отключит Varnish на этом узле, таким образом очистив кеш в памяти. Для меня это не имеет особого значения.
Ваша кластерная архитектура смущает меня, поскольку кажется, что вы запускаете службы, которые должны управляться кластером (например, Varnish), автономно на двух узлах одновременно, и позволять диспетчеру ресурсов кластера (CRM) просто манипулировать IP-адресами.
Чего вы хотите достичь с помощью настройки кластера? Отказоустойчивость? Балансировки нагрузки? Обе? Имейте в виду, я говорю о ресурсах кластера (Varnish, IP-адреса и т. Д.), А не о внутренних серверах, на которые Varnish распределяет нагрузку.
На мой взгляд, вам нужен активно-пассивный двухузловой кластер, обеспечивающий отказоустойчивость. Один узел активен и запускает Varnish, виртуальные IP-адреса и, возможно, другие ресурсы, а другой узел является пассивным и ничего не делает, пока диспетчер ресурсов кластера не переместит ресурсы на пассивный узел, после чего он станет активным. Это проверенная временем архитектура, стара, как само время. Но чтобы это работало, нужно дать CRM полный контроль над ресурсами. Я рекомендую следовать Кластеры с нуля и моделирование вашего кластера после этого.
редактировать после вашего обновленного вопроса: ваш CIB выглядит хорошо, и после того, как вы исправите сценарий инициализации Varnish, чтобы повторные вызовы "start" возвращали 0, вы сможете добавить следующий примитив (настройте таймауты и интервалы по своему вкусу):
primitive p_varnish lsb:varnish \
op monitor interval="10s" timeout="15s" \
op start interval="0" timeout="10s" \
op stop interval="0" timeout="10s"
Не забудьте добавить его в группу балансировщиков (последний элемент в списке):
group balancer eth0_gateway eth1_iceman_slider eth1_iceman_slider_ts \
eth1_iceman_slider_pm eth1_iceman_slider_jy eth1_iceman eth1_slider \
eth1_viper eth1_jester p_varnish
Редактировать 2: Чтобы уменьшить порог миграции, добавьте раздел ресурсов по умолчанию в конце вашего CIB и установите migration-threshold недвижимость на низкое количество. Значение 1 означает, что ресурс будет перенесен после единичного сбоя. Также рекомендуется установить закрепление ресурса, чтобы ресурс, который был перенесен из-за сбоя узла (перезагрузки или выключения), не переносился автоматически обратно позже, когда узел снова станет доступен.
rsc_defaults $id="rsc-options" \
resource-stickiness="100" \
migration-threshold="1"