Вопросы Теги

CentOS 7: PCS Pacemaker Corosync Active / Active HAProxy dependency

Я пытаюсь настроить PCS для HAProxy на CentOS7 в конфигурации активный / активный. Раньше я делал активный / активный, но я не знаком с ограничениями и группы зависимостей.

Пока все хорошо: 

 2 nodes configured
 4 resources configured

 Online: [ HOST1 HOST2 ]

 Full list of resources:

  Clone Set: VIPHA-clone [VIPHA] (unique)
      VIPHA:0     (ocf::heartbeat:IPaddr2):       Started HOST2
      VIPHA:1     (ocf::heartbeat:IPaddr2):       Started HOST1
  Clone Set: haproxy-clone [haproxy]
      Started: [ HOST2 HOST1 ]

Однако теперь я хотел бы добавить ограничение, согласно которому HAPRoxy должен быть запущен, чтобы IP-адрес обслуживался хостом:

pcs ограничение порядка haproxy-clone, затем VIPHA -clone

Проблема в том, что HAProxy никогда не запускается, потому что он не может привязаться к IP, пока он не будет запущен первым.

Как мне настроить это так, чтобы:

  1. ПК переводили IP-адрес на хосте в автономный режим, если проверка работоспособности (т. Е. Запущенный процесс haproxy) завершалась неудачно?

  2. ПК поднимали IP-адрес только при проверке работоспособности (т.е. процесс haproxy запущен) успешно?

    • Если это невозможно, как описано выше, начните в то же время и ведите себя как №1

Я ценю любой ввод. Спасибо!

2
задан 29 October 2018 в 19:45
2 ответа

Если вы не привязаны к кардиостимулятору / corosync, описанное вами поведение может быть достигнуто с помощью opensvc , используя файл конфигурации службы ниже: 

[DEFAULT]
id = 84327b87-13f6-4d32-b90a-a7fad87a8d92
nodes = server1 server2
flex_min_nodes = 2
topology = flex
orchestrate = ha
monitor_action = freezestop

[ip#vip]
ipname@server1 = 192.168.100.240
ipname@server2 = 192.168.100.241
ipdev = br0
monitor = true

[app#haproxy]
type = simple
start = /sbin/haproxy -f /etc/haproxy/haproxy.cfg
restart = 1
monitor = true

Пояснения:

[ПО УМОЛЧАНИЮ раздел - это глобальные настройки конфигурации:

  • id = .... уникальный идентификатор службы, автоматически сгенерированный во время создания службы ( svcmgr -s myservice create , а затем svcmgr -s myservice edit config )

  • nodes = server1 server2 означает, что мы работают 2 узла opensvc , кластер

  • flex_min_nodes = 2 сообщают, что мы ожидаем, что служба запустит как минимум 2 экземпляра. В этом кластере с 2 узлами у нас будет по 1 экземпляру на узел.

  • topology = flex указывает, что мы используем топологию «активный / активный»

  • orchestrate = ha указывает, что служба должна быть автоматически управляемый демоном opensvc

  • monitor_action = freezestop , используется для принудительного действия при выходе из строя критического ресурса (например, сбой или завершение процесса haproxy). Если это произойдет, Демон opensvc должен принять решение. 3 возможных параметра:

    • freezestop : экземпляр локальной службы остановлен и переведен в замороженное состояние.
    • reboot : узел перезагружается.
    • сбой : сбой узла .

[ip # vip] : используется для объявления vip службы:

  • на server1 ip 192.168.100.240 будет настроен на интерфейсе br0 при запуске службы
  • на server2 IP 192.168.100.241 будет настроен на интерфейсе br0 при запуске службы
  • monitor = true сообщает агенту opensvc , что этот ресурс критичен (если он выходит из строя, активируйте службу monitor_action )

[app # haproxy] : описывает материал приложения:

  • type = simple указывает, что служба управляет одним приложением процесса (без разветвленного демона)
  • start = / sbin / haproxy -f /etc/haproxy/haproxy.cfg - это команда, запускаемая, когда запуск службы
  • restart = 1 указывает демону opensvc попытаться перезапустить 1 время этого ресурса, если он выходит из строя.
  • monitor = true haproxy является критическим ресурсом. Если он выходит из строя, попробуйте перезапустить 1 раз из-за предыдущего параметра, а если он не удастся, то активируйте monitor_action

Поскольку служба полагается на vip, вы не обязаны связывать *: 443, а только vip службы.

По поводу вашего вопроса о перезагрузке / stonith, если haproxy выйдет из строя, просто введите restart = 1 в [app # haproxy] , чтобы попробовать перезапуск, и также monitor_action = crash в разделе DEFAULT . Таким образом, выполняется 1 перезапуск, и если это не сработает, узел выходит из строя.

Надеюсь, это поможет.

1
ответ дан 3 December 2019 в 09:56

Я слушаю подстановочный символ в haproxy.cfg

bind *:443

вместо

bind myvip:443

Таким образом, ресурс гапрокси может постоянно запускаться, независимо от того, имеет ли узел VIP ресурс или нет. Если узел получит VIP, то хапрокси немедленно ответит на него.

Очевидным побочным эффектом является то, что хапрокси прослушивает все свои IP адреса, а не только VIP.

Если номер порта конфликтует (например, мне нужен по-другому настроенный порт 443 на другом IP или VIP), я определяю его как bind *:9443, а затем ставлю его за DNAT.

.
3
ответ дан 3 December 2019 в 09:56

Теги

Похожие вопросы